Policy orchestration for SASE access control: PlainID and Zscaler

At a glance

What this is: This is PlainID's description of policy orchestration for SASE access control, centred on discovering existing Zscaler policies and enriching tokens with fine-grained entitlements.

Why it matters: It matters because IAM teams need authorization decisions, token claims, and enforcement points to stay aligned across SASE and adjacent layers, or policy drift creates inconsistent access.

👉 Read PlainID's policy orchestration analysis for SASE access control with Zscaler

Context

SASE access control breaks down when identity, authorization, and enforcement do not share the same policy model. In practice, that means a token may carry one set of entitlements while the security layer applies another, leaving teams with visibility into access but not confidence in how it is enforced.

PlainID's article focuses on orchestration between its policy layer and Zscaler, with policy discovery and token enrichment as the main mechanisms. The issue for practitioners is not simply connectivity, but whether centralized authorization can stay authoritative once it is translated into the controls used at the edge.

Key questions

Q: How should teams centralise authorization for SASE access control?

A: Teams should centralise the policy decision, not just the policy storage. The identity layer, token content, and edge enforcement must all reflect the same entitlement logic, otherwise SASE becomes a collection of inconsistent local decisions. The key governance task is to define one authoritative source of truth and then verify every downstream control consumes that same decision.

Q: Why do token claims matter in identity-aware SASE enforcement?

A: Token claims matter because they often become the enforcement input once the authorization decision leaves the identity layer. If the claims are incomplete, stale, or too coarse, the downstream service may enforce access that no longer matches policy intent. In practice, the control boundary shifts from the decision itself to the fidelity of the token carrying it.

Q: What breaks when access policies exist in multiple SASE tools?

A: Policy sprawl creates contradictory rules, duplicate exceptions, and hidden ownership gaps. Teams may believe central authorization exists, but the actual access outcome is still shaped by local policies left behind in individual tools. That is where enforcement inconsistency appears, especially when different layers interpret the same user or application context differently.

Q: How do teams know whether SASE authorization is actually aligned?

A: Teams should test the full chain from policy source to token enrichment to enforcement. Alignment is real only when the same access request produces the same entitlement meaning across every layer. If the decision changes as it moves through the stack, the organization has orchestration, but not reliable authorization governance.

Technical breakdown

How policy orchestration works across SASE and the identity provider

Policy orchestration is the process of centralising authorization logic so that one policy source can inform multiple enforcement points. In this model, the identity provider sends an authorization request to PlainID, PlainID evaluates approved entitlements, and the resulting decision is returned for enforcement. The security value comes from reducing policy divergence between systems that would otherwise make local decisions independently. In SASE, that matters because access control is only as consistent as the handoff between identity, token issuance, and edge enforcement.

Practical implication: map which system is authoritative for authorization decisions and verify that every enforcement point consumes the same policy outcome.

Why token enrichment changes the control plane

Token enrichment means adding fine-grained entitlement claims to an access token before it reaches the enforcement layer. Instead of relying on a coarse yes or no decision, the token can carry read-only scope, application-specific permissions, or other attributes that the downstream service uses at runtime. This is useful when access needs vary by user approval and policy context, but it also creates a dependency on claim accuracy. If the enrichment step is stale, incomplete, or inconsistent with the source policy, downstream access control inherits that error.

Practical implication: test the claims added to tokens, not just the authorization decision, because the token becomes part of the enforcement boundary.

Policy discovery is a governance problem, not just an integration feature

Policy discovery gives administrators visibility into existing access rules that already exist inside the environment. That matters because SASE estates often accumulate policy in multiple places, making it difficult to know which rules are still active, duplicated, or contradictory. Discovery reduces blind spots, but it does not by itself resolve policy sprawl. The governance challenge is to decide which policy source remains authoritative, how exceptions are tracked, and how old rules are retired without leaving shadow authorization behind.

Practical implication: inventory current access policies before layering on orchestration, or you risk automating inconsistency instead of governing it.

NHI Mgmt Group analysis

SASE authorization only works when the policy decision and the enforcement claim are the same thing. PlainID's model highlights a familiar IAM failure pattern: organisations assume central policy logic will stay intact after translation into tokens and edge enforcement. In reality, the risk is policy drift across layers, where one system authorizes and another enforces a different interpretation. The practitioner conclusion is simple: identity-centred SASE depends on a single authoritative authorization model, not just an integration path.

Token enrichment becomes a governance control only when entitlement semantics are controlled end to end. Fine-grained entitlements are useful because they let downstream systems enforce context-specific access, but they also amplify any inconsistency in approval, policy lookup, or claim construction. That is why this is not just an access convenience story. The control question is whether the token carries the exact entitlement meaning the policy engine intended, or whether the edge is inheriting a softened version of the decision.

Policy discovery exposes authorization sprawl before it becomes an enforcement problem. Many enterprises already have policy in multiple products, multiple teams, and multiple eras of design. Discovery helps surface that fragmentation, but the strategic issue is ownership, not visibility alone. If no one can say which policy layer is authoritative, the organisation will keep producing contradictory decisions across SASE, application, and data controls. The practitioner conclusion is to treat policy source-of-truth as a governance decision, not an implementation detail.

Identity-aware SASE pushes authorization closer to runtime decisions, which raises the bar for consistency. The more dynamic the decision, the more damage comes from stale policy, duplicated rules, or mismatched enforcement points. This is where Zero Trust Architecture and authorization governance intersect in practice: continuous verification only helps if the entitlements being verified are the same ones being enforced. The practitioner conclusion is to validate the full decision chain, from policy source to token to edge.

From our research library:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs — Key Challenges and Risks

What this signals

Identity-aware SASE is becoming a governance problem as much as a network problem. The more organizations distribute authorization across edge services, the more they need clear source-of-truth policy ownership and consistent entitlement semantics, or access decisions will diverge faster than teams can reconcile them.

Authorization drift: when policy intent, token content, and enforcement logic no longer carry the same meaning, teams lose confidence in every access decision that follows. That makes policy lifecycle control and recertification more important, not less, because drift is usually introduced by accumulated exceptions rather than by one obvious failure.

For practitioners, the next step is to treat SASE policy orchestration as part of IAM governance, not as a point integration project. The same discipline that governs authorization models in applications now has to extend to the edge, where tokens and enforcement points can quietly redefine access.

For practitioners

• Define one authorization source of truth Assign ownership for policy decisions before distributing them across SASE, application, and data enforcement points. Document which system issues the authoritative entitlement set and which systems only enforce it.
• Audit token claims for entitlement fidelity Inspect whether the claims added during token enrichment match the intended policy outcome, especially for read-only or fine-grained access. Validate the full claim set, not just the allow or deny result.
• Inventory existing access policies before orchestration Catalogue native policies already present in SASE and adjacent tools, then identify duplicates, overrides, and orphaned rules. Remove ambiguity before pushing central policy into the environment.
• Test enforcement consistency across layers Use representative access requests to confirm that identity provider decisions, enriched tokens, and downstream enforcement all produce the same outcome. Focus on cases where access should be narrowed rather than broadly granted.

Key takeaways

• SASE access control becomes unreliable when policy decisions, token enrichment, and enforcement points do not share the same authorization model.
• Policy discovery helps expose hidden access rules, but governance still has to decide which layer is authoritative and which layers only enforce.
• The operational test is consistency across the full decision chain, because orchestration without alignment simply moves policy drift into a more distributed environment.

Key terms

• Policy Orchestration: Policy orchestration is the coordination layer that ensures identity rules are applied consistently across different platforms and control planes. It matters when each cloud or system uses different primitives, because the challenge becomes preserving policy meaning during translation and enforcement, not just storing the rule centrally.
• Token Enrichment: Token enrichment is the practice of adding useful identity and context claims to a token so downstream systems can make faster, local decisions. It is only effective when the added data is stable enough for authorization and limited enough to avoid stale or bloated tokens.
• Authoritative Policy Source: The system or control plane that defines what access should exist for a role, person, or account. In a mature identity programme, downstream systems consume this policy and reconcile against it rather than maintaining their own separate version of entitlement truth.

What's in the full article

PlainID's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step explanation of the Zscaler authorizer workflow and how the policy handoff occurs
• Product-specific integration sequence showing how PlainID discovers native Zscaler policies and enriches access tokens
• Examples of dynamic, fine-grained access control decisions applied to critical applications
• Webinar and product-sheet details that expand on policy orchestration use cases

👉 PlainID's full article shows the orchestration flow, token enrichment, and policy discovery steps in more detail.

Deepen your knowledge

NHI governance, identity lifecycle management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.