Zero-Trust Policy Enforcement: Common Pitfalls

Zero-trust security is about never trust, always verify - securing users, devices, and connections by default. But enforcing it in multi-cloud environments (like AWS, Azure, and GCP) is challenging. Here’s why organisations struggle and how to fix it:

Key Issues:

• Fragmented Identity Systems: Multiple identity providers lead to inconsistent access controls and higher breach risks.
• Legacy Perimeter Defences: Traditional VPNs and firewalls fail in cloud setups, allowing lateral movement after breaches.
• Poor Visibility: Without a full inventory of assets, policies miss gaps, leaving systems exposed.
• Static Permissions: Broad, unchanging permissions increase risks, especially for service accounts and automation tools.
• Big Bang Deployments: Sudden enforcement without testing causes disruptions and rollback failures.
• Legacy Systems: Older applications and hybrid setups don’t align with zero-trust principles, creating vulnerabilities.
• Team Misalignment: Siloed teams and inconsistent tools lead to unmanaged risks and policy drift.

Fixes:

• Unified Identity Management: Centralise identity providers and enforce MFA, short-lived tokens, and workload authentication.
• Micro-Segmentation: Isolate workloads and use service mesh for encrypted, authenticated communication.
• Observability Tools: Map assets, monitor traffic, and ensure policy exceptions are documented and time-bound.
• Dynamic Authorisation: Shift from static RBAC to context-aware ABAC with temporary, task-specific permissions.
• Phased Rollouts: Test policies in stages, starting with smaller groups, and continuously monitor for issues.
• Legacy Wrapping: Use proxies or managed VPNs to secure older systems without major overhauls.
• Clear Ownership: Create a unified asset inventory and assign responsibility for every resource and policy.

By addressing these pitfalls methodically, organisations can strengthen security while avoiding costly mistakes. The shift to zero trust isn’t instant - it’s a step-by-step process requiring coordination, visibility, and consistent enforcement.

Pitfall 1: Weak Identity Foundation and Authentication Gaps

The Problem: Fragmented Identity Systems

In multi-cloud environments, fragmented identity systems can weaken zero-trust security. When teams use separate identity providers for platforms like AWS, Azure, and GCP, they create isolated silos. Each platform ends up managing its own users, service accounts, and permissions, which makes enforcing consistent access policies a struggle. Without a unified strategy, securing identities across these platforms becomes much harder.

The consequences of this fragmentation can be severe. According to IBM's Cost of a Data Breach Report 2024, 40% of all data breaches involved data stored across multiple environments, with the average cost surpassing £5 million per incident [4]. Even more concerning, 67% of breaches stemmed from lateral movement using a single compromised credential - often because that account had unnecessarily broad access [5].

Unmanaged service accounts pose another major risk. CI/CD pipelines, automation scripts, and microservices often accumulate unchecked permissions. These accounts frequently rely on long-lived credentials without MFA, making them an easy target for attackers.

Your identity plane is your security perimeter now. - CloudAISec [6]

The Solution: A Unified Identity Strategy

To tackle these identity-related challenges within a zero-trust framework, organisations need to adopt a unified approach. Start by consolidating identity providers into a single source of truth. Instead of maintaining separate directories for each cloud platform, federate them under a centralised identity provider that spans the entire environment. This simplifies the process of defining, auditing, and revoking access, regardless of which cloud platform is involved.

Implement MFA for all identities, including service accounts and CI/CD pipelines. Additionally, use SPIFFE IDs (Secure Production Identity Framework for Everyone) for workload-to-workload authentication. These provide cryptographically verifiable identities at runtime, eliminating the need for static credentials. Replacing long-lived keys with short-lived tokens further reduces the window of opportunity for compromise.

A real-world example from April 2026 highlights the effectiveness of this approach. An enterprise operating a multi-cloud platform across AWS and Azure integrated identity-centric workload authentication with automated drift detection. This strategy significantly reduced excessive privilege assignments and unauthorised lateral movement, all while maintaining acceptable performance levels [2]. It’s a clear demonstration of how unifying identity management can strengthen multi-cloud zero-trust efforts.

The move to zero trust is not binary; it's an ongoing approach that requires a fundamental shift to your architecture. - Ashher Syed, HashiCorp [2]

Regular audits are also essential. Monitoring identities, removing dormant accounts, and cleaning up stale service principals can prevent credential sprawl. For more guidance on refining identity strategies in multi-cloud environments, Hokstad Consulting recommends continuous monitoring and periodic reviews as key components of a resilient zero-trust programme.

Pitfall 2: Over-Reliance on Network Perimeter Controls

The Problem: Legacy Perimeter Controls

Traditional perimeter security operates on the assumption that everything inside the network is trustworthy. Tools like VPNs and firewalls maintain this boundary, blocking external threats while allowing relatively unrestricted movement within. This worked well for a single, on-premises data centre. But in today’s multi-cloud environments, this approach crumbles.

When workloads span AWS, Azure, GCP, and on-premises infrastructure, the concept of a secure inside ceases to exist. The perimeter essentially dissolves. Once attackers breach this outdated boundary, they can move laterally between services without much resistance due to insufficient controls over internal traffic.

The traditional network security model - trust everything inside the perimeter, block everything outside - was already failing before cloud adoption. In the cloud, it is fundamentally broken. - Michael Lawrence, Senior Cloud Security Engineer, Stackademic [7]

The risks are clear. According to IBM's Cost of a Data Breach Report 2024, multi-cloud setups amplify the impact of breaches [4], with the global average cost now at USD 4.44 million (around £3.5 million) [1].

To combat these vulnerabilities, organisations must move towards granular, workload-specific security measures.

The Solution: Micro-Segmentation and Service Mesh Policies

Micro-segmentation offers a way to reduce risk by isolating workloads, regardless of where they are hosted. It requires moving away from traditional perimeter-based defences and instead applying controls at the workload level. By dividing environments into isolated zones, micro-segmentation ensures that breaches are contained and lateral movement is restricted.

Service mesh technologies take this a step further by enforcing mutual TLS (mTLS). This approach encrypts all communications between services and requires both sides to authenticate before data can be exchanged. The adoption of service mesh solutions for mTLS has grown by 42% year-on-year, with 79% of organisations now using it specifically for this purpose [8]. For example, HashiCorp Consul automates mTLS encryption across services and enforces application-specific firewall rules, removing the need for separate network-level encryption [9].

A real-world example from April 2026 highlights the impact of these strategies. A company operating a multi-cloud platform across AWS and Azure implemented micro-segmentation as part of a zero-trust framework. This approach significantly reduced unauthorised lateral traffic [2], showcasing the effectiveness of moving beyond perimeter-based security to enforce policies at the workload level.

Zero Trust is not a product. It's not a firewall upgrade or a vendor suite you bolt onto your existing stack. - Michael Lawrence, Senior Cloud Security Engineer, Stackademic [7]

Pitfall 3: Poor Visibility and Incomplete Dependency Mapping

The Problem: Lack of Visibility

If you can’t see it, you can’t protect it. Yet, many organisations dive into enforcing zero-trust policies without fully understanding what exists across their environments. The result? A patchwork of controls riddled with gaps.

Multi-cloud setups make this even trickier. Each cloud provider has its own IAM systems and log formats - like CloudTrail, Azure Monitor, and GCP Audit Logs - making it hard to correlate activities across platforms [1]. On top of that, east-west traffic (the movement within a network) often goes unmonitored because traditional security focuses on the perimeter rather than internal activity [1]. This gives attackers who breach the outer defences a free pass to move laterally.

Unidentified assets only add to the problem [1]. As Katerina L., a Cloud Security Expert at Cloudaware, explains:

The first Zero Trust gap we see is not usually enforcement. It is an asset truth. Teams think they know what exists until we correlate accounts, workloads, owners, environments, and policy violations in one place. [1]

Inconsistent tagging and fragmented asset databases create blind spots in inventories of users, workload identities, and data paths [1]. Without complete visibility, a zero-trust approach is bound to falter.

The Solution: Observability-Driven Policy Design

To fix this, organisations need to prioritise observability. Start by mapping out everything before enforcing policies. This means cataloguing every AWS account, Azure subscription, GCP project, and Kubernetes cluster to create a reliable inventory of users, workloads, and data flows [1].

Tools like Hubble and Calico can help by capturing real-time traffic across environments [11]. Cilium, for instance, supports Layer 7 policies, enabling teams to allow specific HTTP methods (like GET) while blocking others (like DELETE) at the application level [11].

Once you’ve built a comprehensive map, consolidate your findings with CSPM tools, such as Microsoft Defender for Cloud. This lets you tie alerts to specific owners, systems, and workflows, preventing unattended alerts from piling up [3][10]. Mikhail M., General Manager at Cloudaware, highlights the importance of this approach:

A backlog is not a remediation plan. If a finding is not tied to an owner, a system, a business context, and a workflow, it is just another dashboard number. [1]

For every policy exception, document the owner, justification, scope, and expiry date. When exceptions expire, they should automatically return to active remediation rather than lingering as unmanaged risks [1]. This disciplined approach ensures your dependency map stays accurate and up-to-date. By doing so, you strengthen earlier zero-trust strategies like unified identity and micro-segmentation, keeping policies effective across all data flows.

Beyond the Perimeter: Implementing Zero Trust IAM in Hybrid & Multi-Cloud Realities | SHIFT 2025

Pitfall 4: Overly Broad or Static Authorisation Policies

::: @figure {Static RBAC vs Context-Aware ABAC in Zero-Trust Environments} :::

The Problem: Overly Broad, Static Permissions

Even with solid visibility and enforcement mechanisms in place, overly broad and static permissions can severely weaken zero-trust strategies. The core issue lies in the implicit trust granted after authentication, which results in permissions that remain unchanged over time. Traditional Role-Based Access Control (RBAC) often assigns permissions once and never revisits them, regardless of whether the user logs in from an untrusted device, an unusual location, or at an odd hour. Giao Nguyen, IAM Advisor at 1Kosmos, summarises it well:

Complexity is the enemy of execution... authorisation - the decisions about who can do what inside our applications and data - remains largely static and coarse-grained. [12]

The problem is further compounded by non-human identities (NHIs), such as service accounts, CI/CD pipelines, and automation tools. By 2025, data shows that 97% of NHIs have excessive privileges, yet only 5.7% of organisations have full visibility into these accounts [13]. These machine identities often retain broad, permanent permissions, leaving dormant access points that attackers can exploit.

This leads to policy drift, particularly in multi-cloud environments. Each cloud provider - whether it's AWS IAM, Azure Entra ID, or GCP IAM - enforces rules differently. A security measure applied in one cloud may not translate to another, creating gaps that attackers can exploit. By 2025, 67% of enterprise breaches involved attackers moving laterally from one overprivileged account to another [5].

Static permissions not only increase the risk of breaches but also highlight the need for policies that adapt to context and minimise risk.

The Solution: Context-Aware Policies and Automation

To address these challenges, organisations need to move away from static authorisations and adopt dynamic, automated controls. A key step in this transition is shifting from RBAC to Attribute-Based Access Control (ABAC). Unlike RBAC, which relies on predefined roles, ABAC evaluates real-time factors like device compliance, user behaviour, location, and time of access for every request. The differences are stark:

This dynamic model aligns with zero-trust principles by continuously verifying access context and enforcing least privilege. Implementing Just-in-Time (JIT) access is another critical step. Instead of granting standing privileges, JIT ensures permissions are active only for the duration of a specific task - measured in minutes or hours, not days. For instance, in April 2026, DevOpsNess transitioned from 14 long-lived IAM users to a zero-trust model. Using AWS IAM Identity Center and Google Workspace federation, they introduced session durations (e.g., one hour for emergency roles, eight hours for standard roles), blocked new IAM user creation via Service Control Policies (SCPs), and achieved near-instant access revocation [14].

Equally important is treating policies as code. By storing authorisation rules in version control systems like Git, running them through CI/CD pipelines, and testing them before deployment, organisations can maintain consistent policies across multi-cloud environments. Anna Paykina from Cerbos emphasises this point:

Zero Trust is not 'enabled' by buying a product. It's achieved by consistently applying the principle of least privilege and continuous verification everywhere. [12]

Lastly, automate access revocation. Link workload identities directly to service lifecycles so that when a service is decommissioned, its credentials are automatically revoked. This eliminates manual clean-up and prevents lingering access points that could be exploited.

Pitfall 5: Skipping Simulation, Phased Rollout, and Continuous Verification

The Problem: Big Bang Deployments

Dynamic, context-aware policies are only useful if they’re properly enforced - and that’s where many zero-trust programmes stumble. A common mistake is the all-at-once deployment: turning on enforcement for everyone simultaneously without any prior simulation or phased rollout.

The outcome? Predictable chaos. Take the example from April 2026: a financial services firm implemented restrictive Conditional Access policies for all users at once. With no staged rollout, the result was a massive remote access failure. It took two hours of emergency triage to restore operations, forcing the company to introduce a mandatory two-week observation period before rolling out any future policies [16].

But going too far in the other direction is just as risky. Leaving policies in monitor-only mode forever creates a false sense of security. Sure, violations get logged, but they’re not blocked, leaving security gaps wide open. Sven Schuchardt, a Management Consultant and Enterprise Architect, explained it well:

Phase 3 is where most Zero Trust programmes die... Someone flips enforcement on across the board, a legitimate service-to-service call gets blocked, a revenue-path incident ensues, and by Friday the team has retreated to 'permissive mode'. [15]

In reality, even mature zero-trust programmes often only enforce policies on about 60% of applications, leaving the rest in monitor mode to avoid disrupting legacy systems [15]. This isn’t zero trust - it’s partial enforcement with known blind spots. To tackle this, organisations need a deliberate rollout plan paired with ongoing monitoring, complementing the identity and policy controls discussed earlier.

The Solution: Phased Rollouts and Continuous Monitoring

To avoid these pitfalls, organisations should shift gradually from monitoring to full enforcement. A step-by-step enforcement strategy works far better than flipping the switch all at once. Below is a five-step approach that has proven effective:

This phased rollout ensures policies are tested and validated before being applied across the board, supporting the dynamic, context-aware enforcement discussed earlier.

To minimise disruptions, limit enforcement transitions to two segments at a time. Testing too many segments at once increases the risk of compounding misconfigurations, making it harder to pinpoint and resolve issues [15].

Start with canary groups to limit the impact of any issues. For example, begin with your IT team (Ring 0), then move to one technical business unit (Ring 1), before rolling out to the rest of the organisation (Ring 2). This approach reduces the likelihood of major outages and provides real-world insights before scaling up. In fact, phased rollouts have been shown to reduce segmentation-related outages by about 40% compared to big bang deployments [15].

Rollback readiness is critical. Have rollback scripts prepared to restore services within 15 minutes, and clearly define triggers in your runbooks. For instance, roll back immediately if a Tier 1 application goes down, or pause enforcement if helpdesk tickets exceed three times the baseline for over an hour [15]. As FireMon’s rollout guidance puts it:

If the rollback isn't rehearsed, the enforcement isn't ready. [15]

Finally, enforcement doesn’t stop once policies are rolled out. Continuous verification is essential. Even compliant devices can pose risks if policies are only checked at login. Policies need to dynamically re-evaluate session context, identifying anomalies like impossible travel, unusual access times, or new device signatures throughout the session, not just at authentication [17][18].

Pitfall 6: Ignoring Legacy Systems and Hybrid Connectivity

The Problem: Legacy and Hybrid Gaps

Even with careful planning and gradual implementation, legacy systems and hybrid connectivity often create weak points in zero-trust strategies. Here's the issue: legacy applications were designed for traditional, fixed network perimeters - a setup that doesn't align with zero-trust principles [20][21]. This challenge is similar to the hurdles encountered during phased rollouts, requiring a customised approach to address these older systems and hybrid configurations.

Then there's the problem with VPNs. These tools provide broad network access, which can be a gift to attackers. Once they compromise a single endpoint, they can move laterally across the network with ease [20][21]. Tim Tipton, Director of Cybersecurity Transformation at Arctiq, captures this shift in tactics perfectly:

Attackers no longer 'storm the perimeter' because there is no single perimeter. [21]

Hybrid connectivity options, like AWS Direct Connect, VPC peering, and site-to-site VPNs, often lack the necessary telemetry to monitor internal east-west traffic. This creates visibility gaps, making it much harder to detect suspicious activity [20][1]. Legacy systems also tend to rely on outdated authentication methods, making them prime targets for attackers [20][22]. With the global average cost of a data breach projected to hit USD 4.44 million by 2025 [1], failing to include these systems in zero-trust plans is a risk most organisations simply can't afford.

The Solution: Wrapping and Modernising Legacy Systems

Addressing legacy systems is crucial for maintaining the integrity of a zero-trust approach. However, this doesn't mean tearing everything down and starting from scratch. George Stern, Enterprise Connectivity & Security Specialist at Cloud Gateway, dispels this common misconception:

The assumption that Zero Trust requires ripping everything out and starting again is one of the most persistent and damaging misconceptions in enterprise security. [20]

A practical way forward is adopting a zero-trust proxy architecture. This involves placing a proxy server as a Policy Enforcement Point (PEP) in front of the legacy application. The proxy validates every request before it reaches the system. Additionally, deploying a connector near the legacy app creates an outbound-only TLS tunnel to the proxy, preserving the network perimeter [22]. The National Cyber Security Centre (NCSC) supports this approach:

A zero-trust proxy allows for secure remote access to applications that can't natively support zero trust. [22]

For systems that can't even handle a proxy - often those using specialised, non-HTTP protocols - a managed VPN can be a temporary solution. In this setup, legacy traffic is routed through a secure, limited tunnel, while zero-trust-native traffic avoids the VPN entirely. This ensures business continuity without compromising zero-trust principles for the rest of the network [22].

If a proxy is already in use, consider enhancing it with the sidecar pattern. This involves deploying a lightweight proxy alongside the legacy application to intercept traffic, add identity headers, and enforce policies without changing the app's code [23]. This approach is especially useful for vendor software or older codebases that can't be updated. Start by addressing the most critical systems first, then move on to less sensitive ones [20]. Treat these legacy challenges as a prioritised task list rather than a reason to delay implementing zero trust across your organisation. This step is essential for building a consistent and effective zero-trust strategy.

Pitfall 7: Underestimating Complexity and Team Misalignment

The Problem: Siloed Teams and Tools

After addressing technical challenges like visibility gaps and outdated integrations, another major obstacle surfaces: the lack of alignment across teams. In many organisations, teams such as security, platform, and application management operate independently, each focusing on their own responsibilities. While this independence may seem efficient, it often undermines the consistency needed for a zero-trust approach.

A key issue here is fragmented policy syntax and unmanaged resources. For instance, one team might set rules using AWS IAM, while another duplicates those rules in Azure RBAC. Although the intent behind these rules is the same, the implementations often diverge. This can lead to service accounts or workloads being left with excessive permissions and no clear ownership [24][1]. This misalignment is widespread, especially as 98% of enterprises are already working with or planning to adopt multi-cloud or hybrid environments [24].

Without a consolidated asset inventory, teams can overestimate their control, leaving gaps in security. Additionally, unmanaged exceptions - such as permissions granted without clear expiry dates or justification - can create hidden risks buried under layers of approvals [1].

The Solution: Clear Ownership and Unified Tooling

To address these issues, organisations need to rethink how resources are managed and assigned ownership across cloud environments. Igor K., a DevOps Engineer at Cloudaware, offers this practical advice:

The fix is not glamorous: build the asset view first, then map identities, segmentation, least privilege, monitoring, and automation against it. Otherwise, Zero Trust becomes another control stack with no operational memory. [1]

This begins with creating a unified asset inventory, such as a multi-cloud Configuration Management Database (CMDB). This database should link every asset to a specific owner, application, and environment (e.g., production or staging) [24][1]. Once in place, security findings can be sent directly to the appropriate owner through tools teams are already familiar with, rather than disappearing into a central backlog [24][1]. As Mikhail M., General Manager at Cloudaware, points out:

A backlog is not a remediation plan. If a finding is not tied to an owner, a system, a business context, and a workflow, it is just another dashboard number. [1]

In addition to assigning clear ownership - which reinforces earlier strategies like unified identity and micro-segmentation - it’s important to standardise security goals rather than focusing on syntax. For example, instead of writing cloud-specific rules, define broader outcomes like no public access to sensitive data and then translate these into specific implementations for each cloud provider [24]. Using policy-as-code in CI/CD pipelines ensures that any deviations are caught before deployment [6][9].

Another key step is implementing identity tiering. By categorising workload identities into tiers such as Critical, Sensitive, and Standard, organisations can apply predefined controls. This avoids repeated discussions about policies for every new service and ensures that non-human identities, like service accounts or automation pipelines, are managed with the same diligence as human accounts [6].

Balancing Cost and Performance in Zero-Trust Enforcement

The Problem: Cost and Performance Trade-Offs

Implementing zero-trust policies goes beyond managing identities and permissions. Organisations must also navigate the tricky balance between cost and performance.

When zero-trust policies are poorly designed, costs can spiral, and performance suffers. A common issue is excessive centralisation - forcing every access decision through a single policy engine. This creates a bottleneck, increasing latency and making the system fragile. Cross-cloud latency in such setups typically falls between 10 ms and 50 ms [9]. Infrastructure costs can also pile up. For example, AWS PrivateLink and Azure Private Endpoints cost about £5.75 per month per Availability Zone, with additional charges for data processing [9]. Similarly, AWS NAT Gateway data processing costs approximately £0.04 per GB [9]. Without optimised traffic routing, these charges can add up quickly. For organisations operating across multiple cloud environments, finding this balance is critical to maintain strong security while keeping budgets in check.

Sven Schuchardt, a Management Consultant and Enterprise Architect, highlights the financial challenge:

The 90-day foundation cost: $1.4M–$2.1M for a mid-market enterprise... Tooling is rarely the cost overrun. Labour and integration are. [26]

The Solution: Cost-Aware Zero-Trust Design

The answer lies in adopting a central intent, local enforcement model. Instead of routing every access decision through one centralised engine, security policies should be defined centrally but enforced locally using the native authorisation features of each cloud provider - such as AWS IAM or Azure Conditional Access [6]. As CloudAISec advises:

Do not force every access decision through one global chokepoint. Instead, define central policy patterns and enforce them with each cloud's native authorization path. [6]

This approach, when paired with tiered identity models, ensures resource-heavy checks are reserved for critical workloads. Meanwhile, lower-priority environments like build/test setups can use lighter enforcement, reducing overhead without sacrificing security.

On the tooling front, solutions like Cloud Custodian simplify security enforcement and cost management. It can transform ad-hoc scripts into unified rules engines, handling tasks like decommissioning unused resources and automating off-hours shutdowns for non-essential workloads [25]. For organisations using Microsoft 365, bundled licences such as E5 offer a cost-effective way to integrate identity management, endpoint protection, and device management, avoiding unnecessary expenses [26].

The benefits of a well-implemented zero-trust programme are clear. Organisations with mature strategies report a 50% reduction in breach impact [19], and Forrester's Total Economic Impact study notes a 111% ROI with a payback period of just five months [26].

Here’s a summary of key cost and performance factors, along with strategies to optimise them:

For further guidance on crafting cost-efficient zero-trust strategies that maintain strong security without sacrificing performance, consult Hokstad Consulting. Their expertise in cloud cost engineering and DevOps transformation can help customise solutions to fit your organisation’s needs.

Conclusion: Building a Consistent Zero-Trust Programme

Implementing zero-trust in multi-cloud environments is an ongoing effort that requires careful planning and execution. The challenges discussed in this article highlight a key issue: jumping into policy enforcement without a solid groundwork can increase vulnerabilities.

One critical step often overlooked is comprehensive asset mapping. Many teams assume they have control, but without correlating accounts, workloads, owners, environments, and policy violations in a unified view, gaps remain.

To avoid these common missteps, organisations should adopt a phased and structured approach. For example, a 90-day plan could begin with identity inventory and the removal of static credentials. From there, it could progress to microsegmentation and federated credentials, and conclude with automated containment and refining policies. This method ensures measurable progress while maintaining system stability. By 2026, it’s predicted that at least 10% of large enterprises will have achieved a mature zero-trust architecture, compared to less than 1% in 2023 [27]. The key difference? Successful organisations treat zero-trust as an evolving programme, not a one-time product.

To build a resilient zero-trust framework, organisations need to focus on key elements: full asset visibility, context-aware authorisation, and integrating policy-as-code into CI/CD pipelines. Non-human identities, such as CI/CD runners, service principals, and workload roles, require the same level of governance as human accounts [6]. Every exception should have an assigned owner, a clear rationale, and a defined expiration date - because a backlog without accountability is not a plan for remediation.

Hokstad Consulting supports organisations in developing secure and financially sustainable zero-trust programmes. Their expertise spans from embedding policy-as-code into delivery pipelines to optimising enforcement strategies across multi-cloud setups, ensuring security becomes a seamless part of operational workflows.

FAQs