up:: Migration Architecture MOC

The Two-Lens Rule

The two-lens rule is the sorting method that turns a partial cryptographic inventory into a ranked migration queue. Against each system you record two values: shelf life, the number of years its data must stay secret, answered by the business owner of the data, never the security team, and blast radius, the number of systems that depend on this one, answered by the architecture team. Sort the longest secrecy and the widest dependency to the top, migrate the key exchange at the top of the queue first, and write the reason beside every rank. The output is a one-page ranked plan, and the rule works on an incomplete inventory by design: you need enough rows to rank the top, and discovery keeps running underneath while the top migrates.

The short version:

• Record two values per system: shelf life (years the data must stay secret, from the business owner) and blast radius (how many systems depend on this one, from the architecture team).
• Sort longest secrecy and widest dependency to the top. The key exchange at the top migrates first, because it’s the part of the estate losing security today.
• Enough inventory to rank the top is enough to start. Discovery continues underneath, and the queue absorbs new findings at the next re-rank.
• The output is a one-page ranked plan with a written reason per system. Boards fund reasons, and the reason column is what makes the ranking defensible upward.
• The sort runs on the two values alone, so anyone in the room can re-derive it.

Picture an engineer responsible for an aging levee network ahead of a long wet season, with one crew and 200 miles of earthwork. Against each stretch she records two numbers: how many years that section still has to hold, and how many towns sit in the water’s path if it gives way. The stretch that must hold longest with the most towns behind it gets the crew first, and nobody waits for a complete survey of all 200 miles before starting on the section everyone already knows about.

What are the two lenses?

The rule has four parts: two values, two respondents, one sort, one page. The values come first, and each one is a full framework in its own right with its own note.

1. Lens 1 is shelf life, and it IS The Shelf-Life Question. The business owner of the data gets one fixed sentence, “if this were published in full tomorrow, on what date does it stop hurting us?”, and the answer year minus the current year is the shelf life. The question routes to the business owner because the security team will read back the retention schedule, which measures how long you must keep a record rather than how long a stolen copy stays dangerous. For signing keys the same question reworded for unforgeability applies, so trust anchors get a shelf life too.
2. Lens 2 is blast radius: how many systems depend on this one. The full consequence model, with its five dimensions and its reachability trap, lives in Blast Radius. At sort time the two-lens rule runs on the dependency count, the dimension that does most of the work, and the counting mechanics below are how the architecture team produces it.

Lens	The value recorded	Who answers	Why that desk
Shelf life	Years the data must stay secret (unforgeability years, for signing keys)	The business owner of the data	They hold the harm model. Security holds custody knowledge, which returns the retention schedule instead
Blast radius	Count of systems that depend on this one	The architecture team	They hold the dependency graph. Security holds the criticality tier, which is a different number answering a different question

The rule applies the day the inventory holds its first dozen rows. It sits downstream of discovery and the CBOM, because it ranks findings and needs findings to rank, and upstream of the migration work itself, because its output decides where that work starts. Estates where it has less to grab, the single-dominant-system case and the all-short-lived-data case, are covered honestly under where it breaks.

Who answers each lens?

The routing rule carries as much weight as the values, because each lens has exactly one desk that holds the real number and at least one desk that will confidently supply a wrong one.

Shelf life belongs to the business owner: the deal lead, the treasurer, the head of product, the chief medical officer. They can price harm in their own currency inside a minute, and they’ve never needed cryptographic vocabulary to do it, because the question contains none. Ask the security team instead and you get the retention schedule read back with full confidence, and retention points the opposite direction from harm as often as it agrees with it. The full wording, the guards, and the failure modes live in The Shelf-Life Question.

Blast radius belongs to the architecture team, and the reasoning is symmetrical. The business owner sees the record, the security team sees the control, and the architecture team sees the graph: the integration diagrams, the dependency maps, the gateway configurations, the trust chains. Ask security for a dependency count and you tend to get the asset-criticality tier, which measures how much the business would miss the system rather than how many other systems inherit its failure. Ask the business and you get a guess delivered politely. The architecture team is the desk that can actually walk the edges.

How do you count blast radius?

The count answers one question: if this system’s cryptography failed, how many other systems inherit the failure? Three kinds of dependent belong in it.

1. Direct consumers. Systems that call this one, ride its channel, or receive data through it: the services behind an API, the applications replicating across a VPN tunnel, everything terminating through a shared gateway.
2. Trust dependents, counted transitively. Systems that validate what this one signs or issues. A certificate authority’s count includes every certificate chained beneath it, intermediates and leaves alike, and an identity provider’s count includes every application accepting its tokens. Transitive counting is what puts trust anchors where they belong in the sort.
3. Path dependents. Systems whose traffic passes through this one even when they never address it: load balancers, reverse proxies, VPN concentrators. These are the dependents the diagram forgets, because the arrow on the diagram skips the box in the middle.

The architecture team reads the count out of artifacts it already owns: the dependency map or CMDB, API gateway and service-mesh configuration, certificate issuance records (a CA’s issuance log is a census of its dependents), identity-provider app registrations, and network flow data for the paths nobody documented.

Three counting rules keep the number honest and cheap:

1. Count systems rather than connections. A service calling an API 40,000 times a day is 1 dependent.
2. Band when precision gets expensive. Estate-wide, hundreds, dozens, a handful, one. The sort needs order rather than decimals, and a banded count produced this week beats an exact count promised next quarter.
3. When two teams disagree, the larger count stands until a real map settles it, and a count nobody can produce is itself a finding: an unmapped dependency graph around a cryptographic control is a gap worth escalating on its own.

When two rows tie on the count, the fuller model in Blast Radius breaks the tie: privilege, propagation, and recovery complexity separate systems the raw count treats as equals. The reachability trap from that note applies here unchanged, because an internal root CA is hard to reach and catastrophic to lose, so a low count of external exposure never discounts a high count of trust dependents.

How does the two-value sort work?

The sort is deliberately plain: band each lens, then order.

1. Band shelf life into decades, years, and months-to-zero. The banding survives fuzzy answers, because “25 years” and “30 years” land in the same band and the sort comes out identical.
2. Band blast radius into estate-wide, dozens-to-hundreds, a handful, and one.
3. The top of the queue is the intersection: decades of secrecy behind wide dependency. Within a band, the other lens orders the rows. An estate-wide trust anchor overrides the default order and takes the top even though its exposure is a signature exposure, the doctrine Start a Migration carries, because everything beneath it inherits its failure and rotating it is the longest-lead move in the program.
4. At the top of the queue, the key exchange migrates first. This is The Two-Lane Split doing its job inside the rule: public-key cryptography does two jobs that fail on two schedules, key establishment is exposed to harvest-now-decrypt-later collection today, and signatures become forgeable only once a live quantum machine exists. So the leak-now rows execute first, while the long-lead trust rows open their plans in the same week with completion dates. The federal deadlines run the same stagger: key establishment by the end of 2030, signatures by the end of 2031.

Source: CISA, NSA, and NIST, “Quantum-Readiness: Migration to Post-Quantum Cryptography,” joint factsheet, August 21, 2023, CSI_QUANTUM_READINESS_MIGRATION_TO_PQC.PDF.

Source: Executive Order 14412, “Securing the Nation Against Advanced Cryptographic Attacks,” 91 FR 38483, June 25, 2026, federalregister.gov.

The sort stays a sort. Two banded values and an override produce a queue any director can re-derive in the room, and a ranking that can be re-derived is a ranking that gets defended by people other than its author. That property is worth more to the program than any additional sophistication, because the queue’s whole job is to survive contact with a funding conversation.

Do you need a complete inventory before you rank?

No, and the rule is built on that answer: you need enough of an inventory to rank the top, and you migrate the top while discovery continues underneath. A full cryptographic map of a real estate takes many months to years, and the top of the risk list is usually knowable in weeks, because the systems holding decades-lived data behind wide dependency are the ones the business already knows by name. Waiting for completeness leaves exactly those systems leaking while the catalog fills in with rows that were never going to rank.

The stability argument is what makes starting early safe rather than reckless. Discovery mostly adds rows below the top, since most of any estate is short-lived data on narrow paths, and when a sweep does surface a new decades-band, wide-dependency row, the next re-rank promotes it, and the migration already underway on the previous top was still the right work. The queue is a living sort with a cadence, and the cadence is what absorbs incompleteness.

The federal program is built the same way. OMB M-23-02 requires agencies to submit a prioritized inventory of their cryptographic systems annually through 2035, which is prioritization and discovery running concurrently by design, year after year, rather than a single finished census followed by a single finished plan.

Source: OMB, “Migrating to Post-Quantum Cryptography,” M-23-02, November 18, 2022, M-23-02 PDF.

Scope the first pass to the crown jewels, the way Start a Migration and the CBOM note walk it: 3 to 5 systems, their certificates, their configurations, their key exchanges. That’s a rankable inventory in weeks, and it’s all the rule needs to produce a defensible top.

What does a worked ranking look like?

Take a generic mid-sized company after a first-pass discovery effort: 8 systems inventoried, values collected from the owners and the architecture team, nothing else finished. Every number, date, and count in this table is illustrative; your owners and your architecture team supply the real ones.

Rank	System	Shelf life (from the business owner)	Depends on it (from the architecture team)	The reason, as written on the plan
1	Internal root CA (ECDSA)	15 years of unforgeability; the oldest device fleet trusting it retires in 2041 (platform owner)	~300; every certificate in the estate chains to it (issuance log)	Estate-wide dependency, and rotating a root is the longest-lead move in the program. Nothing leaks from it today, since forgery waits on a live quantum machine, so rank 1 buys a start date and a completion date rather than an emergency
2	Customer transaction API (TLS, ECDHE)	25 years; the identity fields hurt for the life of the customer (VP of product)	38 internal services and partner systems (gateway dependency map)	Decades-lived regulated data crossing a collectible path daily behind wide dependency. Its key exchange is losing security right now, so it’s the first migration the team executes, to ML-KEM via hybrid
3	Data-center replication VPN (IPsec, classical DH)	25 years; the same customer records as the API (VP of product)	14 systems ride the tunnel (network architecture)	The same decades-band records on a second collectible path, with narrower reach than the API, so it follows rather than ties
4	HR platform (internal TLS)	40 years; dates of birth and national IDs for the youngest employees (HR director)	3 (integration map)	The longest secrecy in the estate on a handful of dependents. The decades band holds it above everything short-lived regardless of its small footprint
5	Backup archive, data keys wrapped with RSA-2048	25 years; full copies of the production records (VP of product)	1, the archive itself	One stolen tape is a harvest event, and the RSA wrap around the data keys is the part that falls. Shelf life alone keeps a dependency count of 1 in the top half
6	SSO token signing (SAML, OIDC)	Hours; tokens expire the same day (identity owner)	80 applications accept its tokens (app registrations)	The widest reach outside the top, on the shortest clock. A forged token needs a live machine at the moment of attack, so it schedules on the deliberate signing track behind the leak-now rows
7	Internal wiki (TLS)	2 years; project chatter goes stale fast (engineering lead)	1	Short-lived content on a single system. It migrates when its platform refreshes
8	Marketing site (TLS)	0 years; the content was written to be published (CMO)	2	An honest zero. The same vulnerable handshake as rank 2 with nothing secret behind it, which is the clearest proof the sort ranks data rather than protocols

Four things about the finished queue are worth noticing, because they’re the patterns every real estate repeats:

1. Rank 1 and first-executed are different rows. The root CA tops the page because everything depends on it and its rotation has the longest lead, and the first migration the team actually performs is rank 2’s key exchange, because that’s the row bleeding today. The queue orders attention and funding; the lanes time the moves inside it.
2. The banding is visible in ranks 3 through 5. All three sit in the decades band on shelf life, so dependency orders them, and the 40-year HR platform sits below the wider-reach VPN without any argument about whether 40 beats 25, because the band already decided what mattered.
3. Row 6 shows the lenses working against each other honestly. Wide reach on a short clock lands mid-queue with a scheduled track rather than a panic.
4. The zeros are half the output. Ranks 7 and 8 leave the room with a written reason to wait, which is what stops “everything is urgent” from reinfecting the program at the next budget cycle.

What goes on the one-page plan?

The deliverable is 1 page, on purpose, because a scoped ask with visible reasoning is what a busy executive approves. It carries:

1. A header with the program owner and the binding date. The named owner in writing, and the earliest deadline the organization actually owes someone, found through The Binding-Date Questions and cited to its clause.
2. The ranked rows, top of the queue only. Each row holds the rank, the system, both values with their provenance (the owner who gave the shelf life and the date they gave it; the artifact the count came from), the written reason, and the first move with its destination: key exchange to ML-KEM through hybrid on the leak-now rows, a signing migration plan toward ML-DSA with a completion date on the trust rows.
3. One small reversible first move. A hybrid handshake on a single internal service, or a discovery pass on one more system, so the program starts with a step nobody has to defend as a one-way door.

Source: NIST, FIPS 203 and FIPS 204, finalized August 13, 2024, FIPS 203, FIPS 204.

The rest of the inventory lives in the working register, with The Cryptographic Risk Register as its home, and the plan points at it. The page stays one page even when the inventory grows to 400 rows, because the page is the top of the queue and the argument for it, and everything below the top is the register’s job.

Common misconceptions

1. “Rank by business criticality.” Criticality is the disaster-recovery lens: it measures what hurts if a system goes down, and it says nothing about what’s losing security fastest. A critical system can run cryptography that’s in no hurry while a forgotten one hemorrhages decades-lived records. Rank by the two lenses, and let criticality inform how carefully each change is handled rather than which change comes first.
2. “Start with whatever feels most urgent.” Urgency-feel tracks visibility: the system in the auditor’s finding, the one in this week’s headlines, the one a vendor built a pitch around. The lenses track exposure, and the most exposed system in most estates is one nobody was talking about, because harvesting generates no alerts and no headlines.
3. “Finish the inventory, then prioritize.” That order sounds rigorous and quietly maximizes exposure, because the months spent completing the catalog are months the top of the queue keeps leaking. The top is knowable from a partial inventory in weeks, and the annual federal inventory cycle exists precisely because discovery and prioritization run concurrently for years.
4. “Rank it once and execute.” The ranking is a living sort. Discovery adds rows, owners revise shelf lives when deals close and products sunset, and architecture changes rewrite dependency counts. A queue ranked in January and untouched in October is a snapshot pretending to be a plan.
5. “Two values have to be combined into a single score.” The sort works on bands and an override, and it stays re-derivable by anyone in the room, which is the property that makes it defensible. A composite number has to be explained; a sort can be checked.
6. “A dependency count of 1 means it can wait.” The lenses work together. The backup archive in the worked example holds a count of 1 and 25 years of shelf life, and it ranks in the top half, because a single harvest event against decades-lived data outweighs a wide footprint of ephemeral traffic.

Pro tips

1. Re-rank on a cadence, and let discovery set it. Every discovery sweep that lands feeds a re-rank, with a quarterly floor if sweeps run slower, plus trigger events: an acquisition, a new product line, a mandate date moving, a top-band finding. The re-rank is minutes of work once the values have owners, and it’s what keeps the start-before-complete rule honest.
2. When two systems genuinely tie, the earlier binding date wins. Both decades-band, similar reach: the tiebreaker is which system’s mandate, certification, or customer clause comes due first, because that date is already owed to someone outside the building. The Binding-Date Questions is how you find it per system.
3. Write the reason on every row, in business language. Boards read reasons, and a reason that names the data, the owner, and the dependency survives the meeting without its author present. A rank without a reason gets relitigated every quarter by whoever wasn’t in the room when it was set.
4. Capture provenance with each value. Who gave the shelf life, their role, the date; which artifact produced the count. The provenance is what converts the queue from an opinion into evidence, and it’s the difference between defending the ranking and re-deriving it from scratch at every challenge.
5. Band rather than measure. Chasing an exact dependency count or a to-the-year shelf life delays the sort without changing it. Decades versus years decides more than 23 versus 27 ever will, and the precision can arrive later, attached to rows that survived the first cut.

Where does the two-lens rule break?

Published limits, because a ranking tool that can’t fail is a ranking tool nobody has tested:

1. Estates with one dominant system. When a single platform holds most of the long-lived data and most of the dependency, the sort is trivial and the answer was known before the exercise. The rule still earns its keep one level down: the sequencing moves inside that system, and its termination points, key stores, integration paths, and trust chains become the rows the lenses rank.
2. Genuinely short-lived data everywhere. Where nothing must stay secret beyond a year or two, lens 1 goes flat and blast radius alone ranks the queue. Most of the remaining quantum urgency in such an estate sits on the signing side, where service lives stay long even when data lives are short, the edge The Shelf-Life Question documents.
3. It ranks what discovery has found. A system nobody has inventoried holds no rank, and the rule has no opinion about it. The cadence and the crown-jewel-first scope shrink that window, and the limit stands: the queue is only as complete as the discovery feeding it.
4. Rank order and execution order can diverge. A vendor-controlled row can sit at rank 2 while the vendor’s roadmap runs on its own calendar, and a long-lead trust rotation executes across years while shorter rows beneath it finish first. The plan records the dependency and the pressure applied rather than pretending the queue is a schedule.

How do you defend the ranking to a board?

The defense is built into the artifact, which is the point of carrying the reason column at all. Four properties do the work:

1. Every rank has a reason in business language. “This system carries records that hurt for 25 years, 38 systems depend on it, and the part that’s leaking migrates first” is a sentence a director can repeat to another director. Boards fund reasons they can restate.
2. Every value has provenance. The shelf life came from a named owner on a dated conversation, and the count came from a named artifact. When someone asks “who says?”, the answer is a colleague’s name rather than a consultant’s slide.
3. The “why isn’t my system first” challenge answers itself. Read the challenger’s two values off the register next to the top row’s values, and the sort re-derives itself in front of the room. The ranking wins the argument by being checkable rather than by being asserted.
4. The ask is scoped. Phase 1 is the top of the queue and one reversible first move, weeks of work, rather than an estate-wide program approved on faith. Brief Your Board carries the fuller version of that conversation, and Own Your Quantum Risk is the same program seen from the executive owner’s chair.

Questions people ask

What do the two lenses actually measure? Time and reach. Shelf life measures how many years a system’s data stays dangerous if a copy is taken, which is the clock that decides urgency under harvesting. Blast radius measures how many systems inherit a failure, which is the reach that decides consequence. Either one alone ranks the estate wrong in its own characteristic way: shelf life alone buries the trust anchors, and reach alone buries the quiet archive.

How is the two-lens rule different from Mosca’s theorem? Mosca’s inequality is per-data-class arithmetic that decides whether a migration is already late, and the two-lens rule is a sort that decides what to touch first. They share lens 1, since the shelf life is Mosca’s X, and they answer different questions: run Mosca to learn how much trouble you’re in, run the two lenses to decide where to start.

Why does blast radius alone rank the estate wrong? Because consequence without a clock treats a wide-reach system serving ephemeral traffic as urgent while a narrow archive of decades-lived records waits. Reach says how bad a failure spreads, and shelf life says whose failure is already being staged today through harvesting. The queue needs both, which is the whole reason the rule has two lenses.

Do I need a complete inventory before I can rank? No. Enough inventory to rank the top is enough to start, and the top is usually knowable in weeks from a crown-jewel scope. Discovery continues underneath, each sweep feeds a re-rank, and a new finding that belongs at the top gets promoted without invalidating the work already moving.

Who fills in the two values? The business owner of the data supplies the shelf life, in years, through the fixed wording of The Shelf-Life Question. The architecture team supplies the dependency count from the maps, configurations, and issuance records it already owns. The security team runs the process and owns neither number, which is exactly what makes the result survive scrutiny.

What if two systems land on the same rank? The earlier binding date wins. Check which system’s mandate, certification, or customer contract clause comes due first through The Binding-Date Questions, and give that system the higher slot, because its deadline is already owed to someone outside the organization.

What if the business owner can’t give a number? Use the exact wording, which converts feelings into dates, and convert “forever” into a proxy date such as the customer’s lifetime or the product’s end of support. For orphaned data with no living owner, record the regulatory retention floor as a conservative stand-in, mark the row unowned, and escalate the missing owner as its own finding.

How long does producing the ranked plan take? Weeks, on a crown-jewel scope. Collecting shelf lives is minutes per owner, the dependency counts come from artifacts the architecture team already holds, and the sort itself is an afternoon. Start a Migration walks the same deliverable as the close of a 90-day Phase 1.

What happens to the bottom of the queue? It waits, with a written reason, which is a different thing from being forgotten. Short-lived, narrow rows migrate when their platforms refresh, the register keeps their values current, and the re-rank cadence promotes any row whose shelf life or dependency picture changes. The zeros at the bottom are half the value of the exercise, because they’re what keeps the top short enough to fund.

---

Everything here is the map, given freely. The two-lens rule run against your own estate, owner by owner and count by count, until the ranking is one your board and your regulator would both sign, is the work I do. Request the workshop.

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