Data exposure and the harvest-now-decrypt-later threat

An adversary able to record encrypted traffic today can decrypt it once a cryptographically relevant quantum computer exists. The exposure this creates is not visible in the cryptography a CBOM currently discloses, because it depends on how long the data carried must remain confidential and on whether the traffic can be captured at all. This section sets out what has to be recorded to make that exposure assessable, and where those facts belong.

What makes this threat different

Most cryptographic risk is prospective. A weakness discovered in an algorithm affects the traffic protected by it from that point forward, and the remedy is to stop using it. This threat is retrospective. Traffic captured and stored today is decrypted years later, when the capability arrives, and no action taken at that point recovers the confidentiality of data that has already been recorded.

The consequence for planning is that the decision to migrate has to be taken before the capability exists, and the window in which the decision matters is closing while the estimate of when the capability arrives remains uncertain. An organization that waits for confirmation has already lost the traffic it was protecting.

The threat therefore applies unevenly. Data that ceases to be sensitive within a year is largely unaffected, because a recording made today has little value by the time it can be read. Data that must remain confidential for decades is exposed now, regardless of the algorithm protecting it, if that algorithm is one a quantum computer will break.

Why the cryptography alone does not answer the question

Consider two interfaces on two products. Both terminate TLS 1.3, both negotiate X25519 for key exchange and AES-256-GCM for encryption, and both authenticate with an RSA-2048 certificate. Against every attribute the baseline profile requires, the two are identical. Their exposure to this threat is not comparable.

The three quantities

The assessment reduces to a comparison between three periods, in the formulation Mosca gives. Two of them describe the organization and one describes the world.

Where the first two added together exceed the third, data being transmitted now will be readable before it stops being sensitive. The organization is already exposed, and the exposure grows with every day the interface continues to operate.

The methodology supplies the second quantity through the migration profile, which records what a capability requires and what is blocking it. It supplies nothing at all for the first. That is the gap this section addresses.

Two kinds of data, with different owners

Which party can state these facts depends on which kind of data an interface carries, and the answer is not the same for every interface.

Conveyed payload is whatever the customer chooses to send. A vendor shipping a device does not know what that will be, and the same product carries public information at one site and long-lived personal records at another. A requirement on the vendor to classify it produces a refusal or a guess, and the latter is worse because it will be relied on.

Intrinsic data is what an interface must carry to function, and the vendor knows precisely what it is because the vendor designed the interface. A management interface carries administrative credentials. A key management interface carries key material. An update channel carries a signed image and the signature verifying it. An enrolment interface carries device identity and private key material.

The intrinsic case carries the worse exposure

The exposure in the vendor-knowable half is the greater of the two.

Take a management session protected by a classical key exchange, carrying a device credential. An adversary records the session now and decrypts it in 2035. If that credential is a certificate with a twenty-year validity, or a key held in hardware that cannot be rotated in the field, the adversary does not obtain stale information. It obtains a working secret. The confidentiality lifetime of that payload equals the lifetime of the credential, and the vendor knows that lifetime because the vendor chose it.

Ordinary business information loses sensitivity as it ages, which is what makes short confidentiality lifetimes tolerable. Credentials and key material do not, and may still be live when the recording is read. A model that admits only operator knowledge discards the half of the problem where the consequences are most serious.

Where each fact belongs

Lifecycle Data separates a product CBOM, describing what a vendor ships, from a service or deployment CBOM, describing what an operator runs in a particular configuration. The proposal is that intrinsic data is declared in the first and conveyed payload in the second, so that each fact is stated by the party competent to state it. That is the test the methodology applies throughout.

Proposed attributes

The following are candidates for a deployment-scope profile. Names follow the conventions in Method, and each is a fact the operator can state rather than a judgement about the result.

confidentialityLifetime carries most of the value. If the working group adopts one attribute from this list, that is the one, because it is the quantity the comparison needs and because the others qualify rather than supply it.

Bands, and why not dates

A date implies a precision the answer does not have. An operator asked how long clinical records must stay confidential will reasonably say decades, and a profile that demands a date invites either a fabricated one or an empty field. Bands also aggregate: a migration programme wants to know how many interfaces fall in the longest band, and that question is answerable across suppliers only if the bands are the same everywhere.

What stays outside the CBOM

The date at which a cryptographically relevant quantum computer is expected is not a fact about any product, and no CBOM should record it. It is an estimate that moves with published research and with national guidance, and a document that embedded it would be authoritative in appearance and wrong in substance within a year.

Under the treatment in Policy Evaluation, that estimate is an input to external versioned policy. The resulting urgency ranking is a derived judgement, computed at the time of asking, carrying the policy version and the date it was applied. This is the same treatment the methodology already gives post-quantum posture, so the machinery exists and no new mechanism is required.

Storage as well as transit

Discussion of this threat usually assumes network capture, and the transit case is the clearer one. Stored ciphertext is exposed in the same way and by a shorter route, since an adversary that obtains a backup has the recording without needing to intercept anything. Storage interfaces are already within the model, and the storage value in the interface type vocabulary exists for them. A deployment profile addressing this threat should require them to be declared, and the retentionAtRest attribute is where the duration is recorded.

Open points

• Whether data attributes are accepted as deployment scope only, and excluded from product CBOMs. This is the decision the rest of the section rests on.
• Where the band boundaries fall. The values above follow the periods that appear in published migration guidance, and the group may prefer others.
• Whether dataClassification earns its place, given that it cannot be aggregated across organizations and the classification schemes it draws on are not public.
• Whether storage interfaces need attributes of their own beyond retention.
• Whether a deployment-scope profile should be written as an extension of the interface disclosure baseline or as an independent profile. The composition rules in Profile permit either.