Related · tier-1 reading. For how to migrate before the NIST deadline and stay verifiable, see Post-Quantum.
When NIST deprecates an algorithm or a new mathematical attack surfaces, you cannot afford a 12-month re-architecture. Crypto agility means your cryptographic algorithms are configuration, not code. Switch families, rotate keys, and add new standards without redeploying a single application.
Crypto agility is the architectural property that allows an organization to change cryptographic algorithms, key sizes, protocol parameters, and trust anchors without modifying application code, replacing hardware, or scheduling downtime. In a crypto-agile system, the choice of algorithm is externalized from the applications that consume cryptographic services. Applications call a signing function. Which algorithm executes — Ed25519, ML-DSA-65, FALCON-512, SLH-DSA — is determined by policy, not by compiled code.
This is not a theoretical nicety. It is a survival requirement. The history of cryptography is a history of algorithms being broken. MD5 was considered secure for 15 years before collision attacks made it dangerous. SHA-1 was trusted for two decades before the SHAttered attack demonstrated practical collisions. RSA key sizes that were safe in 2000 are inadequate today. Every algorithm eventually falls, and the organizations that survive are the ones that can rotate without rebuilding.
Post-quantum cryptography makes crypto agility even more urgent. The NIST standardization process selected four algorithms in 2024, but the field is still maturing. NIST has explicitly stated that additional algorithms will be standardized. New attacks against lattice-based schemes are published regularly. The security margins of ML-KEM and ML-DSA are being actively researched. An organization that hard-codes ML-DSA-65 into every application today may need to upgrade to ML-DSA-87 or switch to an entirely different algorithm family within five years.
Without crypto agility, every algorithm change is a migration project. You experienced this with SHA-1 deprecation, which took most large organizations 3-5 years to complete. You experienced it again with TLS 1.0/1.1 deprecation, which required coordinated changes across web servers, load balancers, CDNs, and client applications. Post-quantum migration is larger than both of those combined.
The problem is compounded by uncertainty. NIST has standardized ML-DSA, ML-KEM, SLH-DSA, and FN-DSA. But what happens if a breakthrough reduces the security of lattice-based schemes? What happens if NIST standardizes a code-based or isogeny-based algorithm in the next round? What happens if key sizes need to increase to maintain security margins? An organization without crypto agility faces another multi-year migration for each of these scenarios.
With crypto agility, these scenarios become configuration changes. A new algorithm is added to the API. A policy update rotates active algorithms from ML-DSA-65 to ML-DSA-87. A hybrid mode is enabled to run a new algorithm family alongside existing ones for validation. No code changes. No redeployment. No downtime. The difference between a crypto-agile organization and a static one is the difference between a week-long policy update and a two-year infrastructure replacement.
Crypto agility is not a feature bolted onto H33. It is the foundational architectural decision. Every API call, every attestation, every verification is algorithm-independent by design.
H33's three-key signer uses ML-DSA (MLWE lattices), FALCON (NTRU lattices), and SLH-DSA (stateless hash functions). These rely on three independent mathematical problems. A breakthrough against one family does not weaken the others. Your security is resilient against unknown future attacks because it does not depend on a single mathematical bet.
Change the active signature algorithm, key exchange algorithm, or hash function through an API parameter. No code change. No redeployment. No downtime. The rotation takes effect on the next API call. Previous attestations remain valid and verifiable under their original algorithms because H33-74 attestations record which algorithms were used at creation time.
Run classical and post-quantum algorithms simultaneously on the same data. Ed25519 + ML-DSA for signatures. ECDH + ML-KEM for key exchange. Hybrid mode provides backward compatibility with systems that only understand classical algorithms while adding post-quantum forward security. Drop the classical layer when you are ready, not when a vendor tells you to.
The HATS specification defines how attestations are structured, verified, and replayed, independent of which algorithms produced them. Any HATS-conformant verifier can validate any HATS attestation regardless of algorithm family. This means your verification infrastructure survives algorithm changes without modification.
Every H33-74 attestation records the algorithm family, key identifier, and parameters used at creation. Historical attestations remain verifiable forever because the verification path is encoded in the attestation itself. You never lose the ability to verify old data when you rotate to new algorithms.
H33 uses NIST-standardized algorithms (FIPS 203, 204, 205), not proprietary constructions. The HATS specification is publicly available for independent implementation. You can verify H33 attestations without H33 software. If you ever need to move to a different provider, your cryptographic outputs are portable and independently verifiable.
The practical differences between organizations with hard-coded cryptography and those with algorithm-independent architecture.
| Dimension | Static Cryptography | Crypto-Agile (H33) |
|---|---|---|
| Algorithm Change | Code change + recompile + redeploy + test | API parameter change; immediate |
| Time to Rotate | Weeks to months | Minutes |
| Emergency Response | Emergency patch cycle; high risk of regression | Policy update; zero regression risk |
| Multi-Algorithm Support | Requires parallel codepaths maintained by developers | Built-in; all algorithms available simultaneously |
| Hybrid Mode | Custom engineering for each algorithm pair | API flag; classical + PQ simultaneous |
| Historical Verification | Old algorithms must remain in codebase indefinitely | Algorithm-tagged attestations; self-describing verification |
| Compliance Posture | Algorithm inventory maintained manually; gaps common | Automated algorithm inventory via API telemetry |
| Vendor Lock-In | Tied to specific library or HSM vendor's algorithm support | NIST standards + open HATS specification |
Algorithm changes should be policy decisions, not engineering projects. When NIST revises a standard or a new attack surfaces, the response should take hours, not quarters. Crypto agility makes that possible.
Crypto agility is the ability to switch cryptographic algorithms, key sizes, and protocol parameters without redeploying applications or replacing infrastructure. In a crypto-agile system, algorithms are configuration, not code. When NIST deprecates an algorithm or a new attack surfaces, you change a parameter, not a codebase.
Post-quantum cryptography is still evolving. NIST may revise standards, new attacks may reduce security margins, and additional algorithms will be standardized. Crypto agility ensures your organization can respond to these changes in hours, not months. Without it, every algorithm change requires a full infrastructure migration cycle. See the post-quantum migration guide for the full migration framework.
H33 implements crypto agility through three mechanisms: a multi-algorithm API that supports all NIST PQ standards plus classical algorithms, an algorithm rotation capability that switches active algorithms through API configuration without redeployment, and three independent hardness assumptions (MLWE lattices, NTRU lattices, stateless hash functions) so that no single mathematical breakthrough compromises the system.
Not with H33. The HATS specification is publicly available, and all cryptographic operations produce independently verifiable outputs. You can verify H33 attestations without H33 software. The algorithms used are NIST standards (FIPS 203, 204, 205), not proprietary constructions.
Yes. H33 supports hybrid mode where multiple algorithm families operate simultaneously on the same data. You can run Ed25519 + ML-DSA signatures in parallel, providing both classical backward compatibility and post-quantum forward security. You can also run ML-DSA + FALCON + SLH-DSA simultaneously for maximum resilience across three independent hardness assumptions.
Deploy crypto-agile infrastructure today. Switch algorithms tomorrow without changing a line of code.