A foundational security policy sets the non-negotiable conditions for access across an organization. It is evaluated for every request, before service-specific permissions can matter. Typical requirements include strong authentication, a secure device, and restrictions on sensitive actions. In a zero-trust architecture, authentication establishes who or what is requesting access; foundational policy evaluates whether that request meets the organization’s baseline conditions. section 15.2 section 15.3.1
Block access from an unmanaged device
A policy can leave principal, action, and resource unrestricted so that it applies universally. This Cedar rule forbids a request unless the device posture score meets the required threshold and multifactor authentication (MFA) was performed: forbid(principal, action, resource) unless { context.device.posture.score >= 80 && context.authn.mfa_performed == true }; This is a baseline guardrail, not a rule for a particular application. A report-viewing policy may permit access, but it cannot bypass the device and authentication requirements. section 15.3.1 section 15.3.4
Foundational policies differ from shared operational policies and application policies by scope and ownership. Security and identity teams own enterprise-wide requirements. Functional groups own shared rules that span selected systems or workflows, such as deployment or maintenance conditions. Product teams own service-specific authorization logic. The policy engine gathers the relevant policies into one effective set and makes a unified decision for the request. section 15.3.4 section 15.3
Figure 15.3 Zero-trust authorization is based on layered policies. Foundational security policies define enterprise-wide requirements. Shared operational policies capture rules owned by functional groups and applied across multiple systems or workflows. Application policies define service-specific authorization logic. These layers differ in scope and ownership but are evaluated together to produce a unified authorization decision.
The layered-policy diagram shows how enterprise-wide, cross-system, and service-specific rules retain separate ownership while contributing to one authorization decision. section 15.3
Layering only protects the baseline when conflicts resolve predictably. Under forbid-overrides-permit semantics, a foundational forbid defeats an application-level permit. This prevents a locally permissive rule from weakening an organization-wide security requirement and lets teams distribute policy ownership without fragmenting enforcement. section 15.3.4 section 15.7
Treat foundational-policy changes as cross-system changes:
- Test a proposed requirement against representative requests from multiple systems, not only against the policy in isolation. section 15.4
- Include missing device-posture signals, expired authentication sessions, and conflicting operational conditions in layered-policy tests. section 15.4
- Confirm that the combined decision remains correct after foundational, shared operational, and application policies are evaluated together. section 15.4
Because these policies travel with every access request, they can expose gaps in operational readiness. Requiring managed devices, for example, may reveal tools still used from unmanaged laptops and force device-enrollment work. Clear baseline requirements therefore connect authorization decisions to identity quality, device management, auditability, and organizational governance. section 15.3.1 section 15.7
