High-Side Data: Your First PQC and Modernisation Target

Not long-lived data vulnerable to HNDL.

Three things sit inside your high-side enclave right now. A real-time targeting feed. A token-signing key. A cross-domain guard.

None of them will appear in your long-lived data inventory, because none of them are long-lived.

Compromise any one and the consequence is immediate, severe and irreversible.

Ask a PQC programme what it is protecting and you will hear about long-lived data and harvest-now-decrypt-later. Correct, and incomplete. A retention filter cannot see those three assets by construction, because retention is the filter.

That gap has a name.

What high-side data is

High-side data lives on a classified or restricted segment operating above the level of the systems and users on the low side. It cannot be moved, queried or exposed outside the enclave without explicit downgrading, sanitisation or a cross-domain transfer.

Five properties define it. Retention is not among them.

1. Classification level

2. Enclave isolation

3. Cross-domain controls

4. Cryptographic immobility

5. Consequence of compromise

The taxonomy that fixes the sequencing problem

Long-lived data is a vulnerability class. Defined by retention window: multi-year confidentiality requirements, adversary incentive to store ciphertext. It is what makes HNDL viable. It can sit anywhere, including low-side cloud storage.

Short-window data is defined by short retention. Confidentiality matters for minutes or hours. Adversaries gain nothing from storing it. HNDL does not apply.

High-side data is a consequence class. Defined by classification, isolation, immobility and blast radius. It can be either of the above.

Some high-side data is long-lived: mission archives, intelligence holdings, provenance logs. Some is short-window and catastrophic: real-time targeting data, operational telemetry, identity tokens. The two overlap. They are not synonyms.

Where the retention filter fails twice

It under-ranks. Applied honestly, the long-lived criterion returns medical records, personnel files, intellectual property, financial archives, statutory holdings. It identifies what is eligible for harvesting and ranks none of it. The output is a spreadsheet, not a sequence.

It omits. Short-window high-side data is invisible to a retention-based filter by construction. Its quantum exposure is real, but it is not a confidentiality exposure. Break the crypto protecting a targeting feed or a token-signing key and the failure is integrity and governance: forged instructions, spoofed identity, decisions made on material an adversary authored. No decrypt-later timeline. Damage contemporaneous, and no rollback, because you cannot retrospectively establish what was genuine.

HNDL is the mechanism. Long-lived data is the vulnerability class. Neither sets priority. They describe exposure.

Federal policy already works this way

None of this is a proposal. Consequence-based prioritisation is now the stated basis of US federal PQC policy, and the definition is explicit about it.

Executive Order 14412, signed 22 June 2026, sets the systems to migrate first as High Value Assets and high impact systems. A high impact system is one where at least one security objective, confidentiality, integrity or availability, carries a FIPS 199 impact value of high.

Integrity and availability sit alongside confidentiality. The organising criterion is consequence of compromise. Retention window is not mentioned.

Immobility is now a mandated prioritisation criterion

The implementing memorandum sharpens it, and picks up the fourth of the five properties.

OMB Memorandum M-26-15, issued 24 June 2026, requires risk-based prioritisation of high impact systems, HVAs, and systems judged particularly vulnerable to CRQC attack. It names logical access control systems built on asymmetric cryptography, PKI among them, as candidates. Then it goes further: systems incapable of supporting PQC or hybrid cryptography must be identified and given priority for replacement or decommissioning.

Immobility is no longer an excuse for deferral. It is now a trigger for prioritisation.

NSA reached the same conclusion earlier and said why. Asked in its CNSA 2.0 FAQ why firmware signatures are more urgent than general encryption, the answer is immobility, not duration:

"In many firmware-signing cases the validation algorithm is not easily updated. Thus, firmware-signing algorithms are frequently locked in for the life of a system."

Two regulators, one criterion, and it is not retention.

Three tracks, and high side is on the slowest

Here is the tension nobody is costing in.

M-26-15 does not apply to national security systems. EO 14412 routes them separately: the NSA reports on NSS migration status to the President, and the federal civilian deadlines do not bind them.

So the civilian track gets firm dates. HVAs and high impact systems must use PQC for key establishment by 31 December 2030 and for digital signatures by 31 December 2031. The FAR is being amended to require covered contractors to comply with PQC-incorporating FIPS by 31 December 2030.

The high-side estate runs on CNSA 2.0 instead. Firmware signing and traditional networking equipment exclusively CNSA 2.0 by 2030. Operating systems, niche and constrained equipment, large PKI systems, and custom or legacy applications by 2033. Full NSS transition by 2035.

Some high-side systems will move sooner. Procurement gates bite from 2026 onward, and anything designated an HVA or caught by CSfC and NIAP profile updates gets pulled forward. Those are the exceptions. For the bulk of the classified estate, the schedule sits later than the civilian one, on the material with the highest consequence of compromise.

Then there is the third track, and it is the fastest. Microsoft pulled its quantum-safe target from 2033 to 2029. Google set 2029. Cloudflare followed in April 2026. None of that is law. It is market signal. It matters to high-side estates for one reason: they run on commercial products they do not control.

Microsoft's stated position is that by 2029 new connections, code signatures and data-at-rest encryption rely solely on approved PQC algorithms, with quantum-vulnerable ciphers deprecated. NIST IR 8547, the transition document M-26-15 requires agency migration plans to align with, lists RSA and elliptic-curve algorithms as deprecated after 2030 and disallowed after 2035. It remains an initial public draft, which is itself worth noting: federal migration plans are being written against a document that has not been finalised.

Set that against a classified estate whose custom and legacy applications have until 2033. The cryptography inside the enclave is formally deprecated before the enclave's own deadline to replace it.

Why interoperability makes this worse, not just awkward

Guards, key management systems, HSMs, operating systems and network equipment inside high-side enclaves are commercial products. As vendor defaults move to PQC-preferred and then PQC-only, an accredited platform that cannot negotiate PQC does not fail loudly. It negotiates downward.

That is the actual exposure. An endpoint that supports ML-KEM but still permits a classical-only handshake remains open to downgrade attack, because an adversary can force the session back to quantum-vulnerable key exchange. Classical support cannot be switched off while anything still needs it.

So a high-side enclave running classical cryptography past 2030 does not only carry its own risk. It obliges every counterparty it touches, coalition links, cross-domain transfers, managed transport, to keep quantum-vulnerable options enabled in order to talk to it. SSLv3 is the precedent: deprecated after POODLE in 2014, kept alive for years by the endpoints that could not move, and exploitable throughout precisely because it was kept alive.

The immobile estate does not simply miss its own deadline. It becomes the reason the wider system cannot close the window.

Three things the air gap does not protect against

An air gap stops remote access. It does not undo prior exfiltration. What has been harvested is harvested.

High-side data does not stay still. It moves between enclaves, sites, platforms and coalition partners over encrypted links carried on satellite, radio and leased infrastructure you do not own. Classical algorithms, transport you cannot audit. That harvest surface sits outside the enclave.

An air gap complicates revocation. Software entering the enclave arrives signed, and an isolated system cannot reach an external OCSP responder. Internal mirrors and manually imported CRLs mitigate this, and mature programmes run them. They do not eliminate it: revocation intelligence arrives on a human cycle rather than a live one, which widens the window in which a forged artefact validates cleanly. Isolation makes forgery harder to detect, not easier.

Add the boundary itself. Diodes enforce one-way flow physically and are largely indifferent to quantum. Guards are not. Guards performing signature validation during content inspection are cryptographic dependencies at the highest-trust boundary in the architecture, and they rarely carry that weight in a CBOM.

Where to start

Split the enclave by exposure type. Long-lived holdings need confidentiality migration to ML-KEM. Short-window material needs integrity and identity migration to ML-DSA. Different work, different urgency, different algorithms. M-26-15's own phasing splits key establishment from signatures for exactly this reason.

Map every encrypted link carrying high-side data across infrastructure you do not control. Usually worse than the at-rest picture.

Treat cross-domain guards as trust anchors, not plumbing.

Inventory hardware-bound key material first, because it constrains your options before you have chosen any. Under M-26-15 logic, anything that cannot take PQC or hybrid is a replacement decision, and that is a procurement lead time, not a patch cycle.

Ask your vendors what happens to classical support in 2029, not 2033. The answer determines whether your accredited platforms still have a supply chain, and whether your peers can close their downgrade paths.

For long data-life concerns on immobile platforms, NSA's CSfC position is that pre-shared symmetric keys implemented to established standards are a better near-term measure than experimental asymmetric algorithms. Symmetric crypto at sufficient key length is quantum-resistant. It buys cover while replacement is procured.

The one-sentence version

EO 14412 prioritises by consequence, including integrity, not by retention window. High-side data is the estate where that criterion bites hardest and the timeline runs longest. Migrate the archive by all means, but do it after the targeting feed, the token-signing key and the cross-domain guard.

The SITG Comment

Retention windows are easy to inventory, which is precisely why programmes start there. Consequence is harder, because it requires someone to say out loud which systems the organisation cannot function without, and to accept the cost of fixing those first. That is a governance decision, not a cryptographic one, and it is the reason so many CBOM exercises produce an asset register rather than a migration order.

High-side data is where the avoidance shows up clearly. It carries the highest consequence of compromise, the least cryptographic mobility, and the longest permitted timeline. Nothing about that combination is accidental. It is what happens when isolation is treated as a substitute for agility, and when the estates hardest to change are the ones handed the widest deadline.

The window is not 2033. It is the procurement cycle you are in now. Hardware-bound cryptography is replaced on capital timescales, commercial classical support disappears from 2029, and provenance you cannot verify today cannot be reconstructed later. Every quarter spent triaging by retention is a quarter not spent on the assets that determine whether the organisation can still prove what is genuine.

Name your high-side data. Map its trust anchors. Fund those first. Everything else in the CBOM is sequencing, and sequencing is cheap once the order is right.

Author. Brian Couzens, SITG Consulting.

Opinion. The analysis, the high-side data framing and the taxonomy set out here are my own. They do not represent the views of any client, partner or other organisation. This article is commentary and general information. It is not legal, regulatory, procurement or security advice, and it is no substitute for assessment of your own environment by people who can see it.

Use and attribution. Quotation, citation, discussion and sharing are welcome, with attribution to Brian Couzens, SITG Consulting, and a link to the original article. Reproduction in full, adaptation into derivative work, or use within commercial training, marketing or advisory material requires prior written permission. Enquiries: brian.couzens@sitg-consulting.com

Currency of sources. Regulatory positions are stated as at 30 July 2026 and are drawn from primary sources: Executive Order 14412 (22 June 2026), OMB Memorandum M-26-15 (24 June 2026), NSA CNSA 2.0 and the CNSA 2.0 FAQ (April 2024, Ver 2.0), and NIST IR 8547. NIST IR 8547 remains an initial public draft. Vendor timelines are drawn from public reporting rather than vendor documentation. Timelines, drafts and guidance are subject to revision. Verify against the primary sources before relying on any date in planning or procurement.

© 2026 Brian Couzens, SITG Consulting. All rights reserved.

PQC Discovery Sprint | Sitg-Consulting