Is there any estimate for when updated versions of the [various policies, procedures, etc.](https://www.iana.org/dnssec/procedures) are expected to be published, addressing the changes that are necessary to accommodate the HSM migration? It seems to me that significant parts of the concept need to be reworked. If I understand correctly, today the RKSHs hold a copy of the SMK, which otherwise exists only on (and is exportable from) the HSMs, and is used to allow for the use of the key backup that only exists in the KMFs alongside the HSMs, such that the only scenario in which RKSHs are in play would be some catastrophic event that destroys/tampers all HSMs while not physically destroying the KMFs to the extent that the application backup cards are inaccessible. With the new HSMs seemingly allowing backups exclusively to other HSMs, which presumably would not be any more hardened/less volatile than the main operational ones when it comes to environmental factors, is the RKSH role still relevant? As far as I can tell, the new HSMs don’t have any type of credential that would be required in a backup recovery situation that wouldn’t be similarly required in more mundane scenarios such as normal replacement of HSMs over the lifespan of the keys. Hypothetically there could be dedicated backup HSMs, with CO credentials held exclusively by the RKSHs, but that would seem to not align with the general concepts that seem to underlie the processes in place, which prioritize availability and tamper-*evidence *over strict security (e.g. with the CO credentials themselves all being stored onsite, in order to explicitly allow for forced entry, drilling, etc. when there’s no better option). The only scenario that comes to mind is would be if backup HSMs were introduced that would be stored offsite, outside the KMFs, whereby the RKSHs would provide an additional level of security, but that doesn’t sound particularly likely.