Learning outcomes
- Separate device identity, ownership, management, and health claims.
- Trace device evidence from its source to the authorization decision.
- Set freshness, failure, and revocation behavior for each signal.
- Test copied identity, stale posture, unavailable source, and unmanaged device cases.
System and boundaries
A device identity names or cryptographically identifies a device or device-held key. Ownership states who controls or is responsible for it. Management state records enrollment in an endpoint system. Posture describes selected current properties, such as operating-system version, disk encryption, screen lock, or endpoint-agent status.
These claims have different authorities and lifetimes. A certificate can identify a key without proving current health. A healthy endpoint signal can come from an unmanaged device unless the signal is bound to a managed identity.
Request and decision flow
Map enrollment, key creation, certificate or identifier issuance, endpoint measurement, evidence signing, transport, validation, policy evaluation, caching, and revocation. State which source owns each fact and how the evidence binds to the device and user session.
At the decision point, keep user authentication, device identity, posture, resource, action, and request context separate. A policy can require several of them, but one should not be used as an unsupported substitute for another.
Failure domains
Test a copied or exported device credential. Test a managed device after it becomes noncompliant. Test stale cached posture. Test the posture source during outage. Test a valid device used by the wrong user and a valid user on the wrong device. Test retirement, re-enrollment, key rotation, and loss.
Shared endpoint, directory, and policy services can fail together. State whether access denies, uses bounded cached evidence, or allows a narrow emergency path for each resource class.
Design tradeoffs and residual risk
Fresh posture reduces stale decisions but adds latency and dependency risk. Device-bound keys improve identification but need recovery and replacement. Detailed posture can improve decisions while increasing privacy and device fingerprinting exposure. Managed status cannot prove that a device is free of compromise.
Pomerium boundary
Pomerium can evaluate documented device identity and posture criteria as part of route policy. The operator owns device enrollment, endpoint evidence quality, source availability, freshness settings, and response to device loss or noncompliance. The application still owns permissions for its actions.
Exercise
Choose one device-aware route. Create an evidence table with user identity, device identity, ownership, management, health, source, collection time, maximum age, cache, failure result, and revocation action.
Run one stale-posture test and one unavailable-source test. Record how long an already authenticated device can continue to act after it becomes noncompliant.
Evaluation checklist
- Are device identity, ownership, management, and posture separate claims?
- Is each signal bound to the intended device, user session, source, and time?
- Can a key or posture result be copied or replayed?
- Is stale and unavailable evidence behavior explicit for each resource class?
- Are loss, retirement, re-enrollment, and key rotation tested?
- Does the policy avoid collecting device data that it does not use?
Next learning unit
Continuous Verification
Continuous verification means that a system continues to evaluate authorization during a session instead of treating the initial login as permanent trust.
