up:: Migration Architecture MOC

The Agility Test

The agility test is a per-system, operational, binary question, put to the team that owns each priority system in a post-quantum migration: “can we change the cryptographic algorithm this system uses by changing its configuration, without recompiling or redeploying the application? Not in theory. On this system, today.” A yes puts the system in the fast lane, where migration is a setting and a test. A no marks one of the systems that define the program, because each no is a code rewrite, a vendor conversation, or a piece of firmware on a multi-year replacement cycle. The test measures the one property, crypto-agility, that decides more of a migration’s cost than any other, and it measures it the only way that holds up: on the running system, in the present tense, with the owning team answering for it.

The short version:

• The test is one question per system: can we change the cryptographic algorithm this system uses by changing its configuration, without recompiling or redeploying the application? Not in theory. On this system, today.
• Yes means the fast lane. The system migrates with a setting and a test.
• No means the system helps define the program, because a no is a code rewrite, a vendor conversation, or a firmware replacement cycle, and each of those has its own clock.
• The application rule rides inside the test: assess to price, never to gate. The urgent systems migrate whether they’re agile or not.
• The output is your priority list split in two: the systems agility makes cheap, and the systems whose rigidity is the real budget.

Think of a mechanic writing an estimate. Before quoting the repair, she checks one thing about each part on the work order: does it bolt on, or is it welded in? The bolted parts are an hour of labor each. The welded ones are the quote, because reaching them means cutting, and cutting means the job stops being a parts swap and becomes fabrication. She runs that check before pricing anything, and she’d never refuse to fix the brakes until every welded part had been converted to bolts. The agility test is the same walk down the work order, asked of cryptography.

What is the agility test?

The agility test is one question, asked system by system, and every clause in the wording is doing work.

1. “Can we change the cryptographic algorithm this system uses” scopes the question to the algorithm itself, the thing the post-quantum transition actually replaces. Swapping RSA key transport for ML-KEM, or an ECDSA certificate chain for ML-DSA, is the move the question is rehearsing.
2. “By changing its configuration” names the mechanism. The algorithm choice has to live somewhere an operator can reach: a policy file, a TLS group list, a KMS key spec, a provider registration. A config reload or a service restart still counts as configuration. A new build artifact does not.
3. “Without recompiling or redeploying the application” is the disqualifier. If the path to a new algorithm runs through source code, a build pipeline, and a release, the system fails the test, whatever its components claim on a datasheet.
4. “Not in theory. On this system, today.” kills the 3 answers that usually arrive instead of evidence: the datasheet, the roadmap, and the reference architecture. The question is about this deployed instance, in its current state, answered by the people who would actually make the change.

Ask it of the owning team rather than the vendor or the architecture diagram, because the owning team is the only party whose answer is falsifiable this week. The test is binary on purpose. “Partially agile” and “agile in the next version” both resolve to no for pricing purposes, and pricing is what the test is for.

The test operationalizes the definition of crypto-agility, the architectural property of keeping algorithm choice in configuration rather than baked into the build. That note covers the property itself, the design patterns that produce it, and what it does and does not guarantee. This note covers the instrument that measures it.

Why is configuration change the line?

Because configuration-changeability is where the three real cryptographic architectures separate, and it’s the only line an owner can verify without a research project.

1. Provider and abstraction architectures pass. When applications call a generic operation (sign, encrypt, a TLS library’s negotiation) and a provider layer resolves the actual algorithm from policy at runtime, the algorithm genuinely lives in configuration. In a 2026 banking proof-of-concept, moving a Java API gateway to hybrid post-quantum TLS required registering the BouncyCastle post-quantum provider at application startup and nothing else; the TLS configuration naming the hybrid key-exchange group did the rest, and the application code never changed. That’s what a yes looks like when it’s real.

Source: Balaji et al., “Operationalising Post-Quantum TLS,” arXiv:2605.17955 (2026).

2. Library-linked applications usually fail, and this is the trap. An application can link a cryptographic library that fully supports ML-KEM and still fail the test, because the application names its algorithms at the call sites: an RSA_sign call here, a hardcoded cipher-suite string there, a key size passed as a literal. Upgrading the library changes what the system could run. Changing what it does run means editing every call site, which is a recompile and a redeploy, which is a no. The library is capability; the call sites are the decision, and the test asks about the decision.

3. Hardcoded and embedded choices fail outright. Systems that bake the algorithm into application logic, stored data formats, protocol framing, or device firmware have moved the choice somewhere no configuration can reach. For those, the change is redevelopment or hardware replacement, and the test’s job is to say so before the budget assumes otherwise.

The line also has a decade of engineering doctrine behind it. The IETF’s algorithm-agility guidance, BCP 201, is Best Current Practice and “provides guidelines to ensure that protocols have the ability to migrate from one mandatory-to-implement algorithm suite to another”; its normative requirement is narrower, that a protocol “MUST include a mechanism to identify the algorithm or suite that is being used”, which is exactly the property the test checks for at the deployment level rather than the specification level. NIST’s own crypto-agility publication, CSWP 39upd1, surveys approaches to achieving the property across protocols, applications, hardware, and firmware without publishing an instrument for checking it per system. The test is that instrument: the deployment-level question the guidance implies and never quite asks.

Source: R. Housley, “Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms,” RFC 7696 / BCP 201, November 2015, rfc-editor.org/info/rfc7696; NIST CSWP 39upd1, Considerations for Achieving Crypto Agility: Strategies and Practices (final 19 December 2025, updated 29 June 2026).

Source: NIST IR 8547 ipd, “Transition to Post-Quantum Cryptography Standards,” November 2024.

What counts as a yes, and what counts as a no?

Five answers come back in practice, and each one carries a different price tag. This is the sorting table the test produces:

Answer	What it means	What it costs	Example failure mode
Yes, demonstrated	The algorithm is named in a config key, policy, or provider setting the team can point to, and they’ve flipped it (or one like it) before.	A change window: the setting, a reload, and a test.	The setting flips cleanly but the larger post-quantum handshake breaks a path through an old middlebox; the “and a test” half of the fast lane exists for exactly this.
”Yes, in theory”	The datasheet or reference architecture says yes; nobody in the room can name the config key.	Unknown, which for planning purposes means no until demonstrated.	The key exists but application code overrides it at the call sites, discovered mid-migration.
No, code	The algorithm is chosen in application source: call sites, hardcoded suite strings, literal key sizes.	Engineering work: edit the call sites, rebuild, redeploy, regression-test. Priced in developer quarters.	The rewrite surfaces stored data and message formats that also encode the old algorithm, and the project grows.
No, vendor	The cryptography lives inside a product you can’t rebuild: an appliance, a SaaS platform, a licensed application.	A procurement and contract cycle plus the vendor’s roadmap, on the vendor’s clock.	The vendor “supports PQC” in a version your contract doesn’t cover, or on a tier you’d have to repurchase.
No, firmware	The algorithm ships in device firmware or silicon: OT equipment, payment terminals, embedded fleets.	The replacement cycle, measured in years, or a compensating-control wrap in the meantime.	The fleet can’t be flashed in the field, so the hardware refresh becomes the migration.

Two boundary calls keep the sorting honest. A config change that needs a service restart is still a yes, because restarts are operations rather than engineering. And a system that’s agile for TLS but hardcoded for its stored-data encryption gets two answers, one per cryptographic function, because the test is really per algorithm-in-use rather than per hostname. Where a system does several cryptographic jobs, run the question against each job.

What’s the difference between algorithm agility and architectural agility?

Two capabilities hide under the one word “agile,” and the test as written measures only the first, which is worth being precise about because vendors rarely are.

1. Algorithm agility is the ability to replace the cryptographic primitive: swap the key-exchange group, rotate the signature algorithm, change the cipher. This is what the agility test’s yes certifies, it’s what RFC 7696 standardized for protocols, and it’s almost always what a vendor means when the word “crypto-agile” appears on a slide.
2. Architectural agility is the ability to evolve the surrounding structure: the trust model, the key-distribution design, the credential lifecycle. Moving from long-lived certificates to short-lived credentials, or adding a recovery path for a compromised certificate authority, are architectural moves, and a system can pass the algorithm-level test completely while being rigid on every one of them.

A 2026 review of quantum-resistant networks draws the line formally, and states the consequence: organizations should distinguish algorithm agility (replacing primitives) from architectural agility (evolving trust models, key-distribution architectures, and lifecycle controls), because networks lacking these properties may remain brittle even after adopting post-quantum algorithms.

Source: Bertino et al., “Quantum-Resistant Networks,” arXiv:2605.04129 (2026), §10.2.

What each tier is worth follows from what each one prices. An algorithm-agility yes prices this migration, the RSA-to-ML-KEM swap in front of you, which is why the test asks at that level. Architectural agility prices the next decade, whether the estate can absorb a trust-model change without a re-platforming project. The test deliberately stays at tier one because tier one is checkable today and drives the current budget; treat the architectural questions as a separate, slower inquiry, and treat any vendor’s unqualified “we’re agile” as a claim about tier one until shown otherwise.

Should you make systems agile before migrating them?

Assess to price, never to gate. Run the test across the priority list to learn what the migration costs, then migrate the urgent systems whether they’re agile or not. The temptation the rule exists to block is the prerequisite plan: pause the migration, spend 2 or 3 years re-architecting the estate for agility, then migrate everything cheaply. It sounds disciplined, and it inverts the risk math three ways.

1. The exposure clock doesn’t pause for the re-architecture. Data protected by quantum-vulnerable key exchange is subject to harvest-now-decrypt-later collection the entire time the retrofit runs. Every year spent making a system agile before migrating it is a year its traffic is captured under the old algorithm, and for long-shelf-life data that captured year never comes back.
2. The retrofit is most of the cost the agility was supposed to avoid. Making a hardcoded system agile means opening the code, which is the same expensive work as migrating it. Doing the retrofit first and the algorithm swap second pays for the code-opening twice on the schedule, and the payoff, a cheap next swap, mostly arrives on the migration after this one.
3. The deadlines are indifferent to your architecture. NIST IR 8547 deprecates 112-bit classical public-key algorithms after 2030 and disallows the classical schemes after 2035, and application-specific standards may pull individual systems earlier. A prerequisite program that delays the urgent swaps spends the calendar the deadlines are counting.

Source: NIST IR 8547 ipd, §4, November 2024.

The rule cuts the other way too, and it’s worth saying plainly: a no on the test raises a system’s urgency rather than excusing it. A rigid system holding long-shelf-life data starts first, because its path, the rewrite, the vendor escalation, the hardware refresh, has the longest lead time, and a lead time only starts counting the day you start it. For the systems where the answer is no and the data is urgent, the expensive path is the migration, and the test’s contribution is that you priced it on purpose instead of discovering it in month 9.

Building agility into greenfield systems is a different question with an easy answer: yes, always, it’s nearly free at design time. The rule governs the deployed estate, where retrofitting competes with migrating for the same budget and the same years.

What does the test look like on a real priority list?

Run it against a ranked top 10, the kind of list a two-lens pass over the inventory produces. The estate below is generic and the answers are illustrative; the shape is what recurs.

Rank	System	Test answer	Reason	What migrating it costs
1	Customer API edge (TLS termination)	Yes	Key-exchange groups are a load-balancer config list	A change window and a wire check
2	Internal PKI and issuing CAs	No	Vendor CA product; algorithm set fixed per version	Vendor upgrade cycle, then estate-wide reissuance
3	Payments gateway	No	Sealed vendor appliance	Contract and roadmap conversation, on the vendor’s clock
4	Data-lake key wrapping	Yes	Wrapping algorithm is a KMS key-spec setting	A key-spec change plus staged re-wrap
5	Core banking application	No	Algorithms named at call sites in 20-year-old code	The rewrite that anchors the engineering budget
6	Site-to-site VPN mesh	Yes	IKE proposal sets are device configuration	Config rollout across the fleet, then verification
7	OT sensor network	No	Crypto burned into device firmware	The hardware refresh cycle, in years
8	Code-signing pipeline	No	Signing algorithm fixed in build tooling and HSM firmware	Tooling rework plus an HSM firmware dependency
9	Internal service mesh (mTLS)	Yes	Sidecar proxies take a mesh-wide cipher policy	A policy push and a canary
10	B2B file-transfer service	Yes	Managed transfer platform exposes algorithm policy	A policy change plus partner compatibility testing

The split is the deliverable. 5 systems land in the fast lane: each is a setting, a rollout, and a verification, and together they schedule as change windows over a quarter. The other 5 land in the pile that defines the program, and the recorded reasons sort that pile into its 3 cost families: the code rewrites (ranks 5 and 8) go to the engineering roadmap, the vendor dependencies (ranks 2 and 3) go to procurement and contract renewal, and the firmware fleet (rank 7) goes on the multi-year refresh plan, with its lead time starting now for exactly the reason above.

Notice what changed. Before the test, “migrate the top 10” was a single undifferentiated project with a guessed budget. After 10 conversations, roughly a week of asking, half the list is nearly free, and the other half has named reasons, named owners, and the right clocks attached. The estimate stopped being a number and became a structure.

Common misconceptions

• “The datasheet says the product is crypto-agile, so the system passes.” Datasheet agility describes the product line; operational agility describes your deployment. The capability can be real in the product and unreachable in your instance, because of the version you run, the integration that pins algorithms in code, or a license tier. The test is asked of the deployed system, present tense, which is why “not in theory, on this system, today” is part of the wording.
• “We can buy agility.” Crypto-agility is an architectural property of each system, so a purchased component that’s agile does nothing for the rigid systems around it. Products can contain agility; estates have it or don’t, one system at a time, and the test is how you find out which.
• “A yes means the system is quantum-safe.” A yes means the algorithm is cheap to change, and says nothing about what’s currently running. An agile system still negotiating classical key exchange is exactly as exposed as a rigid one. Agility is a migration enabler rather than a security control, a distinction Crypto-Agility covers in full.
• “Make everything agile first, then migrate.” That plan re-architects while the exposure clock runs and pays for the expensive code-opening twice. Assess to price, never to gate: the urgent systems migrate on whatever architecture they have.
• “We use OpenSSL / JCA / a modern crypto library, so we’re agile.” The library sets what the system could run; the application’s call sites decide what it does run. If the algorithm names live in source code, the library’s flexibility is unreachable without a rebuild, and the answer is no.
• “A no means the system migrates last.” Usually the reverse. A no with urgent data means the longest lead time in the program, whether that lead time is a rewrite, a vendor escalation, or a hardware refresh, and long lead times start first. The test orders cost; urgency still comes from the data, which is the two-lens side of the pairing.

Pro tips

1. When the answer is “yes, in theory,” ask for the config key. The follow-up is one sentence: show me the setting. A team with real agility names the file, the policy, or the console field in seconds. A team that reaches for the architecture diagram has answered the question, and the ledger entry is no-until-demonstrated.
2. Test it on a single system before believing any estate-wide claim. Pick one yes-system, schedule the change, flip the algorithm in a test environment or a canary slice, and watch it take effect. One demonstrated flip is worth any number of asserted ones, and estates that run this drill routinely find their first “yes” was really a “yes, except.”
3. Verify the flip on the wire, never just in the config. A changed setting proves the menu changed; proof the new algorithm actually runs comes from the negotiated record afterward, which is the Wire Over Config discipline applied as the test’s acceptance check.
4. Record every no with its reason: code, vendor, or firmware. The reason is the cost driver. Code-nos price as engineering work you control, vendor-nos price as contract cycles you influence, and firmware-nos price as replacement calendars you mostly inherit. A list of bare nos is a mood; a list of nos-with-reasons is a budget structure.
5. Ask per cryptographic function, not per hostname. A system can be agile for its TLS and rigid for its stored-data encryption or its signing. Run the question against each algorithm the system actually uses, or the single answer will hide the expensive half.

Where does the test break?

1. Systems being decommissioned inside the migration window. For a system with a confirmed retirement date ahead of the relevant deadline, the test is moot: retirement is the migration, and the only cryptographic question left is whether the data it protected needs re-encrypting on its way to the successor system. Spending a rewrite or a vendor escalation on a system with 18 months to live is the one way the test can mislead, so check the retirement calendar before acting on any no.
2. The fast lane still has a test in it. A yes prices the change as a setting and a test, and the second half is load-bearing. Post-quantum algorithms are bigger, an ML-KEM-768 public key is 1,184 bytes where an X25519 key is 32, and larger handshakes can break paths, buffers, and middleboxes even when the config flips perfectly. The test prices the change; Cryptographic Interoperability is why the verification step stays in the price.

Source: FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard, August 2024; A. Langley et al., “Elliptic Curves for Security,” RFC 7748, January 2016, rfc-editor.org/info/rfc7748.

3. The test reads a moment, and estates move. An answer is true the day it’s given. A vendor ships a version that exposes the algorithm setting, a refactor hardcodes what used to be configurable, a platform migration changes the answer in either direction. Re-run the test when a no-system’s underlying reason changes, and re-confirm a yes before scheduling the change window that depends on it.

How do you use it in the boardroom?

The test compresses to one question for the moment a migration budget lands on the table: “How many of our priority systems passed the agility test, and for each one that failed, is the reason code, vendor, or firmware?” A program that has run the test answers with the split and the reasons, and the conversation moves to sequencing and lead times. A program that answers with an estate-wide percentage or a vendor’s assurance hasn’t priced its own migration yet, and now everyone in the room knows precisely which conversation to have next.

The same instrument works pointed at claims. When a vendor or an internal team offers “we’re crypto-agile” in place of evidence, the board-level response is the test’s own follow-up: show us the configuration change, demonstrated on one system. It’s a fair ask, it takes a day to satisfy when it’s true, and it converts the word on the slide into either a capability or a work item.

Questions people ask

Who actually answers the test for a given system? The team that operates it: the people who would file the change request and take the pager if it went wrong. Vendors, architects, and datasheets inform the answer, and the owning team gives it, because they’re the only party who can be proven wrong by next Tuesday.

How long does running the test across a priority list take? For a top-10 list, typically days of conversations rather than weeks of tooling, because the question needs an owner’s knowledge rather than a scan. The demonstrated-flip verification on selected systems adds change windows, and those are worth scheduling for the yes-systems you plan to migrate first anyway.

What if the owning team honestly doesn’t know? Then the current answer is no, in the useful sense: an algorithm nobody can locate in configuration is an algorithm nobody can change through configuration this week. Record it as unknown, assign the homework of finding where the algorithm choice lives, and let the answer graduate to yes when someone can point at the key.

Does a yes mean we can migrate that system today? It means the mechanism is ready; the migration still needs a target algorithm supported end to end, compatibility across whatever the system talks to, and a verification step. The yes removes the engineering project from the path. Cryptographic Interoperability covers what remains.

How do I run the test on SaaS and cloud services? As written, mostly you can’t, because the configuration is the provider’s. The question translates: does the service expose an algorithm or TLS-policy setting to you, and if it doesn’t, the system files as a vendor-no with the provider named as the dependency. That boundary between what you can test and what you must ask about is its own discipline on vendor surfaces, covered in Vendor-Controlled Crypto Surfaces.

Should I run it on every system or just the ranked list? Start with the ranked list, because the test’s job is pricing the migration you’re about to run, and the priority systems are that migration. Extending it estate-wide is worthwhile as discovery matures, and it’s never a reason to delay acting on the top of the list.

Does the test replace a cryptographic inventory? They answer different questions. A CBOM says what cryptography exists and where; the test says what each system’s cryptography costs to change. The test runs best on top of at least a partial inventory, and one honest pass of it often improves the inventory, because owners surface cryptography the scan missed.

What if the config key exists but the code ignores it? That’s the sharpest version of the theory-practice gap, and it’s why the demonstrated flip and the wire check exist. A setting the application overrides at its call sites is decoration. Until a change to the key visibly changes the algorithm on real connections, score it as a no with reason code.

Is a TLS server that negotiates algorithms automatically a yes? Usually, for that function, because negotiated protocols were built for exactly this and the permitted set is configuration. Confirm the config actually controls the set, confirm the post-quantum groups are available in the stack you run, and remember the negotiated outcome is decided jointly with the client population, which is why the acceptance check reads the wire.

How often should the answers be refreshed? On events rather than a calendar: a vendor version change, a re-platforming, a refactor touching the crypto path, or the approach of a system’s own change window. A standing quarterly review of the no-list specifically pays for itself, because a vendor shipping the setting you’ve been waiting for is the cheapest good news a migration ever gets.

---

Everything here is the map, given freely. Running the test across an estate, verifying the answers, and turning the split into a migration plan a board can fund is the work I do; when your team wants it done properly, that’s a working session with your team.

Last verified 2026-07-26 · Updated 2026-08-25 · Maintained by Addie LaMarr, LaMarr Labs.