The PQC Gap Nobody Has Named: Why Discovery and Posture Management Are Not Enough
- Brian Couzens
- Jul 12
- 4 min read
July 12, 2026
The quantum threat isn't coming. It is already in your infrastructure.
PQC Discovery and PQC Posture Management are maturing fast, but neither can deliver a governed, evidence-driven transformation. The missing capability is Transition Orchestration: the programme architecture that validates and proves every cryptographic decision.
If your organization cannot prove every decision it makes, it does not control its cryptographic estate. It merely tracks it.
Hard Truth #1: Visibility Is Not Control
PQC Discovery tools answered the first question: Where is our vulnerable cryptography?
They scan networks, endpoints, applications, and firmware to inventory RSA, ECC, and Diffie-Hellman instances. They produce the Cryptographic Bill of Materials (CBOM). They triage risk. They create vendor accountability.
But discovery is a point-in-time exercise.
A CBOM is not a migration plan.
Discovery tells you what existed when the scan ran. It does not tell you whether remediation will break production, what sequence avoids catastrophic dependency failure, or how to handle live protocol negotiation.
Discovery gives you a map. It does not give you a strategy.
Hard Truth #2: Posture Management Executes Tasks. It Does Not Validate the Programme.
PQC Posture Management evolved naturally from discovery. It wraps inventory in continuous monitoring, risk scoring, policy enforcement, and executive dashboards. It integrates with ITSM, GRC, and CI/CD. It tracks migration roadmaps, triggers remediation workflows, and renders compliance scores.
This is real operational capability. It is also architecturally bounded.
Posture management platforms execute tasks: swap this algorithm, rotate that certificate, flag that deviation. They automate workflow. They accelerate activity.
What they do not do is govern the integrity of the decision chain that makes that activity valid.
Posture management assumes the assets it monitors are already compatible, already sequenced correctly, and already governed by a programme architecture it did not build. It can tell you a wave is 80 percent complete. It cannot tell you whether the 20 percent remaining contains a vendor certification gap that invalidates the entire wave.
It can enforce policy. It cannot prove the policy was derived from a valid architecture.
It can track interoperability tests. It cannot mandate that interoperability passes before production transition.
Posture management gives you the toolkit to migrate. Transition orchestration gives you the programme architecture to prove the migration was valid.
This is not a feature gap in posture platforms. It is a category distinction between task execution and governed transformation.
Hard Truth #3: The Missing Middle Is Not a Feature. It Is a Missing Category.
This is the gap I see in every PQC strategy conversation:
Discovery finds crypto.
Posture management executes migration tasks and monitors progress.
But who validates the decision chain, governs the sequence, and proves the transition would survive regulatory scrutiny?
This is not project management. Project management tracks tasks and deadlines. It does not validate cryptographic dependencies, interoperability boundaries, vendor certification chains, and rollback viability as binary evidence gates.
The missing capability is Transition Orchestration.
I am proposing this as a defined category: the governed, evidence-driven programme layer that sits between discovery output and posture management dashboards. It is the architecture that ensures the toolkit is applied correctly, in the right sequence, with evidence that survives audit.
What Transition Orchestration Actually Does
1. It governs decision-chain integrity, not task completion.
Every PQC decision creates downstream dependencies: algorithm selection, vendor certification, protocol interoperability, regulatory alignment, rollback viability. One broken link invalidates the wave.
Transition orchestration validates the chain is intact before the next decision is made. When a vendor fails certification, it triggers board escalation, not a Jira ticket. When interoperability fails in staging, it blocks the wave.
Decision-chain integrity is the real PQC bottleneck.
2. It operates in binary gates, not phases.
No progression without validated evidence. A wave does not move to production until interoperability is tested, rollback is exercised, and regulatory alignment is confirmed. "Close enough" is not a category.
3. It sequences risk, not convenience.
Migration executes in waves ordered by sensitivity, data longevity, exposure, and regulatory visibility. The first wave addresses the highest-risk assets, not the easiest ones. Vendor-constrained assets are governed explicitly, not hidden in spreadsheet footnotes.
4. It validates interoperability before production, not after.
Interoperability is not a checkbox. It is a continuous test.
Two endpoints may both claim ML-KEM support. Transition orchestration tests whether they negotiate correctly through your load balancers, WAFs, and API gateways under operational load. It produces evidence that survives audit, not just engineering review.
5. It builds cryptographic agility as architecture, not vendor promise.
Agility is the ability to swap algorithms rapidly without service disruption. Transition orchestration defines the swap procedure, tests it, enforces it at the CI/CD layer, and documents it as evidence. Non-agile builds are rejected before staging.
The Three-Layer Model
Discovery - Visibility and Inventory - "Where is our crypto?" Transition Orchestration - Validation and Execution - "Will the decision chain hold?" Posture Management - Governance and Monitoring - "Are we compliant and on track?"
Without the middle layer, organizations risk a dangerous illusion: perfect visibility into an actively managed environment that still breaks when PQC is actually turned on, because no one proved the decisions were valid.
The Closing Argument
PQC transformation is not a visibility problem. It is not a tooling problem.
It is a proof problem.
Every transformation programme eventually reaches the point where knowing is no longer the constraint, and tooling is no longer the constraint.
The organizations that succeed will not be the ones with the best inventories or the most elegant dashboards.
They will be the ones that can repeatedly prove, validate, and govern every cryptographic decision they make.
Transition Orchestration is how that happens.
For organizations navigating PQC transformation at enterprise scale, the governed execution layer is not optional. If you are building a programme that must survive regulatory audit and operational reality, I welcome the conversation.
Brian Couzens brian.couzens@sitg-consulting.com
Comments