up:: Migration Architecture MOC

The Three Zones

The three zones are the shape a cryptographic estate settles into once discovery starts returning real evidence: Zone 1 is the cryptography you control (the configurations, certificates, and keys your own team holds), Zone 2 is the cryptography you can see but a vendor controls (vendor products with visible crypto, managed services), and Zone 3 is the cryptography that stays invisible no matter what you do (SaaS you don’t host, crypto embedded in vendor products, devices nobody has credentials for). The rule that turns the sort into a framework: Zone 3 goes on the record as a finding, with a date, an owner, and a consequence the board can act on. Held back until someone has an answer, it surfaces as an audit finding instead.

The short version:

• Discovery sorts every cryptographic surface into one of three zones by who controls it: you (Zone 1), a vendor you can still observe (Zone 2), or nobody you can reach (Zone 3).
• Zone 1 migrates on your schedule, Zone 2 migrates on a vendor’s schedule you can pressure, and Zone 3 can only be bounded, dated, and reported.
• The framework’s operating rule: Zone 3 is a finding with a date, an owner, and a consequence, written down the day the map is drawn.
• The map builds from what you already own: 30 days of wire logs, a certificate export, and the vendor questions some vendors can’t answer.
• Every real estate has a Zone 3. A map that shows none was drawn from documentation rather than evidence.

Think of it like an honest survey of a coastline, drawn from a ship. Some territory you’ve walked and can reshape however you like: your own land. Some you can chart precisely through the glass, every cliff and cove, but it belongs to someone else and changes only when they decide: the neighboring coast. And some of the map is interior you have no way to reach, so the surveyor draws the boundary around it, labels the blank, and dates the label, rather than sketching in rivers nobody has seen. The three zones are that survey, run on cryptography, and the labeled blank is the part that makes the whole map trustworthy.

What are the three zones?

Zone 1 is what you control. The server and terminator configurations your team edits, the certificates your own CA issued, the keys in your key stores, the signing routines in the build pipeline you operate. Evidence here is direct and cheap: a configuration extract, a certificate export, a wire capture. When a Zone 1 surface has to migrate, the project is yours to schedule.

Zone 2 is what you can see but a vendor controls. Managed load balancers and CDNs, vendor appliances with a published cipher policy, the public TLS face of a hosted product, managed PKI. You can probe these surfaces, read their documentation, and collect attestations you can test, but changing the algorithms means the vendor ships support and you adopt it. The full anatomy of this zone, including the questions worth asking and the procurement levers, lives in Vendor-Controlled Crypto Surfaces.

Zone 3 is what stays invisible no matter what you do. The internals of a SaaS you don’t host, cryptography embedded in vendor firmware, devices without credentials, and every vendor who declines to answer. Most of it arrived inside something else: an open-source library like BoringSSL vendored into a product, a certificate chain an appliance shipped with, a cipher pinned in firmware years ago. No scan reaches it, no export lists it, and no attestation covers it, which is exactly why it needs its own kind of entry on the record.

Zone	Definition	Examples	What you can demand	What the artifact is
Zone 1, what you control	Cryptography your team can change directly	Your configs, certificates your CA issued, keys in your stores, code you build and sign	Change, on your own schedule	Verified evidence, a config extract, a certificate export, a wire capture
Zone 2, what you can see	Cryptography a vendor operates where evidence is still obtainable	Managed load balancers, CDNs, vendor appliances with published cipher policy, the TLS face of a hosted product	A dated roadmap, a CBOM, contractual commitments at renewal	Probe results plus dated vendor attestation, graded as documented until proven
Zone 3, what stays invisible	Cryptography nothing available to you can observe	Internals of SaaS hosted by someone else, crypto embedded in firmware, devices without credentials, vendors who decline to answer	An answer, or a refusal you can date	A finding, with a date, an owner, and a consequence the board can act on

NIST defines the cryptographic inventory this map feeds as a descriptive record of the cryptography used across an organization’s systems, applications, services, devices, and data flows, and the zones are the estate-level shape that record takes once control is filled in for every row.

Source: CISA, NSA, NIST, “Quantum-Readiness: Migration to Post-Quantum Cryptography,” August 2023, CISA factsheet. Definition, NIST NCCoE, “Migration to Post-Quantum Cryptography” project FAQ, “What is a cryptographic inventory?”, pages.nist.gov.

Why does the map sort by control rather than by system?

Because who controls a surface is the answer that decides how long its migration takes, and it’s the answer that almost never gets filled in. A cryptographic inventory answers 4 questions for every place cryptography runs: which algorithm, where it runs, what it protects, and who controls it (the full set is The Four Questions). The fourth question is the sorting key here. Zone 1 migrates when you schedule the work. Zone 2 migrates when the vendor ships support and you adopt it, so in Mosca’s terms the vendor sets your migration speed for that surface. Zone 3 has no migration schedule at all until it stops being invisible, and migrations stall on exactly this kind of visibility before they ever stall on cryptography.

Sorting by system hides the distinction that matters. Two surfaces on the same machine routinely sit in different zones: the TLS configuration you tune is Zone 1 while the vendor agent running beside it carries pinned crypto you can only ask about. The zones sort cryptographic surfaces rather than machines, and the zone of each surface is the same fact a CBOM captures row by row as the control boundary: customer-managed, vendor-configurable, vendor-opaque, or hardcoded. The three zones are that field, read at estate scale.

How do you map an estate into the three zones?

Three moves produce the map, and none of them needs a tool you don’t already own. Run all three; each one sees a slice the others walk past.

1. Read the wire rather than the config. A configuration lists what a server permits, and the connection log records what it actually negotiated, and those two disagree in any estate old enough to have legacy clients. The rule has its own note, Wire Over Config: the config is the menu, the wire is what was ordered. For zone mapping, the ask is one sentence to whoever runs the network edge and the load balancers: every distinct cipher suite, key-exchange group, and certificate signature algorithm negotiated in the last 30 days, with counts. Most edge equipment is already logging it, and the rest can switch it on in an afternoon. What comes back is Zone 1’s ground truth, and the first sighting of Zone 2, because the far end of every handshake you didn’t terminate belongs to someone else.
2. Pull the certificates rather than the documentation. Every X.509 certificate is a signed, dated, machine-readable declaration: the signature algorithm and the subject public key are structured fields of the certificate itself, so an export can’t misremember the way a spreadsheet does. The certificates your own CA issued confirm Zone 1. The ones it never issued draw the borders: self-signed certificates on appliances, chains a vendor embedded, certificates that expired and are somehow still trusted by something. Each of those marks a surface someone else configured, which places it in Zone 2 when you can reach its owner and in Zone 3 when you can’t.
3. Ask every vendor the question some of them can’t answer. Which algorithms does your product use for key establishment and for signing, and can you provide a CBOM? A real answer, with algorithm names, moves the surface into Zone 2 as dated, documented evidence. A marketing reply or silence moves it into Zone 3, and the move is to write that down with today’s date, because a refusal you can date is evidence and an undated one is a rumor.

Source: RFC 5280, “Internet X.509 Public Key Infrastructure Certificate and CRL Profile,” §4.1 (signatureAlgorithm and subjectPublicKeyInfo as certificate fields), IETF.

The reason the first move outranks a configuration review on its own is measured: a 2026 corpus study of production TLS found 21.8% of TLS-enabled contexts still permitted TLS 1.0 or 1.1 as configured even though most would negotiate a modern version when probed once. That gap between menu and order is where downgrade exposure hides, and the 30-day pull is what closes it.

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

Run all three moves and every cryptographic surface lands in a zone by evidence: Zone 1 by artifacts you produced, Zone 2 by observation plus attestation, and Zone 3 by construction, because it holds whatever produced no evidence after you genuinely looked. That last clause is what keeps the map honest. Zone 3 membership is earned by the looking, never assigned by suspicion, so the boundary you draw around it holds up in front of anyone.

What does a three-zone map look like in practice?

Take a generic mid-size company: a public web application behind a managed cloud load balancer, an internal PKI, a build pipeline that signs releases, a payments processor reached over an API, an HR SaaS, a backup appliance, office printers, and a warehouse of badge readers installed by an integrator a decade ago.

The wire pull comes back with a modern default and a tail: a legacy cipher still negotiated daily by an old client in a partner’s data center. The certificate export turns up everything the internal CA issued, plus a self-signed certificate on the backup appliance, an embedded chain on the badge-reader controller, and one expired certificate something internal still trusts. The vendor round splits cleanly: the payments processor answers with algorithm names and a CBOM, the HR SaaS points at a compliance page and stops, and the badge-reader integrator dissolved years ago. The estate resolves like this:

Surface	How it surfaced	Zone	Why it lands there
Web-tier TLS config and keys	Wire pull, cross-checked against your own configs	Zone 1	You edit the config and hold the keys
Internal PKI and every certificate it issued	Certificate export	Zone 1	Your CA, your rotation schedule
Release-signing keys in the build pipeline	Key-store and config review	Zone 1	Your keys, your pipeline
Managed load balancer cipher policy	Probe plus provider documentation	Zone 2	Visible and configurable, from a menu the provider defines
Payments API transport	Wire pull plus an answered attestation with a CBOM	Zone 2	Observable, attested, and dated
HR SaaS internals (at-rest encryption, key management)	Vendor declined to answer past a compliance page	Zone 3	Unverifiable by any means available; finding dated today
Printer TLS face	Wire pull and probe	Zone 2	Observable, and the firmware vendor decides what it supports
Printer firmware interior	Nothing reaches it	Zone 3	Embedded vendor crypto with no attestation
Badge readers	No credentials, integrator defunct	Zone 3	Unobservable and unownable until replaced

Two things about this map are worth noticing. The printer contributes rows to two zones at once, which is normal: the zones sort surfaces, and one device can hold several. And the three Zone 3 rows go on the record the same week, each with a date and an owner, while the badge-reader mystery is still a mystery. The map ships with its blank labeled instead of waiting for the blank to fill.

What makes Zone 3 a finding with a date?

A gap is a promise that future work will happen, with nobody accountable in the meantime. A finding is an accountable record, and Zone 3 earns the stronger form because it’s the one zone where “we’ll fix it” has no mechanism behind it: there’s no config to change and no patch to schedule, only vendors to pressure, contracts to renegotiate, and hardware to replace. The finding has 4 parts:

1. The boundary, stated plainly: which surfaces carry cryptography that no method available to you can verify.
2. The date the evidence search concluded, which is the date the organization knowably knew.
3. The owner, a named executive, usually whoever holds vendor and third-party risk, because every lever on this zone is contractual.
4. The consequence, in business terms: a data class whose protection is unverifiable, a migration with no schedule available to it, a renewal that would otherwise be signed blind. Where the surface carries long-lived sensitive data, the consequence line inherits the full weight of harvest-now-decrypt-later exposure, unverifiable by construction.

The two futures of an unreported Zone 3 explain the rule. Reported today, it becomes a governance decision: fund verification, apply procurement pressure, replace the surface, or accept the risk formally. Sat on, it stays invisible for another year and then surfaces anyway, in an audit, a customer questionnaire, or an incident review, and by then the question in the room is why the map showed nothing.

Federal practice already treats it this way. OMB M-23-02 requires agencies to inventory their cryptographic systems including contractor-operated ones, and keeps the accountability with the agency rather than the vendor, so a vendor’s silence is a risk the agency owns on paper from the day it’s dated. The joint CISA, NSA, and NIST guidance points every other organization down the same road: engage vendors proactively about post-quantum roadmaps rather than waiting to be told.

Sources: OMB M-23-02, “Migrating to Post-Quantum Cryptography,” November 18, 2022. CISA, NSA, NIST, “Quantum-Readiness: Migration to Post-Quantum Cryptography,” CISA factsheet.

How do you take Zone 3 to the board?

As a standing risk item in exactly the shape boards already act on: dated, owned, consequence attached, decision requested. Most boards have been briefed on the estate’s firewalls and its patching posture and have never once been told that a slice of the organization’s cryptography is unverifiable by anyone they employ. Saying it plainly, with the boundary drawn and the date on it, reads as command of the problem, because that’s what it is.

The one-slide version has 5 lines:

1. The boundary statement, one sentence: these surfaces carry cryptography that no method available to us can verify.
2. The date the map was drawn.
3. The named owner.
4. The consequence, in the business’s own terms: which data, which obligations, which renewals.
5. The decision requested, from a menu of 3 real options: fund verification through procurement and renewal terms, replace the surface, or accept the risk formally and on the record.

Each option is a legitimate outcome, including formal acceptance, because an accepted risk with a date and a signature is governance while an unrecorded one is negligence waiting for a discovery date. The finding is also what authorizes the pressure campaign: renewal terms and procurement standards move vendors, and those levers live at the level the board controls. The wider briefing pattern, including how to frame quantum risk without theatrics, is in Brief Your Board, and the register mechanics are in The Cryptographic Risk Register.

Common misconceptions

1. “The scanner came back clean, so we’re covered.” A scanner maps what it can reach, so a clean report describes the tool’s reach rather than your estate. It has no path into a SaaS you don’t host or a device without credentials, and NIST’s own migration testbed ran multiple discovery tools in tandem precisely because no single one finds everything. A tidy result with your worst exposure missing is the failure mode, and it looks like success.

   Source: NIST NCCoE, “Migration to Post-Quantum Cryptography,” NIST SP 1800-38.

2. “Discovery is a project with an end date.” Every dependency update can change what your software negotiates, and vendors change their products underneath you. A zone map is a living record with a review cadence, and a finished one starts aging the day it’s declared done.

3. “The vendor didn’t answer, so nothing changed.” A non-answer is information. It moves the surface to Zone 3, gets a date, and becomes renewal-negotiation material. Treating silence as neutral is how the invisible share of an estate stays invisible for another year.

4. “Zone 3 on our map means we failed.” Reversed. Every real estate has a Zone 3, and a map that shows none was drawn from documentation rather than evidence. The alarming version of the map is the one with no third zone, because it means nobody looked where the looking stops working.

5. “The zones sort systems.” They sort cryptographic surfaces. One printer contributes a Zone 2 row (its TLS face) and a Zone 3 row (its firmware interior), and collapsing a device to a single zone hides exactly the split that decides who can act.

6. “We moved to the cloud, so this is the provider’s problem now.” The shared-responsibility line places data encryption and key configuration on the customer side for most service models, and infrastructure-as-a-service leaves the whole TLS stack in your Zone 1. Cloud adoption relocates the zone boundaries rather than abolishing them.

   Source: AWS, “Shared Responsibility Model,” aws.amazon.com.

Pro tips

1. Ask for the 30-day pull with counts, and keep the counts. The list of negotiated suites tells you what exists; the counts tell you what’s load-bearing. A weak suite negotiated twice last month is a cleanup ticket, and the same suite negotiated tens of thousands of times a day is a dependency with a constituency, and those are different conversations with different budgets.

2. Treat certificates as testimony. A certificate is a signed, machine-readable declaration that can’t misremember, so when the export disagrees with the documentation, believe the export. Sort the certificates your CA never issued to the top of the review: each one is a border marker between Zone 1 and everything else.

3. Date-stamp every vendor non-answer the day it arrives, and file the marketing replies as non-answers, because that’s what they are. Two dated non-answers across consecutive quarters is escalation material when the renewal comes up, and the dates are what make it escalation material rather than a grievance.

4. When the first answer is evasive, narrow the question rather than repeating it. “Which algorithms for key establishment, which for signing, and can you provide a CBOM in CycloneDX format” is answerable by any engineering team in an afternoon, because the format exists precisely to carry that answer. A vendor who can’t answer the narrow version has answered a different question.

   Source: CycloneDX, “Cryptography Bill of Materials,” cyclonedx.org.

5. Log zone crossings. When a vendor ships a CBOM, a surface crosses from Zone 3 into Zone 2; when a device fleet is replaced, its rows cross into Zone 1 or 2. The crossing log is the plainest record that the invisible share of the estate is shrinking, and it reads well in front of a board precisely because every entry carries a date.

Where do the three zones break down?

The model earns trust by publishing its own limits, so here they are.

Fully air-gapped estates collapse the middle zone. Zone 2’s defining condition is a third party operating cryptography you can still observe, and an air gap removes the operating third party: vendor software runs under your custody, updates arrive on media you carry across the gap, and nothing is managed from outside. Zone 2 collapses into Zone 1 and the model simplifies to two zones, what you control and what’s sealed inside the boxes. The vendor lever moves accordingly, from renewal pressure to acquisition-time requirements, because most of the leverage exists before the hardware crosses the gap.

Estates that are almost entirely SaaS invert the emphasis. The sort still works, but Zone 1 is nearly empty and every lever is contractual, so the zone map reads less like an engineering plan and more like a procurement agenda. That’s an accurate description of such an estate, and better to learn from the map than from a stalled migration.

The zones sort by control and stay silent about priority. Deciding which Zone 1 surface migrates first takes the data classes and the risk models: blast radius for dependency weight, Mosca for timing, HNDL for what’s already exposed. The zone map tells you who can act on each surface, the risk sort tells you where to aim them, and a program needs both.

Questions people ask

Are the three zones a replacement for a CBOM? No. The CBOM is the row-level ledger and the zones are the estate-level sort of one of its fields, the control boundary. You build the ledger through discovery and read the zones off it.

What’s the actual difference between Zone 2 and Zone 3? Whether any evidence is obtainable by any means available to you. Zone 2 surfaces yield probes, published cipher policies, or attestations you can test and date. Zone 3 surfaces yield none of those after a genuine attempt, which is why membership is earned by looking rather than assigned by guess.

Can Zone 3 shrink? Yes, and tracking the crossings is half the point. A vendor who ships a CBOM moves a surface into Zone 2, a replaced device fleet moves rows into Zone 1 or 2, and procurement language forces the question on every new purchase before it enters the estate. Each crossing gets a date.

Who should own the Zone 3 finding? A named executive, usually whoever holds vendor and third-party risk, because every lever on Zone 3 is contractual: procurement terms, renewal negotiation, replacement budget. The cryptographic detail can sit with the security team, and the finding needs an owner who can act on contracts.

Do I need the full zone map before starting migration? No. The zones emerge from the first discovery pass, and the right move is to migrate the top Zone 1 risks while the map keeps filling in. Waiting for a complete map is a reliable way to ship nothing.

Is it safe to put Zone 3 in front of auditors and regulators? A dated, owned finding is the defensible posture, and federal practice points the same way: agency inventories have to cover contractor-operated systems, with accountability staying at the agency. The indefensible version is the map that showed nothing until an auditor drew it for you.

What do I need to buy to build the map? The 3 moves run on what an estate already owns: edge and load-balancer logs, a certificate export, and vendor questions sent over email. The broader tool landscape, source scanners, TLS scanners, and certificate platforms, is covered in Cryptographic Discovery Tooling, and none of it is a prerequisite for the first map.

Does Zone 2 mean the vendor carries the risk? The vendor carries the timeline and you carry the risk. In Mosca’s terms the vendor sets your migration speed for that surface, while the exposure of the data behind it stays yours, which is why every Zone 2 surface belongs in your risk register with the vendor’s roadmap answer and the renewal date attached.

---

Everything here is the map, given freely. The version measured against your own estate, with discovery run, zones drawn, and the Zone 3 finding dated for your board, is the work I do, and the engagements are here.

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