NIST SP 800-207 zero trust with open source

Implementing NIST SP 800-207 zero trust with open source: the short answer

NIST SP 800-207 is a concept framework, not a product list. It describes zero trust as moving defenses from static, network-based perimeters toward users, assets and resources, and it defines logical components (a policy engine, a policy administrator and policy enforcement points) that make access decisions for each request. Open-source software can fill these roles, but no single project does it all. In practice, a self-hosted design pairs an identity provider such as Keycloak with an overlay network or identity-aware proxy such as OpenZiti or Pomerium, and feeds device signals into the decision. The framework asks the organization to know who or what is requesting access, to check the device and context, to grant access per resource rather than per network segment, and to log and monitor every decision. Each of those requirements needs an owner, a data source and evidence.

For a leadership team or auditor, the useful question is which component makes each decision and where that decision is enforced. The identity provider holds the authentication record, the controller or proxy policy holds the authorization rules, and the enforcement point blocks or allows the connection. Device posture is the signal most likely to be missing. Open-source options for posture are thinner than for identity, so the reader should confirm which device signals the chosen overlay or proxy can consume, whether through its own integrations or through a commercial feature, and what happens when a signal is unavailable. Keycloak's own high availability and database requirements also shape whether the identity layer can support the decision path reliably.

DeployOpen implements and documents these designs in the client's own infrastructure and prepares the controls and evidence that an assessor will ask for. DeployOpen does not issue audit reports, attestations or certifications. Independent assessors and certification bodies make those determinations, so the design should be written so an assessor can test it. Before scoping work, ask your team to map each NIST component to a named product, confirm the device signal sources in writing, and identify which resources still rely on network position for access.

Mapping SP 800-207 tenets and components to requirements

This table maps the resource-focused, per-session and logging expectations of NIST SP 800-207 to the open-source components that can meet them, along with the configuration work each one needs. Read each row as a design question: which component decides, which one enforces, and what evidence you will have afterward. The main takeaway is that no single open-source product covers every element, so the identity provider, the overlay or proxy and the logging stack must be designed together.

SP 800-207 element	What the function must do	How to configure the open-source component
Resource-focused access	Grant access to individual resources (applications, services, hosts) rather than to network segments, so a valid session reaches only the named resource.	Publish each app as its own route or service. In OpenZiti, define services and dial policies per identity. In Pomerium, define one route per app with its own policy. Avoid broad subnet routes unless a specific need is documented.
Per-session authentication and authorization	Authenticate the user and device for each session and re-evaluate access, with the decision tied to the requester rather than the network location.	Use Keycloak or another OIDC provider as the source of identity. Set short session lifetimes in the proxy or overlay, enable MFA at the identity provider, and confirm that revocation ends active sessions in your chosen product.
Dynamic policy using identity and device signals	Policy decisions use attributes such as group, role, device state and risk, and they change when those signals change.	Map identity provider groups to policy attributes. Pomerium Enterprise reserves external device posture integrations and Rego policies, so confirm which posture sources your edition supports. For OpenZiti, confirm how posture checks are modeled before relying on them.
Policy engine and policy administrator	The engine makes the access decision and the administrator sets up and changes the paths that enforce it, with clear separation of duties.	Keep the policy store under your control: the OpenZiti controller or a self-hosted Pomerium Core cluster. Apply change control and review to policy files, and limit who can edit policies. Confirm where administrator roles are defined in your edition.
Policy enforcement points	Each access path has a point that allows or blocks traffic, and it must sit in front of the resource, not only at the network edge.	Place OpenZiti edge routers, tunnelers or SDKs at each resource, or place a Pomerium proxy in front of web and SSH services. Keep resources dark where possible, so no inbound ports need to be open. Test that direct connections to the resource are refused.
Logging and monitoring of access	Record who accessed which resource, when, from which device and with what decision, and make those records available for review.	Forward controller, proxy and identity provider logs to your SIEM. Confirm which access logs each edition produces and their retention. Keycloak exposes metrics for observability. Check that decision logs include the policy that allowed or denied each request.
Gap: device trust and posture	The standard describes device signals as a input to policy, but the open-source stack does not supply a complete device health source by default.	Choose a posture source (for example an endpoint agent or MDM feed) and confirm the integration with the chosen overlay or proxy. Document the residual risk for unmanaged devices.

Which SP 800-207 deployment model fits your environment

Use this model when the control plane can run in a cloud account or enclave that you operate, and enforcement points sit close to the applications they protect. NIST SP 800-207 places the policy engine and policy administrator in front of every access decision, so the design question is where those functions run and who can reach them. With OpenZiti, the controller issues and verifies identities and defines which identities reach which services through which edge routers. Private routers inside a private network only make outbound connections, so no inbound firewall rules are needed for them.

Network access: an edge router in a trusted zone gives enrolled devices a path to internal networks without installing a client on every server.
Host access: a tunneler beside a service lets it accept connections only through the overlay, with no open listening ports.
Application access: an SDK embeds identity and encryption in the application when your team controls the code.
Pomerium pattern: an identity-aware reverse proxy fronts web apps. With Pomerium Zero, Pomerium hosts the control plane while the Core cluster runs in your environment, so application traffic stays there. (Pomerium pricing)
Constraint: a hosted control plane still holds policy and access logs. Confirm exactly which metadata leaves your boundary before approval.

Confirm with the vendor which control plane components, relays and log streams leave your boundary, and record the answer in your policy engine design.

Open-source platforms that fit each zero trust role

NIST SP 800-207 separates the decision points from the enforcement points, and no single open-source project covers every role. The cards below pair each role with a platform that fits it, what that platform leaves to you, and what to confirm before you commit.

Keycloak as identity provider and policy input

Keycloak issues the identity, group and authentication signals that a policy engine reads before granting access. It supports OpenID Connect, OAuth 2.0 and SAML 2.0, and it can federate Active Directory or LDAP. It does not evaluate device health or make access decisions on its own, so you still need a policy layer and a posture source. Confirm the high availability design, since both supported clustered designs need a synchronously replicated database.

OpenZiti as overlay with dark services

OpenZiti fits the policy decision and enforcement roles at the network layer. Its controller issues x509 identities and defines which identities reach which services, while edge routers carry the traffic. Services can be dark, with no listening ports, and revoking access ends active connections. Check whether SDK-based application access or tunnelers suit your apps, and confirm how your team will operate the controller.

Pomerium Core as identity-aware proxy

Pomerium Core is an Apache-2.0 reverse proxy that checks identity and context on every request to a web app, SSH host or TCP service. It fits the enforcement point role for browser-based access and sits naturally with Keycloak as its OIDC provider. Its Core edition is self-run, and the policy and admin features listed below are reserved for Enterprise. Pomerium Zero can host the control plane while the cluster stays in your environment, but confirm that option against your data handling rules before relying on it.

Device signals from osquery or Wazuh agents

Device posture is the signal most NIST deployments lack. osquery exposes endpoint state through SQL queries, and Wazuh agents report inventory, configuration and alerts to a central manager. Neither product issues access decisions, so a policy engine must consume their output through a supported integration. Pomerium lists FleetDM device posture as an Enterprise integration, so confirm which posture sources your chosen policy layer can read before you design around them.

Enterprise edition limits to confirm

Several capabilities that auditors often ask about sit outside the open-source tier. Pomerium Enterprise reserves directory sync, Rego policies, RBAC for administrators, session management and SSH session recording. Confirm whether each of these is required for your control set, and budget for the edition that includes it. Also check whether the Pomerium Zero Business plan limits, including 100 routes and 100 policies, fit your application count.

How Keycloak supplies identity and session signals

In an open source zero trust design built on NIST SP 800-207, Keycloak is most often the identity provider that feeds the policy engine: it authenticates the user, issues OpenID Connect or SAML assertions, and brokers logins to upstream directories or external identity providers through its identity brokering feature. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0 single sign-on and LDAP and Active Directory user federation, so the same realm can serve browser-based apps, overlay network enrollment and legacy SAML services. The policy engine, whether it is the proxy's policy language or the controller's service policies, only sees what Keycloak issues, so the token contents and session behavior are part of the access decision, not an afterthought.

Production use requires an external PostgreSQL, MariaDB, MySQL, SQL Server, Oracle or Aurora-class database rather than the development file database, and a high availability design that Keycloak documents as either a single cluster spread across availability zones or a multi-cluster design, both needing a synchronously replicated database. For updates, use the Keycloak Operator with manual approval mode, which the project strongly recommends to avoid unplanned upgrades, and be aware that schema migration runs automatically at startup by default. Large deployments can apply migration SQL manually. Schedule that step as a controlled change, because an identity outage stops every zero trust access decision that depends on it.

Before go-live, confirm with your architects and the policy engine owners which access token and session lifetimes match your risk tolerance, how long a revoked user or disabled device can still hold a valid token, and which claims (groups, roles, authentication method, device or assurance attributes) the proxy or overlay will read. Confirm that the claims you need can be mapped from upstream directories, that multi-factor authentication results are present in the token, and that session logs reach your SIEM. These settings are deployment decisions, so validate them in a test realm with the actual policy rules before relying on them for regulated access.

Evidence auditors ask for in a zero trust assessment

What architecture diagrams do auditors expect for a zero trust design?

Auditors expect a current diagram that maps each NIST SP 800-207 component (policy engine, policy administrator and policy enforcement points) to a named product, host and network zone. The diagram should show the identity provider, the OpenZiti controller or Pomerium control plane, edge routers or proxies, device signal sources and the SIEM that receives logs. Keep a version history tied to change records, and confirm with your assessor whether they want logical, data flow or network diagrams, since each answers a different question. Confirm who owns the diagram and how often it is reviewed against the live configuration.

How do you prove which policies control access to each application?

A policy inventory lists every rule that grants or denies access, with the identities or groups it covers, the services or routes it applies to, the posture conditions it requires and its owner. In OpenZiti, the controller holds service, identity and policy definitions that can be exported through its REST API or admin console. In Pomerium, route and policy definitions live in configuration that is typically stored in version control, which gives a diff history. Confirm that exports can be scheduled, that they are stored outside the system they describe, and that each policy carries an approver and a review date.

Which authentication logs should the identity provider keep?

Authentication evidence comes from the identity provider, such as Keycloak, that issues the tokens or assertions used by the access layer. Useful records include successful and failed sign-ins, the authentication method used (password, OTP, passkey or certificate), session creation and termination, and administrative changes to users, clients and realms. Keycloak exposes events that can be stored in its database and forwarded, and it publishes metrics for observability. Confirm the retention period in your database, whether events are exported to the SIEM in near real time, and whether the records show the unique user identifier needed for the audit trail.

What records show authorization decisions made at the access layer?

Authorization evidence shows each allow or deny decision with the identity, target service, time, source and the policy that matched. Pomerium access logs record per-request decisions for routes it protects, and OpenZiti controller and edge router records show which identities dialed which services and when sessions were terminated. These records answer the question of whether access was both authorized and monitored. Confirm the log fields your auditor needs, whether denied attempts are logged as well as allowed ones, how logs are shipped to the SIEM, and whether timestamps are synchronized across components.

What device posture records do auditors ask for?

Device posture evidence records the checks a device passed before access was granted, such as disk encryption, operating system patch level, endpoint agent presence or managed-device status. Posture data usually comes from an MDM, EDR or osquery-based source, and the access layer consumes it through an integration. Pomerium reserves external posture integrations, such as FleetDM, for its Enterprise edition, so confirm which posture sources your chosen edition supports. Ask for the timestamp of each posture check, the result stored with each access decision, and what happens when posture data is stale or missing.

What change records prove upgrades and configuration changes were controlled?

Change records show who changed a control, what changed, why, who approved it and when it went live. For this stack, they come from the ticketing system, the version control history of configuration, the Keycloak Operator or deployment pipeline logs, and the release notes of each component. Keycloak recommends manual approval mode for operator updates to avoid unintended automatic upgrades, and it applies database schema migrations at startup by default, which should be recorded as a change. Confirm that each upgrade has a test result, a rollback plan and a link to the approval.

How do access review results show that least privilege is maintained?

Access review results document periodic confirmation that each identity still needs each grant, along with the reviewer, the decision and any removals. In a ZTNA design, reviews cover group membership in the identity provider, OpenZiti identities and service policies, and Pomerium route policies. If identity governance runs in a separate platform such as midPoint, its certification campaigns become the primary record, and the ZTNA policies should be checked against them. Confirm the review frequency your framework expects, who signs off, and whether removals are reflected in policy exports within a time you can state to the assessor.

Gaps that tooling alone does not close

Deploying an overlay or proxy gives you enforcement points, but NIST SP 800-207 describes an architecture, not a product list. The cards below cover the gaps that remain after installation: device signals, policy design, edition limits, standards evidence and the operating model that keeps the design honest.

Device posture needs outside signals

Posture is not built into every overlay or proxy. An overlay can check that a client is enrolled, but checks such as disk encryption, OS patch level or EDR presence usually come from a separate device management or endpoint tool and must reach the policy engine through an integration you build and test. Ask each candidate which posture sources it can consume natively, which need custom code, and what happens when a device signal is missing or stale.

Continuous evaluation depends on policy design

NIST SP 800-207 expects access decisions to be re-evaluated as conditions change, but the platform only re-checks what you write rules for. A session that stays open after a group change, or a token that outlives a role removal, is a policy gap, not a platform defect. Document which signals trigger re-authorization, how fast revocation must take effect, and how you test that a revoked identity loses access to active sessions.

The framework does not prescribe products

NIST SP 800-207 describes logical components such as the policy engine, policy administrator and policy enforcement points, and general deployment models. It does not say which open-source project fills each role or how they must be wired together. Your architecture document has to name the product chosen for each component, the trust data it consumes and the interfaces between them, because an assessor will test that design rather than the framework text.

Edition limits on self-hosted features

Open-source cores often leave specific features in a commercial tier. In Pomerium's case, the Enterprise edition reserves items such as directory sync, Rego policies, RBAC for administrators, session management and SSH session recording. If your design depends on any of these, the self-hosted core may not meet it. Confirm each control against the edition you would actually run, and get the license terms in writing before you rely on a feature.

Standards mapping needs an assessor

A mapping of components to NIST SP 800-207 or to a control set is a design argument, and only an independent assessor or certification body can conclude that a control is met. Build the mapping so each claim points to a configuration, a log source or a test result you can show. Expect the assessor to ask how each control was verified, who approved the exception list and how the evidence is kept current after upgrades.

A documented trust model and operations

Zero trust depends on running the platform as well as installing it. You need a written trust model that states which identities, devices and services are trusted, who can change policy, how signing keys and certificates are rotated, and how the control plane is backed up and restored. Assign owners for the identity provider, the overlay or proxy and the device signals, and rehearse access revocation so the process works under pressure.

What drives the cost and effort of a self-hosted zero trust build

The largest cost of a self-hosted NIST SP 800-207 build is usually labor, not software. The open-source components that map to the policy engine, policy administrator and policy enforcement points are typically free to download, so the budget is driven by the people who design the trust model, integrate the identity provider with directories and device signals, and keep the enforcement points running. Before quoting, ask each bidder to separate software licensing from services and to state which edition is assumed. Several candidates have a free core and a paid tier: Pomerium Core is Apache-2.0 and self-run, while its Enterprise edition reserves directory sync, Rego policies, RBAC for administrators and session recording. Keycloak is Apache-2.0 with no paid edition in its upstream project, but a supported distribution such as Red Hat build of Keycloak carries a subscription. Confirm which features your design needs, since a feature gap found mid-project changes the cost.

Infrastructure is a recurring cost that scales with the design. The identity provider needs a database from Keycloak's supported list, a clustered deployment, and synchronous database replication for its high availability designs. Gateways and controllers add compute in each zone where they run, and OpenZiti or Pomerium clusters need certificates, DNS and monitoring. Ask for the number of nodes, the database engine and the backup and restore procedure in writing. Directory and device integration is the second recurring driver: each new source, such as Active Directory federation or a posture feed, adds testing and maintenance. One-time work includes the initial trust model, policy design, integration build and penetration testing of the enforcement points. Recurring work includes Keycloak upgrades, which the Operator documentation advises approving manually, and reviews of policies as people and apps change.

Plan the upgrade cadence before you sign. Keycloak plans four minor releases a year and says breaking changes in a minor release are opt-in, but each upgrade still needs a test cycle, a schema migration plan and rollback steps. Schema migration runs automatically at startup by default, and the upgrading guide suggests manual migration for large deployments, which adds effort. For a price comparison, Pomerium publishes per-user plans for its managed Zero offering (Zero Business at $9 per user per month billed monthly or $7 billed annually), which you can set against your own run cost. Those plans cover a managed control plane only, so the comparison should include the Core cluster you would still run. Ask each vendor or partner for a quote that lists the one-time build, the monthly run effort, the license terms for each edition, and the effort to add a new application.

Questions buyers ask before hiring help with zero trust

How much does implementing NIST SP 800-207 zero trust with open source cost?

No single figure applies, because cost depends on the scope agreed in writing. The main components are the work to design the policy engine, policy administrator and enforcement points, the integration with your identity provider and device signals, application-by-application migration, and testing. Software licenses for the open-source core are usually zero, but some editions and managed control planes carry fees. Pomerium's public pricing lists Core as open source and self-run, and paid plans as per-user subscriptions, which is one comparison point. Ask every bidder to separate one-time build effort from recurring costs such as hosting, upgrades, patching and support retainers, and to price each application migration separately.

How long does a zero trust rollout take?

Duration follows the number of applications, user groups, device types and identity sources in scope, and it is not a fixed number. A narrow pilot covering one identity provider and a small set of web applications is far quicker than a migration that retires a VPN for all users and network segments. Plan the work in phases: design and policy mapping first, then a pilot, then application-by-application cutover with the VPN kept in place during transition. Ask for a phased plan with entry and exit criteria for each phase in the written scope, and make sure it names the approvals and change windows your organization needs.

What does our team need to provide during the engagement?

Expect to supply named owners for the identity provider, the network, the endpoint management tooling and each business application. Your team also needs to decide access policy in business terms, such as which groups reach which resources, under which device conditions and for how long. Provide access to test accounts, staging environments, current VPN configuration, firewall rules and logs, and a change approval path. Without these inputs, design decisions stall. Confirm the expected time commitment from each owner in the statement of work before work begins.

Can our internal team build this zero trust setup without outside help?

A capable team can build a zero trust design alone, especially if it already runs an identity provider, certificate management and infrastructure as code. The harder parts are usually policy design across many applications, high availability for the control plane, secure upgrade paths, and producing the evidence an assessor asks for. Ask yourself whether your team has time for ongoing operations and upgrades after launch, not only for the first deployment. Many organizations split the work: internal staff own policy and business decisions, while an implementation partner handles architecture, deployment and documentation.

Does DeployOpen certify that our zero trust design meets compliance requirements?

No. DeployOpen plans, implements, hardens and documents systems and prepares the controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. For example, a HIPAA technical safeguards review or an FTC Safeguards Rule assessment would require evidence such as unique user identification, access logs and encryption settings, which the implementation can help produce. Ask any partner to state in writing which evidence it will deliver and which decisions remain with your assessor.

Should we choose OpenZiti or Pomerium for zero trust access?

Choose OpenZiti when you need network-level or application-embedded access that reaches non-web services and can keep services dark with no open inbound ports. Choose Pomerium when the main need is identity-aware access to web applications and other HTTP-based services through a reverse proxy, with a simpler clientless experience. OpenZiti supports network, host and SDK-based access models and encrypts traffic end to end, while Pomerium Core is Apache-2.0 licensed and fits well with Kubernetes ingress. Many estates use both. Test each candidate against your application list, your device posture requirements and your logging needs before deciding.

What breaks most often when a zero trust control plane is self-hosted?

The most common failures involve identity provider dependencies, certificate expiry, database availability and upgrade timing. Keycloak, for example, requires a synchronously replicated database for its supported high availability designs, and its operator documentation strongly recommends manual approval for operator updates to avoid unintended upgrades. Plan monitoring for the control plane, test failover before cutover, and document a rollback path. Confirm the supported high availability architecture, database engine and upgrade process with each vendor before you commit to a design.

How a DeployOpen zero trust engagement runs

The engagement moves from a written scope to a mapped design, a working build, tested controls and an evidence package the client's own assessors can review. Each phase closes with a named output, so the client decides what moves forward.

Agree scope and boundaries in writing
DeployOpen and the client agree the scope in writing before work starts: which applications, user populations, device types and network segments are covered, which identity provider is the authority, and where the control plane will run. The client's security, network and compliance leads sign off the scope document. The step closes when the scope, deliverables and timeline are accepted, and anything left out is recorded as out of scope.
Map NIST components to the chosen stack
DeployOpen maps the policy engine, policy administrator and policy enforcement points described in NIST SP 800-207 to concrete components, such as an OpenZiti controller, a Pomerium proxy or a Keycloak realm, and records which device signals and identity attributes feed each decision. The output is a component map, a data flow diagram and a gap register listing what the open-source pieces do not cover and who will close each gap. The step closes when the client's architecture reviewers accept the map.
Design policy, identity and deployment model
The team sets the access model for each application: network access through an edge router, host access with a tunneler, or application access with an embedded SDK. It defines identity groups, per-resource policies, session lifetimes and the logging fields each decision produces. Keycloak high availability and database requirements are checked against the client's environment during this step. The output is a signed design document and a policy matrix that maps user groups to resources.
Build, harden and integrate the components
Engineers deploy the control plane, edge or proxy components and the identity provider inside the client's own infrastructure, connect them to the directory and device signal sources, and configure logging to the client's SIEM. Upgrade and operator update settings are fixed to manual approval where the platform recommends it. The step closes when a pilot application is reachable only through policy, and every test user's access is logged end to end.
Test policy enforcement and failure behavior
DeployOpen tests the design against its own requirements: denied access without a valid identity, dark services that show no open ports, immediate session termination after revocation, and behavior when the identity provider or control plane is unavailable. Security testing covers the applications and APIs behind the gateway. Each test has a recorded expected result and actual result. The step closes with a test report listing any failures and their remediation status.
Prepare the compliance evidence package
DeployOpen assembles the evidence the client's assessors will ask for: the component map, policy exports, access and audit logs, configuration baselines, test results and the operational runbooks. Evidence is mapped to the controls the client is assessed against, such as unique user identification, audit controls and multi-factor authentication. DeployOpen prepares this material but does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. The step closes when the client confirms the package is complete for its assessor.
Hand over runbooks and operations
The client's operators receive documentation, administrator training, upgrade and backup procedures, and a list of open gaps with owners. Ongoing support, upgrades and continuous testing are available as separate retainers, and the handover states which of those the client has chosen. The step closes when the client's operators have run the runbooks themselves in a supervised session and accepted the handover.

How DeployOpen scopes, delivers and supports zero trust work

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For NIST SP 800-207 work, that means agreeing in writing which policy engine, policy administrator and enforcement points are in scope before any component is installed.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope names the identity provider, overlay or proxy, device signal sources and protected applications covered by the design.
Scope also records which SP 800-207 components are self-hosted, which are provided by a vendor, and which gaps stay with your team.

How we build

Components are deployed in your environment, including the controller or proxy control plane, edge or enforcement points and identity integrations.
Access policies are written per resource and tested against the identities, groups and device states named in the scope.
Security testing of the deployed access path can cover applications, APIs and infrastructure, including dark services and revocation behavior.

How we hand over

Handover includes architecture documentation, configuration records, policy inventories and runbooks for each component.
Evidence is prepared for compliance assessments, such as access logs and authentication records, for review by your independent auditors.
DeployOpen prepares controls and evidence but does not issue audit reports, attestations or certifications.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Upgrade planning covers controller, proxy and identity provider releases, including change approval steps your team agrees to.
Retainer scope is agreed in writing, including which components, environments and testing cadence it covers.

Implementing NIST SP 800-207 zero trust with open source