Hybrid Zero Trust: securing your access across datacenter, AWS and OVHcloud
Your environments are each protected on their own. But who protects the access between them?
A company can properly secure its datacenter, structure its AWS accounts, isolate its OVHcloud projects and enable multi-factor authentication. Yet an access remains dangerous if the controls don't talk to each other, if a private link is treated as proof of trust, or if a provider can reach more resources than necessary. In a hybrid information system, the risk often lies less within each environment than in how they're connected.
The issue is no longer just protecting a perimeter. For every critical access, the company needs to answer five simple questions: who is requesting access, from what device or service, toward which resource, under what policy, and with what ability to revoke it? This logic applies to employees and administrators, but also to applications, APIs, pipelines and workloads communicating with each other.
This article offers an operational reading of Zero Trust for a company combining a datacenter, legacy applications, AWS, OVHcloud and SaaS services. It doesn't present a universal architecture or a product catalog. It shows how to build a coherent framework, choose the right control points, organize responsibilities, and move forward progressively without disrupting operations.
When risk slips between environments
Picture Nova Industrie, a fictional 180-employee SMB spread across three sites. Its information system relies on Active Directory, several on-site business applications, Microsoft 365, two AWS accounts used for digital services, and several OVHcloud projects. Remote work is common, and about ten providers handle maintenance, support and development.
The company has already invested in security: multi-factor authentication, endpoint protection, recent firewalls, VPN, backups, and partial log centralization. On paper, every building block looks defensible. But a provider account is used from an unknown device to open a VPN session. Network access gives visibility into several internal addresses. The attacker then reaches a jump server, retrieves an application secret, and attempts to call a service hosted in AWS.
No control was entirely missing. The problem was in how they fit together. The VPN had authenticated the account without limiting the user to the two applications actually needed. The device's state, known to the protection system, didn't influence the decision. The application secret was valid for too long. And the logs didn't make it possible to quickly link the provider's identity, their device, the VPN session, the jump server and the cloud call.
This question changes the discussion. It moves the company away from looking for a "Zero Trust product" and toward a verifiable model. One solution may cover user access, another privileges, a third workload identities. What matters is the consistency of the guarantees and the ability to prove a resource has no bypass path.
Why a hybrid IT estate makes the traditional model insufficient
In a legacy environment, security long relied on a simple distinction: the outside was considered hostile and the inside relatively trustworthy. That picture has become too fragile. An employee may authenticate to a SaaS service before accessing an on-site application. An AWS workload may call an API in OVHcloud. An administrator may act from a privileged workstation on a cloud console without traffic ever passing back through the datacenter.
Identities aren't homogeneous
An Active Directory user, an AWS role, an OVHcloud service identity, a technical account and a certificate follow neither the same mechanisms nor the same lifecycles. Some identities are named, others shared by mistake, others still embedded in a script. As long as the company can't attribute every request to a human or technical identity and an owner, the access policy remains partial.
Control points are distributed
Control can be enforced by a ZTNA proxy, an agent, a bastion, a PAM solution, an API gateway, a service mesh, a firewall, or a cloud-native IAM mechanism. Trying to force all traffic through a single point recreates a bottleneck, increases dependency, and fits poorly with cloud usage. The challenge is distributing rule enforcement without losing governance.
Signals come from different systems
Identity comes from the identity provider, device posture from an EDR or MDM, resource criticality from an application inventory, behavioral risk from a detection tool, and context from a cloud engine. A decision is only truly contextual if these signals are reliable, recent enough, and correlatable. A posture that's several days old can't justify sensitive admin access.
Legacy applications force coexistence
Not every application supports SAML, OIDC, short-lived tokens, or a modern gateway. Some require a thick client, a fixed IP address, or a legacy protocol. Transformation therefore needs to organize coexistence: federation where possible, proxy or ZTNA for web applications, VDI for unmanaged devices, a bastion for administration, and a limited VPN when the exception is still necessary.
Zero Trust explained as a decision, not a product
NIST SP 800-207 describes a logical architecture in which a Policy Engine makes the decision, a Policy Administrator turns that decision into a session action, and a Policy Enforcement Point applies the result. These roles are logical: a single product can fulfill several of them, and several technologies can cooperate to cover one use case.
In a hybrid IT estate, having one universal engine is rarely realistic. The identity provider's conditional access, PAM, ZTNA, cloud IAM policies and application controls each handle part of the decisions. NIST SP 800-207A extends this logic to cloud-native and multicloud environments: application and service identity, API gateways, proxies and application identity infrastructure become as important as human identity.
The goal isn't for every environment to use the same technology. They need to produce comparable guarantees: a verifiable identity, least privilege, a control point placed near the resource, a governed policy, usable logging, effective revocation, and a known behavior in case of failure.
The principles that must hold true everywhere
- The network carries traffic, but never grants trust on its own.
- Every request must be attributable to a human or technical identity and an owner.
- Policy protects a specific resource; access to one application shouldn't open an entire segment.
- The assurance level must match the criticality of the action and the data.
- The signals used must be verifiable, recent and available at the time of the decision.
- The enforcement point must sit as close as possible to the resource and be impossible to bypass.
- The control plane — identity, PAM, policies, certificates and consoles — must be treated as a critical asset.
- Every critical control must have a documented, tested and approved degraded mode.
These principles can be held up against every project. A team is free to select a different mechanism in AWS and in OVHcloud, but it must demonstrate the identity used, the policy applied, the control point, the available telemetry, and the expected behavior when one of the signals or services becomes unavailable.
Placing controls according to real traffic flows
A Zero Trust architecture doesn't start with a product diagram. It starts with critical flows: who accesses what, why, at what privilege level, and via which routes. The right control point depends on the resource and the protocol. An application proxy may suit a web portal; it replaces neither PAM for administration nor workload identity for an API.
| Priority flow | Recommended control point | Minimum signals | Desired outcome |
|---|---|---|---|
| Employee to on-site web application | ZTNA or application reverse proxy | Identity, MFA, posture, group, criticality | Access limited to the application, no segment exposure |
| Provider to admin tool | PAM, bastion or virtual workstation | Third-party identity, approval, time window, device | Temporary, recorded, revocable session |
| Employee to AWS application | Application control or native service | Federated identity, posture, context | Short-lived role and resource-conditioned access |
| AWS workload to OVHcloud API | API gateway, mTLS or workload proxy | Service identity, audience, environment | Fine-grained authorization and short-lived secret |
| Administrator to cloud console | IdP, cloud IAM and PAM | Separate admin account, strong MFA, privileged workstation | Traced, approved and quickly revocable action |
Anatomy of an access decision
Take a provider who needs to access a maintenance tool. The control point collects their identity, device state, time, risk level and the requested resource. The policy requires an active third-party identity, phishing-resistant authentication, a recent posture, and an approved intervention window. If all conditions are met, a session limited to the application is created for a short duration.
If the device isn't managed, the response shouldn't be systematically binary. The company can require a virtual workstation, allow read-only access, or ask for additional validation. A critical device alert, the end of the contract, or abnormal behavior should trigger a reassessment and, if necessary, cut an already-open session. The actual delay between the event and revocation then becomes a security indicator.
For every critical resource, the owner should be able to answer a simple question: through what mechanism are all routes to this resource controlled? An application protected by a proxy but still directly reachable via its private address has a bypass path. This must be verified technically, not inferred from a diagram.
Three possible architecture models
The choice of architecture depends on maturity, available skills, the diversity of the estate, and the acceptable level of dependency. Three families come up repeatedly. None is perfect; the decision should be driven by use cases, resilience, and the operating model.
| Criteria | Integrated suite | Centralized best-of-breed | Federation by use case |
|---|---|---|---|
| Initial speed | High | Low to medium | Medium |
| Heterogeneous coverage | Medium | High | High |
| Integration complexity | Low to medium | Very high | Managed per scope |
| Vendor dependency | High | Medium | Low to medium |
| Local resilience | Variable | Centralization risk | High if domains stay autonomous |
| Governance required | Medium | Very high | High |
An integrated primary suite
The company chooses a dominant vendor for identity, posture, application access and part of the telemetry. This approach often speeds up the first rollouts, reduces the number of integrations, and simplifies support. It can, however, cover legacy applications, workloads, or a second cloud imperfectly. Contractual and technical dependency must be examined from the start.
A centralized best-of-breed assembly
Each domain uses the technology considered best: IdP, EDR, PAM, ZTNA, segmentation, API security and data protection are separate, while a central layer orchestrates decisions. Coverage can be rich, but the integration itself becomes a product to design, test and maintain. Formats, identifiers, APIs, latencies and responsibilities create a complexity that sometimes exceeds the company's operating capacity.
An architecture federated by use case
The company enforces a common foundation — reference identities, criticality levels, minimum requirements, decision evidence and governance — then uses the engine and control point suited to each environment. Local decisions stay autonomous within a shared framework. For an organization combining a datacenter, AWS, OVHcloud and application legacy, this approach is often the most realistic.
Translating the model into each environment
Datacenter and legacy applications
Active Directory remains an essential source for identities and groups, but it shouldn't become the universal engine for every decision. Critical access must also account for posture, application sensitivity, context and duration. Compatible applications are federated. Others are placed behind a reverse proxy, a ZTNA PEP, a virtual workstation, or a bastion depending on the protocol and risk level.
The network keeps a major role. It limits communication between zones, protects control planes, and prevents bypassing of enforcement points. Segmentation should nonetheless be derived from observed flows. Overly ambitious microsegmentation, undertaken before dependencies are discovered, causes disruptions and an accumulation of exceptions that end up weakening the whole system.
AWS
In AWS, a multi-account strategy makes it possible to separate workloads, environments, logs and certain security functions. This separation is a useful boundary, but it doesn't replace authorization. Roles, conditions, resource policies and session duration determine what an identity can actually do. Human identity should be federated from the company's identity provider rather than recreated account by account.
For applications, AWS Verified Access can, depending on use cases and service availability, evaluate requests based on identity and posture without imposing a traditional VPN. Other architectures rely on an application control, a load balancer, an API gateway or VPC Lattice. For workloads, roles and service identities should be preferred over static keys. Privileged access uses temporary roles, and logs are centralized in a separate scope.
OVHcloud
In OVHcloud, Public Cloud projects should separate environments or criticality levels in an understandable way. Human rights are limited via IAM policies where the service and context allow. Technical identities shouldn't rely on shared personal credentials. Every service account needs an owner, a scope, a duration and a revocation procedure.
vRack provides useful private connectivity between resources and sites, but it isn't proof of authorization. Traffic that travels over a private network still needs to be authenticated, filtered and logged. For APIs and workload-to-workload communication, service identity, mTLS, short-lived tokens or an application gateway help reduce the implicit trust granted to an IP address and segment.
What the three environments have in common
Implementation won't be identical, and that's fine. User access control in the datacenter, an AWS IAM policy, and an OVHcloud service identity use different mechanisms. They nonetheless need to be evaluated against the same questions: is the identity verifiable? is the scope minimal? is the session limited? does the resource have a bypass path? can events be correlated? does revocation actually work?
Legacy applications: moving forward without blocking operations
Zero Trust doesn't require replacing every legacy application immediately. It requires making exceptions visible, limited and temporary. An old web application can be placed behind a reverse proxy. A thick client used by a provider can be presented through a virtual workstation. A sensitive console can go through a bastion or PAM. A fully incompatible application can keep a VPN, provided it's segmented and limited to the strict minimum.
| Transition model | Suited to | Benefit | Point of caution |
|---|---|---|---|
| Native federation | SAML or OIDC application | Centralized identity and lifecycle | Application evolution and testing |
| Reverse proxy / ZTNA | Legacy web application | Fast, per-application access | Internal visibility sometimes limited |
| VDI / virtual workstation | Thick client or third-party device | Managed environment and confined data | Cost, capacity and user experience |
| Bastion / PAM | Server or database administration | Temporary, traceable session | Critical point that must be made resilient |
| Limited VPN | Temporary incompatible exception | Continuity during migration | Scope, owner and sunset date mandatory |
A residual VPN isn't automatically a failure. It becomes one when it has no scope, no owner, no compensating control and no sunset date. Every exception should be logged in a register with the resource concerned, the accepted risk, temporary controls, the responsible person, and the next review date.
Designing resilience before blocking
Decision components become critical to operations. An architecture that blocks all operations during a minor outage will get worked around by teams. Conversely, an architecture that allows everything as soon as a signal disappears cancels out its own security. Failure behavior must be defined per resource and per action, then tested before generalization.
Identity provider unavailability may lead to denying new sensitive sessions while keeping certain already-validated sessions active for a bounded duration. The absence of a recent EDR signal may require a virtual workstation or read-only access. Policy engine unavailability may trigger a restrictive local rule or use a cached decision for a common case. An outage between clouds may queue replayable operations and cleanly stop non-replayable transactions.
The choice between fail-open and fail-closed isn't just a security preference. Browsing a catalog, editing sensitive data, and modifying production don't carry the same impact. The decision must factor in business criticality, the ability to detect abuse, the duration of degraded mode, and compensating controls. Emergency accounts, when needed, must be protected, monitored and tested; a "break-glass" account unknown to the actual process is not a safeguard.
A realistic roadmap in four waves
The transformation should deliver one complete use case before seeking global coverage. Each wave has entry criteria, a pilot, an observation period before enforcement, a rollback, and exit criteria. This discipline reduces disruption and makes it possible to demonstrate a real reduction in risk.
Wave 0 — make dependencies visible
The company inventories applications, identities, privileges, routes, workloads and owners. It identifies critical resources, bypass paths, and the components the access decision depends on. The expected outcome isn't a perfect CMDB, but a map reliable enough to choose a first use case and avoid protecting one route while leaving another open.
Wave 1 — protect one complete journey
A good pilot often involves providers, since the risk is easy to read and the scope is manageable. Two applications can be migrated with named identity, MFA, posture, ZTNA, logging, support and revocation. The associated administration must be included in the pilot, for example with a PAM or bastion, so the business use case isn't secured while the privileged path stays exposed.
Wave 2 — industrialize by family
The company defines reproducible models for five families: modern application, legacy web application, administration, API and workload. Each model specifies identity, control point, mandatory signals, logging, degraded mode and responsibilities. Replaced VPN routes are removed; remaining exceptions are dated and tracked.
Wave 3 — extend to cloud flows and data
Service identities are generalized, communications between AWS, OVHcloud and the datacenter are strengthened, and policies evolve based on data classification. The company tests lateral-movement attempts, expired certificates, wrong audiences, calls from another workload, and temporary unavailability of the issuing mechanism. Technical evidence then aligns with risk scenarios.
Criteria for moving between waves
- The resource's business owner and technical owner are identified.
- All normal and fallback routes to the resource have been inventoried.
- Support knows how to handle a false denial, a device change and a lost authenticator.
- Degraded mode and rollback have been tested with the teams involved.
- Logs make it possible to link identity, device or workload, session, decision and resource.
- Benefit and friction are measured during the pilot before moving to enforcement.
Governing policies and distributing responsibilities
A Zero Trust policy isn't a technical rule left to an isolated administrator. It spans the business, security architecture, identity, network, cloud teams, support and the SOC. The business owner defines criticality and legitimate uses. Security architecture defines the framework. IAM, ZTNA or PAM platforms configure the mechanisms. Cloud and network teams enforce controls in their domains. The SOC monitors and requests revocation as risk evolves.
A policy's lifecycle includes at minimum design, simulation, approval, pilot, deployment, observation and review. A register should specify the engine involved, the resource, the attributes used, the version, the owner, exceptions and tests. Without this register, several technically correct rules can become contradictory or keep applying after the need has disappeared.
In an SMB, the same person may hold several roles. That doesn't remove the need to distinguish them. A provider proposing a rule shouldn't be the only one validating the business risk. A team administering the platform shouldn't be the only one interpreting alerts. The goal is to avoid gray areas, not to create heavy bureaucracy.
Indicators that speak to leadership
The number of "integrated" applications isn't enough. An application can be counted as protected while still being reachable via a direct route. Indicators need to measure decision quality, coverage of critical resources, revocation capability, and the friction created for users.
- Coverage of critical resources by a control point with no bypass route.
- Share of sensitive decisions using a sufficiently recent posture signal.
- Percentage of privileged access carried out with a separate, temporary, tracked identity.
- End-to-end revocation time, measured under real conditions.
- False-denial rate and median resolution time by support.
- Share of workloads using a short-lived identity rather than a static secret.
- Control-plane availability and degraded-mode test results.
- Number, age and criticality of exceptions, with their owner and sunset date.
Every indicator needs a source, a formula, a frequency, a target and an owner. Leadership doesn't need to track every technical event. It needs to be able to see whether critical access is becoming more explainable, whether potential spread is decreasing, whether privileges are shorter-lived, and whether the transformation remains sustainable for the teams.
The mistakes that weaken the project
Treating the private network as proof of trust
VPN, peering, vRack and dedicated links reduce public exposure, but prove neither the identity nor the authorization of a flow. Private connectivity must remain a transport mechanism. Access is granted by an identity, a policy and a control suited to the resource.
Protecting users and forgetting workloads
A static key stored in a pipeline can bypass every control imposed on employees. Services, scripts and deployment chains need an attributable technical identity with minimal scope and short duration. Renewal and revocation are part of the architecture, not just operations.
Installing a control point while leaving a direct route open
An attacker will choose the least-controlled path. Protecting an application's public URL isn't enough if the server remains reachable from a large internal segment. Closing bypass routes must be part of the pilot's exit criteria.
Stacking products without a shared vocabulary
Local rules can become inconsistent if criticality levels, identifiers, owners and failure behaviors aren't aligned. The company needs a shared framework before adding an orchestration layer. Otherwise, every integration increases operational debt.
Neglecting support and user experience
False denials, device changes, lost authenticators and urgent interventions are predictable. Without a procedure, teams will create shared accounts, request permanent exceptions, or re-enable overly broad access. Support is therefore a security component in its own right.
Quick self-assessment: is your architecture actually consistent?
This self-assessment doesn't produce a compliance score. It helps determine whether the company has the foundations needed to launch a pilot, or whether it should first improve visibility. Answer Yes, Partially, No, or I don't know.
- Can you name the resources whose unavailability or compromise would have the greatest impact?
- Do you know which human and technical identities can reach each of these resources?
- Is provider access limited to the necessary applications, a duration and an approved window?
- Does device or workload state actually influence sensitive decisions?
- Are private connections between sites and clouds still subject to application-level authentication and authorization?
- Can you demonstrate that a protected resource has no bypass route?
- Is the end-to-end revocation time for an access or session measured?
- Have the degraded modes for identity, policies and logging been tested?
Several "No" or "I don't know" answers don't mean you need to buy a new platform right away. They usually point to the priority: clarify resources, flows, identities and owners before choosing the first use case. A good roadmap starts with visibility and a shared risk decision.
Conclusion: seek consistency, not uniformity
A successful hybrid Zero Trust architecture doesn't replicate the same tool in every environment. It organizes decision consistency. The datacenter, AWS and OVHcloud can use different mechanisms as long as each one can identify the subject, evaluate the right signals, protect the resource with a control point, produce evidence, and react to revocation or failure.
The architect's role is to make this consistency explicit: define the principles, choose the enforcement points, arbitrate centralization, handle legacy applications, design degraded modes, and assign responsibilities. For an SMB, a federated, progressive architecture delivers concrete results without launching a disproportionate program or depending on a wholesale transformation of the information system.
The expected outcome isn't a final diagram. It's an operational capability: every critical access can be explained, enforced, observed, revoked and tested, regardless of which environment hosts the resource. That capability is what reduces the risk of spread, secures third-party interventions, and gives leadership a more reliable view of its exposure.
FAQ
Do you need to remove every VPN to adopt Zero Trust?
No. A VPN may remain necessary for certain protocols or applications. It should, however, be limited, segmented, tied to a strong identity, and included in a roadmap. The issue isn't its existence, but the overly broad trust it can open up after authentication.
Is a private AWS-OVHcloud link enough?
No. It reduces exposure to the internet, but doesn't prove the service's identity or the call's authorization. The architecture needs to add a workload identity, application-level authorization, logging and revocation capability suited to the flow.
Do you need a single policy engine?
Not necessarily. In a hybrid IT estate, several engines are often more realistic: identity, ZTNA, PAM, cloud IAM and application controls. The challenge is federating them around consistent principles, a criticality vocabulary, owners and evidence.
Which use case should you start with?
Choose a high-risk flow with a manageable scope: provider access to two applications, administration of a critical service, or communication between two workloads. The pilot should cover identity, policy, the enforcement point, logs, support, revocation and degraded mode.
What role does ARCrezo play in this type of project?
ARCrezo works on its core expertise: network architecture, segmentation, firewalls, VPN, remote access, inter-site and hybrid flows, documentation and roadmap preparation. IAM, PAM, EDR, application security or broad compliance domains may require complementary specialists depending on context.
Key references
Editorial note: cloud services, their features and their availability change over time. Design choices should be confirmed against official documentation and validated for the regions, offers and constraints applicable to the company at the time of the project.
- NIST SP 800-207 — Zero Trust Architecture (2020)
- NIST SP 800-207A — Zero Trust for Cloud-Native and Multicloud Applications (2023)
- NIST SP 1800-35 — Implementing a Zero Trust Architecture, final version (2025)
- AWS Security Reference Architecture
- AWS Verified Access
- OVHcloud — Public Cloud security best practices
- OVHcloud — IAM policies
- OVHcloud — Public Cloud vRack