Marin’s Law on Crypto-Agility: Adaptability Determines Survivability

Thesis: Migration time to safer cryptography is inversely proportional to an organization’s crypto-agility.

Formally: Let A denote an organization’s crypto-agility (0 ≤ A ≤ 1) and Y the wall-clock time required to replace a cryptographic primitive across all in-scope systems. Then Y ≈ K ⁄ A for some complexity constant K. As A → 0, Y → ∞.

Corollary: Raising A today shortens all future cryptographic migrations – for quantum threats and for classical breaks, policy shifts, or performance needs.

This is the practical twin to Mosca’s inequality. Where Mosca tells you why time is short, my “law” tells you what to build so time bends in your favor: agility.

Introduction

Sooo, you might be wondering why I’m introducing something grandly dubbed “Marin’s Law.” Well, I’m trying to immortalize myself alongside Moore, Murphy, Brooks or Poe (So I’d appreciate if you start quoting Marin’s Law). But even if that fails, I am serious about the idea behind it. In essence, it’s related to the crucial point I’ve observed: the ease and speed with which you can upgrade to safer cryptography depends directly on how crypto-agile you are. If that sounds abstract, think of it this way: if your organization is nimble in swapping out encryption algorithms, moving to a stronger, safer one is no big deal. If not, well… it can feel like turning “Ever Given” around in Suez.

And if it all sounds a bit too Captain Obvious-y – tell me, is you organization already crypto agile? There you go. We obviously need some simple “principle” to motivate policy makers and decision makers. We can also try: “Yoga for your crypto: the more flexible you are, the less it hurts” or “Friends don’t let friends hard-code ciphers.”

Let me put that in different terms. Crypto-agility basically means having the ability to quickly and seamlessly switch to stronger cryptographic algorithms when the existing ones show weakness. It’s the flexibility to adapt your encryption “on the fly” without breaking everything else. So when I say “migration time to safer cryptography is inversely proportional to an organization’s crypto-agility,” I’m just giving a fancy label to a simple truth: the more agile you are with your cryptography, the less time (and pain) you’ll endure when upgrading to new, stronger safeguards. Conversely, if your systems are rigid and crypto-illiterate (so to speak), even a routine crypto upgrade can turn into a multi-year slog. So my “Law” is a reminder that building in this flexibility now pays off hugely later, especially when a new threat or algorithm shows up and you need to respond yesterday.

Why do I care so much about this? Because I’ve seen first-hand how painful and slow a cryptographic migration can be when crypto-agility is lacking. I’ve worked with organizations where swapping out an encryption algorithm was not a weekend project, it was a multi-year ordeal. Actually, I’ve been working with one organization, on and off, for over ten years! In other words, the technology to replace obsolete encryption was ready, but the organizations were not. And we have multiple examples of that in the past. Organizations simply hadn’t built in the flexibility to quickly drop in a new cipher, so the “temporary” fix became a two-decade fixture. That kind of drawn-out transition is exactly what happens when crypto-agility is missing – upgrading becomes slow, complex, expensive, and frankly, nerve-wracking.

This isn’t just ancient history or theoretical musings; the pattern keeps repeating. When systems aren’t crypto-agile, outdated and even insecure algorithms tend to linger far past their expiration dates, often because ripping them out would break things that are still running. Case in point: the SHA-1 hash function. Even after it was known to be broken and NIST told everyone to stop using it, SHA-1 support hung around for years in various protocols, simply because not all the dependent systems could drop it overnight. It’s actually been declared as cryptographically broken in 2011, but is still widely used today (not sure what for). That’s the nightmare scenario crypto-agility is meant to prevent – being stuck on a sinking ship because it’s too hard to grab a lifeboat.

I care about this because if we don’t get better at crypto-agility, we’ll keep replaying these same incidents, leaving ourselves vulnerable at the worst possible times. And with new threats like quantum computers on the horizon, we simply can’t afford a 20-year cryptographic upgrade cycle anymore. In short, crypto-agility needs to jump from a “nice-to-have someday” to a must-have now. It’s not a dusty best-practice checkbox; it’s quickly becoming a first-order requirement for any organization that wants to survive and thrive in the evolving security landscape. And it is something you can start today, in parallel with your cryptographic inventory (indeed, many organizations recommend exactly that).

Why crypto-agility is now a first-order requirement

1. The standards are here: NIST finalized PQC standards in August 2024. These are the baseline building blocks for post-quantum key establishment and signatures. Organizations no longer need to “wait and see”; the primitives are standardized and on the shelf. 
2. Policy tailwinds are strong: In the U.S., OMB M-23-02 told federal agencies to begin with a prioritized cryptographic inventory and planning – an approach any enterprise can mirror. NSA’s CNSA 2.0 suite sets timelines for National Security Systems and spotlights post-quantum code-signing. Across the Atlantic, ENISA and ETSI publish migration guidance, underscoring that agility and planning, not heroic last-minute swaps, win this race. UK, Canada, Israel, and many others have all published similar guidelines and regulations.
3. Agility is now an official discipline: NIST’s 2025 crypto-agility white paper (CSWP 39, IPD) defines agility as the capability to replace/adapt algorithms in protocols, software, hardware, and infrastructure without disrupting running systems – and calls for concrete mechanisms to achieve it. The NIST NCCoE’s PQC migration project likewise treats agility and discovery as step zero. 
4. It pays off immediately. Agility reduces mean-time-to-remediate for any cryptographic issue: deprecations (e.g., per SP 800-131A), library vulnerabilities, compliance-driven algorithm changes, or jurisdiction-specific requirements. You don’t need a quantum computer on the horizon to harvest these benefits. 

The agility dividend (today, not “when CRQCs arrive”)

• Incident response: If a signature scheme or TLS ciphersuite is downgraded or found brittle, crypto-agile systems swap it with minimal code churn and no service downtime – a capability NIST places at the heart of resilience. 
• Procurement and compliance: An agile stack meets new mandates (e.g., PQC in government contracts, or sectoral profiles) by flipping policy and configuration instead of rewriting applications. (See OMB M-23-02’s inventory/road-mapping model.) 
• Supply-chain clarity: SBOMs extended with CBOM (Cryptography Bill of Materials) expose which apps, devices, and third-party products use which algorithms and key sizes – turning opaque “crypto debt” into a managed portfolio. NIST NCCoE’s SP 1800-38B preliminary draft explicitly prioritizes discovery and CBOM. 
• Future-proofing protocols: IETF work on hybrid and ML-KEM key agreement in TLS 1.3 lets you test PQ-T (post-quantum + traditional) handshakes in controlled environments now, so a production cutover later is boring. 
• Secure release engineering: You can adopt quantum-resistant code-signing today – NIST SP 800-208 (LMS/XMSS) profiles stateful hash-based signatures already recognized in CNSA 2.0 guidance for software and firmware. That’s low-hanging fruit with real risk-reduction now. 

What exactly is “crypto-agility”?

Working definition (aligned to NIST): the capability to replace and adapt cryptographic algorithms across protocols, applications, software, hardware, and infrastructures, without interrupting running systems, while maintaining interoperability. In practice, it’s an architectural property, a combination of governance, interfaces, and tooling, not just a library upgrade. 

Measure what you build (suggested leading indicators):

• CBOM coverage (% of apps/services with machine-readable crypto inventory). 
• Central crypto adoption (% of code paths using approved crypto APIs/services rather than direct calls). 
• TLS 1.3 adoption (% external and internal endpoints). (NIST transition guidance endorses managed deprecations/upgrades.) 
• MTTR-C (mean time to remediate a crypto control change) and policy compliance rate (e.g., SP 800-131A-aligned). 

“No-regrets” moves you can start  today, even without a “quantum budget”

These steps are policy- and architecture-first. They cost time (but not much), and do not cost hardware refreshes.

1. Create a one-page cryptography standard. List allowed algorithms, key sizes, and protocols (e.g., TLS 1.3; deprecate SHA-1; align with SP 800-131A). Publish it internally; make exceptions gated. This alone cuts future migration friction. 
2. Begin a living cryptographic inventory (CBOM). Add a cryptography section to your SBOM process; track algorithms, libraries, key lengths, certificates, and where they’re used. Use the NCCoE discovery workflow as a reference pattern. 
3. Abstract crypto behind stable interfaces. In code, ban direct library calls where possible; route through an internal crypto service provider (JCA/JCE, PKCS #11, KMIP, or a vetted internal wrapper). This is the lever that makes swaps cheap – exactly what NIST means by agility “without disrupting running systems.” 
4. Centralize key management and automate rotation. Consolidate to approved KMS/HSM interfaces and enforce rotation policies. You’ll satisfy today’s audits and be able to flip in PQC keys later without touching apps. (SP 800-131A provides transition patterns.) 
5. Enforce TLS 1.3 by default. Make 1.3 your baseline for internal and external services; capture telemetry on ciphersuite usage. You’ll be aligned with modern protocol ossification-resistant design and ready for hybrid groups. 
6. Pilot PQC where it’s already safe to do so.
   • Code/firmware signing: trial LMS/XMSS (SP 800-208) for internal artifacts and embedded devices. 
   • Non-production TLS: A/B-test hybrid (ECDHE+ML-KEM) handshakes using current IETF drafts to validate operational fit (latency, telemetry, interop). 
7. Bake agility into procurement. Update RFPs and contracts to require: (a) disclosure of a CBOM, (b) documented algorithm-swap procedures and timelines, and (c) roadmap for FIPS 203/204/205 support. (OMB’s posture centers inventory and forward planning; mirror it with vendors.) 
8. Name an owner. Assign a “Head of Cryptography” (role, not necessarily a new hire) accountable for policy, inventory, exceptions, and the cutover plan. NIST’s guidance emphasizes that agility is as much governance as engineering. 

Conclusion

Marin’s Law is a simple lever: raise A to shrink Y. Crypto-agility is the control surface that turns a once-in-a-generation cryptographic transition into a manageable, iterative program – with benefits that land this quarter, not just on Q-day.