Security Ceremonies: Why Secure Systems Are More Than Math

A security protocol that ignores its human participants is an incomplete protocol. That is the central argument of Carl Ellison’s 2007 paper, Ceremony Design and Analysis.¹ While the term ceremony was coined earlier by Jesse Walker of Intel,² Ellison gave it analytical force where operators, witnesses, and physical interactions are part of the protocol, not peripheral to it. They deserve explicit design and analysis with a level of rigour similar to that applied to technical protocol work.

In PKI and infrastructure contexts, one often encounters the narrower term key ceremony, referring specifically to procedures around generating, loading, rotating, or retiring cryptographic keys.³ Both terms are used throughout this blog, though I am inclined towards security ceremony because it better captures the essence of these procedures.

Looking beyond cryptography and hardware

Cryptography solves a specific problem: it makes it mathematically hard to forge a signature or read a message without the right key. Hardware security modules solve an adjacent problem: they make it physically hard to extract a key from a tamper-resistant device. However, neither solves the broader problem of proving that the right actions happened, in the presence of the right people, under the right conditions. This raises further questions: Who authorised this key to be generated? Who was in the room? Was the device the one expected; unmodified and unsealed? Was the process fully followed, or were steps skipped under time pressure? Could anyone have coerced the operator?

These questions do not have mathematical answers. Rather, they require human attestation, role separation, and evidence to prove that the procedure was actually followed.

In addition, there is a deeper issue: security policy cannot be built into equipment alone; people define the conditions of use. A device, however secure, can only enforce a policy humans have communicated to it. That handover, whether treated as one or not, “can never be a pure protocol and therefore must always be a ceremony,”¹ as Ellison puts it. These human steps are not superfluous; they address the questions that cryptography cannot, and demonstrate how security policy is made real.

What is a ceremony?

A ceremony is more than running a script. It includes the people, channels, and records required to make sensitive operations trustworthy and reviewable.

What a ceremony produces is not only an outcome, but also evidence: who was present, what was done, and what each participant attests to.

These procedures are ritual-like: they are repeated, structured interactions through which people and systems perform prescribed actions in a particular order.⁴ That structure matters because ceremonies are carried out by people, not idealised actors. In practice, this means explicit roles for operators, witnesses, and auditors, along with scripted steps, logged actions, and signed attestations. Every decision should be traceable. Every participant should be accountable.

A ceremony must also account for something that protocol design often abstracts away: humans do not behave like machines. People get tired, skip checks, interpret instructions differently, and optimise for speed under pressure. A well-designed ceremony does not depend solely on diligence. Rather, it allows us to reduce ambiguity, constrain unsafe choices, and leave a record that can be reviewed afterwards.

The IANA DNSSEC root zone signing ceremony is the most visible example of this practice. It is held quarterly in secure facilities on both US coasts, involves cryptographic officers and recovery key shareholders, and is livestreamed for public scrutiny.⁵ This is not because the cryptography requires it, but because the trust model does.⁶

Remember, the purpose of a ceremony is to establish trust, not to manage technical difficulty.

The origins

By the time the concept was formally defined in 2007, the practice was already decades old. The rise of PKI in the 1990s and the need to bootstrap root certificate authorities created a practical necessity: organisations had to prove, to auditors as well as to each other, that their most sensitive keys were generated correctly and never exposed.⁷ Informal procedures were written down, roles were assigned, and witnesses were invited.

The DNSSEC root zone signing ceremony, institutionalised around 2010, became the most visible public expression of this approach.⁵ But dual custody, chain of evidence, and witnessed handoffs are older than computing itself. By 1981, NSA documentation was already describing long-established practices such as scheduled key changes, strict key-handling procedures, and formal controls around the storage and distribution of key material.⁸ These practices existed more as operational craft than as first-class system design.

The industry has now learned to take ceremonies seriously, but still lacks simple, reusable ways to describe them, execute them, and review what actually happened.

This is where Rite steps in.