The CTEM reference architecture nobody draws

A regulated organization sits down for a Continuous Threat Exposure Management program review. The deck opens on the five stages and the meeting drifts to the same dead end it always does. How do the stages hand off, who owns the data at each boundary, and what closes the loop when a finding is validated? Nobody at the table can point at a picture. The original Gartner write-up from July 21, 2022 (D'Hoinne, Shoard, Schneider) drew process. The XM Cyber practical guide licensed those five stages and wrapped an operator's map around them. Vendor pages draw their own product boxes. None of it is a vendor-neutral technical reference for the layers underneath, and that missing artifact is what this piece is.

One open effort deserves credit before we claim ground

The community already has one contribution worth naming first. ctem.org publishes an open taxonomy of 29 CTEM identifiers across 8 top-level categories as machine-readable JSON, the way CVE identifiers standardize vulnerability names, with its own reference on the five program stages living alongside the catalog. Taxonomy is not architecture. It hands practitioners a shared vocabulary for exposures, not the data models, state machines, or ownership boundaries the technical layers actually need to close a loop. Reference architecture is the second half of that conversation.

Two market moves in 2025 forced this into the open

Gartner shifted the market twice in the last eighteen months, and the moves matter because the market names now correspond to specific layers underneath. Adversarial Exposure Validation received its own Market Guide in March 2025 with a 2026 edition, formally consolidating breach and attack simulation together with automated penetration testing into a single Validate category, and the guide's citable predictions are that 60% of organizations will run structured exposure validation by 2029 and 30% will link AEV results to automated remediation. Exposure Assessment Platforms picked up the inaugural Magic Quadrant in November 2025 with 20 vendors, replacing the Vulnerability Assessment Market Guide outright, and Tenable's own category guide reads it the same way. Two market categories now sit under the program and no published document maps them cleanly to the layers a working implementation runs. Naming those layers is what lets a buyer read the market map correctly and see the gaps.

Six layers under the five stages

A working CTEM implementation has six architectural layers under the process:

1. Asset truth.
2. Exposure ingestion.
3. Intelligence enrichment.
4. Risk scoring.
5. Validation.
6. Remediation evidence.

Each layer has a specific job and a specific failure mode. When a program drifts, the drift is almost always traceable to one layer that never got built out, and every layer above it inherits the error whether the team recognizes it or not.

Layer 1: Asset truth

The resolved identity of the thing you are defending, across every identifier that names it: hostname, IP, cloud instance ID, container image digest, Kubernetes UID, EDR device ID, CMDB record, application owner, and environment tag. Our recent asset identity graph piece covered the shape at depth, so the mechanics do not get replayed here. The failure mode is the same either way. When the scanner names the asset one way and the CMDB names it another and nothing resolves them, every finding above this layer carries a duplication tax. The queue lies about how many things there are, remediation stops trusting it, and priority becomes theater.

Layer 2: Exposure ingestion

Sensors in. Scanner output, SCA and SBOM findings, cloud misconfigurations, external attack surface discoveries, identity exposures, web and API findings, Kubernetes and container findings, manual pentest results, and BAS failures. Each source arrives with its own schema, and the common mistake is treating each stream as its own queue while attackers chain across them. This layer's actual job is to normalize every stream into one exposure entity that the layers above operate against. OCSF Vulnerability Finding, OASIS SARIF 2.1.0, and Elastic ECS model the sensor event well and then stop there, which is right for their scope; the mutable exposure entity lives one level up and belongs to CTEM rather than to any of the sensor schemas.

Layer 3: Intelligence enrichment

Findings become priorities only after context lands on them. CVSS base, EPSS score, CISA KEV membership, VulnCheck or similar exploit maturity, CISA Vulnrichment or ADP supplements, threat actor targeting, vendor patch state, business owner, asset criticality, reachability, and compensating controls. Interface discipline matters more than the field list. Enrichment writes onto the exposure entity, not back into the scanner record, so ingestion stays idempotent and enrichment stays auditable. A layer that reaches back into the scanner has to be rewritten in six months when the scanner is replaced.

Layer 4: Risk scoring

The scoring plane is the program's control plane. The score decides which ticket opens, which SLA applies, which owner gets paged, which exception is legitimate, and which chart reaches the board. Single-signal scoring breaks every downstream workflow, which is why CVSS v4's own severity is not risk language reads more as a warning label than as a slogan. What the queue actually needs is a composite of severity, exploitability, active exploitation, asset context, reachability, supply-chain propagation, defense efficacy, validation verdict, and consequence. Ship a shallow score and every routing decision, every SLA breach report, and every executive metric inherits the error.

Layer 5: Validation

Belief becomes evidence here. Validation asks the four questions the scanner cannot answer: does the path work under the current control set, does the SOC see the technique when it fires, does segmentation stop lateral movement, and did the fix land the way the ticket claims. This is where AEV lives on the market map, and it is why BAS and automated penetration testing folded into one category in 2025. A CTEM platform without a Validate layer is a triage dashboard with high-confidence prioritization pretending to be evidence, and the audit conversation catches up to the pretense soon enough.

Layer 6: Remediation evidence

The final layer is not a closed ticket. It is proof. Finding ingested, score assigned, owner mapped, action taken, patch or mitigation applied, rescan completed, validation verdict recorded, and an explicit exception filed when residual risk was accepted. That artifact is what makes the program defensible to an auditor, a board committee, or a next-quarter budget review. When evidence is thin, quarterly reporting becomes archaeology and analysts spend their weeks answering questions this layer should answer itself.

The layers only mean anything when they close a loop

Wire the six together and the shape becomes clear. Ingestion writes the entity, enrichment updates it, scoring reads it, validation runs against it and writes a verdict back, remediation changes state, and evidence records the outcome. The next observation from Layer 1 or Layer 2 rewrites the entity again and the loop advances a turn. A platform that presents each layer as its own tab and hopes an analyst is the connective tissue is presenting exposure, not managing it. Our earlier local-first CTEM piece stands as an orthogonal contribution: it argued about where the loop runs and who holds the data, while this piece argues about what the loop is made of.

Two anti-patterns worth naming

Scanner-only CTEM. The team buys an EAP, calls the ingestion and enrichment layers a program, and never wires Validate or Evidence. Every quarter's report is a scanner queue with a Gartner sticker on it, and the metrics never get past mean time to close on findings the team hopes were real.

Dashboard-only CTEM. The team buys a data lake, streams every layer into it, and hires an analyst to reconcile identity, enrichment, and scoring by hand. Dashboards render, nothing closes, and the loop that would prove the program is real never runs because there is no state machine underneath, only a set of joins.

A buyer checklist against the six layers

Run five questions against any platform that pitches itself as CTEM. Which layer does it own end to end, and which layers does it assume you already have? Does the exposure entity have its own identity, or is it a projection of the scanner record? Does validation write a verdict back onto the entity, or does it live in a separate tool nothing joins to the queue? What is the evidence artifact your auditor actually receives, and how is it generated? If prioritization is wrong on Tuesday, which layer do you fix on Wednesday? A vendor that answers all five in a straight line is worth a proof of value; one that answers one and reroutes to a demo is selling a dashboard.

Patent USPTO 11,805,145 already touches continuous threat-informed exposure management, a reminder that vendor-neutral technical architectures do not survive without a community carrying them.

CVEasy runs all six layers inside the customer's trust boundary, with TRIS driving Layer 4 and BASzy closing Layer 5. The reason we insist on the local-first constraint is Layer 1: the resolved map of your asset estate is the most sensitive artifact the program produces, and it belongs on hardware you control.