Why open source zero trust access changes the VPN problem for financial institutions
A bank or fintech security lead usually inherits a VPN that gives remote staff, trading desk users and vendors the same broad reach into the network. The fit for most institutions is a per-application access model built on an identity-aware proxy such as Pomerium for web and SSH back-office tools, with OpenZiti for dark services and applications that can embed its SDK. Overlay options such as NetBird or Headscale are worth evaluating for network-level access, but their fit must be confirmed against your segmentation and logging requirements. Where the control plane runs matters to regulators because it holds identity decisions, policy and access logs, which are the evidence an examiner will ask for.
Financial services differ from other sectors for three reasons. First, the FTC Safeguards Rule at 16 CFR 314.4(c) requires multi-factor authentication for any individual accessing any information system at covered non-bank institutions, unless the Qualified Individual approves an equivalent control in writing, so the ZTNA gateway must enforce MFA rather than rely on the VPN client. Second, DORA has applied since 17 January 2025 and Article 30(2) requires ICT contracts to state where services are provided and data processed, which makes a self-hosted control plane easier to document than a vendor-run service. Third, PCI DSS applies wherever the cardholder data environment is reachable, so every path into that environment must be in scope for the assessment.
Before choosing a pattern, confirm three things with your compliance and network teams: which back-office and trading tools are web, SSH, RDP or custom protocols, which of them touch cardholder data or critical functions, and whether your regulators expect the access logs to stay inside your jurisdiction. Those answers decide whether a proxy, an overlay or a dark-service model fits each application. Ask any implementation partner to show how the policy decision point, the log store and the MFA enforcement point are each hosted and who holds the keys.
Which financial services requirements shape the ZTNA design
This table maps the financial services requirements most likely to shape a ZTNA design to the design decision each one forces. Read it as a checklist: confirm which rules apply to your entity, then check whether the access, logging and contract choices in your design can produce the evidence each row asks for.
| Requirement | Source | What it means for the build |
|---|---|---|
| MFA for any individual accessing an information system | FTC Safeguards Rule, 16 CFR 314.4(c)(5), for non-bank institutions under FTC jurisdiction | Every route to an internal app or network needs MFA enforced by the identity provider, with no bypass for admins or legacy paths. Written approval is needed for any equivalent control. |
| Unique user identification and audit controls | HIPAA Security Rule, 45 CFR 164.312, relevant only where ePHI is present | Only relevant if the entity also handles ePHI. Each session should map to a named identity, and access logs should be retained and reviewed. |
| Monitoring and logging of authorized user activity | FTC Safeguards Rule, 16 CFR 314.4 | Log identity, target application, device posture result and session times at the proxy or overlay. Confirm which logs your edition exports and where they are stored. |
| Register of ICT contractual arrangements | DORA Article 28(3) | Record the self-hosted ZTNA components, their vendors and any managed control plane as ICT services. Keep the entries current when components change. |
| Contract terms on data location and changes | DORA Article 30(2) | Where a managed control plane or relay is used, confirm in writing where the service runs and processes data, and how advance notice of changes is given. |
| Exit strategy for services supporting critical functions | DORA Article 28(8) | Document how access would be restored without the ZTNA product, including VPN fallback and tested migration steps. Tie this to dark services and app-by-app cutover plans. |
| Access to programs and data in ICFR scope | SEC Release 33-8810, IT general control areas, SOX Section 404 | Access provisioning, changes and removal for ZTNA policies become IT general control evidence. Keep policy change records and periodic access reviews. |
| Access control scope for the cardholder data environment | PCI DSS v4.0.1 (PCI SSC) | If remote access reaches systems that store, process or transmit cardholder data, those paths are in scope. Confirm with your QSA how to segment and document them. |
Which open-source ZTNA platforms fit regulated trading and back-office access
Financial institutions rarely need one tool for every access pattern. Browser-based back-office tools, device-bound trading networks and engineering or admin overlays each point to a different platform, and each platform leaves a different set of controls to build around it. The cards below set out where each option fits, where it stops, and what to confirm before a design is approved.
Pomerium for browser-based back-office tools
Pomerium is an identity-aware reverse proxy that puts a policy check in front of internal web apps without a client on the user's machine. Pomerium Core is licensed under Apache-2.0 and is run by the institution. The Enterprise edition adds directory sync, Rego policies, administrator RBAC and SSH session recording and playback, so a regulated team should confirm which of these features its edition includes before it depends on them. Confirm whether session recording is in the edition being bought.
OpenZiti for dark trading services
OpenZiti is an overlay platform where each connection carries a cryptographic identity, is authorized by policy and is encrypted end to end. Its controller issues identities and defines which identity reaches which service through which edge router. Services can run with no open inbound ports, because the service side dials out to a router, which suits order gateways and market data feeds that should not be reachable from the internet. Teams should test failover of the edge routers and confirm how posture checks are wired in, since these depend on the deployment design.
OpenZiti SDKs for embedded application access
OpenZiti offers SDKs for Go, C, Python, Node.js, Java, Swift and C#, which let an application embed identity and encryption instead of relying on a network tunneler. This fits in-house back-office applications where the team controls the code and needs application-to-application encryption. It does not fit vendor packages that cannot be modified. Confirm with the application owner whether changes to source code are allowed and who signs off on them under the change management process.
NetBird and Headscale for engineering overlays
NetBird and Headscale create WireGuard-based overlay networks that suit engineers and administrators who need broad network reach to staging, databases and internal tools. They are a poor match for giving trading desks or back-office staff a narrow set of applications, because the overlay model grants network-level reach. Use them for privileged engineering groups, and pair them with a PAM tool for session recording. Confirm the coordination server placement and which relay components hold metadata.
Keycloak, authentik and ZITADEL for SSO and MFA
None of the access proxies or overlays above authenticate users on their own. Keycloak, authentik and ZITADEL supply single sign-on, multi-factor authentication and, where needed, passkeys, and the access platform trusts the tokens they issue. Keycloak 26.8.1 and ZITADEL v4.19.5 are current examples of the releases to track. The FTC Safeguards Rule requires multi-factor authentication for any individual accessing an information system, so the identity provider is the control to evidence first. Confirm which factors are enforced for each application group.
How a bank rolls out zero trust access app by app without a big-bang cutover
The sequence moves users from the VPN to per-application access in controlled waves, so each step produces evidence a regulator and an auditor can review before the next one starts.
Inventory applications and access paths
The bank's network and application teams list every internal application, database, SSH target and trading or back-office tool that remote users reach today, along with the VPN routes, firewall rules and service accounts that make each path work. Owners are assigned for each application, and each one is tagged by business function and by whether it supports a critical or important function, since that affects contract, exit and change-record requirements. The step is done when the inventory reconciles against VPN route tables and firewall logs, and any path that cannot be explained has an owner and an open question. Ask the implementation partner to show how the inventory feeds the access policy design.
Align identity and MFA with the existing provider
Security and identity teams confirm which workforce identity provider is authoritative, how groups map to roles, and which multi-factor methods are accepted for remote access. The FTC Safeguards Rule requires multi-factor authentication for any individual accessing an information system for covered non-bank institutions, so the design records who is covered and any written equivalent control the Qualified Individual approves. The output is a documented mapping of directory groups to application policies, with test accounts confirming that a user with the right group can reach one application and no others. Confirm with the identity team that group changes flow from the joiner, mover and leaver process rather than manual edits.
Pilot on one back-office tool
The team selects one low-risk back-office application with a limited user population and publishes it through the chosen proxy or overlay while the VPN stays in place for everything else. Users in a named pilot group reach only that application, and the team tests session length, reauthentication, failover and behavior when a user is removed from the group. Revocation is tested by confirming that an active session ends when access is withdrawn. The pilot is complete when the test results, the policy file under version control and the rollback steps are approved by the application owner and the change board.
Validate posture and logging
Before any wave of trading or back-office traffic moves, the team confirms which device posture signals the platform can read on managed laptops and how they are enforced, and which access and audit logs leave the ZTNA components. Logs are forwarded to the bank's existing SIEM, and the team checks that each request records the user, device, application, decision and time in a form the security operations team can search. The step closes when a sample of logs has been reviewed against the test cases and gaps are either fixed or recorded as accepted risks. Ask vendors which posture integrations are native and which need custom work.
Run VPN and ZTNA in parallel during cutover
During each wave, the VPN and the new access path run side by side, so users keep a working route while their applications move. The team sets a written criterion for each application that decides when its VPN route is removed, and it keeps the VPN rules for that application until the criterion is met and signed off. Parallel running also means two sets of logs and two policy sets, so the team reviews both during the overlap period to avoid gaps in monitoring. The step is done for each application when its users have used the new path successfully and the VPN route is disabled under change control.
Migrate trading and back-office apps in waves
Applications are migrated in waves grouped by business owner, sensitivity and dependency, starting with applications that have clear owners and well-understood traffic. Trading applications typically need the most testing for latency, session behavior and connectivity to market data, so they move after the back-office pattern is proven and with the trading desk's sign-off. Each wave gets its own change record, test evidence and a rollback plan, and no wave starts until the previous one has passed its exit check. The output is a wave log that shows which applications moved, when, under which change ticket and who approved them.
Assemble the regulator evidence pack
The team compiles a pack that shows the design, the controls and the evidence for each application group, mapped to the relevant obligations such as access control, multi-factor authentication, logging and encryption in transit. For SOX-relevant applications, the pack includes access request and approval records, change records for access policy updates, and periodic access reviews, which connect to the IT general control areas named in SEC Release 33-8810. DeployOpen prepares the evidence and controls, while independent auditors decide whether they are sufficient. Ask the compliance lead to confirm which regulator and which assessment will receive the pack before it is assembled.
Retire the VPN and document the exit plan
The VPN is retired only after every in-scope application has passed its criterion, all waves are closed and the monitoring confirms that no unexpected VPN traffic remains. The team documents the exit plan for each component, including data return, configuration export, key rotation and the steps to move to another platform if needed, which supports the exit strategy and contract requirements in DORA for ICT services that support critical or important functions. The step is complete when the VPN configuration is archived under retention rules, the exit plan has been reviewed by the risk owner, and the final evidence pack is filed with the change records.
Integration points that financial services teams must connect
A zero trust access layer makes decisions from identity, device, and logging data, so it is only as strong as the systems it connects to. The cards below cover the integrations that most often determine whether per-application access holds up under audit and under incident response.
Identity provider and MFA
The access layer should trust one identity source for workforce users, with MFA enforced at sign-in rather than per application. Keycloak supports OpenID Connect, SAML 2.0, LDAP and Active Directory federation, and Pomerium documents Keycloak among its supported identity providers. Confirm which factors your MFA design accepts, whether the identity provider can enforce phishing-resistant methods for administrators, and how group claims map to access policies for trading and back-office apps.
Device posture source
Posture checks only help if the access layer receives a reliable signal from managed endpoints. Pomerium reserves external data integrations such as FleetDM device posture for its Enterprise edition, so confirm whether your edition and deployment model accept that feed. Confirm which attributes you need (disk encryption, OS patch level, EDR presence, certificate on device), how often they refresh, and what happens when the posture source is unreachable during an outage.
SIEM log ingestion
Regulators and internal audit will ask who reached which application, from which device, and when. Access and audit logs from the proxy or overlay need to reach the same SIEM that holds identity and endpoint events so investigations can join them. Wazuh is one open source option for that collection and correlation. Confirm log format, field names for user and device, retention periods set by your policy, and whether session-level records are available for SSH and TCP access.
Secrets and certificate handling
Overlay networks and proxies rely on certificates and keys for device and service identity, and the upstream services they protect often need database or API credentials. Store those in a self-hosted secrets platform so issuance, rotation and revocation are recorded in one place. OpenBao is MPL-2.0 licensed and hosted under the OpenSSF, while Infisical ships MIT code with an enterprise directory under a separate license. Confirm key custody rules, rotation intervals your policy requires, and whether your security team accepts either tool for the key material in scope.
Network segmentation for trading segments
Per-application access does not remove the need to keep trading networks separate from general corporate networks. Connectors and routers placed in or next to trading segments should dial out to a controlled point, with no inbound firewall openings required for the service side. Confirm which segments the connector can reach, whether market data and order flow traverse the same path as the access traffic, and how change control approves new routes into a trading zone.
Third-party vendor access
Market data providers, core banking vendors and outsourced developers need access to specific systems under contracts that DORA requires to state where services run and where data is processed. Each vendor identity should map to a named application, a time-limited policy and a logged session. Confirm how vendor accounts are provisioned and removed, whether your identity provider supports external identities, and how the register of ICT contractual arrangements links to each vendor policy.
What examiners and auditors ask for from ZTNA logs and configuration
This table lists the evidence items a bank or fintech is likely to be asked for when examiners or auditors review remote access, with what each item proves and which component produces it. Read it as a preparation checklist: confirm each item exists, is exportable and is retained for the period your regulator expects. DeployOpen prepares the systems, controls and evidence, but auditors and examiners draw the conclusions.
| Evidence item | What it proves | Which component produces it |
|---|---|---|
| Access policy export | Which identities and device conditions could reach which internal applications at a given date | OpenZiti controller or Pomerium policy configuration, exported through the REST API or management console |
| Policy change history | Who changed an access rule, when, and under which approval, supporting change management and SOX-style IT general control testing | Version-controlled policy files (for example, Terraform or Git) plus the platform's management audit log |
| Authentication and MFA records | That each user authenticated through the identity provider with multi-factor authentication, as the FTC Safeguards Rule expects for information system access | Identity provider logs from Keycloak, authentik, ZITADEL or your existing enterprise directory |
| Per-request access and audit logs | Which user or service reached which application, when, and whether the request was allowed or denied | Pomerium access and audit logs, or OpenZiti controller and router logs forwarded to your SIEM |
| Session records where enabled | What an administrator or vendor did during a privileged session, supporting monitoring and forensic review | Pomerium Enterprise SSH session recording, or a dedicated PAM tool if session capture is required for other protocols |
| Device posture results | That only managed and compliant devices were admitted at the time of access | Posture integration output from your endpoint tooling, confirmed against the edition you license |
| DORA register of information entries | That the ZTNA platform, its hosting location and its providers are recorded as ICT contractual arrangements | Your third-party risk register, populated from vendor contracts and the deployment inventory maintained by your team |
| DORA exit strategy and transition plan | How access would be moved to another platform or reinstated after a provider failure, as DORA Article 28(8) asks for critical or important functions | Documented runbooks owned by your organization, tested against the self-hosted control plane and the fallback VPN or alternative |
Questions financial services teams ask before replacing their VPN
What drives the cost of replacing a VPN with open source zero trust access?
The cost is set by the number of applications to migrate, the number of user and device populations, and how much of the control plane you run yourself. The software itself is free to download under licenses such as Apache 2.0 for OpenZiti and Pomerium Core, so the spend goes to infrastructure, identity integration, migration work per application, testing, logging and ongoing operations. Some costs are one-time, such as design, policy modeling and cutover. Others recur, such as infrastructure, certificate and identity administration, upgrades and support. Ask any partner for a quote that separates these lines and states which applications, identity providers and device signals are in scope.
Can our internal team run a ZTNA migration without an outside partner?
Some teams can, especially if they already operate an identity provider, reverse proxies and network infrastructure, and they have time to build test cases for each application. The harder parts are rarely the software installation. They are mapping which users reach which services, handling non-web protocols, writing policies that match the old VPN rules, and proving the result to auditors. A fixed-scope engagement can cover some or all of that, and DeployOpen implements, hardens and documents self-hosted open source platforms in the client's own infrastructure. Decide which parts your staff will own after handover before you agree on scope.
What does our team need to provide during the engagement?
Expect to supply a named sponsor, an application inventory with owners, the current VPN rule set and its logs, identity provider access with the right to add applications, and access to the network segments where the new components will run. Security and compliance staff should review policy design and evidence requirements early, and application owners need time for testing. Ask the implementation partner for a written list of prerequisites with owners and dates, and confirm which of these depend on change windows at your bank.
Can the ZTNA control plane stay inside our own infrastructure?
Yes, for the open source options that support it. OpenZiti's README states the platform can run on the operator's own infrastructure with no vendor dependencies, and Pomerium Core is self-run, while Pomerium Zero keeps application traffic in the customer environment and hosts only the control plane. Confirm for each product whether the management console, identity integration, logs and any hosted relay or update path stay within your boundary. Document where each component runs and what data it holds, because that map is what regulators and your third-party risk team will ask for.
Does moving to ZTNA change our PCI DSS scope?
It can, and the answer depends on how the cardholder data environment is defined and which systems can reach it. PCI DSS applies to entities that store, process or transmit cardholder data or could affect the security of that environment, and PCI DSS v4.0.1 is the only active version. Replacing a VPN does not remove a system from scope by itself. Ask your Qualified Security Assessor to review the access paths, the proxies or overlay nodes that could touch cardholder systems, and the logs they generate, before you change the scope statement. The assessor makes that determination, not the software vendor.
How does a DORA exit strategy apply to a ZTNA vendor?
If the ZTNA service supports a critical or important function, DORA Article 28(8) expects a documented, tested exit strategy and transition plan for that ICT service, and Article 28(3) requires the provider to appear in your register of information. Self-hosting open source components reduces dependence on a single vendor, but it does not remove the need for a plan, because you still rely on the people, support contracts and update channels behind the software. For any commercial support or managed control plane, Article 30(2) requires the contract to state where data is processed and to cover data return on termination. Ask for those terms in writing.
How do device posture checks and access logs satisfy regulators?
Posture checks limit access to managed, compliant devices, and access logs show who reached which application and when. The FTC Safeguards Rule at 16 CFR 314.4 requires multi-factor authentication for any individual accessing an information system unless the Qualified Individual approves an equivalent control in writing, and it requires monitoring and logging of authorized user activity. Confirm that your chosen platform can enforce MFA through your identity provider, export logs to your SIEM with retention that meets your policy, and record policy changes. Pomerium lists access and audit logs in its Zero plans, while some features such as directory sync and Rego policies are reserved for its Enterprise edition, so check edition limits early.
How DeployOpen scopes zero trust work for regulated institutions
Every DeployOpen zero trust engagement starts with a written scope, and no work begins until the scope, deliverables and timeline are agreed in writing. For a bank or fintech replacing or shrinking its VPN, that scope has to name the applications moving off the VPN, such as trading front ends and back-office tools, the managed devices whose posture will be checked, the identity provider the policies will reference, and the log destinations that regulators or internal audit will read. Ask every partner, DeployOpen included, to put the application inventory, the excluded systems and the cutover method into the statement of work. A quote follows from that written scope, so a vague scope produces a vague quote.
DeployOpen plans, implements, hardens and documents the platform inside your own cloud accounts, data centers or private networks. For this use case, that typically means the control plane for a chosen overlay or identity-aware proxy, the enforcement points in front of each application, the policy definitions as version-controlled configuration, and the runbooks that show who approves a new route and how a revoked user is cut off. The same work produces the evidence files a compliance team asks for when it maps the design to requirements such as multi-factor authentication and access logging under the FTC Safeguards Rule. DeployOpen prepares that evidence. It does not issue audit reports or attestations, and your independent assessor decides whether the controls are sufficient.
Because access paths are exactly where attackers probe, DeployOpen also runs security testing against the finished design, covering the exposed endpoints, the policy logic and the device posture checks, and it documents the findings and fixes. Ongoing support, upgrades and continuous testing are available as retainers, which suits a control plane that must track vendor releases and regulatory change over several years. Confirm in writing which items sit in the fixed scope and which move into a retainer, and ask for the exit and data return terms for any hosted component you keep alongside the self-hosted one.
Questions to put to an implementation partner for financial services ZTNA
Where should the ZTNA control plane and relays run for a bank?
Run the control plane and the data-path relays in the bank's own cloud accounts or data centers, so that policy, identity records and session metadata never leave the bank's control. Ask the partner to draw each component (controller or management plane, edge routers or relays, identity provider connector, logging pipeline) and mark where each one runs and who holds administrative credentials. For OpenZiti, the controller and edge routers are the components to place. For Pomerium, the Core cluster runs in your environment, but Pomerium Zero hosts the management console, so confirm that split against your data residency rules before selecting a plan.
What traffic and metadata can the platform operator see?
Ask the partner to list every data element that leaves the bank's network and where it goes. Application payloads should stay encrypted end to end, but connection metadata such as identities, service names, timestamps, source addresses and policy decisions may reach a management plane. With OpenZiti SDKs, the data path is encrypted application to application, and with tunnelers it is encrypted tunneler to tunneler, so confirm which hop your design uses. Ask for this as a written data flow diagram tied to your data classification.
How do users and applications keep working when the identity provider or control plane is down?
Ask the partner to describe the failure modes for each component and state which existing sessions survive an outage and which new connections fail closed. Confirm whether the identity provider is clustered in your environment, how long already-issued session tokens remain valid, and whether a break-glass path exists that is itself logged and approved. Also ask how the design behaves for trading and back-office applications that operators must reach during market hours. Verify the answers in a failover test in your environment rather than accepting a diagram.
Which Pomerium Enterprise features does the bank need, and what does each one change?
List the controls you need before you select an edition. The Pomerium pricing page reserves directory sync, external data integrations such as FleetDM device posture, Rego policies, RBAC for administrators, session management, and SSH session recording and playback for the Enterprise edition, while Zero plans include SSO, mTLS, attribute-based policies, access and audit logs and a management API. If posture checks on managed devices or recorded SSH sessions are required by your controls, Enterprise is the edition to scope. Ask the partner for a written licensing position and confirm pricing directly with the vendor, because the page lists Enterprise at custom pricing.
Does the contract cover the DORA Article 30 terms for every service provider?
Ask the partner to show how each contract addresses the Article 30(2) items: the locations where services are provided and data is processed, advance notice of location changes, and data return on insolvency or termination. Ask whether the partner will include these terms in its own statement of work and whether any open-source vendor you adopt needs a separate agreement. DeployOpen's engagements are fixed-scope and agreed in writing before work starts, so the scope document is the place to record these terms. Have your legal and third-party risk teams confirm the wording and the register of information entries.
What logs does the design produce, and how long are they kept?
Ask which logs the ZTNA components write (authentication events, policy decisions, session start and stop, administrative changes, and any SSH session recordings), where they are stored and how they reach your SIEM. Retention is set by your regulator and your internal records policy, not by the tool, so ask the partner to map each log type to a retention period you supply and to show how logs are protected from alteration. The FTC Safeguards Rule and SEC examinations both expect you to be able to show who accessed what and when, so test a sample request end to end before go-live.
How do you support a tested exit from the ZTNA platform?
Ask for the exit plan in writing before deployment. A DORA-aligned exit covers how policies, identities and application routes are exported in a documented format, how the old VPN stays available during a rollback window, and how the partner tests the transition. Ask whether the partner will run the exit test in a non-production environment and record the results. Because the platforms are open source, ask which configuration is stored as code and which parts depend on a vendor console or a proprietary format.
What will this engagement cost, and what recurs after go-live?
The one-time costs are design, deployment, integration with your identity provider and device posture tools, application migration, testing and documentation. The recurring costs are infrastructure you run, staff time for operations, upgrades, any vendor subscriptions for the edition you choose, and support. Ask the partner to separate these in the quote, to state which are fixed by the written scope and which change with the number of applications, users and devices, and to name the assumptions behind each line. Ask the partner to provide a written scope before comparing quotes so that the comparison is like for like.
How DeployOpen works on this engagement
The sequence moves from a written scope that names the applications, identity sources and regulatory evidence in play, through a tested build and cutover, to a handover and an optional retainer that keeps the control plane current. Each step ends with a named output the bank or fintech can check.
Agree the scope and application inventory in writing
DeployOpen works with the security, identity and application owners to list the trading, back-office and internal tools that will move off the VPN, the identity provider and device signals each one needs, and the regulatory frameworks the evidence must support, such as the PCI DSS, DORA or FTC Safeguards Rule obligations that apply to your entity. The output is a fixed-scope proposal with deliverables, responsibilities and a timeline agreed in writing before any work starts. Confirm with your own compliance team which frameworks apply to which systems.
Map control plane placement and data flows
The team documents where the OpenZiti controller or Pomerium Core cluster will run, which components hold identity, policy and logs, and where any relay or edge router sits relative to your data center or cloud accounts. This step also records the ICT services and their data locations so the register of information and contract terms under DORA can be updated. The output is a reviewed architecture diagram and a data-flow record that your security and third-party risk teams sign off.
Integrate identity, groups and posture signals
Engineers connect your identity provider, such as Microsoft Entra ID, Okta or Keycloak, so that group membership and multi-factor authentication decide access to each application. Where you need device posture checks on managed laptops, the team confirms which edition or integration supports them, since some capabilities sit in enterprise editions and must be verified before design freeze. The output is a test matrix showing which user groups reach which applications, from which device states, and which requests are denied.
Build policies, hardening and log pipelines
The team writes per-application access policies, configures dark services with no inbound ports where the chosen model allows it, applies encryption in transit, and forwards access and audit logs to the SIEM you already run or to a self-hosted log platform. Administrative roles and change control are set up so that policy edits are traceable. The output is a hardened configuration baseline and a documented log schema that shows which fields record user, device, application and decision for each access event.
Test access, failure modes and revocation
DeployOpen runs functional and security tests against the deployed environment, covering denied access for out-of-scope users, behavior when the identity provider or control plane is unavailable, and whether revoking a user terminates active sessions as designed. Findings are logged, fixed and retested before cutover. The output is a signed test report with each finding closed or accepted in writing by the named risk owner, which can also feed the evidence file for an assessor.
Cut over application by application and hand over
Applications move in waves while the VPN stays available for fallback, and the team tracks each wave against the agreed inventory. At handover, DeployOpen delivers runbooks, configuration as code, backup and restore procedures, upgrade notes, and a control matrix mapping each access control to the evidence it produces. Your operations staff run a joint exercise to confirm they can perform routine changes. The output is a completed inventory with each application marked live, retired or deferred, and signed handover documents.
Maintain the platform under a retainer
If you choose ongoing support, DeployOpen provides upgrades, patch review against published releases, continuous or periodic testing, and changes to policy as new applications or regulatory expectations arrive. Scope, service levels and fees are defined in the retainer agreement, which should be requested as a separate written quote. The output is a recurring service report covering changes made, tests run and open risks, which your internal reviewers can use in governance meetings.
