At A Glance
- Zero Trust guidance from NIST, CISA, DoD, and NSA converges on one practical enforcement model: identity-defined reachability. Authenticate first, authorize a named service, then create only that path, across people, workloads, OT, partners, and AI agents, without redesigning the network.
- NetFoundry and OpenZiti implement this vendor-neutral model as Identity-First Reachability™.
- We built a browser-based, open-source lab with the Department of the Navy (DoN), Department of War (DoW), and Warfighting Acquisition University (WAU) to make the model testable and repeatable, using Keycloak, OpenZiti, Zeek, and Wazuh.
- The lab walks practitioners through the full loop: Identify → Authorize → Connect → Observe → Detect → Respond → Adapt.
Zero Trust does not lack guidance: NIST provides architectural direction, CISA provides a maturity path, the Department of Defense provides capabilities and activities, and NSA implementation guidelines provide practical tasks and evidence. But which connectivity model makes those requirements work consistently?
Consider NSA Zero Trust Implementation Guideline Activity 1.7.1, which expects applications to deny access by default to protected functions and data, reduce default permissions, remove excess privileges, and audit access continuously. It doesn’t mandate identity-defined reachability, and NIST Special Publication 800-207, the CISA Zero Trust Maturity Model, and other major guidance don’t prescribe it, either.
But look at their combined direction: deny access by default, authorize specific resources, segment communication, continuously validate authority, correlate activity with identity, and adapt enforcement when risk changes. Now apply that to a person accessing an application, a workload calling an API, an engineer reaching an operational technology (OT) service, an agent invoking a tool, or two services spanning independently managed networks.
Identity-defined reachability becomes the simplest common enforcement model. Identity establishes the subject; a named service, policy, and context determine authority; only then is the permitted path created. The networks beneath can remain independently operated. OT zones can retain their ISA/IEC 62443 structure. Existing boundaries can continue to provide containment. The authorized relationship no longer has to be recreated in every network it crosses.
What does identity-defined reachability change?
Traditional connectivity establishes network reachability first, then relies on downstream controls to decide what the subject may use. That logic is repeated in VPNs, routes, access-control lists, firewalls, proxies, and local policy.
Identity-defined reachability reverses the sequence:
- Authenticate the human, workload, device, or agent.
- Evaluate its authority for a named service using policy and current context.
- Create only the service path that is allowed.
An unauthorized subject has no authorized path to the service, so it never reaches the application login page in the first place.
This is a vendor-neutral concept; NetFoundry and OpenZiti implement it through Identity-First Reachability™, using cryptographic identities, service policy, encrypted overlays, and dark services. The larger question is: which identity may reach which named service, under which conditions, right now?
Topology still matters. Segmentation, zones, conduits, and firewalls provide containment and defense in depth. In OT, safety, availability, deterministic behavior, and safe recovery constrain enforcement. ISA/IEC 62443 zones and conduits remain essential; identity and service policy can make each conduit more precise. We should preserve the operational boundary while governing the subject-to-service relationships that cross it.
Why does guidance need a practical lab?
Nobody would declare a pilot ready because they had read the flight manual. The simulator is where the pilot learns how controls interact, how failure presents itself, and whether one response creates another problem.
Zero Trust needs the same treatment. Practical Zero Trust training is a hands-on environment in which participants configure, test, observe, and adapt the full decision-and-enforcement loop around a protected service. It turns architecture into evidence.
The browser-based, pre-staged environment was built in partnership with the DoN, DoW, and WAU around a simple loop:
Identify → Authorize → Connect → Observe → Detect → Respond → Adapt.
Participants can work with human access, machine-to-machine communication, a dark OT service, and closed-loop response. Optional scenarios extend the same model to mission partners and agentic AI. Note that this is training, not an official DoN reference architecture, certification, or production deployment. Practitioners can inspect and challenge the model.
| Component | Role in the lab | What participants can prove |
|---|---|---|
| Keycloak | Authentication, federation, and claims | Valid identity is necessary, but does not create service authority |
| OpenZiti / NetFoundry | Identity, named services, policy, encryption, and enforcement | Only matching identity and policy create a service path |
| Zeek | Network and protocol observation, including Modbus | Behavior can be tied to service and network evidence |
| Wazuh | Detection, correlation, and response workflow | Detection can lead to changed authority and retesting |
Keycloak establishes the subject; OpenZiti evaluates policy and creates the path; Zeek observes behavior, and Wazuh detects and correlates activity. The response workflow then uses the OpenZiti application programming interface to change authority.
Why is this model easier to reuse?
It’s the simplest reusable enforcement abstraction because the same decision can be expressed across very different environments.
A person may access one application. A workload may call one API. A maintenance engineer may reach one OT service through an approved conduit. A mission partner may use one capability without surrendering its identity provider or network. An AI agent may invoke one tool without standing reachability to everything behind it.
The underlying transports and operational constraints differ, but the policy question stays stable. That reduces the connectivity tax: the repeated VPN, firewall, network address translation, routing, VLAN, access-control-list, ticketing, and accreditation work required whenever a new relationship crosses a boundary.
It’s the same logic behind NetFoundry’s broader microsegmentation practice: enforcing least-privilege access workload by workload, without redesigning VLANs or firewall rules to do it.
It also helps with federation without consolidation. Organizations don’t need one network, one identity provider, or one administrator. They need a trustworthy way to establish the subject, name the service, exchange sufficient context, and enforce the agreed relationship at each side.
This matters more as non-human activity accelerates. As I argued in the Cloud Security Alliance article AI-Speed Risk Requires Identity-Defined Reachability, machine-speed action turns permanently reachable tools, models, and data stores into a larger liability. Agent identity is useful, but only if it is bound to specific, observable, and revocable service authority.
What evidence does the lab produce?
The capstone follows a compact evidence chain:
Identity → Service and policy → Behavior → Detection → Response → Retest.
Retesting matters. An alert proves something was noticed but it doesn’t prove policy changed, enforcement applied the change, or the mission remained available.
The stronger result is selective: the offending identity-to-service path fails while unrelated authorized flows continue. Participants can inspect the identity, service, policy, behavior, response, and retest evidence.
Why does open source matter?
Open source makes the environment inspectable, repeatable, and adaptable. Participants can see where decisions are made and enforced, what telemetry is produced, and how components interact. They need not accept a black-box claim that a product is “Zero Trust.”
That transparency does not make the work free of complexity; it exposes the complexity so it can be tested, governed, and improved. It also creates a practical foundation that a university, research organization, training provider, or enterprise team can adapt around its own mission threads.
Where should we take it next?
We built this environment to be used, challenged, and adapted, not left as another set of Zero Trust slides.
We’re looking for public-sector, industrial, and enterprise teams that want to put practitioners through the lab; universities, research organizations, and training providers interested in developing it into a broader practical curriculum or skills-based credential; and organizations that want to evaluate the OpenZiti, Keycloak, Zeek, and Wazuh stack against one of their own mission threads. A formal certification could be explored with the right assessment and accreditation partner, but it should follow demonstrated skills rather than become a marketing label.
If any of those describe you, get in touch. Bring one real use case: a human, workload, partner, OT system, or agent that needs access to one important service. We will use the lab to test whether you can remove ambient reachability, authorize the service before creating the path, observe the decision, and revoke access without redesigning the surrounding network.
Frequently Asked Questions
What is identity-defined reachability?
NetFoundry and OpenZiti call this model Identity-First Reachability™, but the underlying concept is vendor-neutral: an authenticated identity — a person, workload, device, or agent — must be authorized for a specific named service before any network path to that service exists. An unauthorized subject never gets a route to the service in the first place, rather than failing at its login page.
Does NSA Activity 1.7.1 require identity-defined reachability?
No. Activity 1.7.1 specifies deny-by-default outcomes as a target, not a required connectivity architecture, but identity-defined reachability is the practical way to deliver those outcomes consistently across heterogeneous environments.
Does identity-defined reachability replace network segmentation and firewalls?
NetFoundry’s model doesn’t replace existing containment — it adds a policy layer on top of it. Segmentation, zones, and firewalls continue to provide defense in depth, while identity-defined reachability governs which authenticated identity may reach which named service within or across those existing boundaries. OT safety, availability, deterministic behavior, and recovery requirements still shape enforcement.
Can the training become a certification program?
The current lab is a practical training, not a certification. It could support a skills-based credential or future certification if a partner defines learning outcomes, assessment criteria, governance, accreditation, and maintenance — the lab already provides a strong foundation because participants must produce and retest operational evidence.
- Confirm that no participant, operational environment, mission system, or non-public Department of the Navy detail is identifiable.
- Confirm whether the course has completed delivery, reached dry-run status, or remains in development; retain “designed to” language unless delivery is confirmed.
- Confirm the approved description of NetFoundry’s relationship with the Department of the Navy and whether “developed for” is cleared for public use.
- Do not publish the estimated four-tool coverage of Department of Defense Zero Trust activities until the activity-by-activity mapping has been reviewed.
