1. A signature is only as good as its key

Every guarantee in a Never Trust system — request integrity, caller identity, non-repudiation, tamper-evidence — reduces to one fact: a private key produced a value that an attacker could not have produced. If that key can be extracted, every guarantee built on it collapses at once, silently, and retroactively. Key custody is therefore not one control among many; it is the root of trust the entire pipeline inherits.

The only durable answer is to ensure the key material never exists in extractable form anywhere the application runs. It is generated inside a hardware security module (HSM), never leaves the cryptographic boundary, and is exercised only by asking the module to perform an operation on the application’s behalf. NIST’s key-management guidance (SP 800-57) treats the protection of private and secret keys as the precondition for every other assurance; FIPS 140-3 is how that protection is independently validated.

2. What FIPS 140-3 Level 3 actually buys

FIPS 140-3 is the joint U.S./Canadian standard for cryptographic modules (it incorporates ISO/IEC 19790 and is tested under the NIST/CCCS CMVP). It defines four ascending assurance levels across eleven requirement areas — module specification, interfaces, roles and authentication, the finite-state model, physical security, the operating environment, key management, self-tests, and more. Level 3 is the bar serious key custody targets. Over Level 2 it adds, materially:

• Identity-based operator authentication — each operator and role is individually authenticated, not merely authorized by a shared role secret, so actions are attributable;
• Tamper detection and response — physical intrusion triggers active zeroization of plaintext keys and critical security parameters, rather than merely leaving evidence of tampering (the Level 2 bar);
• Identity separation of critical parameters — the interfaces that input or output keys and CSPs are physically or logically separated from all other ports, and plaintext CSPs are entered/output only through a trusted path;
• Environmental failure protection for keys against out-of-range voltage and temperature.

The practical payoff is independent assurance that the module resists software extraction and a meaningful class of physical attack — the difference between “we encrypt the key at rest” and “the key has no extractable plaintext form, ever.” Level 4 raises the physical bar further (envelope-level tamper response); Level 3 is the point on the curve where assurance is high and operational cost stays reasonable for a multi-tenant financial platform.

3. Single-tenant Managed HSM, attested

B5 Secure places signing keys in an Azure Key Vault Managed HSM — a single-tenant, fully managed pool of FIPS 140-3 Level 3-validated hardware, not a shared multi-tenant vault. The hardware boundary is dedicated to your keys, and even the cloud operator is cryptographically excluded from them: the Managed HSM security domain is generated under a quorum of customer-held keys (see Multi-Person Control), so Microsoft cannot recover key material on your behalf.

Provenance is not taken on faith. Key attestation produces a signed statement, chained to the vendor’s roots, that a given key was generated and resides inside the validated boundary and is non-exportable. That converts “trust us” into verifiable evidence an auditor or counterparty can check independently — the same posture as bring-your-own-key / hold-your-own-key custody, without the operational burden of running the metal yourself.

4. Sign by reference — the calling convention

In B5 Secure the signing key is a reference, never a value. The pipeline resolves its primitives through a provider (the crypto-agility property covered in Confidential by Default) and binds the key source to the Managed HSM. No code path materializes the private key:

// Keys resolved by reference; nothing private enters process memory
services.AddB5SecurityKit(o => {
  o.Keys.Source    = KeySource.AzureManagedHsm;   // FIPS 140-3 L3, single-tenant
  o.Keys.Reference = "hsm://b5-signing/req-signing-2026";
  o.Signing.Algorithm = HmacAlg.HmacSha384;        // SHA-2 family, swappable
  o.Keys.RequireAttestation = true;             // fail closed if provenance can't be proven
});

The HSM round-trip adds latency — single-digit milliseconds per operation against a Managed HSM — which is why B5 Secure reserves hardware signing for the operations that warrant it (request-signing keys, service identities, key-encryption keys) and lets higher-volume symmetric work use keys wrapped by an HSM-resident key-encryption key. Throughput scales with the partition count of the dedicated pool, not with application instances.

5. Post-quantum keys, same boundary

Crypto-agility is a custody property as much as an algorithm one. As the signing primitive migrates from classical ECDSA/HMAC toward ML-DSA (FIPS 204) under the 2026 profile, the keys for the new primitive are generated and held in the same validated boundary — the calling convention does not change, only the resolved algorithm does. That keeps the “harvest-now, decrypt-later” exposure window from ever touching extractable key material, and aligns long-lived signing keys with the CNSA 2.0 transition timeline rather than stranding them on classical curves.

6. What an attacker actually gets

Model the worst realistic case: an attacker achieves remote code execution inside the application. Because no private key is ever in process, they do not get the key. What they get is a signing oracle — the ability to ask the HSM to sign while the foothold lasts — which is a bounded, observable, and revocable capability, not a permanent compromise:

• Bounded — the application can only request the operations its identity is permitted; least privilege (B5 ADA) limits what can even be asked for;
• Observable — every signing call is logged at the HSM and the pipeline, so anomalous volume or timing surfaces in monitoring;
• Revocable — suspension and key rotation cut the oracle off immediately, and nothing the attacker captured remains usable once the key is rotated;
• Non-retroactive — prior signatures stay valid and attributable; the attacker cannot forge history because they never held the key.

7. Where this lands in an audit

Hardware-rooted, attested key custody is the evidence auditors look for, and it maps cleanly onto the controls counterparties test: FIPS 140-3 Level 3 validation for the module itself; SOC 2 (CC6.1 logical access, CC6.7 cryptographic controls) for how keys are provisioned and used; and PCI DSS Requirement 3 for the HSM-backed protection and key-management lifecycle where cardholder-adjacent data is in scope. Because provenance is attestable, the control is demonstrable on demand rather than asserted in a policy document — which is the difference between passing an audit and surviving a forensic review.