In today’s IT landscape, “Identity is the new perimeter” is no longer just a slogan, but the foundation of a modern Zero Trust security strategy. Read also our blog post on Zero Trust & IAM: https://incyber.consulteer.com/de/insights/zero-trust-iam
Yet while authentication (SSO, MFA, passkeys) is largely under control and widely standardized (SAML / OAuth / OpenID Connect), the subsequent authorization often resembles a patchwork of proprietary logic and outdated models.
Authentication (AuthN) and Authorization (AuthZ) – simply explained
You visit your neighbor and knock on his door.
He looks through the peephole and recognizes you (authentication).
He opens the door and lets you in.
You enter the apartment and talk to him. Gradually, you feel comfortable and sit down on the sofa. He has no objection (you are authorized).
You even use his bathroom (still authorized).
After a while, you get hungry and try to open his fridge to see what’s inside. He stops you and tells you that you are not allowed to do that (not authorized).
In this first part of our blog series together with our partner cidaas, we analyze why traditional IAM architectures have a fundamental authorization problem and why AuthZEN is the necessary standard to implement a true Zero Trust Architecture (ZTA) according to global standards such as NIST SP 800-207.
The Core Problem: When Authorization Becomes the Bottleneck
Traditional approaches such as Role-Based Access Control (RBAC) reach their limits in dynamic cloud environments.
The problem: Authorization logic today is often an architectural obstacle. In legacy applications, it is usually deeply embedded in the source code, while in heterogeneous system landscapes, attempts are made to force modern requirements into rigid, centralized directory structures such as Active Directory (AD).
Even in lift-and-shift cloud migrations, monolithic security concepts are often carried over unchanged. The result is a rigid access model that cannot reflect either the dynamics of microservices or the granular requirements of modern API ecosystems and hybrid cloud models.
This inevitably leads to challenges such as:
Role explosion: Analysts such as Gartner have observed for years that organizations struggle under the burden of thousands of technical roles that are nearly impossible to audit manually.
Lack of contextual intelligence: RBAC only recognizes the state “user has role X.” Whether access occurs from an insecure public Wi-Fi network or at an unusual time is not taken into account.
The necessary step to address these challenges is the transition to dynamic access control using Attribute-Based Access Control (ABAC) or Policy-Based Access Control (PBAC). Here, access decisions are made in real time based on attributes (subject, resource, action, environment, etc.) or context-dependent policies (business rules, identity, user attributes, roles, corporate policies, or external factors).
Our partner cidaas has published an insightful article on this topic.
The Architectural Shift: Why Zero Trust enforces the Decoupling of Authorization
In a traditional security architecture, the principle was: “Trust the internal network.” Once authenticated, a user could often move freely within their assigned roles.
A modern Zero Trust Architecture (ZTA), as defined in NIST SP 800-207, breaks radically with this concept. The core principle is: No subject and no asset is implicitly trusted. Every single request must be authorized dynamically and in context.
To achieve this level of security, a fundamental decoupling of authorization logic from the application itself is essential. This requires three key architectural transformations:
A. Externalization: Separation of Policy and Application Code
In traditional systems, the logic (“Is user A allowed to edit resource B?”) is often hardcoded directly into the application. This creates significant problems:
Lack of transparency: Neither IT security teams nor auditors can see which rules are actually active in the code.
Lack of agility: Any change to a business rule (e.g. new compliance requirements) requires code changes, testing, and redeployment of the entire application.
Inconsistency: In microservices architectures, authorization rules tend to diverge across different services.
The solution: Moving decision logic into an external layer. The application becomes “dumb” with regard to rules; it simply requests an access decision and enforces the result.
B. Introduction of the PDP/PEP Model
Decoupling is operationalized through the strict separation of decision and enforcement, as described in the NIST Zero Trust reference model:
Policy Decision Point (PDP): The central “brain.” This is where policies reside. The PDP evaluates requests in a neutral manner and makes a binary decision (permit/deny) or returns additional conditions.
Policy Enforcement Point (PEP): The “guard.” It sits directly in the data path (e.g. as an API gateway, a sidecar in a service mesh, or middleware). The PEP intercepts the request, queries the PDP, and enforces the result.
C. Context-Based Dynamics Instead of Static Privileges
A true Zero Trust model does not rely solely on identity for decisions, but incorporates real-time data from so-called Policy Information Points (PIP). An authorization decision only becomes intelligent through context:
Identity & device: Is the user verified via MFA and is the device compliant?
Environment: Is access happening during normal working hours or from a high-risk location?
Threat level: Has the SOC currently flagged this user with an elevated risk score?
This dynamic can no longer be captured using static roles (RBAC). Only through decoupling and standardization—which is precisely where AuthZEN comes in—can these complex signals be processed into a secure decision in milliseconds.
AuthZEN: Standardizing of the Authorization Layer
Until now, the broad adoption of PBAC has been hindered by a lack of interoperability. Each policy engine spoke its own language. This is where the OpenID Foundation comes in with the AuthZEN Working Group.
AuthZEN is not a new IAM feature, but defines a standardized interface (API) for authorization decisions in modern Zero Trust architectures. The primary goal of this authorization API is interoperability.
AuthZEN is not a new IAM feature, but rather defines a standardized interface (API) for authorization decisions in modern Zero Trust architectures.
The primary goal of this authorization API is interoperability. The interface acts as the link between the Policy Decision Point (e.g., IAM system) and the Policy Enforcement Point (e.g., app/service), enabling them to communicate without either component needing to know the other’s internal details.
A simplified authorization process with AuthZEN looks as follows.
Request: Your application (PEP) creates a JSON payload and transmits the subject (who), the action (operation), the resource (target), and the context (environmental data).
{ "subject": { "id": "user-99", "attributes": { "risk_score": "low" } }, "action": { "name": "delete_record" }, "resource": { "type": "financial_report", "id": "2026-q1" }, "context": { "mfa_age": 300 }}
Evaluation: The application sends this payload to the PDP. The PDP evaluates the request based on its configured policies (e.g. OpenFGA, OPA, etc.).
Decision: The PDP returns a JSON response containing a boolean decision (allow or deny) and optional information (context regarding the denial).
{ "decision": "allow"}
Through the standardization of this communication via the AuthZEN Authorization API 1.0, authorization finally becomes vendor-independent and centrally controllable.
Conclusion: AuthZEN is a strategic investment
We initially stated: “Identity is the new perimeter.” However, a modern security boundary is only as effective as its consistent enforcement. AuthZEN is the key building block to free authorization from application silos and transform it into a centrally controlled, auditable, and Zero Trust–ready infrastructure layer. It is the necessary architectural component to finally “complete” IAM and realize a true Zero Trust architecture as a future-proof security approach.
AuthZEN is, however, more than “just” a technical interface specification – it is a strategic tool for risk management and business agility:
Compliance & auditability: In regulated industries (e.g. under DORA or NIS2), organizations must be able to demonstrate why access was granted. By centralizing policies at the PDP, this becomes possible at the push of a button.
Developer productivity: Developers no longer need to implement authorization logic (hardcoding). They use standardized PEPs, reducing time-to-market for new features.
Resilience: Security policies can be changed globally and in real time (e.g. during an ongoing attack) without modifying a single line of code in applications.
Outlook for part two of this blog series
What does this look like in practice? In the second part of this series, our partner cidaas explains how AuthZEN can be integrated into existing IAM and application landscapes and which integration patterns have proven effective in practice.
