Cryptographic key management on AWS, with a key ceremony that survives an audit

It is the formal, witnessed and documented procedure through which a master cryptographic key is generated and its control is split across several people. It happens in a single session, following a script written in advance, with custodians receiving independent fragments or credentials, witnesses attesting to what happened, and minutes everyone signs at the end. Its value is not technical: it is verifiable proof that no single person could ever know the key, and that the control existed from the first minute of that key.

Because the HSM proves the key is protected today, but only the ceremony proves how it was born and who controls it. If the key was generated on an individual laptop and then loaded into the module, the hardware is still flawless and the control is still broken: that person could have copied it. The ceremony answers the questions an auditor, a regulator or the board ask when something goes wrong — who was present, who holds what, how many signatures are required, what happens if someone resigns — and no configuration answers those.

AWS KMS is a managed, multi-tenant service, excellent for encrypting AWS services with minimal operational effort and automatic rotation. AWS CloudHSM gives you dedicated single-tenant hardware modules, validated to FIPS 140-3 Level 3, where you manage crypto users and keys. CloudHSM is chosen when the regulatory framework or the contract requires exclusive custody, demonstrable dual control and an auditable ceremony. They also combine: the KMS custom key store lets services such as S3, EBS or RDS encrypt backed by your keys in CloudHSM.

In CloudHSM, no. AWS keeps a limited credential that lets it monitor cluster health and run encrypted backups, and nothing else: it cannot read key material or perform operations with your keys. HSM user management is yours. That model is precisely what makes exclusive custody defensible in front of a regulator.

The most frequent among our clients are private certificate authorities and internal certificate issuance, digital signing of documents and transactions, encryption of databases and backups with keys under your control, tokenization of sensitive data, and custody of the master keys protecting the rest of the cryptographic hierarchy. The common denominator is the same: keys whose exposure would be a major incident, and whose control you have to be able to demonstrate to a third party.

It depends on purpose and on the framework that applies to you, not on a universal number. Data keys typically rotate more often than master keys, and master keys rotate through a formal ceremony rather than a button. What matters is that an agreed calendar exists, with named owners and a tested procedure: the rotation that was never rehearsed is the one that fails the day you need it.

It is solved by design, not improvisation. From the start we define how many custodians exist and how many signatures are required, so the absence of one neither blocks operations nor exposes the key. We also leave a custodian handover procedure and a rehearsed recovery ceremony, so replacing a person is a planned task rather than a crisis.

Yes, and it is the most common scenario in banking and insurance. If your applications already use PKCS #11, JCE or CNG/KSP, the application-side change is contained. The real work is moving the governance: rebuilding the key hierarchy, redefining custodians and running the ceremony in the new environment with the same formality. We handle it as part of the AWS migration process.

The technical cluster deployment and integration take a few weeks. The timeline is set by governance: agreeing the key policy, appointing custodians and witnesses, aligning Security, Compliance and Internal Audit, and scheduling the ceremony. In regulated projects we typically work within a six to ten week range end to end. Let us talk and we will estimate it on your case.

Signed ceremony minutes from custodians and witnesses, the executed script with any deviations recorded, the role and segregation-of-duties matrix, a key inventory with purpose and lifecycle, the log of sealed envelopes and credentials, CloudTrail records, and the rotation and recovery calendar. It is the package that lets you answer an audit without reconstructing the story from scratch.