You need enough to satisfy your operational and security-policy requirements. How that translates to an actual number of PED Keys depends on your situation. Here is some guidance.
The basic amount is described in the topic/page "About PED Keys". See also the Cryptoki Roles diagram. How many HSMs do you have?
Do you intend to use common authentication for many Luna HSMs? The authentication secret on a single blue SO PED Key, for example, could be used with as many HSMs as you like. There is no limit. However if you wish to limit the risk of compromise of a common blue PED Key, you will need to have groups of HSMs with a distinct blue PED Key for each
That will tell you the number of groups, and how many different blue PED Keys you need. Now double that number, at least, to allow for off-premises backup copies to be kept in secure storage in case one is lost or damaged. If you have only one blue PED Key for a group of HSMs, and that PED Key is lost or damaged, the HSMs of that group must be re-initialized (all contents lost) and a new blue PED Key imprinted. In most cases, the contents of an HSM are of some value, so at least one backup per blue PED Key should exist.
You (or your organization's security policy) might prefer to have a separate blue SO PED Key - each containing a distinct/unique Security Officer authentication secret - for each HSM in your system. No single blue PED Key can unlock more than one HSM in that scenario. The number of blue keys that you need is the number of HSMs that you have. Now double that number in order to have at least one backup of each blue key.
Does your security policy allow you to trust your personnel? Perhaps you wish to spread the responsibility - and reduce the possibility of unilateral action - by splitting the SO authentication secret, invoking multi-person authentication. Choose the MofN option so that no single blue PED Key is sufficient to unlock an HSM. Two or more blue PED Keys (your choice, up to a maximum of 16 splits of each SO secret) would be needed to access each HSM. Distribute each split to a different person, ensuring that no one person can unlock the HSM.
Having decided that you want (say) three separate people to be present when the SO authenticates to the HSM, you should also allow a few extra splits of that secret, to accommodate accidents, illness, vacations, business travel, or other reasons that would take some key-holders away from the HSM site. Perhaps you settle on two additional splits as sufficient additional key-holders. You have specified M of N equals 3 of 5. Each HSM's SO secret is split into five components, of which any three from that set can combine to reconstitute the SO secret.
Whether you assigned SOs to HSMs on a one-for-one or a group basis (see above), you now multiply that number of SOs by N (the number of splits into which each SO secret is separated). There is no overlap - no split can be part of more than one secret. The number of PED Keys to manage has become significant, especially when you consider that each one (each split of each SO secret) should have at least one backup.
With MofN, you need very good procedures to physically identify and track the various keys.
Each HSM can have multiple partitions. The number depends upon your operational requirement and the number that you purchased, per HSM, up to the product maximum per unit. Each partition requires authentication - a black PED Key.
You have all the same options as described above for the blue SO PED Key(s) - you should have at least one backup per primary black PED Key. That is, you might have multiple partitions, each with a unique authentication secret; therefore each would have a unique PED Key. Or, you might elect to group your partitions under common ownership, so that groups of partitions (on one or more HSMs) might share black PED Keys.
As with the SO secret, you can also elect to split the partition black PED Key secret by invoking the MofN .
Each HSM has a domain. Each HSM partition has a domain. That domain is carried on a red PED Key, and must be shared with another HSM if you wish to clone the HSM content from one to another, for example when making a backup.
Domains must match across partitions for you to clone or back up your partitions, or when assembling HSM partitions into an HA group.
As above, you can make whatever arrangements you wish regarding uniqueness, grouping, MofN (or not), etc., for the red PED Keys.
In addition, you might have orange PED Keys if you are using the , and you might have purple PED Keys if you are using the , and you might have white PED Keys if you invoke the Audit role . In any case, you can invoke MofN, or not, as you choose, which affects the number of orange or purple or white PED keys that you must manage.
Orange Remote PED Keys and white Audit PED Keys can be shared/common among multiple HSMs and PED workstations, if desired, just like all other PED Key colors except purple.
SRK secrets are unique per HSM - they are not shared. A purple PED Key is associated with just one HSM. One additional point to remember about purple PED Keys: you can choose to 're-split' the SRK, which places a new secret on a new purple key (or keys if you invoke MofN), but you cannot overwrite a current purple key for the same HSM. The HSM prevents the imprinting/overwriting of any key that carries the current SRV for the current HSM. This is a safety measure.
If you wished, you could overwrite a purple key (or keys) that held an old version of SRV for the current HSM (from a previous re-split). You could also overwrite a purple key that held a current/valid SRV for a different HSM - which would be a problem for that other HSM. The PED and HSM protect the integrity of the current HSM's current SRK, but have no way of knowing whether purple keys from other HSMs are current. In that latter case, you are given the standard PED warning that you are attempting to overwrite a key with data on it (followed by a second reminder "are you sure?"), but you are not prevented from ignoring that warning (twice).
All other PED Key roles allow you to overwrite any key (any color) with a new secret. A warning is given if a key is not blank, but you have the choice to overwrite, or to pause while you find a blank or .
With all of the above in mind, it is not possible to suggest one "correct" number of PED Keys for your situation. It depends upon the choices that you make at several stages. In all cases, we repeat the recommendation to have at least one backup in case a PED Key (any color) is lost or damaged.