Post-Quantum Security Sheets

QASO POST-QUANTUM SHEETS · why qaso

Why QASO?

01

Cybersecurity has plenty of tools that report signals. What is missing is a trusted layer that proves what is protected, what is merely claimed, and what can be changed with authority.

The gap

Security teams drown in findings, but still cannot answer the board’s simplest question

Are our critical paths actually protected?

Not “does one product support PQC,” not “did a scanner see a version,” and not “does a dashboard look green.” QASO ties observed behavior to validated claims, owners, policy, and governed response.

Violet quantum security architecture motif.

QASO answer

Observe the estate. Validate the claim. Approve the action. Prove the result.

SignalEvidenceDecisionAction

Secure observes the estateAssure validates the claimSOAR governs the action

QASO POST-QUANTUM SHEETS · what is missing

The missing security layer

02

The cybersecurity space is crowded with scanners, dashboards, ticket queues, and playbooks. QASO connects them into one evidence-to-action system.

Tools see pieces

A scanner sees one component

Useful, but it does not prove the real business path is protected end to end.

Claims drift

Dashboards turn support into certainty

A product can support a control while the estate negotiates something weaker in production.

Owners vanish

Findings lose authority

Teams can debate a risk for weeks when evidence, policy, and approval live in different systems.

Actions need proof

Automation needs a boundary

Response should be scoped, approved, reversible, and verified after it runs.

Why unique

QASO is not another scanner; it is the operating layer above security evidence

Secure observes infrastructure relationships. Assure tests whether claims are defensible. SOAR routes governed response. The result is a living proof graph, not another pile of alerts.

QASO POST-QUANTUM SHEETS · crypto baseline

The crypto shift

03

PQC changes the public-key algorithms used for key establishment and signatures. Bulk encryption still relies on fast symmetric cryptography such as AES.

Current model

Classical public-key algorithms carry today’s trust

Key establishmentECDHE, ECDH, Diffie-Hellman

AuthenticationRSA, ECDSA, certificate chains

Bulk encryptionAES session keys

Post-quantum model

Standardized PQC algorithms replace the vulnerable public-key layer

Key establishmentML-KEM or hybrid classical plus PQC

AuthenticationML-DSA or SLH-DSA where supported

Bulk encryptionAES remains the high-speed data cipher

Why this matters

Inventory alone cannot answer readiness

The practical question sits inside each handshake and each trust boundary: what algorithm was negotiated, what certificate authenticated the peer, and does that match policy for this path?

QASO POST-QUANTUM SHEETS · handshake mechanics

Identity is still the hard part

04

A connection can have strong key establishment and still authenticate the wrong party. PQC migration must cover both shared secrets and identity binding.

Confidential key establishment

Two systems derive shared secret material that feeds symmetric session encryption.

Current: ECDHEPQC target: ML-KEM or hybrid KEM

Endpoint authentication

A certificate and signature bind the public key to an identity and prove private-key possession.

Current: RSA and ECDSAPQC target: ML-DSA or SLH-DSA where the ecosystem supports it

Implementation implication

Secure needs evidence from both sides of the handshake

Secure records negotiated key establishment, certificate chain, signature algorithm, endpoint identity, and source of observation. Assure replays whether that evidence supports the claim. SOAR acts only after policy and owner approval.

QASO POST-QUANTUM SHEETS · vendor-upgrade gap

Capable is not protected

05

A server can support hybrid PQC while real clients still negotiate classical key exchange through old libraries, proxies, or fallback behavior.

Server after upgradeX25519 · secp256r1 · X25519 plus ML-KEM hybrid

Client AHybrid PQ negotiated

Client BFallback to X25519

Client CLegacy library path

Observed protected path Observed vulnerable paths

Why the gap happens

Capability can diverge from traffic

Old clients, load balancers, TLS termination, protocol limits, unsupported downstream services, and misconfiguration can all cause a classical negotiation even when the upgraded component advertises PQC support.

QASO POST-QUANTUM SHEETS · security-state model

The state model

06

Secure should model each state separately, then calculate the gap between required policy and observed behavior.

CapabilityWhat the component can do

ConfigurationWhat the team enabled

ObservationWhat traffic actually negotiated

PolicyWhat critical paths require

GapWhat remains exposed

Capability evidenceVendor version, firmware, library, HSM support, protocol interrogation

Observed evidenceTLS version, KEM, signature, cipher, certificate, source packet or scan

Policy evidenceCriticality, data class, trust boundary, required algorithm, exception owner

Secure observes the estateAssure validates the claimSOAR governs the action

QASO POST-QUANTUM SHEETS · quantum timing model

Mosca becomes operational

07

Secure should calculate quantum urgency per relationship: protect first where data shelf life plus migration time exceeds the credible quantum threat horizon.

SShelf life

How long the data or transaction must stay confidential after capture.

+

MMigration time

How long the owner needs to upgrade, test, approve, and deploy PQC controls.

>

QQuantum horizon

Estimated time until cryptographically relevant quantum capability threatens the algorithm.

Secure calculation inputs

Secure turns Mosca from a policy worksheet into an evidence-backed risk graph

RelationshipSource, destination, protocol, business owner, data class, trust boundary

Observed cryptoTLS version, KEM, signature algorithm, cipher, certificate chain, fallback behavior

Timing pressureShelf life plus migration time compared with the selected quantum horizon scenario

Priority outputUrgent, scheduled, monitored, or accepted with named owner and compensating control

Urgent when S + M exceeds QScheduled when migration completes before the risk window closesMonitored when the installation lacks enough evidence to score confidence

QASO POST-QUANTUM SHEETS · crypto topology

Edges are the evidence

08

Cryptographic security happens on communication relationships, so Secure must treat edges as first-class evidence objects.

A

Hybrid PQ

B

ECDHE

C

ECDHE

E

ML-KEM

D

Relationship record

The evidence object that decides protection

Source identity, destination identity, protocol, TLS version, key establishment, signature algorithm, cipher, certificate, trust chain, first observed, last observed, evidence source, confidence, and policy status.

QASO POST-QUANTUM SHEETS · market gap

Vendor tools miss the path

09

Each vendor can correctly report its own PQC support while the end-to-end customer path remains partially vulnerable.

1Clientobserved

2Ciscovendor claim

3F5unknown edge

4API gatewayobserved

5Java appvendor claim

6Kafkaunknown edge

7Oracleobserved

8HSMvendor claim

Vendor view

Support status for one component

Version 12.4 supports ML-KEM. The claim can be true and still fail to prove the customer’s full application path.

QASO view

Observed behavior across the customer estate

Secure maps the path. Assure validates claims against evidence. SOAR routes approved remediation when a path violates policy.

QASO POST-QUANTUM SHEETS · reusable primitive

Bigger than PQC

10

Expected security state versus observed security state applies to TLS, certificates, segmentation, and legacy services.

TLS

Version drift

Policy requires TLS 1.3. Secure observes TLS 1.2, TLS 1.0, and plaintext on real device paths.

Certificates

Trust-chain drift

Policy expects approved enterprise certificates. Secure finds expired, self-signed, or unexpected certificates on alternate ports.

Segmentation

Reachability drift

Policy allows camera-to-NVR traffic. Observation shows extra routes to internet, PLC, or corporate database targets.

Legacy services

Protocol drift

Policy allows SSH. Observation finds HTTPS, Telnet, SNMPv2c, or vendor maintenance services still reachable.

Product thesis

PQC becomes one use case of a broader verification architecture

The same Secure, Assure, and SOAR primitives can track required state, observed state, evidence source, claim confidence, named owner, and governed response.

QASO POST-QUANTUM SHEETS · legacy estate

Legacy risk stays honest

11

QASO should never claim a legacy device became quantum-safe if the device still talks classically inside a local segment.

PLCNo PQC patch guaranteed

CameraNo PQC patch guaranteed

BMS controllerNo PQC patch guaranteed

Medical deviceNo PQC patch guaranteed

Badge readerNo PQC patch guaranteed

HVACNo PQC patch guaranteed

PrinterNo PQC patch guaranteed

IoT sensorNo PQC patch guaranteed

Protected truth

Boundary traffic can gain PQC or hybrid protection

Gateway-to-gateway communication can use a secure overlay when traffic crosses a defined trust boundary.

Residual truth

The local device segment may remain classical

QASO records that residual exposure, the compensating controls, and the named risk owner instead of overstating safety.

QASO POST-QUANTUM SHEETS · enforcement architecture

Overlay the boundary

12

The overlay should protect selected boundary crossings, not blindly tunnel every packet everywhere.

OT zone

PLCCameraHMIBMSIoTHVAC

QASO gateway

PQ or hybrid protected overlayEncapsulated legacy traffic

QASO gateway

Datacenter

AppsSIEMNVRHSMAPI

Implementation boundary

What the slide proves

The legacy endpoint remains unchanged. The original packet gets encapsulated by the gateway. The receiving gateway decrypts and forwards the original traffic. QASO records which segment stayed classical and which boundary received protection.

QASO POST-QUANTUM SHEETS · platform architecture

Evidence to action

13

Secure and Assure feed the control plane. SOAR governs the response and can task the data plane under approved scope.

Secure

Observe

Maps assets, crypto posture, reachability, attack paths, unsupported systems, and communication relationships.

Assure

Validate

Replays claims against evidence sources, attaches provenance and coverage, and marks stale or unsupported claims.

SOAR

Govern and execute

Opens cases, routes approvals, signs action scope, tasks relays or gateways, and verifies the result.

Control plane: discovery, identity, topology, policy, risk, path computationData plane: tunneling, encryption, segmentation, traffic steering, allowlistingGovernance plane: owner, approval, exception, rollback, verification evidence

ADiscover

BIdentify

CObserve

DAssess

EMitigate

FVerify

GMonitor

What the 13 sheets cover

Why QASO, the missing security layer, the PQC crypto shift, identity binding, capability-versus-protection, state modeling, Mosca urgency, relationship evidence, vendor blind spots, reusable verification, legacy residual risk, boundary overlays, and the Secure-Assure-SOAR operating loop.

Open deployment architecture

Why QASO for post-quantum security