General comments on the timeline: 1) At this point you've defined a process which will have steady state of 2 keys in the trust anchor set for about 2/3s of the period.   An emergency key revocation is possible during that period of time.   The other 1/3 of the time, you have no standby key available.   Why not just go ahead and do what 5011 recommends you do and add a third key?   If there is a size issue, adding an EC key as the third key allows you to get a head start on algorithm rollover.  (Last sentence of 2.5 is incorrect "requiring changes ... more often" - you can keep the same schedule, the keys just stick around a bit longer). 2) The period of three years is tied to the active period of a key, rather than to a specific roll-over (e.g. Key N+1 replacing Key N).   The operational plan needs to consider whether any delays in taking a key out of service will violate general cryptographic guidance.  Make sure that you're following both the guidance for key lifetime, and any sunset provisions for key strength that show up in the meantime.  E.g. NIST SP 800-57Pt1, table 4 sunsets RSA2048 as of 2031 - or roughly at the beginning of the 4th key rollover if this schedule is followed. 3) As a consequence of the three year period, there is approximately 1.75 years between major HSM actions (e.g. key generation and revocation - the period D).  Loss of skills by the HSM operators during the long period need to be considered. 4) There is no real reason to have the standby key present on the HSM after generation until it's ready to start signing stuff.  I'm assuming that the AEP has a backup mechanism for generated keys that's used between HSM operations (which is pretty obvious as both HSMs must share a storage master key to allow for key copying). 5) G and H - Assuming that there is a backup mechanism for the HSMs, simply deleting the keys from the HSM won't necessarily cause them to be destroyed if any backups were made.  Both HSMs must go through an update for the Storage Master Key to complete the deletion of the key material. 6) Consider other mechanisms for co-generation of the private key on two different HSMs as opposed to generate/export/import current model.   For example    HSM A -> Genkeypair -> ECDH Ka1, HSM B -> Genkeypair -> Kb1.     HSMA ECDH (Ka1.private, Kb1.public) -> KDF() -> either RSA gen seed or EC private key.      The use of ECDH gets the same secret on both HSMs without the need to move sensitive information out of the HSM, even in an encrypted form.   The shared secret can be fed into a KDF to generate an EC private key, which can then be used to generate a public key from the private one.   If you're doing RSA key pair generation, use the shared secret as a seed to a PRNG which is used in turn to generate the RSA key pairs. 7) Would it help if I made an errata for RFC5011 "In section 5, 'Missing' state, delete 'This is an abnormal state'"? Mike StJohns, NthPermutation Security