The Department of Defense's Zero Trust Reference Architecture v2.0 is one of the most rigorous frameworks ever published for securing networked infrastructure. It's detailed, architecturally sound, and long overdue. It's also, if we're honest, frequently misread by the vendors who claim to support it.
I've spent a lot of time over the past year mapping Invisinet's architecture against the DoD RA — its seven pillars, its architecture patterns, its MITRE ATT&CK® and D3FENDTM alignments. What I found reinforced something we've believed since we built this company: the moment of enforcement matters more than almost any other design decision in a Zero Trust architecture. Most solutions enforce after a connection is made. We enforce before one is possible.
That's not a marketing distinction. It's a structural one, and it has measurable consequences for how an adversary is able to move through a network.
Where Invisinet Fits in the DoD RA
The DoD RA organizes Zero Trust across seven pillars: User, Device, Network & Environment, Applications & Workloads, Data, Visibility & Analytics, and Automation & Orchestration. No single vendor covers all seven natively — anyone telling you otherwise is selling something. What matters is where you're strongest, where your gaps are, and how honestly you represent both.
Invisinet's strongest alignment is the Network & Environment pillar, which is where the DoD RA addresses cloaking, segmentation, lateral movement restriction, and domain policy enforcement. Our architecture maps directly to four core RA patterns: Domain Policy Enforcement for Resource Access, Software Defined Perimeter, East-West Segmentation, and Conditional Authorization.
The mechanism behind all of it is First Packet AuthenticationTM. When any system — a user endpoint, an IoT device, an automated process — attempts to connect to a protected resource, it must present a cryptographic, one-time-use identity token called a TAC-ID in the very first TCP SYN packet. Our enforcement gateway evaluates that token before any session connection is permitted. If the token is missing, expired, or unauthorized, the gateway drops the traffic silently and returns nothing. No SYN/ACK, no banner, no error. The resource is simply invisible.
This isn't a novel concept — the DoD RA describes it as the Software Defined Perimeter pattern, where conditional authorization governs service reachability rather than network membership. What makes our approach distinctive is where the decision happens: at the TCP layer, before session establishment, at the moment the connection is initiated. The protected resource cannot be scanned, fingerprinted, or probed unless the requesting identity has already been validated.
What This Means in ATT&CK Terms
MITRE ATT&CK® and D3FENDTM give us a common language for talking about what controls actually disrupt. When I look at where Invisinet disrupts adversary behavior most structurally, it's in the early stages of the kill chain.
Reconnaissance is the first phase any attacker operates in, and it's one of the least-defended. Active scanning techniques — T1595, T1590, T1592 — depend on protected resources being reachable enough to reveal something about themselves. First Packet Authentication eliminates that surface. Resources protected by Invisinet don't respond to unauthorized probes. There's no useful scan result. That directly maps to D3FEND's Network Isolation and Network Traffic Filtering patterns, and it means attackers lose the reconnaissance phase before they've invested anything in Initial Access.
Initial Access is where FPA's enforcement model is strongest. Techniques like exploiting public-facing services (T1190), abusing external remote access (T1133), or using valid credentials from a prior compromise (T1078) all assume that the targeted service is reachable once you have the right credentials or an exploitable vulnerability. Invisinet breaks that assumption. Valid credentials alone do not create network reachability. The identity token must also be present, valid, and policy-authorized — meaning a compromised password or a stolen session doesn't automatically translate into a viable attack path.
The Discovery and Lateral Movement phases are where micro-segmentation pays off at scale. Unauthorized internal probes against Invisinet-protected segments return nothing, preventing the reconnaissance that typically precedes lateral movement. Per-session, identity-bound access control limits pivot paths even when an attacker already has a foothold — T1021, T1210, and T1550 depend on the ability to move between segments using re-used credentials or exploited services. When each service access requires an independently validated TAC-ID and policy authorization, that kind of reuse fails at the transport layer.
Where Invisinet is partial — and I'd rather say this plainly than have a prospect find it out mid-deployment — is in Command & Control and Exfiltration. We can restrict allowed session paths and log everything to SIEM via our Invisinet Messaging Framework, but we're not a full secure web gateway, DNS filter, or content-aware DLP platform. Those controls are complementary, not redundant.
The Competitive Reality
I'm going to describe the architectures of our major competitors without naming them, because the architecture comparison is what matters — not brand positioning.
One category of competitor operates primarily as a cloud-delivered security exchange platform: a large-scale proxy infrastructure that handles internet and SaaS traffic inspection, secure web gateway, CASB-style controls, and cloud-brokered private application access. This is powerful for internet-bound traffic, user-to-cloud access, and data protection controls. It's the right answer for a lot of problems. What it doesn't do is eliminate service reachability before a TCP connection is established. The enforcement model operates on sessions and content that are already in flight, which means attacker-observable network exposure exists at the pre-connection layer in ways our architecture eliminates.
A second category operates as a mature software-defined perimeter and ZTNA broker: a controller-and-gateway model that establishes dynamic user-to-resource entitlements and routes access through policy-governed access paths. This is a strong architecture for remote access, hybrid work, and conditional authorization workflows. The gap, architecturally, is that the entitlement model operates at the session/application layer rather than the TCP transport layer, so the mechanism for pre-connection cloaking differs from what we do at L4.
The third category is workload micro-segmentation and breach containment: host-based segmentation that maps east-west traffic and enforces at the workload boundary. The primary use case is limiting the blast radius after a breach — stopping lateral spread through granular segmentation policy. This is excellent capability for breach containment. The difference is timing and position: host-based enforcement happens at or after the host level, while Invisinet enforces at the network transport layer before sessions exist.
The honest read on all three: these are architecturally complementary controls, not replacements for each other. In a DoD seven-pillar model, you need SSE/SASE inspection for internet and cloud paths, you need mature ZTNA brokerage for hybrid access workflows, you need host-based segmentation for workload containment — and you need transport-layer first-packet enforcement for pre-connection cloaking, identity-based micro-segmentation, and early kill-chain disruption. Invisinet fits in the stack as the enforcement layer that protects services before the other controls even have a chance to engage.
What DoD Evaluators Should Look For
If you're evaluating Zero Trust capabilities against the DoD RA, the most important question isn't "does this vendor support Zero Trust?" Every vendor says yes. The question is: at what point in the network interaction does your chosen architecture apply enforcement, and what attack phases does that timing foreclose?
For Invisinet, enforcement happens before TCP session establishment. That timing forecloses reconnaissance, initial access to protected services, and lateral movement based on service reachability — and it does so without requiring changes to the underlying network infrastructure. The micro-segmentation overlay runs at Layer 4, policy is distributed through publisher domains and InvisiGate/InvisiPoint enforcement nodes, and all session telemetry flows in real time to SIEM via our Invisinet Messaging Framework for downstream analytics and RMF evidence collection.
The gaps we close are early-stage and structural. The gaps we leave open — data-layer controls, endpoint hygiene, full egress inspection — are gaps that a complementary stack closes. Build the right control stack for your threat model, and be honest about what each layer in it actually does.
That's the standard we hold ourselves to.
Brendan Sullivan is the CEO of Invisinet Technologies. To learn more about how Invisinet's First Packet Authentication™ and Software Defined Perimeter platform can protect critical infrastructure, visit invisinet.com or request a demo.
