A valid employee identity does not automatically make an access request trustworthy. An employee can authenticate successfully from a device that is unmanaged, out of date, compromised, or operating in an unexpected environment. Device posture is the current, context-dependent assessment of that device’s trustworthiness, used alongside identity and other signals when making an access decision. section 3.8 section 15.2
Posture is not a permanent label such as “trusted device.” It combines device-related attributes evaluated at the time of access. A policy can therefore distinguish a managed, compliant device with recent attestation from a device whose security information is missing or stale. section 3.8
A posture assessment commonly considers whether the device is:
- Managed by the organization, so its controls and compliance state can be assessed. section 3.8 section 13.3.3
- Compliant with required controls, such as an approved operating-system version, encryption, and screen lock. section 3.8
- Healthy, rather than jailbroken, rooted, or reporting malware. section 3.8
- Operating in an expected environment, including an appropriate network, geography, or time. section 3.8
- Recently attested, rather than represented by stale security information. section 3.8
Device posture complements authentication rather than replacing it. Authentication establishes evidence of who or what made a request; posture adds evidence about the device involved. In a zero-trust design, a request from a properly authenticated person can still be denied when the device fails a policy required for a sensitive resource. section 3.8 section 15.2
The signal is especially useful where static authorization alone is insufficient. Access based only on an access-control list (ACL) or role-based access control (RBAC) assignment cannot account for a device changing between compliant and noncompliant states. Attribute-Based Access Control (ABAC), Relationship-Based Access Control (ReBAC), and Policy-Based Access Control (PBAC) provide ways to evaluate such changing context, with added complexity. section 5.3
Employee administration versus customer access
An organization can require its employees to present both an OpenID Connect (OIDC) identity token and a signed posture token from a company-managed device. A Policy Enforcement Point (PEP) can use that context to require a compliant device for administration, support escalation, or cross-tenant work. The same requirement may not fit tenant customers using hardware the organization neither provisions nor manages; their access can instead rely on their identity provider and tenant-scoped authorization model. section 13.3.3
For posture to influence a decision consistently, it must reach the policy engine as trustworthy authorization context. The policy engine evaluates it with identity attributes, roles, relationships, environmental conditions, and operational signals such as on-call status; the PEP guarding the target resource enforces the result. Governance is required to keep these signals defined, validated, and current. section 15.1 section 15.2
Figure 15.1 Why the perimeter model fails in modern environments. In the traditional model (left), a firewall defined a clear boundary, and anything inside the perimeter was implicitly trusted. In modern environments (right), cloud services, mobile work, SaaS applications, and external collaborators eliminate meaningful boundaries.
Modern cloud services, mobile work, SaaS applications, and external collaborators weaken perimeter-based trust, making request-level context such as device posture more important. section 15.1
