Open source zero trust access for public sector

Why open source zero trust access fits public sector agencies

Agencies that want to retire a VPN that places every authorized user on the whole internal network can start with identity-based access to individual applications. Open source zero trust access fits this goal because each application is authorized per user and per device, and the control plane can run inside the agency's own infrastructure. The reference point for federal civilian agencies is OMB M-22-09, which set zero trust goals to be met by the end of fiscal year 2024 and requires agencies to consider at least one device-level signal alongside identity when authorizing a user. Those goals map cleanly to a ZTNA design: identity provider sign-in, device posture, least-privilege policy per application and logs of every access decision.

Self-hosting the control plane matters for public bodies because the policy engine, identity issuance and access logs describe who reaches which system and when. Keeping them in agency-controlled accounts, data centers or isolated networks keeps that metadata under the agency's authority and simplifies the boundary an assessor must review. The platform families differ in shape. OpenZiti fits dark services and overlay access, since its services can have no open ports and its edge routers dial out. Pomerium fits identity-aware web and SSH access in front of internal applications. Whichever is chosen, DeployOpen can plan, implement and harden the system, but it does not issue authorizations. The agency's authorizing official, and the assessors it engages, decide whether the design meets its requirements. Confirm early which control baseline and authorization path apply to the system.

Which requirements shape a zero trust access design for government

This table maps the federal and criminal justice requirements most likely to shape a self-hosted zero trust access design to what each one means for the build. Read each row as a question to settle with your assessor, authorizing official and legal counsel before choosing components. The main takeaway is that the control plane, logs and any cloud-hosted piece carry most of the compliance weight, so their hosting location should be decided first.

Requirement	What it asks for	What it means for the build
OMB M-22-09 (identity and device signals)	Agencies authorize users using identity information plus at least one device-level signal, with encrypted connections and identity-based access to internal applications.	Pick an identity provider that issues the user identity, then confirm which device posture signal your ZTNA product can consume. Keep the policy decision tied to both signals in logs.
NIST SP 800-53 Rev. 5 control families	Access control, identification and authentication, audit and accountability, and system and communications protection controls describe how access and transmission are governed.	Map each ZTNA component (identity provider, controller, routers or proxy, logs) to control families with your system security plan. Ask the vendor or partner which controls their configuration supports.
SP 800-53B baselines (low, moderate, high)	Baselines select 149 controls for low, 287 for moderate and 370 for high, with the baseline set by the system's impact categorization.	Confirm the impact level of the applications behind the access layer before design. A higher baseline usually raises logging, key management and continuous monitoring work for the whole access path.
FedRAMP scope under M-24-15	FedRAMP covers cloud products that handle federal information on behalf of an agency. Systems used only for one agency's operations, not offered as a shared service, are out of scope.	A self-hosted controller in your own agency or contracted environment may fall outside FedRAMP scope. Any vendor-hosted control plane, relay or logging service that handles agency information needs a scope determination with your authorizing official.
CJIS Security Policy v6.1 encryption	For criminal justice information in transit and at rest outside physically secure locations, use FIPS 140-3 validated modules or AES with at least 256-bit keys, and scan for vulnerabilities at least monthly.	Confirm the cryptographic modules used by the tunnel, proxy and storage layers are validated for FIPS 140-3 or use AES-256. Plan monthly scanning of every access component, including self-hosted routers and proxies.
32 CFR 2002.14(h)(2) and CUI on non-federal systems	Agencies apply NIST SP 800-171 requirements when setting safeguards for controlled unclassified information on non-federal systems, unless the CUI category prescribes other safeguards.	If contractors or partners reach CUI through the access layer, their devices and networks fall under those requirements. Document which data paths touch CUI and whether the controller can reach it.
ADA Title II WCAG 2.1 AA dates	State and local government web content and mobile apps, including those provided through contracts, must meet WCAG 2.1 Level A and AA from 26 April 2027 (entities serving 50,000 or more) or 26 April 2028 (smaller entities and special districts).	Any agency-facing login or access portal, including the proxy's sign-in pages and error screens, should meet WCAG 2.1 AA before those dates. Ask the vendor for its accessibility evidence and test the portal with assistive technology.

Which open source platform fits which agency access pattern

This pattern fits staff on agency-managed laptops who today reach the internal network through a VPN that exposes whole network segments. An overlay network built on OpenZiti replaces that model with identity-based service access, so each user reaches only the services their policy names. OpenZiti separates the management plane from the data plane. The controller issues and verifies x509 identities for every participant and defines which identities reach which services through which edge routers. Edge routers form the mesh data plane, and public routers accept inbound connections while private routers only dial out. Tunnelers for Linux, Windows, macOS, iOS and Android carry unmodified software onto the overlay.

Controller placement: run the controller inside agency-controlled infrastructure so identity and policy records stay under agency custody.
Private routers: place them inside protected networks so no inbound firewall rules are needed for staff access.
Tunnelers on managed devices: deploy them through the agency's endpoint management tooling to keep the device signal consistent.
Coverage gaps: confirm which legacy protocols and client platforms the tunnelers must support before cutover.
Parallel running: keep the VPN available during migration until each application group has been verified.

Confirm with your security team which device signals OMB M-22-09 expects you to use and whether the tunneler deployment can read them.

Platforms that fit public sector zero trust access and why

Agencies moving toward zero trust need three things working together: an overlay or proxy that enforces identity-based access, an identity provider that issues the user and device signals, and a control plane the agency can run itself. The cards below cover the components that fit that pattern and the edition or deployment questions to settle before committing.

OpenZiti as the overlay

OpenZiti authenticates every connection with a cryptographic identity, applies policy, and encrypts traffic end to end. Its controller issues and verifies identities and defines which identities reach which services through which edge routers. Because private routers only dial out, agencies can avoid inbound firewall openings for internal services. Check which deployment model fits each system: network access through a router, host access with a tunneler, or application access with an SDK. The project is Apache 2.0 and created and sponsored by NetFoundry, and the README states it can run on the operator's own infrastructure.

Pomerium Core for web applications

Pomerium Core is an identity and context-aware reverse proxy that provides clientless access to internal web apps without a VPN client, which suits browser-based systems used by staff and vendors. It is licensed under Apache-2.0 and can be run as a self-operated cluster. Agencies should confirm how policies are written and managed in the open edition, since directory sync, Rego policies and administrator RBAC are reserved for Pomerium Enterprise. Test each route against the agency's identity provider and log output before cutover.

Pomerium ingress for Kubernetes

For agencies running internal services on Kubernetes, the Pomerium ingress controller applies the same identity-aware policy to cluster services that the proxy applies to web routes. It is published under Apache-2.0 in its own repository. Confirm how route definitions are versioned and reviewed, because the policy file becomes part of the access control evidence an assessor will request. Pair the controller with the agency's certificate process so TLS for each service is issued and renewed under a documented procedure.

Keycloak as the identity provider

Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, so it can front both modern applications and older SAML-based systems. It federates LDAP and Active Directory users, which matters where the agency's workforce records already live in a directory. Keycloak can also broker identities from other providers. Confirm which multi-factor methods and device signals the agency needs the identity provider to supply, because the proxy or overlay can only enforce what the identity provider and posture data provide.

Pomerium Enterprise feature boundaries

Several controls agencies often assume are part of the proxy sit in Pomerium Enterprise: directory sync, external data integrations such as device posture from FleetDM, Rego policies, RBAC for administrators, session management, and SSH session recording and playback. Pomerium's pricing page also describes Enterprise as using a self-hosted control plane. Before design sign-off, list each required control and confirm in writing whether it is in Core, in a managed Zero plan, or in Enterprise. Edition limits can change the evidence available to an assessor.

Identity governance as a separate layer

Access reviews, joiner, mover and leaver provisioning, and certifications sit outside the proxy or overlay. Evolveum midPoint is an identity governance platform that can feed group and role data into the access policies described above. Decide early which system is the source of truth for group membership, because drift between the identity provider and the governance system is a common finding. The detailed design and regulatory mapping are covered on the identity governance page.

Deployment patterns inside agency networks

An OpenZiti deployment for an agency is built from a few distinct parts, and each one changes what sits inside the network boundary. The choices below determine where the control plane lives, whether any inbound ports open, and how legacy and new applications connect. Settle these before drafting an authorization boundary.

Control plane placement

The OpenZiti controller issues and verifies x509 identities, defines which identities reach which services through which edge routers, and hosts the REST API and admin console. For agencies, the controller usually belongs inside the agency network or an accredited enclave, so identity issuance and policy stay under agency control. Ask the implementation partner to document every host, database and certificate authority the controller depends on, and where each one runs.

Public edge routers

Public edge routers are the entry points reachable from the internet, so clients outside the network can authenticate and reach the mesh. Because they face the internet, they become the components that need the most hardening review. Confirm which zone they sit in, what logging they produce, and whether the agency's boundary policy allows an internet-facing component at all for its use cases.

Private edge routers

Private routers run inside private networks and make only outbound connections, so no inbound firewall rules are needed. This is the main reason the pattern fits enclaves where inbound exceptions are hard to justify. Check that the outbound destinations are documented and approved, and that the change board understands that outbound reachability still has to be governed.

Tunnelers for legacy software

Tunnelers for Linux, Windows, macOS, iOS and Android let unmodified software reach dark services without changes to the application. This covers the older case management, reporting and internal tools that agencies cannot rewrite on short notice. With tunnelers, encryption covers tunneler to tunneler, so the agency should confirm where the tunneler sits relative to the protected service and document that path.

SDK embedding for new applications

SDKs for Go, C, Python, Node.js, Java, Swift and C# embed identity and encryption inside the application, so the service needs no listening ports at all. Traffic is protected from application to application using libsodium for the data path and mTLS for authentication. This suits new builds, but each SDK adds a maintenance and patching obligation that belongs in the system security plan.

Cloud dependencies and operator control

OpenZiti's README states the full platform can run on the operator's own infrastructure with no vendor dependencies, while NetFoundry offers a managed global network with SLAs. Agencies should confirm in writing which components, updates, telemetry or certificate services touch cloud services, and whether any hosted option is involved. Treat that inventory as a formal input to the FedRAMP and boundary review.

How an agency moves from VPN to app-by-app access

The sequence takes an agency from a broad VPN that reaches the whole network to named applications reached by identity, device signal and policy, with each phase closing on a signed or recorded output the security office can audit.

Define scope and the authorization boundary
The agency's security office and the information system security officer (ISSO) agree which systems, user groups and data types the new access path covers, and which systems stay on the VPN for now. The team records the authorization boundary in the system security plan, so the ZTNA components inherit the same scope as existing controls. Lead: the ISSO with the platform owner. Output: a signed scope statement that names the in-scope applications, identity sources and any cloud components that process federal information, checked against the FedRAMP scope rules before anything is deployed.
Inventory applications and user populations
Platform engineers list every internal application reachable through the VPN, with its protocol (web, SSH, RDP, database or UDP), hostname, owner and sensitivity, and map each one to the user groups that need it today. Many agencies find that a large share of VPN traffic goes to a few systems, and that some legacy applications cannot be fronted by a proxy at all. Output: a route inventory with one row per application, its access pattern, its owner and a proposed migration order. Confirm each owner before the next phase starts.
Integrate the identity provider and select device signals
The team connects the agency's identity provider, such as an existing Keycloak or directory-backed service, to the chosen access platform and defines group-based access rules. OMB M-22-09 expects at least one device-level signal alongside identity, so the team selects which posture data (for example, managed-device status or disk encryption) the access decision will use, and confirms that the chosen platform can consume it. Output: a policy set that ties each route to identity groups and device conditions, with multi-factor authentication enforced at sign-in.
Pilot with a small set of internal web apps
A small pilot group of users reaches a limited set of internal web applications through the new path while the VPN remains in place for everything else. The pilot tests login, policy decisions, session expiry, error handling and whether the applications work through the proxy or overlay without changes. Owners review the results with the security office. Output: test evidence that records each pilot test case, its expected and actual result, the defects found and their fixes, and a sign-off from the application owners.
Run the VPN and new access in parallel
During cutover, users keep the VPN as a fallback while migrated applications move to the new path in waves. The team monitors access logs for failed authorizations, unexpected denials and traffic that still uses the VPN, and it adjusts policies before the next wave. Each wave has a rollback step that restores VPN routing for the affected applications. Output: a cutover record for each wave showing the applications moved, the user groups affected, the issues raised, how they were resolved and the rollback decision.
Decommission broad VPN access
Once every in-scope application runs on the new path and the cutover record shows no open access issues, the team removes the VPN routes to those systems and then narrows or retires the VPN account groups that no longer need it. The change goes through the agency's normal change control, and the security office confirms that the VPN no longer reaches the migrated networks. Output: a decommissioning record listing the removed routes and accounts, the change ticket references and a post-change check that confirms the VPN can no longer reach them.
Monitor access continuously after go-live
The operations team keeps reviewing authorization logs, policy changes and device posture results, and it reviews the policy set on a schedule the agency sets in its own control procedures. The team also confirms that logs feed the agency's monitoring and retention systems, and that access reviews and log evidence are available to assessors. Output: a recurring monitoring record with log review results, policy change history and any open findings, kept with the system security plan so the authorization boundary stays accurate as applications are added or retired.

Evidence agency assessors and inspectors general ask for

This table maps the evidence an assessor or Inspector General team typically asks for to the component that produces it in a self-hosted zero trust design. Read each row as a question to confirm with the auditor before build, since the exact artifacts depend on the agency's system boundary and the assessment plan. The main takeaway is that most of the evidence comes from logs and configuration history, so retention and change control must be designed in from the start.

Evidence	Produced by	What to confirm before build
Policy definitions and change history	OpenZiti controller or Pomerium policy configuration kept in version control	Whether the agency requires signed change records and who approves policy edits
Identity assertions and MFA records	Keycloak authentication events and the identity provider logs it brokers	Which authentication methods are accepted and how MFA events are retained and exported
Access and audit logs	Pomerium access logs or OpenZiti controller and router logs forwarded to the agency log store	Retention period, log fields that show user, device and resource, and who reviews them
Device posture records	Posture signals from the device management tool passed into the access decision	Which device signals satisfy the M-22-09 device-level requirement and how posture results are stored
Encryption configuration and certificate records	TLS settings on the proxy, OpenZiti identity certificates and the certificate authority inventory	Cryptographic module requirements for the data in transit and the certificate lifetime rules
Revocation test results	Test records showing that revoking an identity or disabling a service ends active sessions and blocks new connections	Test frequency, the scenarios assessors expect and how results are signed off and filed
Inventory of protected applications and routes	Route or service definitions in the proxy or controller, matched to the system inventory	Whether every internal application in the boundary appears in the inventory and in the access policy

What changes when the agency is a federal, state or local body

The level of government and the type of data an agency handles change which access controls are mandatory and where the boundary of the design sits. Start by classifying each application by the data it touches, then decide which regime governs each class. A single ZTNA control plane can serve several regimes, but the evidence, logging and encryption settings often differ by the data flowing through each route.

FedRAMP scope is narrower than many teams assume. Under the FedRAMP scope rules, the authorization requirement attaches to cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. A self-hosted OpenZiti controller or Pomerium Core cluster running in the agency's own environment is not a cloud service offered to the government, so it does not carry a FedRAMP requirement by itself. A hosted control plane run by a vendor for the agency's traffic may be a different case, so confirm with the agency's authorizing official and its FedRAMP scope analysis before choosing a managed option. Criminal justice data is a separate trigger. Where CJI flows, the CJIS Security Policy v6.1 requires FIPS 140-3 validated modules or AES with 256-bit keys for CJI in transit outside physically secure locations, so confirm the cryptographic modules in every tunneler, proxy and SDK used on those routes.

Controlled unclassified information held by non-federal systems follows a different path. Under 32 CFR 2002.14(h)(2), federal agencies use NIST SP 800-171 when setting requirements for CUI on non-federal systems, which means contractors and grantee networks reaching agency apps may need to meet those requirements on their own side of the tunnel. NIS2 is another case: it covers central government entities regardless of size, but it excludes entities working in national security, public security, defense or law enforcement. Agencies in those excluded areas should not assume NIS2 reporting or risk-management duties apply, while agencies in general administration should check whether their member state extends NIS2 to local bodies. Each boundary is a question for counsel, but the access design answers them the same way: separate policy domains, separate logs and separate identity sources for each class of user and data.

Common questions from agencies planning zero trust access

Does OMB M-22-09 require zero trust access by the end of FY2024?

M-22-09 set a federal zero trust architecture strategy with specific cybersecurity standards and objectives that agencies were expected to meet by the end of fiscal year 2024. It also requires agencies to consider at least one device-level signal alongside identity information when authorizing users. Agencies that have not finished should confirm with their agency CIO office and their Inspector General which objectives are still open, which ones carry over into current plans, and how progress is reported. The memo sets goals, so the gap between that deadline and today is best measured against the agency's own inventory of applications and access paths.

How do device signals work in a zero trust access design?

A device signal is a fact about the endpoint, such as whether it is managed, patched, encrypted or enrolled, that the access decision can check alongside the user's identity. M-22-09 requires agencies to consider at least one such signal when authorizing a user. In an open source design, the identity provider or the ZTNA policy engine receives the signal from an endpoint management or posture tool and makes it a condition for each route or service. Pomerium's Enterprise edition lists external data integrations such as FleetDM device posture, so confirm which posture sources your chosen edition and tooling can read before you commit to a design.

Does FedRAMP apply to a self-hosted zero trust platform?

FedRAMP's scope covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. Under the FedRAMP Consolidated Rules for 2026, systems used only for a single agency's operations on cloud infrastructure, and not offered as a shared service, are out of scope. A control plane that your agency runs in its own accounts or data centers is therefore usually a question for your authorizing official rather than a FedRAMP listing. Hosted control planes, such as a vendor-run management console, need to be checked against the scope rules and the vendor's authorization status. Confirm the boundary with your agency's security office in writing.

What drives the cost of an agency zero trust access project?

The main cost drivers are the number of applications to migrate, the mix of app types (web, SSH, RDP, databases, UDP), the number of identity providers and device signal sources to integrate, and the approval and accreditation work your agency requires. The open source software itself carries no license fee for Pomerium Core, OpenZiti and Keycloak, which are Apache-2.0 licensed, but you still pay for infrastructure, staff time, integration, testing and ongoing operations. Recurring costs include patching, upgrades, certificate handling and log retention. Ask any implementation partner for a quote that separates one-time work from annual operations and lists assumptions about applications and environments.

Can agency staff run a self-hosted zero trust platform themselves?

Internal staff can run it if they have people who understand identity protocols, network routing, certificate lifecycles and the agency's accreditation process, and enough time for on-call and upgrades. Most agencies start with a small, well-defined pilot, then decide which parts stay in-house. Confirm the skills and hours your team can commit, the on-call coverage expected from the operations team, and the upgrade cadence that your change board will accept. A partner can cover implementation, hardening and documentation, while your staff keep day-to-day control of policies and access reviews.

What must an agency provide before a zero trust project starts?

An agency typically needs to provide an inventory of internal applications and their owners, the identity provider and directory it will use, the device management or posture tools in place, and the network paths users rely on today. It must also name the authorizing official, the security team that approves changes, and the environments where the platform will run, including cloud accounts, data centers or isolated networks. Access to test users and a rollback plan are also needed before cutover. Ask a partner to list these inputs in the written scope so that gaps are visible before work begins.

How does DeployOpen scope a zero trust access engagement?

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open source platforms inside the client's own infrastructure. Most engagements are fixed-scope, so the applications, environments, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, which remain the job of independent auditors. Ongoing support, upgrades and testing are available as retainers. Ask for a scope document that lists in-scope applications and out-of-scope items.

Which NIST controls should an agency map its zero trust design to?

Agencies typically map access control, identification and authentication, audit and accountability, and system and communications protection controls from NIST SP 800-53 Rev. 5 to the chosen design. The SP 800-53B baselines select different numbers of controls for low, moderate and high impact systems, so the baseline for each system determines the evidence you will need. Release 5.2.0 of 27 August 2025 is the current catalog release. Confirm with your authorizing official which baseline applies, and use the OSCAL profiles to generate a control list rather than building one by hand.

How DeployOpen scopes and delivers public sector zero trust access

DeployOpen works on a fixed-scope engagement where the agency, its integrator or its prime contractor agrees the scope, deliverables and timeline in writing before any work starts. For a zero trust access project, that scope usually lists the applications in the first wave, the identity provider they will use, the device signals that will feed authorization, the control plane platform (for example OpenZiti, Pomerium or NetBird) and the migration steps for each application. Agencies should confirm early who owns the decisions on each of these items, because a scope that leaves the identity provider or the device signal source undefined tends to stall at the authorization design stage. Quotes follow from that written scope, and DeployOpen does not publish a price list.

All implementation happens inside the agency's own infrastructure, whether that is an agency cloud tenancy, a data center or an isolated network. The control plane, such as the OpenZiti controller or the Pomerium Core cluster, runs in that environment, and the agency keeps its keys, logs and policy definitions. Hardening covers the items an assessor will ask about: TLS configuration, administrative access to the controller, separation of the policy administrator from the enforcement points, and log forwarding to the agency's monitoring stack. DeployOpen also produces the documentation the agency needs to operate the system, including the access policy inventory, the runbook for revoking a dark service, and the test results for each application. Testing covers functional access checks, negative tests that confirm unauthorized users cannot reach a service, and failover tests for the routers.

DeployOpen prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, and an agency's authorizing official, inspector general or independent assessor makes those determinations. Agencies should ask for a mapping from each delivered control to the NIST SP 800-53 Rev. 5 controls in their baseline, along with the evidence location for each one. Ongoing upgrades, patching of the open-source components and continuous security testing can be covered by a retainer, which the agency should price separately from the initial build so that operating costs stay visible. Ask any partner to state in writing which parts of the evidence package are generated by the delivery and which still require agency staff to collect.