Open-source alternative to Okta Access Gateway: the short answer
If your legacy internal applications cannot speak SAML or OIDC and sit behind Okta Access Gateway, authentik's proxy provider or Pomerium in front of a self-hosted identity provider can cover most of that role. Kerberos handling, gateway-specific behavior such as how sessions and headers are passed to the application, and any suite-level policy that Okta applies today all need explicit checking before you commit, because none of them transfer automatically. The right choice depends on which app patterns you run: header-based authentication for apps that trust injected identity headers, Kerberos or Windows-integrated access for older intranet tools, and URL-based access rules for web apps that have no login of their own. It also depends on whether the rest of the Okta suite stays. If Okta remains your workforce identity provider, the proxy sits in front of Okta as the upstream provider, and the decision is about which component enforces access to each application.
Pomerium suits teams that want an access proxy with route-level and attribute-based policy and can keep the upstream identity provider unchanged, since its documentation lists Okta and Keycloak among supported providers. authentik suits teams that also want to move the identity provider itself, because its proxy provider runs alongside SSO, LDAP and RADIUS in one product. Start with an inventory: list every gateway-protected application, the pattern it uses, and the policy attached to it, then confirm each pattern against the current documentation of the product you shortlist. DeployOpen scopes, implements, tests and documents this work in your own infrastructure, but it does not certify the result. Independent auditors and certification bodies issue any attestation your compliance program requires.
Mapping Access Gateway capabilities to open-source options
This table maps the main jobs Okta Access Gateway performs for legacy applications to authentik's proxy provider and Pomerium, with notes on what each option covers and what to confirm in your environment. Read the Kerberos and gateway-specific rows first, because those are where a like-for-like swap is least certain. The main takeaway is that the proxy layer is replaceable, but header mapping, Windows sign-on and edge policy need to be tested against each application before cutover.
| Capability | authentik proxy provider | Pomerium | Coverage notes |
|---|---|---|---|
| Header-based identity injection | Proxy provider passes identity to the upstream app, listed in authentik's providers documentation. Confirm the exact header names and mapping. | Passes identity and claims to the upstream route. Confirm the header names each application expects. | Test each legacy app's header contract, including user, groups and email, before cutover. |
| URL-based protection | Protects applications by external host or path and applies it through an outpost. Confirm path-level rules for your URLs. | Routes define which URLs require sign-in and which policy applies. Route limits differ by Pomerium plan. | Map every Access Gateway URL rule to a route or application and check for overlapping paths. |
| Kerberos or Windows-integrated sign-on | The free edition lists Kerberos support. Confirm the delegation and keytab setup for your applications. | Not confirmed in the sources reviewed. Confirm whether Pomerium supports Kerberos or Windows integrated authentication for your apps. | Treat as an item to confirm. Test with real browser sessions, because Access Gateway behavior for this case may differ. |
| Okta policy enforcement at the edge | Access is decided by authentik policies and bindings on the application. Rebuild Okta group and app rules as authentik policies. | Attribute-based policies are included in Zero plans. Rego policies are reserved for the Enterprise edition. | Okta sign-on and access policies do not transfer automatically. Export and rebuild them as the new edge rules. |
| Session handling | Session lifetime and re-authentication are set on the flow and provider. Confirm timeout behavior for legacy apps. | Continuous authorization is included in Zero plans. Session management is reserved for the Enterprise edition. | Check idle timeouts and forced sign-out behavior against each application's own session model. |
| Audit logging | Free edition has community support only. Enhanced audit logging is listed as an Enterprise feature. | Access and audit logs are included in Zero plans. Confirm retention and export options for your audit requirements. | Decide where gateway logs must be kept and whether they reach your SIEM. Confirm the log fields each option emits. |
authentik proxy provider or Pomerium: which fits which app
Access Gateway sits in front of legacy web apps and enforces sign-in before traffic reaches them. The two open-source paths below cover that job in different ways, so the choice depends on where the app runs, who manages the proxy, and whether you need features that sit behind a paid tier.
authentik proxy provider for co-located apps
The proxy provider runs an outpost that sits in front of an app and passes identity headers to it, so apps that trust a header such as a remote user field can keep working without code changes. It fits teams that already run authentik as their identity provider and want one product for SSO, LDAP and proxy access. Check that the outpost can reach the app's internal address, that the app only accepts traffic through the proxy, and how it handles apps that expect Kerberos or client certificates rather than headers.
Pomerium with Keycloak or another OIDC provider
Pomerium is an identity-aware reverse proxy that authenticates users through OAuth 2.0 and OIDC, and it documents Keycloak as a supported identity provider. This suits teams that want a dedicated access layer in front of web apps, SSH targets or Kubernetes services while keeping the identity provider separate. The trade-off is one more component to operate, plus policy and routing configuration that your team must own and test.
Pomerium Core or Pomerium Zero
Pomerium Core is Apache-2.0 licensed and you run it entirely in your own environment. Pomerium Zero keeps the Core cluster in your environment but moves the control plane and management console to Pomerium, which reduces the operations you carry. Application traffic stays in your environment under both models, but the control plane location matters for data residency reviews, so confirm where configuration and access logs are held before choosing Zero.
Pomerium Enterprise feature limits
Several capabilities sit only in Pomerium's Enterprise edition, including directory sync, Rego policies, RBAC for administrators, session management and SSH session recording. If your access rules depend on Rego or on directory groups synced into the proxy, those needs point to Enterprise and should be costed up front. Confirm which of your current Access Gateway policies would need to be rewritten as attribute-based rules in Core or Zero.
authentik Enterprise features are separate
The proxy provider is part of the free authentik edition, while Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management and ticket-based support belong to the Enterprise tier. Choosing the proxy provider does not by itself require a paid subscription. Confirm with the vendor which features your environment needs, because adding one enterprise feature changes the licensing picture for the whole deployment.
How the design changes by app pattern and environment
Header-based applications trust identity values, such as a username or group list, sent by a front end, and they often do not handle login themselves. Access Gateway usually sits in front of these apps and supplies the headers after Okta authenticates the user. In a self-hosted design, the proxy layer takes over that role. authentik's proxy provider can authenticate the user and forward identity to the upstream application, and Pomerium can pass identity values through its route configuration. The right choice depends on what the application reads and how it validates those values.
- Header names and format: List every header the application reads, its exact name, whether it expects one value or a list of groups, and how it behaves when a value is missing.
- Trust boundary: Confirm the application accepts these values only from the proxy address. If clients can reach the application directly, they can forge the headers.
- Session behavior: Confirm the session timeout the application expects and how logout is propagated to the proxy.
- Group mapping: Identify which Okta groups control authorization in the application and where equivalent groups will come from in the new identity provider.
Header handling is often undocumented, so test these points against a staging copy of the application before design sign-off.
URL-based internal web apps are reached by hostname or path in a browser and usually manage their own sessions after the gateway step. Pomerium maps each public hostname to an upstream service and attaches policy to that route. Pomerium Core is Apache-2.0 and runs in your own environment, and its identity provider documentation lists Keycloak and Okta, so the identity source can stay where it is during a phased move. authentik's proxy provider covers the same pattern with its own applications and policies. Both approaches depend on a clean route inventory.
- Route inventory: Count hostnames and paths, note any wildcard needs, and mark which applications need internal DNS and which need public DNS.
- Cookie and domain rules: Confirm which applications set their own cookies, which domains they expect, and any SameSite requirements that could conflict with the proxy session.
- Long-lived connections: Confirm whether the application uses WebSockets, streaming or large uploads, and check the timeouts and size limits on each route.
- Policy granularity: List the groups or attributes that gate each route. Rego policies and RBAC for administrators are reserved for Pomerium Enterprise, so confirm whether your access rules need them.
Build the route list with the application owners, because a missed path or redirect is the most common cause of broken logins after cutover.
Kerberos-dependent applications expect a negotiated ticket from the browser, typically from a domain-joined Windows client, so the login happens at the Kerberos layer rather than through a redirect to a web login page. Access Gateway may have been the path for some of these apps, while others may have used integrated Windows authentication directly. The free authentik edition lists Kerberos among its supported protocols, and FreeIPA combines MIT Kerberos with a directory and can create trusts with Microsoft Active Directory. Replacing this pattern changes the authentication mechanism, so it needs its own design review.
- Ticket validation: Confirm whether the application validates Kerberos tickets itself with a keytab or relies on a front end. Keytab creation, rotation and storage are separate operational tasks.
- Service principal and DNS: Confirm service principal naming, DNS aliases and clock synchronization across clients, the key distribution center and the application servers.
- Realm ownership: Confirm whether the Kerberos realm will come from FreeIPA, an existing Active Directory trust or another key distribution center, because that decides who owns password policy and account lifecycle.
- Client configuration: Confirm the trusted site settings, group policy or device management settings for negotiated authentication, and how non-Windows clients will sign in.
Kerberos designs often need the most coordination between identity, desktop and application teams, so confirm the realm and client settings before selecting a proxy.
Kubernetes-hosted applications route traffic through an ingress layer, so the gateway decision often becomes an ingress decision. Pomerium publishes a Kubernetes Ingress Controller under Apache-2.0 that runs Pomerium as the ingress for cluster services. authentik can also run on Kubernetes, and its installation guide covers that model, with outposts handling the proxy role for applications. The choice depends on whether the cluster already has an ingress controller, who owns routing changes and where the identity provider should run.
- Existing ingress: Confirm whether an ingress controller is already in place and whether it can run beside Pomerium's controller without conflicts over ingress classes or load balancer addresses.
- Identity provider placement: Confirm whether the identity provider runs inside the same cluster or outside it, since that affects network policy, failure domains and how many paths a login must cross.
- Database dependency: authentik stores its configuration and data in PostgreSQL, so confirm a highly available database, backup schedule and restore test before cutover.
- Release management: Confirm how Pomerium and identity provider releases are staged across environments, and who receives authentik security notices, which the project announces at least 24 hours in advance.
Before writing any manifests, confirm which team owns the ingress and who approves routing changes.
Running the proxy alongside the rest of the Okta suite
Replacing Access Gateway does not have to mean replacing Okta. Pomerium can sit in front of legacy apps while Okta, or a self-hosted identity provider, keeps the user lifecycle, MFA and the rest of the SSO estate. The four cards below set out the options and the points to test before any change goes live.
Keeping Okta as the identity provider
If Okta still holds the workforce, Pomerium can use Okta as its OIDC identity provider, so users sign in once and the proxy reads their groups and attributes for policy decisions. This keeps the directory, lifecycle and MFA where they are today. Confirm that the Okta authorization server issues the claims your Pomerium policies depend on, such as group membership, and that the application registration in Okta matches the callback URL of each Pomerium route.
Federating Okta into Pomerium
Pomerium lists Okta among its supported identity providers, alongside Keycloak and Microsoft Entra ID, so the same proxy can work with either an Okta tenant or a self-hosted identity provider. Changing the upstream later means editing the identity provider configuration rather than rebuilding every route. Session lifetime, token refresh and MFA step-up behavior must be tested end to end, because a proxy session can outlive or expire before the Okta session does.
What Okta keeps
Okta continues to handle everything it does outside the gateway: provisioning and deprovisioning, MFA enrollment, SSO for SaaS and other web apps, and any Okta-managed device or policy rules. Access Gateway's own role is narrow, so removing it does not remove these functions. Inventory which legacy apps were authorized only through Access Gateway, because those are the ones that need a Pomerium route and a policy before the gateway is switched off.
What moves if the suite leaves
If the whole Okta suite is being replaced, the proxy stays the same but its upstream changes to a self-hosted identity provider such as Keycloak, and the user store, MFA factors and lifecycle processes move with it. Users and passwords need a migration plan, because Okta does not export password hashes in a form you can reuse elsewhere. Ask your Pomerium partner or vendor to confirm which Enterprise features, such as directory sync and Rego policies, your target design requires.
Migrating gateway-protected apps without a cutover outage
This sequence moves each Access Gateway-protected app behind a self-hosted proxy one group at a time, so every app has a tested path and a rollback option before the gateway rules are removed.
Inventory every gateway-protected application
List each app that Okta Access Gateway fronts, with its hostname, path rules, authentication pattern (header-based, Kerberos or URL-based), the groups allowed in, and the session timeout it currently enforces. Include apps that reach the gateway only through a bookmark or a shared URL, because those are the ones teams most often miss. The step is done when the inventory is reviewed by the application owners and every entry has a named owner and a business criticality rating. Ask your Okta administrator to export the gateway configuration so nothing is recorded from memory.
Map each app to a proxy route or provider
For each inventory entry, decide whether it becomes an authentik proxy provider, a Pomerium route in front of the self-hosted identity provider, or a native OIDC or SAML integration where the application can accept one directly. Record the upstream address, the identity claims or headers the application expects, and any Kerberos requirement that the proxy must satisfy. Apps that depend on a header set by the gateway need that header name and value confirmed with the application team before anything else is built. The output is a mapping sheet that the engineering team signs off.
Stand up the identity provider and decide the upstream
Deploy the chosen self-hosted identity provider, such as authentik or Keycloak, in your infrastructure with its database, backups and TLS in place. Decide whether Okta stays as the upstream identity source during the transition, which lets users keep their existing credentials, or whether the self-hosted provider becomes the source for these apps. DeployOpen plans and documents this stage as fixed-scope work, with the scope and deliverables agreed in writing before build starts. Confirm the platform's current release and its supported versions against the vendor's security policy before you choose a version to deploy.
Pilot one low-risk application
Choose a single application with a small user group, limited data sensitivity and an owner who can test quickly. Route it through the new proxy in parallel with the gateway, using a separate hostname or a test group so production users keep the existing path. Run a documented test script covering sign-in, sign-out, deep links and the application's administrative functions. The step is complete when the pilot owner signs off on the results and every failure has a recorded fix or a decision to accept it.
Test session timeouts and header values
Compare the session lifetime, idle timeout and re-authentication behavior of the new proxy with the values recorded in the inventory. Check every header or claim the application reads, including user identifiers, group membership and any value used for authorization decisions, and confirm it matches the gateway output byte for byte where the application depends on it. Test logout from both the application and the identity provider, and confirm that a revoked user loses access within the timeout you intend. Document each difference, because an unnoticed change in a header value is a common cause of access errors after cutover.
Move users in waves
Migrate the remaining apps and user groups in planned waves, starting with the smallest and least critical group and expanding only after the previous wave has run without open incidents for the agreed observation period. Keep the Access Gateway rule for each app active until its wave is closed. Publish the wave schedule, the support contact and the rollback steps to users before each move, and log every support request that involves sign-in during the wave. The output is a wave log showing the app, the users moved, the date, and any issues found.
Retire gateway rules after a rollback window
Once every wave has been stable through the rollback window your change board approves, disable the Access Gateway rules for each app rather than deleting them immediately. Keep the configuration export and the Okta audit logs for the retention period your compliance team requires. Remove the gateway rules only after the owners confirm that no traffic still reaches the old path. Confirm what remains in Okta, such as the directory, other app integrations and any Okta products you still license, and update the asset inventory to match.
What the cost of ownership is made of
Start by separating what you pay Okta today from what you would pay to run the replacement. Access Gateway is not sold as a standalone product in the way many buyers assume: its use is tied to the Okta suite you hold, so the cost question is whether removing it changes your suite tier or add-ons. Ask Okta in writing which line items and add-ons attach to Access Gateway, what happens to them if the rest of your suite remains, and whether any part is billed per application or per user. Keep those answers with the renewal file, because they determine how much of the annual spend actually goes away.
The self-hosted side has more components, and most of them recur. You pay for compute to run the proxy (authentik's outpost or Pomerium Core) and the identity provider, for PostgreSQL with backups and replication, and for a second environment if you need high availability or a staging copy. You also pay for implementation: configuring the proxy, Kerberos delegation or header mapping, and testing each protected application. Patching is a continuing cost, since authentik and Keycloak both release updates several times a year and each upgrade needs regression testing against the protected apps. If you buy support, that is a separate subscription. authentik's Enterprise edition is priced per user per month plus a charge per external user, and Pomerium Zero Business is priced per user per month, while Pomerium Enterprise is custom priced. Request a written quote from each vendor against your exact user counts and feature list, and confirm which features your proxy design needs before comparing totals.
Three factors move the total most. The number of protected applications drives configuration, testing and upgrade effort, because every header, Kerberos or URL rule is a separate piece of work to verify. Kerberos complexity raises the cost further, since constrained delegation, keytab management and service principal design need specialist time and careful testing. The number of environments multiplies everything: each extra production, staging or disaster recovery copy adds compute, database capacity and test cycles. For an illustrative estimate, a team with a small set of header-based apps in one environment will spend far less on implementation than one with Kerberos-backed apps in production, staging and a recovery site. Use that split to scope the work before you ask for a quote.
Questions teams ask before replacing Access Gateway
Can authentik's free proxy provider replace Access Gateway for every app type?
Not for every app type without checking first. The free authentik edition includes proxy authentication, which covers most web applications that rely on headers or URL-based access, but it does not cover every legacy pattern Access Gateway handles. Inventory each app and classify it by how it authenticates: standard OIDC or SAML (no proxy needed), header-based access, URL-based access, Kerberos, or a client-server protocol. Confirm with authentik how the proxy handles each class in your version, since behavior for session handling and header mapping depends on configuration. Apps that cannot sit behind a proxy need a different path, which may mean keeping Access Gateway for them or changing the app.
How much effort does an Access Gateway migration take, and what drives it?
Effort depends mainly on the number of legacy apps, how many distinct authentication patterns they use, and how many unrelated teams own them. Cost has two parts: one-time work to build proxy providers, routes, policies and testing, and recurring work to run the identity provider and reverse proxy yourself. Apps that need a header rewrite, a custom path rule or a Kerberos hop take longer than a plain URL-based app. Ask any implementation partner for a fixed-scope written plan that lists each app, its pattern, its test steps and its cutover order. Timelines should come from that plan rather than from a general estimate.
Can Kerberos single sign-on work once Access Gateway is removed?
Kerberos needs its own design, because Access Gateway and a proxy provider do not handle it in the same way. Keycloak supports LDAP and Active Directory federation, and FreeIPA combines MIT Kerberos with an LDAP directory, so a Kerberos realm is usually held by the directory layer. Decide whether browser-based Kerberos (SPNEGO) is still required, which service principals and keytabs the apps use, and whether the directory will be FreeIPA, Samba AD or an existing Active Directory. Confirm with each vendor the exact Kerberos flow supported for your app versions before committing to a design.
What does the team need to provide before a migration starts?
The team has to provide three things: named owners for every legacy app, network access that lets the new proxy reach each backend, and test accounts that match real user roles. App owners confirm the expected headers, paths and session length, and they sign off on test results. Network work covers DNS, certificates, firewall rules and the path from the proxy to each internal service. Test accounts should include standard users, administrators and users in each group that has access policies, so that authorization rules are verified and not just login. Put these items into the written scope so they are assigned before work begins.
Can our own engineers do the migration in-house?
Your team can do it in-house if it has staff who can operate the identity provider, the reverse proxy, the directory and the backend apps, and who can test each app on a schedule. The main risks are gaps in Kerberos and header handling, untested authorization rules and cutover without rollback. Ask whether the in-house team can cover planning, build, testing, hardening, backup and documentation, and whether anyone is assigned to patch the components after go-live. A fixed-scope engagement from DeployOpen can cover planning, implementation, hardening, backup and documentation, with ongoing support available as a retainer, so the choice is about who carries those tasks over time.
What happens to our Okta licensing if only Access Gateway is removed?
Removing Access Gateway alone usually does not reduce Okta licensing, because the gateway is typically sold and renewed as part of an Okta contract. Check your order form and renewal terms to see which SKUs include Access Gateway, which users are counted, and whether the contract has a minimum. Okta's remaining products, such as Workforce SSO or MFA, would still be billed according to the contract. If you plan to retire the gateway and reduce the Okta footprint, confirm the notice period and the change rules with your Okta account team in writing before renewal.
What stays in Okta if we keep the rest of the suite?
If the rest of the Okta suite stays in place, Okta continues to handle workforce SSO, MFA, the directory and lifecycle tasks that you have not moved. Access Gateway is the only part you would be replacing for legacy apps. Confirm which Okta components sit in front of the proxy during the transition, because the apps may still depend on Okta for sign-in until cutover. Map each legacy app to its current Okta dependency, and document the exit path so that a later move of the rest of the suite does not require redoing the proxy design.
Where open-source gateway replacements fall short
The first gap to check is behavior, not features. Okta Access Gateway sits in front of legacy apps and passes identity to them through headers, Kerberos or URL-based rules, and those rules carry session, header and access settings that were configured over time and are rarely written down. None of them move automatically. Before cutover, export or document the gateway configuration, then list every application with its header mappings, URL patterns and session lifetime. Test each one against an authentik provider or Pomerium route in staging. Where Kerberos is involved, confirm with each application owner how authentication is handled, because the application may depend on details that no gateway setting shows you. Assume parity only after your own tests confirm it.
The second gap is licensing. Pomerium Core is Apache-2.0 and runs in your own environment, but several controls that larger access programs depend on are reserved for Pomerium's Enterprise edition: Rego policies, RBAC for administrators, session management and directory sync. If your gateway rules rely on directory-driven group membership or on session controls, either budget for Enterprise or rewrite those rules as attribute-based policies, which the Pomerium pricing page describes as part of its Zero plans. On the authentik side, the free edition includes proxy authentication and Kerberos, but mTLS client certificate authentication, password history and enhanced audit logging are Enterprise features. Map each required control to an edition in writing before you size the project.
The third gap is support and patching, and it is the one teams most often underestimate. The authentik free edition offers community support only, and Enterprise Plus adds dedicated support with SLAs. Pomerium support follows its edition, so ask the vendor to confirm in writing what a Core deployment receives. The Keycloak project is open source, so a supported distribution comes from another party, such as the Red Hat build of Keycloak, if a contract is required. Patching is your responsibility once you self-host. authentik supports the 2026.5.x and 2026.8.x lines for security fixes and announces security releases at least 24 hours in advance, and authentik's security policy sets out that cadence. Assign an owner for each upgrade and retest every proxied app after it, or arrange ongoing upgrade and support work through a DeployOpen retainer.
Primary sources to check before deciding
Access Gateway replacements split into two decisions: which proxy sits in front of legacy apps, and which identity provider it trusts. The sources below cover both sides, so check the proxy feature set, the edition boundaries and the identity provider integrations before you commit to a design.
authentik provider documentation
This page lists the provider types authentik supports, including the proxy provider that replaces Access Gateway for header-based and URL-based apps. Read the proxy section against your application inventory: confirm whether each legacy app needs forward-auth, a reverse proxy mode, or a direct header injection, and whether Kerberos or header-only apps need a separate path. Note which provider types are free and which depend on the Enterprise edition.
authentik pricing and edition limits
The pricing page shows what the free Open Source edition includes and which features need a paid tier. Check whether the integrations and support terms your team depends on sit in the free edition, since the free edition offers community support only. Ask any vendor for written confirmation of which features your chosen edition includes before you rely on them for production access control.
Pomerium README and scope
The README describes Pomerium as an identity and context-aware reverse proxy for internal web apps and other services without a corporate VPN. Use it to confirm how Pomerium routes traffic, authenticates users and enforces policy in front of applications that have no login of their own. Check how it handles non-web protocols, since Access Gateway's scope is mostly web and header-based access.
Pomerium identity provider compatibility
This page lists the identity providers Pomerium accepts through OAuth 2.0 and OIDC, including Keycloak, Okta and Microsoft Entra ID. Confirm that your existing identity provider, or the self-hosted one you plan to run, appears on the list and that group or attribute claims needed for authorization can be passed through. Test claim mapping with a legacy app before cutover.
Pomerium pricing and control plane
The pricing page separates Core, which you run yourself, from the managed Zero plans and the self-hosted Enterprise control plane. Check which features your policies need, such as directory sync, Rego policies, administrator RBAC and session management, because these sit in the Enterprise edition. Under Zero, the cluster still runs in your environment, so confirm where the control plane and its logs live for your data residency review.
How DeployOpen scopes and delivers gateway replacement
This sequence turns a list of legacy applications behind Okta Access Gateway into a written scope, a tested proxy and identity design, and handover documentation that your team and your auditors can use. Each step ends with a named output so you can check progress before moving on.
Inventory every application behind the gateway
DeployOpen works with your team to list each application that Access Gateway fronts, including its hostname, authentication pattern (header-based, Kerberos, or URL-based), the user groups that reach it, and the application owner. The inventory is compared against Okta app assignments and policies exported from the Admin Console, so nothing protected only by a gateway rule is missed. The output is a signed inventory that becomes the basis of the written scope.
Agree the written scope and fixed deliverables
The inventory is turned into a written statement of work that names the applications in scope, the auth patterns each needs, the target identity provider (self-hosted Keycloak, authentik, or the identity provider you already run), the environments, and the acceptance criteria. Anything out of scope, such as Okta suite products that remain, is stated explicitly. Work starts only after both parties sign the scope, and any change goes through a written change request. The output is an approved scope document.
Design the proxy and identity architecture
DeployOpen designs how requests will flow from users to the proxy, whether authentik's proxy provider, Pomerium in front of your identity provider, or another pattern, and how identity is passed to each legacy app. The design covers where the components run inside your own cloud accounts or data centers, how the database and high availability are arranged, how Kerberos and header trust are handled, and which parts stay in Okta. The output is an architecture document reviewed with your security and platform teams.
Implement and harden the proxy and identity provider
Engineers deploy the chosen components in your environment, configure provider and outpost settings, set up TLS and certificates, restrict header forwarding so clients cannot spoof identity headers, and apply hardening baselines to hosts, containers and the database. Administrative access, logging and secrets handling are set up as part of this work. The output is a running staging environment with a hardening checklist signed off against the architecture document.
Test each application with its owner
For each application in scope, DeployOpen and the application owner run agreed test cases: sign-in through the proxy, group-based access denial and allowance, session expiry, logout, and any Kerberos or header-dependent function. Failures are logged, fixed, and retested until the owner accepts the result in writing. Where an application cannot be protected by a proxy alone, the gap is recorded for a decision by your team. The output is a signed test record per application.
Cut over and document the running service
Traffic is moved from Access Gateway to the new path in a change window agreed with your operations team, with a rollback plan documented before the change. DeployOpen then delivers runbooks for operations, backup and restore, upgrades, user onboarding, and incident handling, along with an configuration record for each protected application. The output is a production cutover record and a handover pack your team can operate without us.
Prepare compliance evidence and agree ongoing support
DeployOpen compiles evidence that supports your compliance assessments, such as access control configurations, change records, test results and hardening baselines, mapped to the controls your assessor cares about. DeployOpen does not issue audit reports or certifications; independent auditors and certification bodies do that work. If you want continuous help, optional retainers cover upgrades, security patching and recurring testing of the proxy path, agreed in a separate written scope. The output is an evidence package and a decision on whether to retain ongoing support.
