qasoThese sheets keep one print-ready look in every site theme.

QASO (Quantum Agentic Security Operations) post-quantum sheets

Why QASO for post-quantum security

Most online security depends on public-key cryptography: the math that lets two computers agree on a secret key and prove who they are. A large enough quantum computer could break that math. Attackers can record encrypted traffic today and try to decrypt it later, so data that must stay secret for years is already exposed.

The fix is post-quantum cryptography (PQC): newer algorithms designed to resist quantum computers. Moving to them takes years, and the first step is knowing where your organization uses cryptography and which connections still negotiate the old algorithms.

QASO helps with a narrower part of that step; it is not a full cryptography inventory. Secure sends a Transport Layer Security (TLS) 1.3 test connection to services it can reach on networks you authorize, records the key exchange the service selects, and labels it quantum-vulnerable, transitional, or unknown; it never labels one quantum-safe on its own. Assure lists the cryptography that application source code calls, by file and line; it is not yet approved for your source code, for installation at your site, or for production use. Security orchestration, automation, and response (SOAR) opens a case and proposes a next step for approval by risk class. Your team plans and carries out each upgrade through its own change process. QASO does not perform or prove a migration and cannot by itself make a system quantum-safe.

Secure: Records what it can see on the networks you authorize, the weaknesses that match, how an attacker could move between systems, and the key exchange each service selects in a test connection (it does not read certificates). For post-quantum timing, you enter how long the data must stay secret, how long a changeover would take, and the year you want tested; Secure compares those numbers and does not carry out the changeover. Discovery is not proof the network is complete. Cloud context is imported. Operational-technology protocols are classified as safety-critical; confirm how plant equipment is collected before a pilot.
Assure: Reviews application source code (currently JavaScript and TypeScript) and its third-party dependencies, cites the exact line, re-checks each finding, and lists the cryptography the code calls. Findings can be assigned an owner or left unassigned. It is an engineering candidate, evaluated on synthetic repositories, and static evidence does not prove runtime safety. Not yet approved for your source code, for installation at your site, or for production use.
SOAR: Watches live packet metadata (source, destination, destination port, and size only) and NetFlow (records of which systems talked to which), never packet contents, reads opt-in, read-only SentinelOne posture and threat data and Splunk searches (up to 50 rows per search), and imports Secure and Assure findings. On-site artificial intelligence (AI) models help investigate and draft a response. It is approved according to its risk class: automatically with a log for the lowest class, and by named people above that (one, two independent people, or a decision owner plus a process engineer); your team makes the change. Two demonstration actuators exist (a lab guest and a rehearsal-copy demo); they are not a general response engine. SOAR is not a security information and event management (SIEM) system.

Glossary

Cryptography names are marked in the sheets; hover or long-press a marked term for its full name.

QASO: Quantum Agentic Security Operations. The product family: Secure, Assure, and SOAR.
PQC: Post-quantum cryptography. New encryption and signature algorithms designed to resist attacks by quantum computers.
KEM: Key encapsulation mechanism. A method two systems use to agree on a shared secret key.
ML-KEM: Module-Lattice-Based Key Encapsulation Mechanism. The standardized post-quantum way to agree on a key.
ML-DSA: Module-Lattice-Based Digital Signature Algorithm. A standardized post-quantum signature for proving identity.
SLH-DSA: Stateless Hash-Based Digital Signature Algorithm. A post-quantum signature built only on hash functions; slower, very conservative.
ECDH: Elliptic-curve Diffie-Hellman. Today’s common way to agree on a key; a large quantum computer could break it.
ECDHE: Elliptic-curve Diffie-Hellman, ephemeral. The same key agreement with a fresh key for each connection; also quantum-vulnerable.
X25519: Curve25519 key agreement. A widely used elliptic-curve key agreement; a large quantum computer could break it.
SECP256R1: secp256r1, the 256-bit prime elliptic curve also called P-256. A common elliptic curve for key agreement and signatures; also quantum-vulnerable.
RSA: Rivest-Shamir-Adleman. An older public-key algorithm used for signatures and encryption; quantum-vulnerable.
ECDSA: Elliptic Curve Digital Signature Algorithm. Today’s common signature algorithm for certificates; quantum-vulnerable.
AES: Advanced Encryption Standard. Fast symmetric encryption for the data itself; stays in use after the move to PQC.
TLS: Transport Layer Security. The protocol that encrypts web and application connections.
HTTPS: Hypertext Transfer Protocol Secure. Web traffic protected by TLS.
SSH: Secure Shell. Encrypted remote login to servers and devices.
IPsec: Internet Protocol Security. A way to encrypt traffic between two networks, often between gateways.
SNMPv2c: Simple Network Management Protocol version 2c. An old device-management protocol that sends its password in clear text.
HSM: Hardware security module. A tamper-resistant device that stores and uses cryptographic keys.
API: Application programming interface. How one software system calls another.
OT: Operational technology. Systems that run physical equipment such as plants and buildings.
PLC: Programmable logic controller. An industrial controller that runs machinery.
HMI: Human-machine interface. The operator screen for industrial equipment.
BMS: Building management system. Controls lighting, access, and climate in a building.
HVAC: Heating, ventilation, and air conditioning. Building climate equipment.
IoT: Internet of Things. Networked sensors and small devices.
NVR: Network video recorder. Stores security-camera footage.
DFD: Data-flow diagram. A drawing of systems, data stores, and the connections between them.
STRIDE: Spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege. A checklist of six threat types.
SOAR: Security orchestration, automation, and response. The QASO product that opens cases and proposes responses for approval by risk class.
AI: Artificial intelligence. Here, language models that run on your own hardware inside SOAR. Secure has no built-in model; it offers a Model Context Protocol (MCP) server an outside assistant can connect to.
NetFlow: NetFlow. Records of which systems talked to which, never packet contents.

QASO post-quantum sheets · why qaso

Why QASO?

Security teams have plenty of tools that report signals. What they often lack is a record that separates what was observed from what is only claimed, and keeps each proposed change’s approval or policy log.

The gap

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

Are the connections we tested covered by a record we can check?

Not “does one product support PQC,” not “did a scanner see a version,” and not “does a dashboard look green.” QASO keeps observed evidence apart from claims, and each response SOAR proposes is approved according to its risk class: automatically with a log for the lowest class, and by named people above that. It does not stand in front of every change your teams make.

Violet quantum security architecture motif.

QASO answer

Record what you can see. Check the code. Propose an action, approved by risk class. After your team makes the change, run the check again.

Secure records what it can seeAssure checks the code (not yet approved for your source code, for installation at your site, or for production use)SOAR proposes the response

QASO post-quantum sheets · what is missing

The missing security layer

The cybersecurity space is crowded with scanners, dashboards, ticket queues, and playbooks. QASO adds an evidence-and-approval step before a change that SOAR proposes.

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 live connections still use an older key exchange; Secure’s test connection does not show which client negotiated which algorithm.

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

A response should be scoped, approved, reversible, and checked again after your team makes the change.

What is different

QASO puts evidence, an owner where one is assigned, and approval by risk class (the lowest class: a policy log, no approval record) in front of a proposed change

Secure records what it can see on the networks you authorize. Assure reviews application source code and re-checks each finding (not yet approved for your source code, for installation at your site, or for production use). SOAR proposes a response for approval by risk class. The three products exchange findings by import; nothing syncs automatically.

QASO post-quantum sheets · cryptography baseline

The shift in public-key cryptography

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

Two questions sit inside each connection: which key exchange was negotiated, and which certificate proved the other side’s identity. Secure’s test connection answers only the first; the certificate stays in your own records.

QASO post-quantum sheets · handshake mechanics

Identity is still the hard part

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

What each product can see

Secure sends a test handshake and records the key exchange the service selects, labelled quantum-vulnerable, transitional, or unknown, with where the observation came from. It does not read the certificate chain. Assure does not check handshakes; it lists the cryptography the application source code calls, by file and line (not yet approved for your source code, for installation at your site, or for production use). SOAR proposes a response; it is approved according to its risk class, and your team makes the change.

QASO post-quantum sheets · vendor-upgrade gap

Capable is not protected

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

Updated clientHybrid negotiated

Older clientFalls back to X25519

Legacy libraryClassical only

Hybrid offer (illustration) Quantum-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 each cause a classical negotiation even when the upgraded component advertises PQC support. A server that offers a hybrid option is not proof that its clients use it. The client rows above are an illustration: Secure’s test connection shows what the server selects for that probe, not which real client negotiated which algorithm.

QASO post-quantum sheets · security-state model

The state model

Keep each state separate, then compare required policy with observed behavior. The gap is what remains exposed.

CapabilityWhat the component can do

ConfigurationWhat the team enabled

ObservationWhat a test handshake selected

PolicyWhat critical paths require

GapWhat remains exposed

Capability evidenceVendor version, firmware, library, hardware security module (HSM) support. Source: vendor documents and your records.

Observed evidenceThe key exchange a service selects in a test handshake (Secure); cryptography calls in source code (Assure).

Policy evidenceCriticality, data class, trust boundary, required algorithm, exception owner. Source: your team’s records.

Secure records what it can seeAssure checks the code (not yet approved for your source code, for installation at your site, or for production use)SOAR proposes the response

QASO post-quantum sheets · quantum timing model

Mosca timing, from your inputs

Mosca’s rule, named after researcher Michele Mosca: if data must stay secret for S years and moving to PQC takes M years, you are already late when S + M is longer than Q, the years until a quantum computer could break today’s key exchange. Secure computes this from inputs you provide.

SShelf life

How long the data must stay confidential after capture. You enter it for each group of systems.

MMigration time

How long your team needs to upgrade, test, approve, and deploy, for each candidate action. You enter it; Secure rejects a migration time of zero.

QQuantum horizon

Years until a quantum computer could break the algorithm. Not a forecast: you choose one or more scenarios, optionally weighted.

Secure calculation

What Secure computes from the inputs you provide

InputsGroups of systems that share a data-retention class and migration path, each with S and M in years, plus the Q scenarios your policy chooses

Per scenarioWhether S + M exceeds Q (pressure: yes or no), and the gap in years

Break-evenBreak-even is shelf life plus migration time. While at least one scenario is not yet under pressure, Secure also shows how many years break-even sits from the nearest such scenario; once every scenario is under pressure, that distance is left blank

Candidate actionsGiven several actions you enter, Secure names one by a documented rule of thumb, not a proof it is best: first an action that leaves no scenario under pressure, then the fewest pressured scenarios, then the largest gap reduction. It does not carry out the action

Observed key exchangeSeparately, a label for each observed key exchange: quantum-vulnerable, transitional, or unknown

Pressure when S + M is longer than QNo pressure when S + M is at or below Q; at equality the margin is zeroThe result is only as good as the S, M, and Q you enter, and it does not prove a migration happened

QASO post-quantum sheets · cryptography topology

Connections are the evidence

Cryptography protects the communication between systems, so the record that matters belongs to each connection, not only to each device.

Hybrid post-quantum (illustration)

ECDHE

ML-KEM

Connection record

What to record for each connection

Source, destination, protocol, TLS version, key establishment, signature algorithm, cipher, certificate chain, when it was seen, where the evidence came from, and the policy it must meet. Secure supplies the key exchange a service selects; the other fields come from your own records, and the policy comes from your team.

QASO post-quantum sheets · market gap

Vendor tools miss the path

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

Illustration: one customer path, with each hop marked by what is known about it.

1Clientunknown edge

2Ciscovendor claim

3F5unknown edge

4Application programming interface (API) gatewayobserved

5Java appvendor claim

6Kafkaunknown edge

7Oraclevendor claim

8HSMunknown edge

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

Recorded evidence along the customer path

Secure records the key exchange for each service it could test, on networks you authorize. Hops marked vendor claim or unknown edge were not tested. Assure lists the cryptography in the application code (not yet approved for your source code, for installation at your site, or for production use). When your team finds a path that fails policy, SOAR can open a case and propose a response; it is approved according to its risk class, and your team carries it out.

QASO post-quantum sheets · reusable primitive

Bigger than PQC

Expected versus observed: Secure’s part is the TLS 1.3 key exchange and the systems it could see; the rest stays in your records.

TLS

Version drift

Policy requires TLS 1.3. Your team compares it with services still offering TLS 1.2, TLS 1.0, or no encryption, using your own records; Secure’s probe tests TLS 1.3 only.

Certificates

Trust-chain drift

Policy expects approved enterprise certificates. Your certificate records show where expired or self-signed ones remain. Secure does not read certificates; certificate chains, expiry, and self-signed status stay in your own records.

Segmentation

Reachability drift

Policy allows camera-to-network video recorder (NVR) traffic. Secure’s attack paths are a hypothesis about movement between systems its collector saw; they are not a map of plant-equipment protocols. Operational-technology protocols are safety-critical; confirm how plant equipment is collected before a pilot.

Legacy services

Protocol drift

Policy allows Secure Shell (SSH). Secure records the reachable services its collector saw, and the key exchange a TLS 1.3 test connection selected; it does not run a separate check for Telnet, SNMPv2c, or vendor maintenance services. Operational-technology protocols are safety-critical; confirm how plant equipment is collected before a pilot.

Product thesis

PQC is one use of a broader habit: compare expected and observed state

The habit applies beyond PQC: compare what policy requires with what was observed. Secure’s part is still only what its collector saw (reachable services and the key exchange a TLS 1.3 test connection selected); certificates and older TLS versions stay in your records. A SOAR case keeps the named decision owner and, above the lowest risk class, the approval for a response it proposed; Assure’s finding owner is a separate record and can be left unassigned.

QASO post-quantum sheets · legacy devices

Legacy risk stays honest

Do not call a legacy device quantum-safe while it still talks classically inside its local segment.

Devices like these may never receive a post-quantum update:

Programmable logic controller (PLC)

Camera

Building management system (BMS) controller

Medical device

Badge reader

Heating, ventilation, and air conditioning (HVAC)

Printer

Internet of Things (IoT) sensor

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

Secure’s post-quantum workspace can hold that remaining exposure with the shelf-life, migration-time and scenario numbers you enter, instead of overstating safety. The record of what stayed classical, and why, is kept by your team.

QASO post-quantum sheets · boundary pattern

Overlay the boundary

An encrypted overlay should protect selected boundary crossings, not blindly tunnel traffic that never leaves its segment.

Operational technology (OT) zone

PLCCameraHuman-machine interface (HMI)BMSIoTHVAC

Vendor gateway

Post-quantum or hybrid encrypted tunnelEncapsulated legacy traffic

Vendor gateway

Datacenter

AppsLog platformNVRHSMAPI

Implementation boundary

What this pattern does and does not do

The legacy endpoint remains unchanged. The sending gateway wraps the original traffic in an encrypted tunnel; the receiving gateway unwraps and forwards it. The gateways are your vendor’s equipment, set up by your team. If a gateway answers a TLS 1.3 test connection, Secure can record the key exchange it selects; Secure does not test Internet Protocol Security (IPsec) or other tunnel key exchanges; your team records which segments stay classical.

QASO post-quantum sheets · platform architecture

Evidence to action

Secure and Assure feed the evidence. SOAR proposes a response; it is approved according to its risk class, and your team carries out the change through its own change process.

Secure

Record

Records what it can see on the networks you authorize, the weaknesses that match, how an attacker could move between systems, and the key exchange each service selects in a test connection (it does not read certificates). For post-quantum timing, you enter how long the data must stay secret, how long a changeover would take, and the year you want tested; Secure compares those numbers and does not carry out the changeover. Discovery is not proof the network is complete. Cloud context is imported. Operational-technology protocols are classified as safety-critical; confirm how plant equipment is collected before a pilot.

Assure

Review code

Reviews JavaScript and TypeScript source code and its third-party dependencies, cites the exact line, re-checks each finding, and lists the cryptography the code calls. An engineering candidate, evaluated on synthetic repositories. Not yet approved for your source code, for installation at your site, or for production use.

SOAR

Propose

Imports Secure and Assure findings, opens cases, and drafts a response with on-site AI models. It is approved according to its risk class: automatically with a log for the lowest class, and by named people above that (one, two independent people, or a decision owner plus a process engineer); your team makes the change.

QASO evidence: discovery, matching weaknesses, attack paths, key exchange from test connections, code findingsYour equipment: tunneling, encryption, segmentation, traffic steering, allowlistingYour governance: owner, approval by risk class, rollback plan, the next check

ADiscoverSecure

BReview codeAssure

CAssessYour team, with Secure timing

DProposeSOAR

EApproveBy risk class

FChangeYour team

GCheck againYou re-run Secure or Assure

What the 13 sheets cover

Why QASO, the missing security layer, the shift in public-key cryptography, identity binding, capability-versus-protection, state modeling, Mosca timing, connection evidence, vendor blind spots, reusable verification, legacy residual risk, boundary overlays, and the Secure-Assure-SOAR operating loop.

Threat modeling: each site installation can be drawn as a data-flow diagram (DFD) and reviewed with STRIDE, a checklist of six threat types.

Open deployment architecture