Zero trust access to internal web apps for contractors: why this case differs
A team that must let outside staff use two or three internal tools, without placing them on the corporate network, usually ends up with the same short answer: put Pomerium in front of each app and gate every route with the organization's own identity provider. The design, however, rests less on the proxy than on three things around it: how contractor identities are created, changed and removed, whether every contractor account uses multi-factor authentication, and whether every request is logged in a form the organization can review. Pomerium is one of several options, but for browser-based access to a handful of web apps the choice of platform is narrow, so the effort belongs in identity and logging.
A VPN is the wrong tool for this group. It places the user on the network, so a contractor who needs one ticketing tool can often reach far more than that tool. Contractors also tend to connect from unmanaged or lightly managed machines, and their access usually ends on a fixed date that is hard to enforce with a shared VPN credential. An identity-aware proxy works per route: each application gets its own policy, the policy reads group membership or attributes from the identity provider, and the session can be made short. Before building, confirm which apps are browser-based, whether any need SSH, database or UDP access (which changes the tool), and who owns the decision to end a contractor's access when a contract stops.
Confirm three things with your identity team before you choose a design. First, whether contractors will be external identities in your existing provider, such as Microsoft Entra ID, Okta or Keycloak, or a separate tenant, since each option changes the sponsorship and expiry workflow. Second, whether your MFA policy for contractors is at least as strict as for employees, because the FTC Safeguards Rule at 16 CFR 314.4 requires multi-factor authentication for any individual accessing an information system, and the HIPAA Security Rule at 45 CFR 164.312 requires unique user identification and audit controls for ePHI systems. Third, where request logs will be stored and who reviews them, because a proxy log that nobody reads does not show control.
Which regulatory requirements shape contractor web access
This table maps two US rules, the HIPAA Security Rule access and transmission provisions and the FTC Safeguards Rule, to specific design decisions for contractor access to internal web apps. Read each row as a requirement, the design choice that addresses it, and the evidence to keep. The rules govern your own systems and data, so confirm with counsel and your compliance lead which of them apply to your data and contracts before you treat any row as binding.
| Requirement | What it asks for | Design decision for contractor access |
|---|---|---|
| Unique user identification (45 CFR 164.312) | Each user is identified uniquely so activity can be traced to a person | Give every contractor a named identity at the identity provider, with no shared accounts for vendor staff |
| Person or entity authentication (45 CFR 164.312) | Verify that a user or system is who it claims to be before access | Require sign-in through the identity provider before Pomerium forwards any request to an internal app |
| Multi-factor authentication (16 CFR 314.4) | MFA for any individual accessing any information system in covered financial institutions | Enforce MFA at the identity provider for every contractor policy, including contractors who use only browsers |
| Access control (45 CFR 164.312) | Limit system access to users and software granted access rights | Write one policy per route tied to identity provider groups, and deny by default for routes not listed |
| Transmission security (45 CFR 164.312) | Guard electronic health information sent over networks | Terminate TLS on every route, including internal upstreams where the app supports it, and reject plain HTTP |
| Encryption in transit (16 CFR 314.4) | Encrypt customer information in transit and at rest | Confirm TLS versions and certificate handling at the proxy, and document which app data stores also encrypt at rest |
| Audit controls (45 CFR 164.312) | Record and examine activity in systems that contain ePHI | Send Pomerium access and audit logs to your SIEM, with contractor identity, route, time and outcome on every request |
| Monitoring user activity (16 CFR 314.4) | Monitor and log the activity of authorized users | Retain request logs centrally and review contractor access on a schedule your compliance lead defines |
Which open-source platforms fit contractor browser access
Contractor browser access depends on three decisions: the proxy that enforces each route, the control plane that holds the policy, and the identity provider that proves who the contractor is. The cards below cover the components that usually appear in that design and the checks to run before choosing any of them.
Pomerium Core as the route proxy
Pomerium Core is the identity-aware reverse proxy that sits in front of each internal web route and checks every request against policy. It is licensed under Apache-2.0 and you run it yourself, so application traffic stays in your environment. Confirm that your team can operate the cluster, certificates and upgrades, because Core does not come with a vendor-hosted control plane. Also confirm how route policy is maintained at your scale before you commit to hand-managed configuration.
Pomerium Zero for managed control
Pomerium Zero keeps the cluster in your environment while Pomerium hosts the control plane and management console. The listed plans include clientless web access, SSO, mTLS, attribute-based policies, access and audit logs, a management API and Terraform support. Check the route, policy and cluster limits on the plan you need, and confirm where logs are stored and for how long, since contractor access records may be requested by auditors or customers.
Pomerium Enterprise for self-hosted control
Enterprise is the edition where the control plane runs in your environment, and it also reserves directory sync, Rego policies, RBAC for administrators and session management. These features matter when contractor lists come from an HR or partner directory, or when policy must be written in Rego for review. Ask Pomerium to confirm which of these features are included in the quote and whether the self-hosted control plane has the same logging coverage as the managed plan.
Keycloak as the identity provider
Keycloak supports OpenID Connect and SAML 2.0, brokers identities from partner directories and runs under Apache-2.0. For contractor access it lets you separate a contractor realm or identity broker from employee login, which keeps partner accounts and their MFA rules apart. Its production databases include PostgreSQL, MySQL and Oracle Database, and its high availability designs need a synchronously replicated database. Confirm that database and cluster topology before you make Keycloak the single login path for every route.
authentik for contractor login flows
authentik is licensed under MIT except for its authentik/enterprise directory, which has a separate enterprise license. Its flows let you define different enrollment and sign-in steps for partners, such as invitation-based onboarding or additional verification. Confirm which features you need sit outside the enterprise directory and which license terms apply to them, and test how it federates with Pomerium using the OpenID Connect settings your environment requires.
ZITADEL for passkeys and multi-tenancy
ZITADEL is licensed under AGPL-3.0 and lists SSO, MFA, passkeys with FIDO2 and WebAuthn, OpenID Connect certification, SAML 2.0, SCIM and multi-tenancy. Multi-tenancy fits organizations that want each contractor company in its own tenant with its own policies. Because AGPL-3.0 has network-use obligations, have counsel confirm how your modifications and hosting affect your obligations before you deploy it for a partner-facing login.
How the contractor access rollout runs, phase by phase
The sequence moves from an inventory of contractor apps and groups to a Pomerium route map, tested policies, forwarded request logs and a recurring access review. Each phase closes with a named artifact, so the client can see what has been proven before the next phase begins.
Inventory apps and contractor groups
The client's application owner and identity team list every internal web app a contractor needs, with its hostname, the protocols it uses, and who owns it. They pair each app with the contractor groups that need it and record which apps must never be exposed to outside users. DeployOpen reviews the list with the client to flag apps that use non-HTTP protocols, which need a different access path. The output is an agreed app inventory and a group-to-app matrix, signed off by the app owners.
Define routes and identity-tied policies
Each approved app becomes a route in Pomerium, with its upstream address and its public hostname. Policies are written per route and tied to groups in the client's identity provider, such as Microsoft Entra ID, Okta or Keycloak, so membership changes take effect without editing Pomerium. The team also decides which routes need MFA, which need a device or network condition, and which sessions end after a set time. The output is a route map and a policy set, reviewed by the app owners and the security lead before any traffic flows.
Deploy Pomerium Core in the client environment
DeployOpen installs Pomerium Core inside the client's own cloud account, data center or Kubernetes cluster, with TLS certificates issued for each public hostname. The identity provider connection is configured with OAuth 2.0 and OpenID Connect, and the deployment is kept in version-controlled configuration so changes can be reviewed. Application traffic stays in the client environment. The output is a running cluster with valid certificates and a configuration record that the client's team can read and change.
Test MFA and session lengths with a pilot group
A small pilot group of contractors from one engagement signs in through each route. The test confirms that the identity provider enforces MFA before access is granted, that unauthorized users are denied on every route, and that sessions end when the configured limit is reached. Testers also check that revoking a user's group membership blocks access. Findings are logged and fixed before wider rollout. The output is a written test record with pass or fail results for each route and policy, signed off by the security team.
Enable request logging and forward it to the SIEM
Pomerium access and audit logs are enabled and forwarded to the client's SIEM, such as Wazuh or another platform the client already runs. Parsing rules map each log field to user, route, decision and timestamp, so an analyst can search every request by contractor identity. Alerts are set for denied attempts and unusual access patterns. The output is a log pipeline with sample events from the pilot, showing that each request by a contractor is recorded and searchable.
Offboard contractors and review access on a set cadence
When a contract ends, the identity team removes the contractor from the groups that grant access, and the test confirms that new sessions are refused. The client sets a review cadence with app owners, who confirm that each contractor still needs each route. Removed access and review decisions are recorded. The output is a review record for each cycle, showing who approved access, what changed, and which accounts were removed.
How Pomerium decides each contractor request
Every contractor request is evaluated against a route policy before it reaches the app. The contractor opens the app's URL in a browser, Pomerium redirects them to your OpenID Connect provider, and the provider returns an identity token. Pomerium uses OAuth 2.0 and OIDC for user identity and supports providers such as Microsoft Entra ID, Okta and Keycloak, so the first decision you make is which provider is the source of truth for contractor accounts. Pomerium then checks the route's policy against the claims it received, such as the user's email domain, group membership or other attributes. The allow or deny decision and the request details are written to Pomerium's access and audit logs. Denials matter as much as allows, because they show whether policies are doing what you intended.
Short sessions and continuous authorization limit how long a contractor's access survives after a change. Session lifetime is set on the proxy side, and Pomerium re-evaluates policy as the session continues, so removing a user from a group or disabling the account should end access rather than waiting for a long token to expire. Confirm three things in your own environment: which claims and groups your provider actually sends (contractor groups are often missing or named differently from employee groups), how quickly a disabled account or removed group propagates to active sessions, and what session and refresh token lifetimes your provider enforces. Test these with a disposable contractor account before the first real onboarding.
Claim mapping is where most route policies fail in practice. A policy that checks for a group the provider never emits will deny everyone, and a policy that checks only the email domain may allow more than intended if the provider accepts external sign-ups. Document, for each route, the exact claim and value the policy depends on, and ask your identity team to confirm that value in a test token. Pomerium's Zero plans include attribute-based policies and continuous authorization, but the Enterprise edition reserves Rego policies and session management, so confirm which of these your chosen edition supports before you design the policy set.
Deployment pattern for contractor access in your environment
Pomerium sits in front of each internal app and checks identity and policy on every request, so the placement of the proxy, the identity provider and the policy data decides who can see what. The cards below cover where the proxy runs, how it trusts your identity provider, how domains and certificates are handled, and what Pomerium Zero keeps inside your environment.
Proxy placement in your cloud or data center
Pomerium Core is Apache-2.0 licensed and runs as a self-managed cluster in your own cloud account, data center or Kubernetes environment. It is the component that receives contractor browser traffic and forwards allowed requests to the internal app. Decide which network zone it sits in, which apps it can reach, and whether it needs a route into a private segment or a dedicated edge subnet. Confirm these placement rules with your network and security teams before the first route is written.
Kubernetes deployment with the ingress controller
If your internal apps already run on Kubernetes, the Pomerium Ingress Controller lets you publish them through Pomerium as ingress. The controller is Apache-2.0 licensed and maintained in its own repository, so your platform team should confirm the supported Kubernetes versions, how routes are declared, and who owns the manifests. Treat the controller as part of your cluster change process, with the same review and rollback steps as other ingress components.
Identity provider connection and claims
Pomerium uses OAuth 2.0 and OpenID Connect to identify users, and its documentation lists providers that include Keycloak, Microsoft Entra ID, Okta and Google. Contractors should sign in through an identity source your organization controls, such as a partner tenant in your IdP or a federated broker. Confirm which claims and groups reach the proxy, how contractor accounts are scoped, and what happens when a contractor's account is disabled in the source directory.
Custom domains and certificate handling
Each app is reached through a hostname, so the domain plan and certificate process must be settled before go-live. Ask who issues and renews the certificates for the proxy and for each route, where private keys are stored, and whether certificates come from a public authority or your internal CA. On the Pomerium Zero plans, custom domains are capped by plan, so confirm the number you need against the plan limits.
Pomerium Zero control plane split
With Pomerium Zero, you run the Core cluster in your environment while Pomerium hosts the control plane and management console. Application traffic stays in your environment, but policy definitions, configuration and access and audit logs are managed by the vendor's service. Ask exactly which metadata and logs leave your network, where they are stored, and how you would operate if the hosted control plane were unreachable.
High availability and identity provider clustering
Confirm how many proxy replicas you need, how they are spread across failure domains, and how traffic is balanced across them. If you run Keycloak as the identity provider, its supported production databases include PostgreSQL, MySQL, MariaDB, Oracle, Microsoft SQL Server and Azure SQL, and each of its documented high availability designs needs a synchronously replicated database. Include database replication lag and failover tests in your acceptance plan, because a contractor who cannot sign in during an outage is an access incident.
Evidence an auditor will ask for and which component produces it
This table maps each piece of evidence an assessor is likely to request for contractor web app access to the component that produces it: Pomerium, the identity provider or the SIEM. Read it as a collection checklist, and confirm each item with your auditor before the assessment begins. DeployOpen prepares this evidence, but auditors and certification bodies issue the conclusions.
| Evidence item | Produced by | What to confirm |
|---|---|---|
| Contractor user list with unique identities | Identity provider | Each contractor has a named account, no shared logins, and a sponsor recorded in the directory |
| MFA enforcement records | Identity provider | Sign-in events show a second factor for every contractor session, with policy settings exported |
| Route policy export | Pomerium | Each internal app route lists the groups or attributes allowed, saved from the policy configuration under version control |
| Session timeout settings | Pomerium and identity provider | Idle and maximum session lifetimes are set in both components and match the agreed contractor access terms |
| TLS configuration | Pomerium | Certificates, protocol versions and cipher settings on the proxy listener are documented and tested |
| Per-request access and audit logs | Pomerium, forwarded to SIEM | Each request records user identity, route, decision and time, retained for the period your auditor specifies |
| Offboarding records | Identity provider and SIEM | Account disable events and the last recorded access for each departed contractor, linked to the removal ticket |
Contractor web app access questions buyers ask before hiring help
What drives the cost of a contractor web app access project?
The biggest drivers are the number of internal apps, how many distinct access policies each one needs, the state of your identity provider, and how far logs must flow into your SIEM. Each app adds routing, testing and a policy review, and each contractor group adds rules to maintain. Pomerium's published pricing gives one reference point: Zero Business is listed at $9 per user per month billed monthly or $7 billed annually, and Enterprise is custom priced with a self-hosted control plane (source: Pomerium pricing page at pomerium.com/pricing). Those are license figures, not implementation costs. Ask any partner for a quote that separates one-time build work from recurring licenses, hosting and support.
How long does it take to put contractor app access in place?
The duration depends on the scope you agree in writing, so no fixed timeline applies across all environments. A short project covering a few apps behind one identity provider differs greatly from one covering many apps, several identity sources and log integration. Ask for a plan that lists each app, its route and policy, the identity provider changes required, the test cases and the cutover steps, then compare timelines against that list. Be wary of any answer that quotes a duration before the app inventory is complete.
What does our team need to provide before the work starts?
Three inputs make the biggest difference: named owners for each internal app, a clear group structure in your identity provider that maps to contractor roles, and a documented contractor lifecycle process. App owners confirm hostnames, upstream health endpoints, required headers and which users may reach what. The group structure determines the policies. The lifecycle process covers how contractors are onboarded, reviewed, time-limited and removed, which is where most access risk sits after the proxy is live.
Can our own engineers build this without outside help?
Yes, if you have engineers comfortable with Pomerium configuration, OpenID Connect settings in your identity provider, TLS and reverse proxy operations. Pomerium Core is licensed under Apache-2.0 and can be run in your own environment, so the software itself carries no license fee (source: pomerium/pomerium GitHub repository). The harder work is ongoing: testing each policy, reviewing session lengths, handling upgrades and keeping logs flowing to your monitoring. Many teams hire help for the initial design and policy review, then keep operations in-house. Decide that split before you start.
How do Pomerium Zero plan limits affect the design?
Zero Personal allows 1 cluster, 10 routes and 5 policies, while Zero Business allows 5 clusters, 100 routes, 100 policies and 5 custom domains (source: Pomerium pricing page). Count your apps and routes first, then map each contractor group to the policies it needs. Because every app route can carry its own policy, a design with many apps and fine-grained groups can reach the policy ceiling sooner than expected. If you need Rego policies, directory sync or session management, those sit in Pomerium's Enterprise edition, so confirm the edition before finalizing the design.
Which identity provider and log settings should we check first?
Check that your identity provider supports OpenID Connect, that contractor accounts are separate from employee accounts, and that multi-factor authentication is enforced for contractors. Pomerium documents support for providers including Microsoft Entra ID, Okta, Google, Keycloak and Ping, among others (source: Pomerium identity provider docs). For logs, confirm which request, authentication and policy decision events you need to retain, how long, and where they are sent. The HIPAA Security Rule and the FTC Safeguards Rule both expect unique user identification and monitoring of user activity where they apply, so confirm with your compliance lead which records are needed.
What should we ask a partner before signing a fixed-scope agreement?
Ask for a written scope that lists every app, route, policy group, identity provider change and log destination, plus the acceptance tests for each one. Ask who holds administrator credentials after handover, how upgrades to Pomerium are handled, and what happens to contractor access when an app owner leaves. Ask whether the partner runs security testing on the protected apps and the proxy configuration before go-live. DeployOpen plans and implements open-source platforms in your own infrastructure and runs security testing, and most engagements are fixed-scope with terms agreed in writing before work starts. It does not issue audit reports or certifications, so ask how compliance evidence will be prepared for your assessors.
Questions to ask an implementation partner for contractor access
Start with where the control plane and logs live. Ask the partner which components run in your environment: the Pomerium Core cluster, the identity provider integration, and the log pipeline. If the design uses Pomerium Zero, ask which parts are hosted by Pomerium (the control plane and management console) and confirm in writing that application traffic stays in your environment, as Pomerium's pricing page describes. Ask who holds administrator access to the control plane, how that access is logged, and how log retention and export to your SIEM are configured, including the retention period you need to meet your own policy. Get the answers as a written architecture diagram, not a verbal summary.
Next, ask how contractor identities are created, scoped and removed. Ask whether they come from your identity provider or a separate contractor directory, who approves each account, and how a contractor's access is revoked on contract end, including active sessions. Ask for the policy for each route: which groups may reach which hostname, whether MFA is required per route, the session lifetime and idle timeout, and how a policy change takes effect for sessions already open. Confirm whether the partner will test a revoked account before handover. Finally, ask which features the design depends on that sit in Pomerium's Enterprise edition, such as directory sync, RBAC for administrators, session management, or Rego policies, and whether the proposal prices them or assumes Core only. Ask for that licensing position in writing, since the choice changes what you can administer yourself.
Finish with upgrades and limits. Ask how the partner tracks Pomerium releases, how it tests a new version against your routes before rollout, and who applies security patches to the cluster, the ingress layer and the identity provider. Ask for the rollback procedure and the maintenance window model. Be clear about what the partner will not provide: it prepares the controls, configuration and evidence for your assessments, but it does not issue audit reports, attestations or certifications. Ask which evidence it will hand over, such as policy exports, access logs and change records, and who at your organization will own the assessment conversation with your auditor.
