CTEM without sending your asset inventory anywhere

A regulated org asks for CTEM. The vendor demo lands well, the slides are clean, and then the implementation conversation arrives at the step it always does: connect your asset feed, your scanner output, your CMDB, your cloud inventory, and stream all of it into our tenant so the platform can do its job. For a hospital network, a defense integrator, a sovereign government, an OT shop, or anyone running an air-gapped enclave, that step is where the project quietly dies. The CTEM program they actually need exists on paper, but every product carrying the name assumes their attack map can leave their network.

That assumption is the architecture choice nobody named.

A name for what we are building

We are calling this design local-first CTEM: a reference architecture that runs all five stages of Continuous Threat Exposure Management inside the customer's trust boundary, with the customer's asset inventory, configs, findings, and remediation evidence held on devices the customer controls. The pieces are not new. The synthesis is.

Two existing bodies of work meet here. CTEM, the program Gartner described in 2022, walks a security team through five stages of scoping, discovery, prioritization, validation, and mobilization, and is deliberately architecture-agnostic about whether your asset inventory belongs in your data center or someone else's. Local-first software, named by Martin Kleppmann and the Ink and Switch group in their 2019 essay, is a set of seven ideals where security and privacy by default sit alongside speed, offline operation, and longevity. That second body of work did not arise from security; it grew out of a frustration with cloud apps that left users renting access to their own data.

Mapping the second onto the first is the contribution. Everything else either credits prior art or pays it down.

What already ships, and what does not

Honest credit comes first. On-prem and air-gapped exposure management already exist as products. Tenable Enclave Security is purpose-built for classified, air-gapped, and FedRAMP High and DoD Impact Level 5 environments, and Tenable Security Center holds asset and vulnerability data on the customer network rather than streaming it to a vendor cloud. Qualcomm holds US patent 10,333,965, a split-plane design where a server analyzes threat reports and ships profiles while the device performs the local vulnerability analysis and response. Single-product on-device scanning, on-prem databases, and offline-consumable feeds like the FIRST EPSS download are real today.

What does not exist is a unified design that walks the local-first ideals through every CTEM stage as one adoptable blueprint. Mainstream CTEM products are SaaS by default. CrowdStrike's CTEM offering is built on the cloud-connected Falcon agent. Qualys is SaaS. The default flow of the industry is to ingest your environment, score it in the vendor cloud, and hand the answers back. That default is what local-first CTEM is named in opposition to.

So the novelty claim is small and precise. We are not claiming on-prem scanning. We are claiming three things: a single name for the architecture, an explicit mapping of local-first principles onto every CTEM stage, and a concrete design for the part everyone gets stuck on, which is staying current without phoning home.

The reference architecture

Five components, one per CTEM stage, all sharing a trust boundary the customer draws.

Scoping

The scoping artifact is a local policy file the security team owns. Crown jewel definitions, compliance scope, business unit tags, and exclusion rules sit beside the code that uses them, never in a vendor tenant. The output of scoping is a target set, not a question sent to anybody's API.

Discovery

Discovery runs as a local asset and inventory agent. Network sweeps, identity directory pulls, cloud account enumeration when cloud accounts are in scope, and container image listing all return into a local store. The inventory itself never leaves the boundary, and that single inversion is the most important departure from the SaaS pattern. Your asset map is the most sensitive artifact you have, and the industry has gotten so used to treating it as a routine ingest that the implication is rarely said out loud.

Prioritization

Prioritization is where SaaS hides the most work and the hardest stage to do locally without giving up signal. The scoring engine has to combine vulnerability data with threat intelligence, exploit probability, asset context, reachability, and compensating controls, then produce a ranking a human can act on. Done correctly, this engine runs as a service inside the boundary and consumes a refreshed intelligence model on a regular cadence. The model update is the single point of contact with the outside world, and the next section is about how that point is engineered.

Validation

Validation runs as local breach and attack simulation. Safe, contained payloads exercise the customer's controls inside the boundary, so the team can tell whether a particular CVE would actually be stopped on a particular asset rather than inheriting the base-score guess that scanners hand them. The verdict never leaves the network that produced it.

Mobilization

Mobilization hands findings to the people and systems that will fix them. Tickets land in the customer's ticketing system, dashboards render inside the customer's identity perimeter, and evidence artifacts stay on disk. Reports for auditors are generated locally and exported under the customer's own controls. The vendor does not need a copy.

The hardest part: staying current without egress

A loop that never updates is not CTEM. A loop that streams everything outbound is not local-first. The bridge between those two failure modes is a signed offline delta bundle.

The bundle is a versioned, signed artifact published by the vendor, or assembled by the customer's own intelligence team when they prefer to run the pipeline themselves. It carries the day's new CVEs, the refreshed EPSS scores, KEV additions, updated detection signatures, and any tuning of the prioritization model. Inside the boundary, the local CTEM platform verifies the signature against a pinned key, applies the delta, and rolls forward. Nothing about the customer's environment goes the other direction.

Two design decisions matter. The bundle has to be pulled rather than pushed, so the customer's egress controls remain the authority on what leaves and what comes back, and the signature has to be checked against a key the customer holds a copy of, so a compromised vendor cannot silently flip the scoring model under them. The Qualcomm split-plane patent describes a similar shape one layer down the stack, and operational precedent already exists in everyday tooling: yum and apt repositories, Sigstore-backed container indices, EPSS downloads, the Microsoft Defender intel cache. We are arguing the pattern belongs at the CTEM layer too, with the signing and rollback contracts spelled out by the architecture rather than left to each vendor.

What local-first CTEM is not

It is not isolationism. A team can choose to pull intelligence over the open internet, through a managed feed, or via a one-way diode in a classified environment. The architecture is about who holds the data and who signs the updates, not about whether the boundary speaks to the outside world at all.

It is not a SOC replacement, and it is not a finished product specification. Gaps remain. The fleet management plane for many local CTEM instances across a federated org is its own design problem; the economics of pushing more compute into the boundary cut differently for a five-person startup than for a federal program; tuning the scoring model purely from local telemetry without leaking it back to a vendor for retraining is an active research question. We are sketching a reference, not declaring a category closed.

A path your team can take

Three steps, in order. First, draw the trust boundary explicitly: what stays inside, what crosses it, and under whose signature it crosses. Second, run the existing CTEM stages on tools that already keep data local, scoping with policy as code, discovery with on-prem agents, validation with self-hosted BAS, mobilization with your existing ticketing. Third, choose the intelligence update mechanism that fits your egress posture. Signed delta bundles are the lowest egress option, a hardened outbound feed proxy is the pragmatic middle for teams with controlled internet access, and a managed enclave is the option for teams that want a vendor to run the bundle pipeline on their behalf while the runtime stays local.

CVEasy is built this way, a local-first CTEM platform with TRIS scoring and BASzy validation running inside the customer's boundary by design. We wrote this piece because the architecture is worth naming whether your team ever runs our software or not.