up:: Migration Architecture MOC

The Four Questions

The four questions are the 4 things a cryptographic inventory answers for every place cryptography runs in an estate: which algorithm is doing the work, where it runs, what it protects, and who controls it. Together they define the minimum a real migration plan can run on. An inventory entry that answers all 4 is something a team can act on; an entry that answers fewer is a note to yourself. The framework sits underneath the two artifacts that operationalize it: Cryptographic Discovery is how the answers get found, and a CBOM is the ledger that records them.

The short version:

• Every place cryptography runs gets 4 answers: which algorithm (at parameter granularity), where it runs (system, service, device, or link), what it protects (data or a trust relationship), and who controls it (you, a vendor, or hardware nobody can upgrade).
• “We use encryption” and “we use AES” answer none of them. A plan acts on rows like “RSA-2048, on the load balancer, protecting customer sessions, controlled by us.”
• The fourth question decides how long the migration takes, and it’s the column that almost never gets filled in, because its answer lives in contracts and vendor conversations rather than in anything a scanner can reach.
• The unit of an inventory is the algorithm-location pair: one row per place, because 2 places running the same algorithm have different owners, different data, and different timelines.
• Federal practice already treats this as mandatory. OMB M-23-02 requires U.S. agencies to inventory their cryptography, keeps contractor-operated systems in scope, and keeps the obligation with the agency for systems operated on its behalf.

Think of the medication list a new doctor asks for. “I take pills” is useless to her. What she can work with is a list that says which drug at which dose (warfarin, 5 mg), when and how it’s taken, what condition it manages, and which physician controls the prescription, because changing any of it safely runs through that person. A cryptographic inventory is that list for an organization’s cryptography, and most estates walk into the migration holding the equivalent of “I take pills.”

What are the four questions?

The four questions are the question tier of cryptographic inventory: the smallest set of answers that turns “we have cryptography somewhere” into a map a migration can execute against. For every place cryptography runs, the inventory answers:

1. Which algorithm? The specific algorithm and parameters. RSA-2048 in this service. Elliptic-curve P-256 on that connection. AES-256 in that database.
2. Where does it run? The system, service, device, or link, precisely enough to hand someone a work order.
3. What does it protect? The data class or the trust relationship, because a customer-record key and a firmware-signing key are different problems on different timelines.
4. Who controls it? You, a vendor, or a device in the field nobody can upgrade. This answer decides how long the migration takes, and it’s the answer that almost never gets filled in.

The framework applies whenever anyone claims to have a cryptographic inventory, at any scale and in any format: a spreadsheet, a governance platform, or a machine-readable CBOM. The CycloneDX CBOM schema carries far more fields than 4, and the extra fields elaborate these same answers plus evidence metadata; the four questions are what every format has to answer to be worth keeping. What the framework does NOT do is rank, cost, or sequence anything. It produces the map; the risk models such as Mosca’s theorem and HNDL exposure consume its answers to make those calls.

Why does an inventory need exactly these four?

Because a migration is a replacement project, and each question maps to a decision the replacement plan has to make. Question 1 tells you what gets replaced, and with what, since replacements and deadlines attach to specific algorithms at specific strengths. Question 2 tells you where the work happens, since every change lands at a location. Question 3 tells you how urgent each row is, since data with a long secrecy life is exposed to harvesting today while a signing key becomes a problem on a different clock. Question 4 tells you who can actually do the work and on whose schedule, which is what the total timeline is made of.

Drop any one of the four and a specific planning failure follows:

1. Without the algorithm, you have assets with no work defined against them.
2. Without the location, you have work with no address, which is a plan with no tasks.
3. Without what it protects, every row looks equally urgent, so prioritization collapses into guessing.
4. Without who controls it, the timeline is fiction, because the slowest rows in any estate are the ones that move on somebody else’s schedule.

U.S. federal guidance converged on the same shape. NIST defines a cryptographic inventory as “a descriptive record of the cryptography used across an organization’s systems, applications, services, devices, and data flows,” which is questions 1 and 2, and their guidance drives organizations toward data sensitivity and direct vendor outreach, which are questions 3 and 4.

Source: definition, NIST NCCoE, “Migration to Post-Quantum Cryptography” project FAQ, “What is a cryptographic inventory?”, pages.nist.gov. Data-sensitivity and vendor-roadmap guidance, CISA, NSA, NIST, “Quantum-Readiness: Migration to Post-Quantum Cryptography,” August 2023, CISA factsheet.

Which algorithm is it?

The first question demands a name with parameters in it. The migration replaces specific algorithms at specific strengths, so the cost, the replacement, and the deadline all change with the parameters. NIST’s draft transition guidance puts dates on exactly this granularity: it deprecates 112-bit-security public-key algorithms, RSA-2048 among them, after 2030 and disallows them after 2035, which means “RSA” as an answer can’t even be checked against the deadline that governs it.

Source: NIST, “Transition to Post-Quantum Cryptography Standards,” initial public draft, NIST IR 8547.

Two answers fail this question so often they deserve names:

1. The family answer. “We use AES” or “we use RSA” names a family and sounds like information. A plan can do nothing with it, because the family contains parameter sets with different security levels, different deprecation dates, and different replacements.
2. The product answer. “We use BitLocker” or “the vendor handles it” names a brand. Products rebrand, re-version, and change their internals; algorithms are what break or survive. Keep asking until the answer has a parameter in it.

There’s a third subtlety for anything that negotiates a connection: the algorithm is chosen at connection time from whatever the configuration permits, so the configured list and the negotiated reality can differ. The answer to question 1 on a negotiated surface is what actually crossed the wire, which is the rule Wire Over Config exists to teach.

Where does it run?

The second question gives every algorithm an address: a system, a service, a device, or a link. The link counts as a place. A TLS connection between two internal services is somewhere cryptography runs, with its own row, its own negotiated algorithm, and its own owner.

Location is what makes an inventory actionable, for three reasons:

1. Work orders have addresses. The migration is a sequence of configuration changes, code changes, certificate reissues, and vendor requests, and each one happens at a place someone can be assigned.
2. The same algorithm at 2 locations is 2 rows. RSA-2048 on the public load balancer and RSA-2048 inside a vendor appliance share nothing operationally: different owner, different data, different control, different timeline. Collapsing them into one line item is how estimates go wrong.
3. Location is where inventories undercount. A great deal of cryptography arrived embedded inside something else, negotiates itself at runtime, or sits inside products nobody maps, so the set of places is larger than the set of things anyone deliberately deployed. Finding those places is the whole discipline of Cryptographic Discovery, and running it honestly resolves the estate into The Three Zones.

A useless answer to question 2 is an algorithm list with no addresses: “we have RSA-2048 in the environment.” True, and unactionable. A good answer is one a new team member could physically or logically navigate to.

What does it protect?

The third question splits every row into one of two kinds, and the kinds run on different clocks:

1. Data rows. The cryptography protects information, and the row inherits the data’s required secrecy lifetime. Encryption guarding records that must stay confidential into the 2030s is exposed right now, because ciphertext recorded today waits patiently for the machine that opens it. That’s the harvest-now-decrypt-later exposure, and it makes long-lived data the migration’s most time-critical category.
2. Trust rows. The cryptography anchors a relationship: a firmware-signing key, a code-signing key, a token-signing key, a CA certificate. These fail by forgery, which needs a working quantum machine, so there’s no retroactive break. Their catch is the deployment tail: a signing key baked into devices that will verify it for the next 15 years has to move long before the threat lands, because everything that trusts it has to move too.

The customer-record key and the firmware-signing key are the canonical contrast. One is a confidentiality problem with a clock that started when the adversary started recording. The other is an integrity problem whose clock starts later but whose fix takes longest. An inventory that records “sensitive” for both has answered neither.

This is also the question the security team can’t answer alone. The algorithm can be read off the wire; the required secrecy life of the data can only come from the business owner who knows the retention obligations and the consequences of disclosure. Question 3 is the bridge between the technical map and the risk models, because the secrecy-lifetime input to Mosca’s theorem is precisely this answer.

Who controls it?

The fourth question is the one the whole framework leans on, the one that decides how long the migration takes, and the one that almost never gets filled in. Every row gets one of four honest values, matching the control-boundary vocabulary a CBOM uses:

1. Customer-managed. The configuration, keys, and certificates are yours. The row moves on your change calendar.
2. Vendor-configurable. You set policy inside a vendor’s product, choosing from the menu the vendor ships. The row moves on your schedule, with a ceiling set by what the vendor has shipped.
3. Vendor-opaque. The cryptography lives inside a product or service you can’t see into. The row moves on the vendor’s roadmap, and your migration date for that row is their roadmap date, whatever your project plan says.
4. Hardcoded. The keys or algorithms are burned into devices in the field. The row moves at hardware-replacement speed, which is measured in budget cycles and years.

A migration’s length is set by its slowest rows, and the slowest rows are identified by exactly this column. Everything in the first value is a project; everything in the last three is a negotiation, a dependency, or a capital expense. That’s why the fourth answer is the plan’s critical path, and why vendor-controlled surfaces deserve their own study.

Why does the column stay blank? Four reasons, and they compound:

1. The answer lives outside the technical estate. It sits in contracts, procurement records, support agreements, and vendor roadmaps. Scanners emit algorithms and endpoints; none of them emits an owner.
2. It crosses team boundaries. PKI, network, and application teams each hold a slice of the picture, vendor management holds another, and no single dashboard shows the whole column.
3. It requires questions some vendors can’t answer. An unanswered vendor question feels like an incomplete row, so the row gets parked. The correct treatment is the reverse: a vendor’s non-answer, date-stamped, IS the answer. “Vendor-opaque, asked on this date, no algorithm disclosure received” is a complete, decision-grade entry.
4. Filling it honestly is uncomfortable. A truthful fourth column documents how much of the estate moves on schedules you don’t set, and that same fact is the single most decision-relevant thing the inventory produces, which is exactly why it has to be written down.

Federal policy has already ruled on the accountability side of this. OMB M-23-02, the memo that has required U.S. agencies to inventory their cryptography since November 2022, keeps contractor-operated systems inside the inventory’s scope and places that obligation on the agency itself for every system, in the memo’s words “whether operated by the agency or on the agency’s behalf”. Control can sit with a vendor while accountability stays with you, and the fourth column is where that gap becomes visible instead of implicit. See OMB M-23-02.

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

What does a good answer look like for each question?

Question	A useful answer looks like	The common failure	Why the failure costs you
Which algorithm?	RSA-2048 on this service’s TLS certificate; ECDHE P-256 negotiated on that connection; AES-256 on that database	”We use encryption,” a family name, or a product name	Deadlines and replacements attach to specific algorithms at specific strengths, so a family or a brand can’t be planned or checked against anything
Where does it run?	A system, service, device, or link someone could be assigned as a work order	An algorithm list with no addresses	Migration work happens at locations; a list without places is a plan without tasks
What does it protect?	The data class with its required secrecy life, or the named trust relationship the key anchors	”Sensitive data,” with no lifetime and no data-vs-trust distinction	Data rows and trust rows run on different clocks, and this answer is what assigns each row its urgency and its harvest exposure
Who controls it?	One of 4 values (customer-managed, vendor-configurable, vendor-opaque, hardcoded), with a name and a date on the vendor rows	Blank	This column is the timeline; every blank row hides a schedule someone else sets

What do the four questions look like on a real estate?

Run them on a sample of surfaces every mid-size organization recognizes. Picture a regional insurer, and take 5 rows from what would be a much longer table. The figures are illustrative; the shapes are universal.

Surface	Which algorithm?	Where does it run?	What does it protect?	Who controls it?
Public web tier	ECDHE P-256 key exchange under an RSA-2048 certificate, confirmed from edge logs	The load balancer terminating TLS for the customer portal	Customer sessions and credentials in transit	Customer-managed
Claims database	AES-256 transparent encryption, per the vendor’s configuration	The primary claims cluster	Claims records that must stay confidential for decades under retention and privacy obligations	Vendor-configurable
Release signing	RSA-3072 code-signing key in an HSM	The build pipeline that signs every release	The trust relationship between the company and everything that installs its software	Customer-managed
Payroll SaaS	Unknown; questionnaire sent, no algorithm disclosure received	The vendor’s cloud	Employee PII and bank details	Vendor-opaque, non-answer dated
Badge readers	Undocumented, keys installed at manufacture	Roughly 200 readers across 12 offices	Physical entry to every site	Hardcoded

Now read what the columns did. The fourth column split one estate into 4 different kinds of work: 2 rows move on the insurer’s own change calendar, 1 moves inside a vendor’s menu, 1 moves on a vendor roadmap nobody has seen, and 1 moves on a hardware budget. The third column split the clocks: the claims row is a harvest problem today, because that ciphertext outlives the transition, while the release-signing row is a forgery problem on a later clock with the longest fix, since every system that verifies those signatures has to move with the key.

And notice the payroll row. Its first cell is blank and the row is still complete, because “vendor-opaque, asked, undisclosed, dated” is an answer a plan can act on and a board can hear. The four questions produce a usable map even where the estate refuses to be seen; the refusal itself gets recorded.

How do the four questions relate to discovery and the CBOM?

The three artifacts stack cleanly. The four questions are the question tier: what the inventory must answer. Cryptographic Discovery is the activity tier: the layered methods (configuration extraction, scanning, certificate inventory, source analysis, vendor inquiry) that go find the answers. The CBOM is the record tier: the durable, machine-readable ledger the answers live in, with an evidence grade on every entry.

Two sibling frameworks carry the parts of this that deserve their own treatment:

1. The Three Zones is the map-level shape the fourth question produces across a whole estate: what you control, what you can see without controlling, and what stays invisible no matter what you do.
2. Wire Over Config is the evidence rule for answering the first question truthfully on any negotiated surface: the configuration is the menu, and the wire is what was ordered.

How do you use the four questions with a board?

The four questions convert “do we have a cryptographic inventory?” from a yes/no a director can’t evaluate into 4 tests a director can run in a single meeting, against whatever artifact is presented:

1. Open it to any page. Do entries name algorithms with parameters, or families and product names?
2. Does every entry have an address, a system or connection a team could be assigned?
3. Do entries separate data from trust relationships, and do the data entries carry a secrecy lifetime?
4. What fraction of the who-controls-it column is filled in, and how many of its vendor rows carry a date?

The fourth test is the one to press, because the first three are usually in better shape than the last: the technical answers come from tools, and the control answers come from work nobody assigned. The fraction of blank cells in that column is an honest proxy for how much of the migration timeline is currently unknown. Directors briefing further up the chain can pair this with Brief Your Board, and with the federal accountability precedent above: OMB M-23-02 requires the inventory to cover each system “whether operated by the agency or on the agency’s behalf,” so a vendor-operated system is still the agency’s to inventory. That is a standard a board can adopt.

Pro tips

1. One row per algorithm-location pair. The pair is the unit of the inventory. “RSA-2048” appearing in 8 places is 8 rows, because each place has its own owner, data class, control boundary, and timeline. Rows shaped this way roll up cleanly; rows shaped as “algorithms we use” never roll down.
2. Date-stamp every vendor non-answer. A blank cell with a vendor name and a date is evidence that compounds: it completes the row today, and each repeated dated ask builds the record that the opacity is the vendor’s, held against the accountability that stays yours.
3. Constrain the fourth answer to the 4 values. Free text in that column produces “IT” and “shared,” which defer the exact decision the column exists to force. Customer-managed, vendor-configurable, vendor-opaque, or hardcoded, and never anything else.
4. Get the third answer from the business owner, and record who answered. Secrecy lifetimes asserted by the security team are guesses. The owner who carries the retention obligation and the disclosure consequence is the source of record.
5. Chase product names down to parameters. When question 1 comes back as a brand, keep asking until the answer has a number in it. Brands re-version silently; parameters are what the deadlines bind to.
6. Re-ask on change, on a cadence. Any dependency update, certificate reissue, or vendor release can quietly change a row’s truth, so wire the questions into change management rather than treating them as an annual event.

Where do the four questions break down?

The framework has honest limits, and the biggest one is the good kind: estates that have already industrialized the answers.

1. Estates with a mature CBOM toolchain. Where a CycloneDX-emitting pipeline already produces algorithm, location, and purpose automatically, the four questions stop being the collection instrument and become the audit of the toolchain’s output. Grade what the pipeline emits: toolchains answer questions 1 and 2 well, answer question 3 patchily, and stay almost silent on question 4, so the framework’s job shifts from asking to verifying that every emitted row actually carries all 4 answers.
2. Very small estates. A young company with one cloud account can answer everything on a single page, and the framework stops feeling like a framework. That’s success; the questions still gate what counts as answered.
3. Boundary judgment at scale. In a large service mesh, thousands of links can share one enforced policy, and a literal row-per-link reading buries the map in duplicates. Collapse rows to the policy level where a single configuration genuinely governs them, and keep rows separate wherever enforcement can drift from policy.

Common misconceptions

• “‘We use AES’ is an inventory answer.” It’s a family name with a reassuring sound, and it leaves the parameters, location, data class, and owner all blank, which makes it 4 blanks pronounced as one word.
• “The inventory is a project with an end date.” It’s a living record. Dependencies update, certificates rotate, vendors ship, and each event can change a row’s truth, so a finished inventory starts drifting from reality the week it’s declared done.
• “The scanner’s output is the inventory.” A scanner produces candidate answers to questions 1 and 2, for the surfaces it can reach, and a clean scan report describes the tool’s reach rather than the estate. Questions 3 and 4 live in business records and vendor relationships, where no scanner has ever been.
• “The certificate list covers it.” Certificates are the visible slice of PKI. Key establishment, at-rest encryption, code signing, token signing, and firmware keys never appear on the certificate list, and those rows are routinely the ones with the longest timelines.
• “Who-controls-it is a procurement detail we can add later.” It’s the timeline question. Deferring it means building a schedule out of the rows you control and discovering the rows you don’t at execution time, which is how a 2-year plan becomes a 6-year one in the middle.
• “All 4 answers everywhere, then we start.” Enough answered rows to rank the top of the estate comes first, and the migration starts while the map keeps filling in. Blank cells are findings to record and work, never a reason to wait.

Questions people ask

How are the four questions different from a CBOM? The four questions are what an inventory must answer; a CBOM is the machine-readable ledger the answers live in, with evidence grades and many more fields. A CBOM row that answers all 4 is useful; a CBOM row that answers fewer is well-formatted filler.

Do I have to answer all four everywhere before starting a migration? No. Answer them fully on the crown-jewel and highest-risk systems first, rank against those rows, and let discovery keep filling the rest while migration work starts at the top.

What if a vendor won’t say which algorithm their product uses? Record the non-answer with the date. The row’s fourth question is now answered, vendor-opaque, even while its first stays blank, and the dated record is what protects you when the accountability question arrives.

Who should own answering the four questions? No single team can. Technical teams hold questions 1 and 2, business owners hold question 3, and procurement plus vendor management hold most of question 4, so someone has to own the record itself. That routing problem is its own discipline: see Cryptographic Ownership.

Is “we use TLS 1.3” an answer to the first question? It’s a protocol, and the algorithms get chosen per connection from what the configuration permits. The answer to question 1 on a negotiated surface is what was actually negotiated, which is the Wire Over Config rule.

How specific does “which algorithm” have to be? Parameter-set specific. RSA-2048 and RSA-4096 carry different security levels and different standing under NIST’s draft transition schedule, and the post-quantum replacements are chosen per algorithm and purpose, so anything coarser can’t be mapped to a deadline or a replacement.

Do the four questions cover symmetric cryptography too? Yes. The quantum-vulnerable rows are the public-key ones, and the symmetric rows still belong on the map, because the same 4 answers drive every cryptographic transition after this one, and question 4 decides the work either way.

How often do the answers change? Continuously, in small ways: a dependency update changes what a service negotiates, a certificate reissue changes a parameter, a vendor release changes an internal. Re-ask on a cadence weighted by risk, and treat every answer as dated the day it was written.

---

Everything here is the map, given freely. When the four questions need answering against your actual estate, with evidence behind every row and a migration picture built on top, that’s a working session with your team.

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