TL;DR: A cryptographic module's certification and a witnessed key ceremony are valuable evidence, but they do not identify every key object that later enters production. An assurance review should trace the approved generation process through transformations, storage, public-key extraction, certificate issuance and publication. Independent checks must address both the strength of the generation method and the identity of the final object, while keeping private material inside its protected boundary.
Memorandum to an assurance committee, October 22, 2026. This is an original control proposal for a fictional certificate authority called Harbor Trust. It is not a reconstruction of eMudhra's internal ceremony, an audit opinion or a claim that the proposed controls satisfy every applicable accreditation requirement. The eMudhra incident provides the question; the memorandum develops a separate engineering response.
In its October 21 statement, eMudhra described a ceremony using FIPS 140-2 Level 3 hardware modules and said a wrap/unwrap step produced weak keys alongside original strong keys. It said the weak keys were published and that root-cause work continued. Those are attributed findings from the company, not an independently completed causal analysis. The committee should resist filling gaps in that account with guesses about a vendor, command or operator.
Decision requested: approve an evidence chain, not a ceremony photograph
Harbor Trust's current approval packet contains a signed attendance sheet, a hardware inventory, a procedure version and a recording of a ceremony. Those records can establish who participated and what procedure was intended. They do not automatically establish that the public key in the final certificate corresponds to the approved object throughout every intervening step.
The proposed change makes that relationship explicit. The packet must identify the generated key object, every authorized transformation or transfer, the public key extracted for certification, the resulting certificate and the material submitted for trust-program review. Each transition has an expected relationship that another reviewer can check without receiving the private key.
The committee is not being asked to replace cryptographic expertise with paperwork. It is being asked to require evidence at the points where a correct component can be connected incorrectly to another correct component. A strong key generated in one object does not protect a certificate that accidentally refers to a different object. A completed ceremony is therefore the beginning of an assurance chain, not its final conclusion.
The proposal also defines a stopping condition. If the relationship between two artifacts cannot be established, the process pauses before publication. The team does not resolve the discrepancy by choosing whichever object allows the schedule to continue. Unexplained identity differences in high-authority cryptographic material deserve investigation before that authority is delegated to the wider ecosystem.
Exhibit one: claims and evidence are different columns
| Claim to approve | Evidence that can support it | Evidence that is insufficient alone |
|---|---|---|
| The generation method is appropriate | Reviewed algorithm, randomness design and approved operating procedure | A long-looking public key |
| The intended module and mode were used | Identified hardware, firmware, configuration and relevant validation scope | A vendor logo in a presentation |
| The certified key is the approved object | Public-key identity records across the actual workflow | A ceremony attendance sheet |
| Only authorized operations occurred | Controlled access, operation records and independent reconciliation | A successful test signature by itself |
| Publication matches approval | Comparison of released certificate material with approved artifacts | A successful upload response |
The table does not promise that any one record is impossible to forge or that an auditor can infer all properties from public output. Its value is in preventing evidence for one proposition from being reused silently as evidence for another. The same packet may support several claims, but each claim needs an explicit reasoning path.
Harbor's reviewers record the scope and limitations of every item. An operation log can be useful while depending on the system that produced it. A witness can confirm an observed step without understanding every cryptographic implication. A test can establish a relationship for one input without proving the strength of the generation process. Assurance becomes stronger when those boundaries are visible.
This also helps budget independent work. The committee can ask where a second implementation, separate reviewer or external specialist would reduce a meaningful shared failure mode. Repeating the same check through the same code path may increase confidence in reproducibility while adding little independence. The review should say which kind of evidence it is buying.
Generation quality cannot be read from the certificate's length
A public key can have the expected encoding and algorithm identifier while the process that selected its secret was defective. The apparent size of the mathematical domain is different from the unpredictability of the actual generation process. A large space offers little protection if the implementation chooses from a tiny, predictable subset of it.
NIST SP 800-133 Revision 2 addresses cryptographic key generation, while SP 800-90B addresses entropy sources used for random-bit generation. Harbor uses those publications to frame the relevant technical questions. It does not infer compliance merely because a product description contains the word random or because a single output passes a superficial statistical test.
The generation review needs to understand where uncertainty enters the system, how it is processed and which operations can replace, truncate or misinterpret the resulting material. These are design and implementation questions. Looking at one public certificate cannot recover the complete history of its secret-generation process.
A simple non-cryptographic analogy helps the committee distinguish the concepts. Printing a six-digit ticket number does not mean a drawing had one million possible outcomes if the ticket machine always selected from ten predetermined values. The display format says how the result is represented. The selection process determines what an observer could predict. The analogy does not provide a method for attacking a real key; it illustrates why representation and generation evidence answer different questions.
Harbor therefore prohibits an assurance statement such as “the key is long, so the ceremony was secure.” It requires a reviewed process and evidence that the intended process produced the object being approved. Specialized tests can detect particular classes of bad output, but their limitations must remain explicit. Passing known checks is not a proof that no unknown defect exists.
Module assurance has a boundary that the deployment must preserve
Cryptographic module validation evaluates a defined product and security boundary under specified conditions. FIPS 140-3 is the current standard referenced here for module-security requirements; eMudhra's incident statement specifically referred to FIPS 140-2 devices. Harbor should not conflate the two references or assume that a standard's name describes every aspect of a deployed workflow.
The procurement review records the exact module, firmware, operating mode and relevant security policy. It then asks which parts of the ceremony occur inside that boundary and which occur in surrounding software or human procedures. A script that chooses an object identifier, a tool that transforms an encoding and a service that publishes a certificate may lie outside the module's evaluated behavior.
That does not make the module's assurance useless. It makes integration evidence necessary. A protected signing operation can still be applied to the wrong request. A securely stored object can still be the wrong object for a certificate. The committee should preserve confidence in the properties actually supported while investigating the connections between components.
Harbor also tracks changes after approval. Firmware updates, replacement devices, altered scripts and new backup processes can change the relevant assumptions. The evidence chain should identify which changes require revalidation of the workflow. A ceremony approved years ago cannot automatically cover a materially different recovery or migration procedure introduced later.
The owner of the overall system remains responsible for these boundaries. Pointing to a hardware certificate cannot transfer every integration decision to the hardware supplier. Conversely, an integration failure should not be described as a demonstrated failure of the module's cryptographic algorithm without evidence supporting that conclusion.
Every transformation needs a named invariant
Harbor's proposed record follows the key through generation, protected storage, authorized backup or transfer, public-key extraction and certificate construction. At each step, the reviewer states what must remain true. The exact implementation depends on the technology and policy; this memorandum does not prescribe a generic export procedure for high-value private keys.
For a protected transfer, the expected invariant may be that the destination object represents the same approved key and retains the required usage restrictions. For public-key extraction, it is that the extracted public material corresponds to the intended private object. For certificate construction, it is that the approved public key and constraints appear in the final signed certificate. The invariant should be concrete enough that a failed comparison has an unambiguous consequence.
Object labels are helpful but insufficient by themselves. A label can be reused, mistyped or associated with an unexpected object after restoration. Harbor combines labels with public-key identity and the system's supported object-identification mechanisms. The records should make accidental substitution detectable without requiring anyone to reveal the secret scalar or other private material.
The review includes error paths. What happens if a transformation reports partial success? Can a retry create another object under the same label? Does a recovery script choose the newest object or the first matching one? These questions concern ordinary workflow ambiguity, not a claim about the actual eMudhra defect. They are worth resolving before an emergency creates pressure to improvise.
A transition that fails its invariant is quarantined from publication. The team preserves the relevant public artifacts and logs, restricts further use as appropriate and obtains specialist review. Repeating the operation until a test passes can destroy the evidence needed to understand why the earlier result differed.
Pairwise consistency helps, but it answers a bounded question
A controlled signature-and-verification check can help establish that an identified private object and a public key correspond. That is valuable evidence for object identity. It does not, by itself, establish that the private key was selected unpredictably. A weak but mathematically consistent key can still produce a valid signature.
Harbor's acceptance record therefore separates consistency checks from generation assurance. The reviewer signs off on each independently. If the process produced an easily predictable key, a successful signature test should not be allowed to conceal that defect under a broad label such as “cryptographic validation passed.” The test name should describe what was actually tested.
The same discipline applies to format validation. Parsing a certificate successfully establishes something about its representation. Verifying the issuer's signature establishes something about the signed data and issuer key. Evaluating constraints establishes another property. These checks complement one another, but none should be inflated into a universal claim about the entire ceremony.
Independent tooling can help detect an implementation-specific mistake, provided the tools do not share the same relevant defect. Harbor documents the reason for choosing an independent implementation and the exact artifacts supplied to it. The objective is not a ceremonial second green checkmark. It is a meaningful reduction in the chance that one mistaken interpretation passes through every approval stage.
Publication is a release that needs its own review
The committee has historically focused on generating the key and issuing the certificate. The proposed process adds a final comparison at publication. The material submitted to repositories, auditors and trust programs must match the approved certificate identity and intended usage. A correct internal artifact is not sufficient if a different one is distributed.
Harbor prepares a public release manifest containing certificate fingerprints, public-key identifiers, intended roles and approval references. The manifest contains no private key material. Another reviewer compares the actual published artifacts with that manifest using a separate retrieval path. This checks the result consumers will see, rather than only the file the publishing operator intended to upload.
The process also covers cross-signs and related representations. Different certificates can contain the same public key while having different issuers or constraints. The inventory should preserve both certificate identity and key identity. Otherwise reviewers can miss that several public artifacts delegate authority to the same underlying key, or mistakenly treat each certificate as a wholly independent secret.
Changes after publication enter the same controlled record. Reissuance, replacement and removal need traceable reasons and a clear relationship to prior artifacts. An emergency correction should not leave several plausible versions in circulation with no authoritative explanation of which one consumers should use.
The committee requires an owner for external coordination. A key problem can affect relying parties beyond Harbor's direct customers. The release manifest and contact records should make it possible to identify who needs timely information without reconstructing the certificate estate from scattered emails during a crisis.
The audit sample should follow the ways the process can fail
Harbor cannot improve assurance simply by adding more screenshots to every packet. It needs tests and review coverage aimed at plausible failure modes. The proposed audit plan follows identity changes, boundary crossings and exceptional operations because those are places where intended and actual behavior can diverge.
The plan includes a normal ceremony, a controlled recovery exercise, an interrupted operation and a rejected publication attempt using deliberately mismatched public test artifacts. These exercises use non-production material under an approved test procedure. Their purpose is to establish that controls detect and contain errors, not to experiment on active public-trust keys.
The reviewer asks whether the workflow stops at the correct point, preserves useful evidence and prevents an unapproved object from reaching publication. A warning that operators routinely ignore is weaker than a control with a defined stop condition and escalation route. The audit should observe behavior under a realistic error rather than only confirm that a policy document says errors are prohibited.
Sampling also needs a rationale. If a new transformation tool is introduced, testing only ceremonies performed before that change will miss the relevant risk. If recovery is rare but powerful, excluding it because no incident occurred during the audit period leaves an important route unexplored. Coverage should follow the system's authority and failure opportunities, not only the frequency of routine operations.
The resulting report distinguishes direct observations, sampled evidence and untested assumptions. That makes it possible for the committee to accept a bounded conclusion or request further work. An assurance statement becomes less useful when its wording is broader than the activities that produced it.
Recovery and retirement are part of key generation's promise
A key does not remain forever in the state created during its first ceremony. It can be backed up, restored, moved, disabled and eventually destroyed according to the system's policy. NIST SP 800-57 Part 1 Revision 5 provides a general key-management framework for considering that lifecycle. Harbor's control proposal follows the object through those later states rather than treating generation as the only moment that matters.
A recovery exercise must establish that the restored object is the intended one and has the appropriate authority. It also needs to account for copies and access paths that remain after recovery. An emergency process that creates an untracked duplicate can complicate later revocation or destruction even if the recovered service works correctly.
Retirement records distinguish disabling use from proving that all authorized copies were handled according to policy. The committee should avoid promising more certainty than the storage and backup architecture can support. What matters is an explicit account of the relevant copies, their controls and the evidence for the chosen retirement action.
The lifecycle view also changes incident preparation. If a problem is found, Harbor needs to identify every certificate and delegation associated with the key, the consumers that may rely on them and the supported routes for communicating distrust. That inventory should already exist. Building it during an emergency consumes time that relying parties may not have.
Two approvals need two meaningful opportunities to disagree
Harbor already requires two people to approve a ceremony. The proposal asks what each person can independently observe and reject. If the second approver sees only the first operator's summary, the process has two signatures but a single evidentiary route. The second person needs access to the relevant public artifacts, expected identities and procedure state in time to detect a discrepancy before publication.
The roles can be complementary. One specialist may review the cryptographic process and module assumptions, while another verifies the artifact relationships and release manifest. Neither should be required to claim expertise outside their competence. Their approvals name the propositions they checked, and unresolved questions go to an appropriate specialist rather than being averaged into a collective yes.
The workflow also protects dissent from scheduling pressure. An approver who finds an unexpected public-key identity must have a supported way to stop the release, preserve evidence and request review. The ceremony owner should not be able to replace that approver merely because a customer deadline is close. Any substitution needs a recorded reason and a new reviewer with equivalent access to the evidence.
This control is valuable because mistakes often become visible to someone other than the person performing the step. It does not imply that two-person control proves randomness quality or prevents every malicious act. It creates a practical opportunity for an independent observation to change the outcome while the decision is still reversible. The committee should evaluate that opportunity through exercises, including a deliberate mismatch in non-production test material, rather than counting signatures alone.
Resources requested and the evidence they buy
The memorandum asks for engineering time to map the workflow, specialist time to review generation and transformation assumptions, and operational time to exercise failure and recovery paths. These are distinct activities. Assigning them all to a single ceremony witness would create an unrealistic expectation of expertise and independence.
Harbor measures the work by completed evidence relationships rather than pages produced. The committee wants to know whether every published key can be traced to an approved object, whether every authorized transformation has a checked invariant and whether the process stops on a meaningful mismatch. A hundred-page packet that cannot answer those questions is not preferable to a concise record that can.
The proposal also reserves capacity for correction. A review that discovers a real ambiguity must be able to delay publication and fund the necessary investigation. If the schedule treats every finding as an administrative inconvenience, additional controls will tend to become ceremonial. The governance mechanism has to support the technical stop condition it claims to require.
Harbor will report unresolved assumptions explicitly. The committee can then decide whether to narrow the release scope, obtain independent expertise or postpone the ceremony. That decision is more responsible than converting an unknown into a green status because the event has already been announced.
Approval language for the committee
The proposed approval states that named artifacts were produced through a reviewed process, that specified identity relationships were checked, and that the evidence supports the declared use under the documented assumptions. It does not state that a certification badge proves the entire surrounding system cannot fail.
The eMudhra disclosure is a reason to scrutinize those surrounding relationships carefully. Its final root cause should be established through the relevant investigation, not invented in an explanatory article. The transferable lesson is already concrete: assurance must reach the object that actually receives and exercises public authority. A strong component, a careful ceremony and an approved procedure create value when the deployed result can be traced back to them.