A policy definition states what is permitted, prohibited, or required under specified conditions. It may describe accepted evidence, authorised actors, thresholds, jurisdictions, authentication levels, time windows, or actions that must follow. Runtime enforcement is the operational application of that policy when a real action is attempted.

The distinction matters because a documented rule does not control anything by itself. At runtime, the system must assemble the relevant facts, evaluate the active policy, return an explicit decision, and ensure that the decision changes what the application, machine, access point, or workflow is allowed to do. A policy engine that returns DENY but is not connected to a control point that stops the action is providing advice, not enforcement.

A complete model therefore separates four functions: policy governance defines and approves the rule; the Policy Decision Point evaluates it; the Policy Enforcement Point applies the result; and the audit layer records what was evaluated and what happened. Sphereon’s architecture is designed to connect these functions so that policy becomes an active control rather than a statement of intent.

Authentication establishes who or what is making a request and, where applicable, the assurance level of that authentication. Role-based access control, or RBAC, assigns broad permissions to roles such as administrator, operator, supplier, or auditor. Runtime authorization evaluates whether this specific actor may perform this specific action on this specific resource under the current conditions.

A role can be one policy input, but it is rarely sufficient for a high-assurance decision. The same operator may be allowed to view a record but not export it, update a tenant they administer but not another tenant, or start a machine only when a current training credential, site induction, and task-specific authorisation are present. A sensitive action may also require step-up authentication even though the user is already logged in.

Sphereon’s EDK normalises authorization requests around the subject, action, resource, and context. This supports role-based, attribute-based, tenant-specific, time-based, jurisdictional, and evidence-based rules without scattering separate access checks throughout application code.

A decision made at login, onboarding, or credential presentation can become stale before the protected action occurs. Roles change, credentials expire or are revoked, mandates are withdrawn, sessions are compromised, policies are updated, and the operational context may differ from the context in which the user was first admitted.

Runtime evaluation places the control immediately before the action. The policy sees the actual operation, resource, tenant, timestamp, jurisdiction, authentication assurance, and other relevant conditions. If the result is DENY, the protected business logic should not execute. If stronger authentication is required, the system can return a step-up challenge before allowing the action.

This is particularly important for high-consequence actions such as signing, exporting sensitive information, issuing credentials, changing policy, entering a restricted area, or operating hazardous equipment. The earlier verification remains useful evidence, but it should not be treated as a permanent authorization for every later action.

A runtime authorization request should contain the minimum information needed to decide the action accurately. A common structure contains four elements:

• Subject: the person, organisation, workload, device, or agent requesting the action, including relevant roles, attributes, and delegated authority.
• Action: the operation being attempted, such as read, issue, sign, approve, export, enter, activate, or delete.
• Resource: the record, credential, key, tenant, machine, zone, document, or other object affected by the action.
• Context: decision-time facts such as tenant, session, timestamp, jurisdiction, authentication assurance, purpose, risk signal, and transaction conditions.

Where the action depends on external evidence, the policy may also need verified claims, issuer trust, credential status, scope, freshness, or semantic interpretation. These inputs should be normalised so that policies do not depend on channel-specific field names.

More data is not automatically better. Sphereon’s EDK documentation describes whitelisting selected token claims rather than forwarding the raw access token to the Policy Decision Point. The same data-minimisation principle should apply to credentials and contextual attributes: disclose what the decision requires, not everything the system happens to possess.

A Policy Decision Point, or PDP, evaluates a policy request and returns a decision. A Policy Enforcement Point, or PEP, sits in the execution path and applies that decision. The PDP answers whether the action is permitted. The PEP makes sure the protected action continues, is blocked, or requires an additional step.

Separating the two keeps authorization logic out of application code. Applications describe the actor, action, resource, and context; a dedicated policy engine evaluates the rule. Policies can then be updated, tested, reviewed, and audited independently from the business service. Sphereon’s EDK uses external PDPs through the OpenID AuthZEN model and can integrate with Cedarling, Open Policy Agent, or another compatible policy service.

The separation is only effective when the PEP cannot be bypassed. Every relevant execution path, including APIs, background jobs, administrative operations, and service-to-service commands, must pass through an appropriate enforcement point. Centralising policy while leaving unprotected alternate paths creates the appearance of control without reliable enforcement.

Verified evidence becomes useful for authorization only after its decision-relevant meaning has been established. The system may first validate format and cryptographic integrity, confirm holder or subject binding, resolve issuer trust, check expiry and revocation status, and determine the scope and meaning of the claims.

The relevant results are then transformed into policy inputs. A rule might require, for example, that the actor holds a current qualification from an accepted issuer, that the qualification covers the requested machine type, that the actor completed the induction for the specific site, and that the current authentication assurance is sufficient. The PDP evaluates those facts together with the action, resource, and context.

The PEP then applies the resulting PERMIT, DENY, or STEP_UP_REQUIRED outcome before the operational action occurs. Verification is therefore an input to authorization, not a substitute for it. A technically valid credential can still produce a denial because it is out of scope, insufficient, presented in the wrong context, or inconsistent with another policy condition.

No. A clear permit or deny result remains essential because the enforcement point must know whether the protected action may execute. However, a useful authorization model can also identify actions that are permissible only after an additional condition has been satisfied.

Sphereon’s current EDK authorization model defines PERMIT, DENY, and STEP_UP_REQUIRED. Step-up means that the action is acceptable in principle, but the current authentication assurance is insufficient. The caller can complete stronger authentication, such as multi-factor authentication, and retry the request.

Broader business workflows may also use denial reasons or policy results to request additional evidence, route a case to human review, impose a time limit, or trigger another controlled process. Those follow-up steps should not blur the authorization result. The system should record the original decision, the unmet condition, the subsequent action, and any later re-evaluation. This keeps enforcement explicit while allowing the surrounding workflow to handle exceptions and remediation.

In a service-to-service architecture, an action may involve at least two principals: the end user on whose behalf the request is made and the workload or service that calls the protected operation. Authorizing only the user can allow a compromised or over-privileged service to perform actions it should never perform. Authorizing only the service can ignore the limits of the user’s authority.

Sphereon’s EDK supports dual-principal evaluation. In a strict model, both the user and the workload must be permitted. This reduces the risk of confused-deputy attacks and prevents a service from using its own technical access to exceed the authority delegated by the user. Other modes can support batch processes or service accounts where no end user exists, but those cases should be explicit rather than inferred.

The policy should therefore distinguish identity, role, workload capability, tenant scope, delegation, and the requested action. For AI agents and automated services, the same principle applies: the system must evaluate both what the actor was authorised to do and whether the executing workload is trusted to perform that action.

The same authoritative policy model can be applied across channels, but this does not mean that every channel sends an identical request. A wallet, procurement API, HR portal, QR reader, building access system, and machine controller expose different technical events and resource types. Each needs an adapter or enforcement point that maps its local event into the same governed concepts.

Consistency comes from shared definitions of the subject, evidence, action, resource, context, trust requirements, and policy consequence. A valid safety qualification should have the same meaning whether it arrives from a wallet, an HR system, or an API. The policy threshold should not change merely because the presentation channel changed.

Sphereon positions VDX and EDK as a common verification, policy, and audit layer across these channels. The practical requirement is that each channel uses the same authoritative semantic and policy definitions and records the same decision context. Otherwise, an organisation may centralise the policy engine while still retaining inconsistent local interpretations.

Policy changes should be treated as controlled production changes, not as informal configuration edits. Each policy should have an identifier, version, owner, approval status, effective period, test set, change rationale, and rollback path. Tests should cover intended permits, intended denials, boundary cases, tenant isolation, missing data, conflicting attributes, and failure conditions.

Sphereon’s EDK supports DISABLED, LOG_ONLY, and ENFORCED modes. LOG_ONLY evaluates the real policy but allows the command to continue, while recording what the decision would have been. This supports shadow testing against representative traffic before enforcement. It is important to recognise that LOG_ONLY is observation, not protection, because denied actions still execute.

A sound rollout compares the new policy with the current policy, investigates unexpected differences, obtains approval, activates the new version for a defined scope, and monitors both false denials and unintended permits. Historical decision records should continue to reference the policy version that was active when each decision was made.

The correct response depends on the consequence of an unauthorised action, but high-assurance systems should normally fail closed. If the PDP cannot produce a trustworthy decision, the protected action is denied or the caller receives a temporary service failure. Allowing the action by default converts an infrastructure outage into a security bypass.

Sphereon’s EDK documents circuit-breaker, cache, and fallback behaviour. The default fallback is DENY. A FAIL option can propagate an infrastructure error so the caller can retry or present an availability message. An ALLOW fallback is available but is described as appropriate only for development. Production use would require a deliberate and well-documented risk decision.

An unavailable PDP should not be recorded as though the policy evaluated the request and returned a normal denial. Operational failure and policy denial are different events. The record should distinguish them so that users, operators, auditors, and incident responders can understand whether access was refused by policy or because the authorization service could not reach a decision.

Caching can reduce latency and protect the PDP from excessive load, but it introduces a period in which a previous decision may be reused after relevant conditions have changed. Whether caching is safe depends on the volatility of the inputs and the consequence of a stale permit.

A cache key must distinguish every factor that can materially change the outcome, including the tenant, subject, action, resource, and any decision-relevant context. A short time-to-live may be appropriate for stable, low-risk permissions. High-risk decisions involving current credential status, authentication assurance, security signals, time windows, or rapidly changing authority may require immediate evaluation or explicit invalidation.

Sphereon’s EDK documentation describes configurable decision caching with keys that include tenant, subject, action, and resource, plus invalidation by subject or tenant. Deployments must assess whether additional contextual inputs require a narrower cache policy. Revocation, role changes, policy updates, compromised sessions, and shared security signals should invalidate affected cached decisions as quickly as the risk requires.

An exception should be represented as a separate governed action, not as an invisible bypass. The system should preserve the original policy result and record who requested the exception, who approved it, the reason, the evidence considered, the affected resource and action, the scope, the effective period, and any compensating controls.

Emergency or break-glass access should use a narrowly authorised policy path, stronger authentication, explicit purpose, limited duration, enhanced monitoring, and mandatory review. The override should not silently rewrite the original denial or make the user appear normally authorised. It should create an additional decision that can be examined independently.

Policy and configuration changes should be audited in the same way. Sphereon’s VDX security documentation describes authorization decisions and configuration changes as audit events. The deployment should link those events to the policy version and distributed trace for the affected action. This allows an organisation to distinguish routine authorization, approved exception handling, and unauthorised circumvention.