A condition is a contextual requirement that decides whether an otherwise relevant authorization policy applies. Authentication establishes who is requesting access; conditions answer whether access is appropriate now, from this device, on this network, for this resource, and under the surrounding circumstances. They prevent authorization from collapsing into a static role or allow-list check. section 4.3.1 section 4.6 section 4.0
In the PARC model, a request combines a principal, action, resource, and conditions. Conditions may draw on principal attributes, resource attributes, and environmental facts such as time, location, device trust, risk score, or workload identity. Because these facts can change between requests, conditions support dynamic access decisions. section 4.3.1 section 7.3 section 5.3
A policy condition commonly checks one or more of the following:
- Time or schedule, such as permitting report access only during approved working hours. section 4.4.1
- Device or network posture, such as requiring a company-managed device for deployment or document access. section 7.2.3 section 7.2.4
- Attributes and relationships, such as matching a requester’s department to a confidential document owner’s department, or confirming ownership. section 7.2.4 section 8.4.2
- Current external facts, such as professional licensure, clinic affiliation, and assignment to a patient care team. section 16.8.2
Conditions are distinct from policy scope. Scope identifies the principals, actions, and resources a rule addresses; condition logic further restricts the circumstances in which that rule takes effect. A complete policy contract therefore permits or forbids a principal to perform an action on a resource only when its conditions are true. section 7.2 section 7.2.3 section 7.2.4
After-hours report access
A project manager requests a team report at 9:17 p.m. from a registered company laptop on a home network. The request may satisfy role and device requirements, yet still be denied because the approved access window ends at 8 p.m. The policy decision point evaluates those contextual facts, retrieves needed attributes, returns the denial, and lets the application explain the restriction. section 4.4.1
In Cedar, conditions are optional Boolean expressions evaluated after policy scope matches the request. A matching policy can require facts such as managed-device status, on-call status, clearance, ownership, or department membership. Cedar evaluates matching scope and condition logic under a deny-overrides decision model. section 7.2.3 section 7.3 section 7.6
Figure 7.1 A complete Cedar policy showing effect (top box), scope (middle box), and conditions (bottom box)
This policy layout separates a permit effect and principal-action-resource scope from contextual checks for ownership and managed-device use. section 7.2.4
Reliable conditions depend on trustworthy, current context. Policy information can come from identity systems, device and session signals, resource metadata, or credential verification. Keeping enforcement, policy evaluation, policy management, and context retrieval separate makes decisions easier to change, explain, audit, and scale. section 4.7 section 8.4.2 section 4.4.1
