The SOC Quantum Playbook: Detection Rules, Threat Intelligence, and Incident Response

One of the most common questions I hear from CISOs starting their PQC migration is deceptively simple: “What should my SOC be doing?”

The answers they typically get are vague. “Monitor for quantum threats.” “Stay aware of developments.” “Integrate quantum risk into your processes.” This is the security equivalent of telling someone to “eat healthy” — technically correct, operationally useless.

The uncomfortable reality: most enterprise SOCs today have zero quantum-specific detection capability, no playbooks for cryptographic algorithm compromise, and no systematic way to verify that systems migrated to post-quantum cryptography (PQC) stay migrated. The monitoring gap is wide, and closing it requires specific engineering work, not just awareness briefings.

Part of the reason is that existing PQC migration frameworks do not give SOC teams much to work with. The QUASAR framework (Weinberg, 2025), for example, notes that “security monitoring should be integrated with existing Security Operations Centers” and that organizations should “leverage automated detection tools, such as Intrusion Detection Systems and anomaly detection models, to quickly identify potential risks.” That is a correct statement of principle. But it does not tell a SOC director what detection rules to write, what thresholds to set, what playbooks to develop, or how to structure a CTI function for quantum threats. NIST’s NCCoE PQC Migration project and Australia’s ASD PQC guidance similarly focus on the migration program itself, with monitoring treated as a post-deployment checkbox rather than a developed operational discipline.

To the best of my knowledge, no published framework or guidance document has operationalized SOC responsibilities for quantum security to the level of specific detection rules, illustrative metrics and thresholds, CTI source requirements, and incident response playbooks. My own Applied Quantum PQC Migration Framework and my book Quantum Ready are an attempt to fill that gap. This article is a summary of those. It walks through the detection use cases, the threat intelligence requirements, the incident response playbooks, and the illustrative metrics that a large enterprise SOC with an integrated cyber threat intelligence (CTI) function should be developing now. I also try to be honest about where the challenges are, where existing tooling falls short, and what is realistic to implement in 2026 versus what requires multi-year investment.

At Applied Quantum, we have developed and deployed these operational processes in detail with enterprise clients through our Secure Quantum practice, and this article reflects lessons from that work. If you find it useful, and especially if you build on it in your own frameworks or methodologies, I would appreciate a citation. I have watched too many of my first-of-kind contributions (the CRQC Quantum Capability Framework, the PQC Migration Framework) appear uncredited in consulting slide decks within months of publication. All I ask is attribution.

The bottom line: quantum security for the SOC is mostly an extension of what good SOCs already do (cryptographic protocol monitoring, data exfiltration detection, certificate management, supply chain integrity verification), but with new detection rules, recalibrated prioritization, and a set of incident response scenarios that most teams have never rehearsed. The biggest single gap is not exotic quantum-specific technology. It is that most SOCs lack operationalized access to the cryptographic inventory. Without knowing which systems should be running ML-KEM (formerly CRYSTALS-Kyber) right now, none of the detection use cases described below actually work.

Why the SOC, and Not Just GRC?

A reasonable objection: isn’t quantum security a governance, risk, and compliance (GRC) problem? Should it live with the CISO’s risk function rather than in the SOC?

Both need to be involved, but they do different things. The GRC function owns the cryptographic inventory, sets migration priorities, tracks compliance with regulatory deadlines like CNSA 2.0 milestones and the EU’s coordinated PQC transition roadmap, and reports to the board on migration progress. That work is essential, and I have covered the CISO’s quantum responsibilities in my PQC Governance Deep Dive and Getting Started with Quantum Security series.

The SOC’s job is different. The SOC detects, investigates, and responds. It watches for attacks in progress, spots anomalies that suggest compromise or misconfiguration, and activates playbooks when something goes wrong. For quantum security, “something going wrong” includes a range of scenarios that have no equivalent in the SOC’s current playbook library: a cryptanalysis paper drops showing a weakness in a deployed PQC algorithm, a hybrid implementation is silently downgraded to classical-only cryptography, or network monitoring reveals patterns consistent with large-scale data harvesting targeting assets with long secrecy requirements.

In large enterprises, the SOC also houses the cyber threat intelligence (CTI) team, and this is where the organizational boundaries get interesting. A mature CTI function operates across the full tactical-operational-strategic spectrum, from tracking new malware campaigns to assessing how geopolitical shifts affect the organization’s threat profile over a three-to-five-year horizon. Tracking CRQC timeline developments, monitoring cryptanalytic research, and assessing which state programs are accelerating quantum capabilities — this work fits naturally within the CTI function. The GRC team consumes that intelligence and makes governance decisions based on it. The CTI team produces it.

So the short answer is that both the GRC function and the SOC have quantum responsibilities, and neither can do the other’s job. The longer answer is the rest of this article.

Operational Detection: Five Use Cases

The SOC’s operational contribution to quantum security centers on detection capabilities that can be built on top of existing infrastructure, primarily the SIEM, network monitoring tools, and certificate management systems already in place. SOC engineers familiar with TLS monitoring and DLP rules will recognize these use cases as extensions of what they already do; none requires exotic quantum-specific technology.

1. Hybrid Downgrade Detection

Organizations deploying hybrid PQC implementations (classical plus post-quantum algorithms running together) face a specific attack vector: an adversary forcing a connection to fall back to classical-only cryptography. This is directly analogous to the TLS downgrade attacks that SOCs have monitored for years, and the detection approach is similar.

The SOC should have SIEM correlation rules that flag connections negotiating classical-only cipher suites when the expected configuration is hybrid. A TLS 1.3 session between two systems that both support ML-KEM should not be completing a handshake using only ECDH. If it does, that is either a misconfiguration (the benign but still important case) or an active downgrade attack.

What this requires in practice: The migration program must feed the SOC a continuously updated registry mapping systems to their expected cryptographic posture: which endpoints, services, and connections should be running hybrid, which are still classical-only pending migration, and which have completed full PQC transition. Without this registry, the SOC cannot distinguish a downgrade from a system that has not been migrated yet. Building and maintaining this mapping is the single largest prerequisite for quantum detection capability, and in my experience, it is the step that most organizations skip.

Illustrative detection rule: Alert when a TLS handshake between two endpoints listed as “hybrid-enabled” in the cryptographic posture registry completes using a cipher suite that does not include an ML-KEM or other PQC key exchange component. Severity: High. Expected false positive rate in a well-maintained environment: low (5-10%), because both endpoints are confirmed PQC-capable, so a classical-only handshake is unexpected. In a poorly maintained registry: high, because stale entries will generate noise constantly.

Honest caveat: Most network monitoring tools and SIEM platforms cannot yet parse hybrid PQC identifiers natively. In TLS 1.3, hybrid key exchanges are negotiated using IANA-assigned NamedGroup codepoints (not X.509 OIDs, which apply to certificate signature algorithms). The NamedGroup values for ML-KEM-768, ML-KEM-1024, and the hybrid key exchange groups need to be added to the SOC’s traffic analysis rules manually. As of mid-2026, this is custom engineering work, not a checkbox in your SIEM vendor’s configuration panel. Expect this to improve as vendors update their protocol parsers, but plan for manual rule development in the near term.

A related operational warning: the most common source of false positives in hybrid downgrade detection will be the organization’s own infrastructure, not adversaries. PQC key encapsulations are significantly larger than classical ECDH ephemeral keys, and hybrid TLS ClientHello messages frequently exceed the size that legacy firewalls, secure web gateways, and SSL inspection proxies can handle without fragmentation. These middleboxes may drop fragmented handshakes or strip unrecognized extensions, forcing a classical-only fallback that looks identical to a downgrade attack. Detection rules must account for benign middlebox-induced downgrades, and the migration program should flag middlebox upgrades as a prerequisite for reliable hybrid deployment.

2. Cryptographic Drift Monitoring

Migration is not a one-time event. After an organization migrates systems to PQC, those systems drift. A developer deploys a new microservice using a classical-only TLS library because that is what the tutorial showed. An IT team restores a database server from a pre-migration backup. A SaaS integration uses an API endpoint that quietly reverts to RSA key exchange after an update. Shadow IT operates entirely outside the migration program’s scope.

The SOC is positioned to catch this drift through continuous network monitoring: flagging connections using deprecated cipher suites that the migration program has marked for retirement. Think of it as continuous compliance verification at the network layer, operating in real time rather than in quarterly audit cycles.

What this requires in practice: A baseline of expected cryptographic posture (the same registry as Use Case 1, or a shared data source) and network tap or flow data that captures enough of the TLS handshake to identify the negotiated cipher suite. Most enterprise network monitoring platforms can do this for classical cipher suites today. Extending to PQC cipher suites requires updating the protocol definitions.

Illustrative detection rule: Alert when any internal endpoint initiates or accepts a TLS session using a classical-only key share (e.g., a standard ECDH NamedGroup without a PQC component) with a system classified as “migration complete” in the inventory. Severity: Medium (likely misconfiguration) escalating to High if the same endpoint generates repeated classical-only sessions across multiple connections. A single instance probably means a misconfigured service; a pattern suggests either systematic regression or an application that was missed during migration.

Illustrative metric: Percentage of monitored TLS sessions using PQC or hybrid cipher suites versus classical-only, measured weekly. Tracked as “Cryptographic Migration Coverage” on a SOC dashboard. Target: monotonically increasing toward 100% for in-scope systems, with any regression investigated within 24 hours.

Honest caveat: Measuring this accurately requires visibility into internal east-west traffic, not just north-south perimeter flows. Many SOCs have limited internal traffic inspection capability, particularly in cloud-native environments where service mesh encryption happens at the application layer. Extending visibility is a prerequisite that may require infrastructure investment beyond the SOC’s budget authority.

3. Certificate Lifecycle Anomalies

PQC migration involves a wholesale transition of certificate infrastructure. Organizations are issuing new certificates using PQC signature algorithms (ML-DSA, SLH-DSA), reconfiguring certificate chains, and in many cases standing up new intermediate Certificate Authorities to support the PQC hierarchy alongside the legacy one during the transition period.

This transition creates a window of elevated risk that the SOC should be monitoring closely. Specific detection targets include: failed certificate chain validations involving PQC certificates (which may indicate interoperability issues or deliberate manipulation), unauthorized certificate issuance during the transition (the operational chaos of migration provides cover for an adversary slipping in a rogue certificate), and certificate expiration management across both the legacy and PQC certificate hierarchies running in parallel.

Illustrative detection rules:

Alert on any certificate issuance event from the organization’s internal CA that uses a PQC signature algorithm not on the approved list. During the transition, organizations may authorize ML-DSA-65 and ML-DSA-87 but not yet SLH-DSA; any SLH-DSA certificate issuance would be unexpected and warrants investigation. Severity: High.

Alert on certificate validation failures where the root cause is a PQC-related chain issue (unknown algorithm OID, unsupported signature scheme in the validator). These may indicate systems that have not been updated to recognize PQC certificates, or they may indicate certificate manipulation. Severity: Medium, with investigation required to determine root cause.

Alert on any CA signing key access or usage event occurring outside scheduled certificate issuance windows, particularly during the transition period. Severity: Critical.

Honest caveat: Certificate transparency (CT) monitoring for PQC certificates is still immature. Most CT log monitors are built for the classical certificate ecosystem, and the tooling for monitoring PQC-specific certificate issuance is still catching up. The SOC may need to build custom monitoring around the organization’s internal CA logs rather than relying on external CT infrastructure.

4. TNFL and Signature Integrity Monitoring

I have argued extensively, starting in 2018, that the quantum threat to digital signatures — what I call Trust Now, Forge Later (TNFL) — may prove more disruptive than the better-known Harvest Now, Decrypt Later (HNDL) threat to encryption. HNDL compromises data created in the past. TNFL enables an adversary to take actions in the present: forging software updates, fabricating financial instructions, impersonating trusted parties. The tabletop exercises I have conducted with governments and enterprises on this topic consistently produce outcomes that participants describe as sobering, because they reveal how many automated systems accept signed inputs without human verification and how rapidly a signature compromise cascades.

For the SOC, this translates to heightened monitoring of code signing events, software update authentication, and systems that depend on automated signature verification.

What this requires in practice: Integration with the organization’s code signing infrastructure, software distribution systems, and any platform that relies on digital signature verification for trust decisions (firmware updates, financial transaction authorization, identity federation). The SOC needs visibility into signing events: who signed what, when, using which key, from which system.

Illustrative detection rules:

Alert on code signing events using unexpected signing keys, unexpected signing identities, or signing events occurring at unusual times. A code signing event at 3 AM from an IP address not associated with the build pipeline warrants immediate investigation. Severity: Critical.

Alert on any modification to signature verification policies in production systems — for example, a configuration change that disables signature checking on firmware updates or software deployments. Severity: Critical.

Monitor for anomalous signing volume: a sudden spike in certificate signing requests or code signatures may indicate automated exploitation of a compromised signing key. Establish a baseline of normal signing activity and alert on deviations exceeding two standard deviations. Severity: High.

Illustrative metric: Mean time to detect an unauthorized signing event (MTD-Signing). Target: under 15 minutes for code signing events associated with production deployments. Measured through periodic red team exercises where the security team simulates a signing key compromise and measures detection latency.

Honest caveat: Most organizations do not have centralized visibility into all signing events across their estate. Code signing may be managed by the development team, firmware signing by the OT team, and certificate signing by the PKI team, each with separate logging and alerting. Unifying these into a single SOC-monitored view requires cross-functional cooperation that is often harder to achieve than any technical integration.

5. Enhanced HNDL-Indicator Detection

The HNDL threat is active today. Adversaries (primarily nation-state intelligence services) are intercepting and storing encrypted data for future quantum decryption. The SOC’s role is to detect the indicators of this harvesting activity: patterns of data exfiltration weighted by the sensitivity and longevity of the data being targeted.

This is the same data exfiltration monitoring that SOCs already perform, but with a quantum-informed reprioritization. A slow, sustained exfiltration of archived diplomatic correspondence or pharmaceutical R&D data is potentially more damaging in a quantum context than a one-time dump of transactional data, because the long-lived data retains its value across the decryption timeline. The quantum framing does not change what the SOC monitors; it changes how they prioritize and escalate.

What this requires in practice: Data classification that identifies assets with long secrecy requirements (typically 10+ years of confidentiality value), mapped to network segments and storage systems. The SOC combines this classification with existing data loss prevention (DLP) and network anomaly detection to weight alerts from high-value, long-lived data stores more heavily.

Illustrative detection rules:

Alert on sustained outbound data transfers from network segments hosting data classified as having secrecy requirements exceeding 10 years (e.g., R&D archives, legal records, strategic planning documents, IP portfolios), even if the transfer volume per session is below traditional DLP thresholds. A 50 MB daily trickle from a strategic archive is more concerning than a 5 GB file transfer from a marketing asset library. Severity: High.

Alert on bulk access patterns to archival storage by service accounts or user accounts that do not normally access those systems. Correlate with VPN and authentication logs to identify potential credential compromise targeting specifically long-lived data. Severity: High.

Illustrative metric: “HNDL Exposure Score” — a composite metric tracking: the percentage of high-secrecy-requirement data stores with active DLP coverage, the mean time to detect anomalous access to those stores, and the percentage of data classified with secrecy-requirement metadata. Target: 100% coverage for data stores with 10+ year secrecy requirements, with mean detection time under 4 hours.

Honest caveat: The HNDL detection use case depends entirely on the quality of data classification. If the organization has not classified its data by secrecy requirement duration (and most have not), then the SOC cannot weight alerts by HNDL relevance. The classification exercise is a prerequisite that typically belongs to the information governance function, not the SOC, but the SOC should be flagging the gap if it exists.

Cyber Threat Intelligence: Quantum Across Three Horizons

Large enterprise SOCs with integrated CTI teams operate across three horizons: tactical (hours to days), operational (weeks to months), and strategic (months to years). Quantum threat intelligence fits naturally across all three, but each level requires different sources, analytical skills, and outputs.

Tactical CTI

At the tactical level, the CTI team deals with specific, actionable indicators. In the quantum context, this includes:

Vulnerability disclosures in PQC implementations. When a CVE is published against a specific version of liboqs, or a side-channel vulnerability is discovered in a hardware vendor’s ML-KEM implementation, the CTI team must assess exposure and feed that assessment to the SOC for immediate triage. How many of our systems run the affected library? Which services are exposed? What is the compensating control while we patch?

Cryptanalysis papers with implementation impact. Not every arXiv preprint matters, but some do. When researchers identify a bug in a specific ML-DSA parameter set (as Daniel Bernstein’s work on ML-DSA highlighted), the CTI team evaluates whether the organization’s deployed implementations are affected and produces an actionable assessment for the SOC within hours.

Illustrative metric: Time from PQC vulnerability disclosure to CTI assessment delivered to SOC (TTAssess-PQC). Target: under 4 hours for vulnerabilities affecting deployed implementations; under 24 hours for vulnerabilities in algorithms the organization plans to adopt.

Required sources: NIST PQC mailing list, vendor security advisories, IETF working group notifications (particularly the pquip and lamps groups), CERT advisories, and curated cryptanalysis feeds. The challenge: most CTI teams are subscribed to threat intelligence feeds focused on malware, APT indicators, and vulnerability databases like NVD. PQC vulnerability information flows through different channels — academic mailing lists, cryptography conference proceedings, arXiv preprints — that CTI analysts may not be monitoring.

Operational CTI

Over weeks and months, CTI analysts track adversary campaigns and evolving tactics. In the quantum context:

Monitoring for changes in adversary collection patterns consistent with HNDL acceleration. If a tracked APT group shifts targeting from operational intelligence (short-lived value) toward strategic archives and R&D repositories (long-lived value), that behavioral change is potentially significant in a quantum context. The data itself tells you nothing about quantum — the significance comes from correlating targeting patterns with knowledge of which data would retain value post-quantum decryption.

Tracking supply chain indicators relevant to PQC. Are threat actors probing PQC library supply chains? Are there anomalous contributions to open-source PQC implementations? When the SOC sees a supply chain attack against a cryptographic library, the CTI team assesses whether the attack targets PQC-specific code paths.

Honest caveat: The operational CTI use cases for quantum are speculative at this stage. No publicly attributed campaign has been documented as specifically targeting PQC implementations for supply chain compromise (as of mid-2026). The monitoring is worth establishing, but CTI teams should size their effort proportionally. This is a watch-and-wait posture, not an active hunt.

Strategic CTI

This is where CRQC timeline tracking and quantum capability assessment live. Strategic CTI assesses threats over months to years and feeds directly into executive decision-making.

Tracking quantum hardware progress toward CRQC. The CTI team monitors developments across quantum computing modalities (superconducting, trapped ion, photonic, neutral atom, silicon spin) and assesses their implications for the CRQC Quantum Capability Framework dimensions: error correction, logical gate operations, decoder performance, continuous operation, and engineering scale. When Google publishes a new error correction result, or IonQ demonstrates a qubit connectivity milestone, the CTI team translates that into an updated risk assessment.

Monitoring national quantum programs. State investment in quantum computing is the primary driver of CRQC development. Tracking the progress of programs in the United States, China, the EU, Australia, Japan, South Korea, and others provides strategic warning of accelerating capability. My China’s Quantum Ambition series covers one dimension of this; the CTI team should be tracking all major national programs relevant to the organization’s threat model.

Monitoring cryptanalytic research trends. Resource estimation papers (like Gidney’s 2025 RSA-2048 paper reducing qubit requirements from 20 million to 4 million) and novel algorithmic approaches to cryptanalysis have direct implications for the organization’s migration urgency. The CTI team should be producing quarterly assessments of how the latest research affects the Q-Day timeline and what that means for the organization’s migration schedule.

Illustrative output: A quarterly “Quantum Threat Landscape Assessment” delivered to the CISO and the risk committee. The assessment covers: changes to CRQC timeline estimates based on the quarter’s developments, regulatory deadline updates (new mandates, shifted timelines), any cryptanalytic developments affecting deployed or planned algorithms, and recommendations for adjusting migration priorities. This is the intelligence product that connects SOC/CTI work to the governance layer.

Required sources and the skills challenge: Producing useful strategic quantum CTI requires reading arXiv preprints, understanding quantum error correction papers, interpreting resource estimation models, and evaluating hardware announcements against a technically grounded framework. This is a very different skill set from tracking APT infrastructure and malware families. Most CTI teams today do not have anyone with this background.

There are three realistic options: hire a specialist (expensive and scarce), train an existing analyst (possible but requires 6-12 months of dedicated development), or contract the analysis externally and integrate it into the CTI workflow (pragmatic for most organizations in the near term). My CRQC Quantum Capability Framework and the CRQC Readiness Benchmark are designed, in part, to provide a structured analytical framework that makes this assessment tractable for analysts who are not quantum physicists.

Incident Response: The Playbooks Nobody Has Written

The detection use cases above generate alerts. The playbooks define what happens when those alerts fire. Most SOCs have well-developed playbooks for ransomware, business email compromise, insider threat, and DDoS. Very few have playbooks for quantum-related incidents. Here are the scenarios that need them.

Playbook 1: PQC Algorithm Vulnerability Disclosure

Trigger: NIST, a CERT, or a credible research group publishes a vulnerability or weakness in a PQC algorithm or implementation deployed in the organization’s environment.

Immediate actions (0-4 hours): CTI team assesses the severity and scope of the vulnerability. Is this a full algorithm break (catastrophic) or an implementation bug in a specific library version (serious but contained)? SOC queries the cryptographic inventory to identify all systems running the affected algorithm or library. Initial impact assessment delivered to the CISO.

Short-term actions (4-48 hours): If the vulnerability is implementation-specific: initiate emergency patching per normal vulnerability management processes, prioritizing internet-facing and high-value systems. If the vulnerability affects the algorithm itself: activate the organization’s crypto-agility capabilities to begin algorithm rotation. This is the scenario that crypto-agile architecture exists to handle, and it is the reason I argue that migration should target crypto-agile architecture rather than simply swapping one algorithm for another.

Coordination requirement: The SOC cannot execute this playbook alone. It requires pre-established coordination between the SOC, the PQC migration program office, the application teams who own affected systems, and the CISO. The playbook should specify a named incident commander, a communication chain, and pre-authorized emergency change windows.

Illustrative drill metric: Time from vulnerability disclosure to completed impact assessment (all affected systems identified). Target: under 4 hours. Measured through annual tabletop exercise. If the organization cannot identify all affected systems within 4 hours, the cryptographic inventory is not operationalized for incident response.

Playbook 2: Confirmed Hybrid Downgrade Attack

Trigger: SOC detects and confirms (not a false positive) that a connection between two PQC-capable systems has been downgraded to classical-only cryptography by an external adversary.

Immediate actions: Isolate the affected network path. Preserve packet captures for forensic analysis. Determine the mechanism of downgrade: is it a man-in-the-middle modifying the TLS ClientHello, a compromised endpoint advertising only classical cipher suites, or a network device stripping PQC extensions? Assess the scope: are other connections being downgraded simultaneously?

Escalation: A confirmed downgrade attack is a strong indicator of an active, sophisticated adversary targeting the organization’s cryptographic infrastructure. Escalate to the CISO immediately and consider engaging external incident response support.

Playbook 3: Credible CRQC Announcement

Trigger: A credible entity (major government, well-funded quantum computing company with verified track record) announces the achievement of a CRQC capable of running Shor’s algorithm against production cryptographic key sizes.

This is the scenario everyone thinks about but nobody plans for concretely. If the organization has not completed its PQC migration by this point, the playbook is less about technical response and more about damage assessment and communication. Systems still running classical-only asymmetric cryptography should be treated as having no cryptographic protection for confidentiality and authenticity.

Immediate actions: Invoke crisis communication procedures. Work with the CISO to produce an impact assessment: what percentage of systems have been migrated? What data protected by classical-only algorithms has the highest sensitivity? What systems dependent on classical digital signatures are most vulnerable to TNFL exploitation? Activate emergency migration procedures for the highest-priority remaining systems.

I should note that this is actually the one playbook where the SOC’s in-the-moment response matters least and prior preparation matters most. The right time to have responded to this scenario was years earlier, through completing the migration program. The playbook exists because organizations need to plan for the possibility that migration is not complete when the announcement comes, which given current migration timelines, is a realistic scenario for many enterprises.

Playbook 4: Emergency Algorithm Rotation

Trigger: The organization initiates an emergency rotation of cryptographic algorithms, whether due to a vulnerability disclosure, a credible CRQC announcement, or a regulatory directive.

SOC’s role: The SOC’s primary responsibility during an algorithm rotation is to not mistake the rotation for an attack. An authorized emergency rotation produces a burst of activity that, without context, looks suspicious: mass certificate revocations and reissuances, sudden changes in negotiated cipher suites across the estate, and a spike in key management system activity. The SOC needs to be briefed on the rotation schedule and scope, with suppression rules in place for expected activity, while maintaining detection for actual adversary activity that might be timed to exploit the operational confusion of a rotation.

Illustrative metric: False positive rate during algorithm rotation drills. Target: less than 10% of rotation-related alerts escalated as potential security incidents. If the rate is higher, the SOC’s contextual integration with the migration program is insufficient.

Tabletop Exercises: Testing What You Cannot Simulate in Production

Playbooks exist on paper until they are exercised. The tabletop exercises below are designed specifically for SOC and CTI teams and should be run at least annually, with the PQC migration program office, the CISO, and relevant application owners participating. At Applied Quantum, we run variants of these exercises with enterprise clients, and the pattern is consistent: teams discover coordination gaps and assumption failures that were invisible in the written playbooks. The value is in the discovery, not in the score.

Exercise 1: The Friday Afternoon CVE. Scenario: A critical CVE is published at 16:30 on a Friday against the specific version of liboqs deployed in the organization’s production TLS termination layer. The CVE describes a side-channel vulnerability that allows key recovery under specific conditions. The exercise tests: Can the SOC identify all affected systems within 4 hours using the cryptographic inventory? Does the CTI team produce a severity assessment that distinguishes “theoretical under lab conditions” from “actively exploitable”? Who authorizes emergency patching outside the normal change window? What compensating controls can be activated while the patch is tested? Measure time from simulated disclosure to completed impact assessment, and separately time from assessment to compensating control activation.

Exercise 2: The Ambiguous Cryptanalysis Paper. Scenario: An arXiv preprint from a credible research group claims a polynomial-time attack against ML-KEM at security level 3. The paper has not been peer-reviewed. Within 24 hours, two well-known cryptographers post rebuttals on social media calling the claim flawed, but a third suggests the core observation may hold for a restricted class of parameters. The exercise tests: How does the CTI team evaluate the credibility and relevance of the claim? At what point does the SOC escalate to the CISO? Does the organization have a defined threshold for when an unreviewed cryptanalysis claim triggers operational action versus a monitoring posture? What communication goes to the board if media coverage amplifies the story before peer review settles it?

Exercise 3: Silent Downgrade. Scenario: Routine SOC monitoring detects that a cluster of internal services (payment processing, customer authentication) have been negotiating classical-only TLS handshakes for the past 72 hours, despite being marked as “hybrid-enabled” in the cryptographic posture registry. Investigation reveals the downgrade coincided with a routine load balancer firmware update from a third-party vendor. The exercise tests: Was the downgrade detected by automated rules or only noticed manually? How does the SOC determine whether this was a vendor misconfiguration or an adversary exploiting the update window? What data traversed those connections during the 72-hour gap, and does it fall into HNDL-relevant categories? Who is responsible for validating that vendor updates preserve the expected cryptographic posture?

Exercise 4: The CRQC Announcement. Scenario: A credible national laboratory announces the demonstration of Shor’s algorithm factoring a 1024-bit RSA key in under 8 hours. Independent verification is expected within weeks. The exercise tests: What is the immediate communication chain? Which systems still depend on RSA or ECC for key exchange or signatures? How quickly can the organization produce an exposure assessment for the board? What emergency migration steps are available for the highest-priority systems? Is there a pre-drafted external communication for customers, partners, and regulators? This exercise is the most valuable one to run, because it exposes the consequences of delayed migration in concrete operational terms. Organizations that complete this exercise typically accelerate their migration timelines within the following quarter.

Exercise 5: Signing Key Compromise. Scenario: The SOC detects an unauthorized code signing event using the organization’s production signing key. The signed artifact is a firmware update that has already been distributed to three branch office network devices. The exercise tests: Can the SOC determine what was signed and whether the artifact is malicious? What is the rollback procedure for deployed firmware? How does the organization revoke the compromised signing key without disrupting all legitimate signed artifacts? How long does it take to re-sign and redistribute clean firmware? This exercise directly tests the TNFL threat scenario in operational terms.

For each exercise, document the findings in a structured after-action report: what worked, what broke, what assumptions proved incorrect, and what changes are required to playbooks, detection rules, or organizational coordination. The after-action report is the output that justifies the exercise.

Skills, Tooling, and the Readiness Gap

I have described five detection use cases, three CTI horizons, four incident response playbooks, and five tabletop exercises. Implementing all of them requires capabilities that most SOCs do not have today. Here is an honest assessment of the gaps.

The Cryptographic Inventory Gap

Every detection use case above depends on the SOC having access to a queryable, up-to-date cryptographic inventory that maps systems to their expected cryptographic posture. In practice, the cryptographic inventory (if one exists at all) usually lives in a GRC spreadsheet, updated quarterly, and not accessible to the SOC’s detection infrastructure. Bridging this gap — making the inventory machine-readable and integrated with the SIEM — is prerequisite work. Without it, the SOC is flying blind on quantum.

I cannot overstate this. The detection rules I have described are straightforward engineering. The inventory integration is the hard part, and it is an organizational challenge as much as a technical one.

The Protocol Parsing Gap

Most SIEM platforms, network detection tools, and TLS inspection devices cannot yet parse PQC cipher suite identifiers, hybrid key exchange groups, or PQC-specific TLS extensions. Vendors are updating their products, but as of mid-2026, many SOCs will need custom Suricata rules, Zeek scripts, or SIEM enrichment pipelines to extract and correlate PQC-relevant handshake parameters. Plan for 2-4 weeks of engineering effort to build and test these custom rules, with ongoing maintenance as PQC implementations evolve.

The CTI Skills Gap

Tactical PQC CTI (monitoring vulnerability advisories, tracking library updates) can be handled by existing analysts with modest training. Operational CTI (correlating adversary targeting patterns with HNDL relevance) requires an analyst with both threat intelligence tradecraft and an understanding of data classification and quantum threat models. Strategic CTI (evaluating quantum hardware milestones, interpreting resource estimation papers, tracking national programs) requires specialized knowledge that most CTI teams do not possess. The realistic path for most organizations is to contract strategic quantum CTI externally and build tactical and operational capability in-house over 12-18 months.

The Playbook Testing Gap

Playbooks that have not been exercised do not work. The four playbooks and five tabletop exercises described above should be tested at least annually, with the PQC migration program office, the SOC, CTI, and the CISO all participating. In my experience running quantum-specific exercises with government and enterprise participants, they consistently reveal coordination gaps and assumption failures that were invisible on paper.

A Realistic Implementation Roadmap

Not everything described in this article can or should be implemented simultaneously. Here is a prioritized sequence that balances urgency with the practical constraint that SOC teams are already stretched.

Phase 1 (Now, 0-3 months): Begin operationalizing the cryptographic inventory for SOC access. Stand up basic CTI monitoring of PQC vulnerability advisories. Draft the PQC Algorithm Vulnerability Disclosure playbook and conduct a tabletop exercise.

Phase 2 (3-9 months): Implement hybrid downgrade detection rules for the highest-priority network segments. Build or acquire PQC cipher suite parsing capability for the primary network monitoring platform. Begin cryptographic drift monitoring for systems that have completed migration. Conduct the first HNDL-focused review of data classification and DLP coverage.

Phase 3 (9-18 months): Extend detection rules to the full enterprise scope. Integrate certificate lifecycle monitoring for PQC certificates. Implement TNFL-specific signing event monitoring. Establish the quarterly Quantum Threat Landscape Assessment as a regular CTI deliverable. Conduct a full algorithm rotation drill.

Phase 4 (Ongoing): Refine detection rules based on operational experience. Update playbooks based on tabletop exercise findings. Track and report quantum security metrics to the CISO as part of regular SOC reporting. Adapt as PQC implementations, standards, and the quantum threat landscape evolve.

Summary of Illustrative Metrics

For SOC leaders who need a starting point for measurement, here are the key metrics discussed above in one place. I want to emphasize: these are illustrative. The right thresholds depend on the organization’s size, risk profile, regulatory environment, and migration maturity. Start with measurement, calibrate thresholds based on observed data, and refine over time.

Cryptographic Migration Coverage: Percentage of monitored TLS sessions using PQC or hybrid cipher suites, measured weekly. Trend should be monotonically increasing.

Cryptographic Drift Incidents: Count of systems detected reverting to classical-only cryptography after migration. Target: zero; any non-zero value triggers investigation.

TTAssess-PQC: Time from PQC vulnerability disclosure to completed CTI assessment delivered to SOC. Target: under 4 hours for deployed implementations.

Impact Assessment Speed: Time from vulnerability disclosure to identification of all affected systems. Target: under 4 hours. Reveals whether the cryptographic inventory is operationalized.

MTD-Signing: Mean time to detect unauthorized signing events. Target: under 15 minutes for production signing keys.

HNDL Exposure Score: Composite metric covering DLP coverage, detection latency, and data classification completeness for high-secrecy-requirement data stores.

Algorithm Rotation Drill FP Rate: False positive rate during rotation exercises. Target: under 10%.

Where This Fits in the Bigger Picture

The SOC’s quantum responsibilities do not exist in isolation. They are one layer of an organizational quantum readiness posture that includes governance (the board’s questions about cryptographic exposure, migration timelines, and vendor dependencies), migration execution (the CISO’s program), procurement and architecture (the CIO’s decisions), and strategic direction (the CEO’s engagement). I have covered enterprise quantum readiness at length in my Getting Started with Quantum Security series and in the forthcoming Quantum Sovereignty, and the practical migration steps in the PQC Migration Framework and Quantum Ready.

What the SOC uniquely contributes is operational reality. Governance can set policy. The migration program can move systems from classical to post-quantum. But only the SOC can tell you, in real time, whether the migration is holding, whether adversaries are actively targeting your cryptographic infrastructure, and whether the organization can actually respond when something goes wrong.

Every SOC has a role in quantum security. Whether yours is equipped to play it is a different question, and for most organizations today, the answer is: not yet. The gap is closable with the engineering and organizational work described above, and the time to start is now. Q-Day predictions will continue to shift, but the deadlines that actually drive action are already set by regulators, insurers, and the organizations you do business with.

The processes and frameworks described in this article are covered in greater detail in the Applied Quantum PQC Migration Framework (CC BY 4.0, free to use with attribution) and in my book Quantum Ready. If your organization needs help implementing these processes, Applied Quantum and Secure Quantum can help.