A valid session from a risky device
The account is authenticated, but a mandatory protection signal has failed or become stale. Policy evaluates that device state separately before granting the requested resource.
DEVICE TRUST
Know which device is requesting access and whether its evidence is still trustworthy.
Device Trust keeps user identity, device identity, posture evidence, and resource policy separate. A valid sign-in does not turn an unknown, stale, or compromised device into a trusted device.
System role: Oten Endpoint + Access Control Plane
Evaluation depends on: Requires enrollment, baseline posture evidence, explainable Health Score inputs, and resource-aware policy assignment.
IDENTITYUser + DeviceBound separately
EVIDENCEPosture + IntegrityFreshness known
POLICYMandatory gatesNo false pass
STATEVerified · Restricted · BlockedResource-aware
OPERATING SCENARIOS
Device trust matters when authentication is no longer enough.
A lost, stolen, or reimaged endpoint
Credentials may still exist after physical control or device ownership changes. Device identity can be revoked without treating every credential as the same object.
Different resources need different assurance
Payroll, source control, and production can require different evidence freshness, identity assurance, and mandatory device conditions.
An evidence provider is unreachable
Provider failure remains Unknown or Stale. It does not silently inherit a passing result from another provider or an old observation.
An offline device reaches its lease boundary
Only signed last-known-good authority can continue within its bounded lease. Expiry cannot be extended by local clock rollback or a process restart.
A user needs a safe path back
The experience identifies the affected resource, failed condition, last observation, and approved remediation channel without exposing sensitive detection detail.
Identity and posture become qualified policy inputs.
Register
An administrator or user starts enrollment through an approved organizational policy.
Bind
The Agent creates or uses a device key protected by the platform trust store or hardware when supported.
Verify
The Control Plane validates enrollment evidence, organization binding, and device ownership.
Observe
The Agent collects only posture evidence authorized by policy.
Evaluate
Checks produce explicit results, freshness, and reason codes; unknown evidence never becomes a pass.
Enforce
ZTNA, Gateway, and PAM policies can require the resulting device trust state.
Recover or revoke
Users receive remediation guidance; administrators can quarantine or revoke the device.
Posture evidence remains specific, attributable, and fresh.
Platform integrity
Secure Boot, TPM or Secure Enclave availability, supported OS state, and Agent release integrity.
Patch and configuration
OS version, critical updates, screen lock, firewall, and required local security configuration.
Data protection
Full-disk encryption and the precise required versus observed state for the platform.
Host protection
Anti-malware or EDR state, evidence provider, timestamp, and subscription or entitlement health.
Ownership and identity
Enrollment state, organization binding, device key or certificate, and management status.
Risk events
Qualified EDR, tamper, anomalous behavior, or administrator quarantine signals and their policy effect.
Trust state is more than a green or red indicator.
Verified
Current evidence satisfies the policy required for the requested resource.
Warning
A noncritical issue or bounded grace period is active, with a deadline and remediation path.
Restricted
Some resources remain available, while resources requiring failed conditions are denied.
Hard blocked
A mandatory gate fails for the requested resource; the UI explains the safe reason and next action.
Quarantined
Security or administrator response isolates business access while preserving approved management channels.
Stale
Evidence is older than policy allows; last observation time and offline behavior remain visible.
Trust remains explicit when evidence or identity changes.
- Hardware-backed storage is unavailable or does not provide equivalent assurance on the platform.
- Device time is skewed or rolled back and cannot extend policy or lease validity.
- A posture provider is unavailable, producing Unknown or Stale rather than Pass.
- A device is reimaged, dual-boots, changes owner, or moves between organizations.
- The Agent remains offline beyond its signed policy or evidence lease.
- An enrollment token or Setup Key is revoked independently from an already-enrolled node.
- A lost or stolen device is quarantined or revoked through explicit device identity state.
REMEDIATION
Restriction preserves the path required for recovery.
Explain
Show the affected resource, safe reason code, evidence source, last observation, and policy owner without exposing sensitive detection data.
Preserve
Quarantine can retain approved management, update, support, and remediation channels while removing business-resource access.
Re-evaluate
Access returns only after fresh qualified evidence produces a new policy decision and the required enforcement points confirm the outcome.
MACOS AUTHORIZATION BOUNDARY
Apple remains the password-verification authority.
On managed macOS configurations that add desktop MFA, Oten does not replace the macOS password verifier or store the user's password. Apple's builtin:authenticate mechanism remains responsible for local password verification. Oten adds a separate, policy-controlled authorization decision through split AuthDevice mechanisms and ogc-core.
Render the challenge
The non-privileged OGCAuthDeviceUI mechanism renders bounded login, MFA, or recovery input. It does not connect to the root-private Core service or evaluate policy.
Bridge the transaction
The privileged OGCAuthDevicePrivileged mechanism validates the authorization context and is the only mechanism that communicates with the dedicated ogc-core AuthDevice service.
Decide in Core
ogc-core evaluates signed policy, verifies online or offline recovery proof, consumes recovery credentials durably before allow, and returns an explicit result.
Preserve platform boundaries
FileVault pre-boot, local password verification, Platform SSO, and the Oten MFA decision remain distinct responsibilities. Password synchronization is a deployment choice, not a universal device-trust invariant.
FAILURE AND RECOVERY
Core-unreachable behavior is signed, bounded, and auditable.
When ogc-core cannot answer before the authorization deadline, the privileged mechanism applies only the signed installation-time emergency directive for that device and authorization right.
Strict deny
The authorization transaction is denied. The UI cannot choose a more permissive result and no cached dynamic policy is evaluated inside the plugin.
Audited emergency bypass
A degraded transaction can proceed only when the signed directive permits that exact scope and an append-only emergency audit record is durable before allow.
Invalid recovery path
A missing or invalid directive, corrupt or full audit spool, or an out-of-scope authorization right results in deny. The system never presents emergency bypass as successful MFA.
Reconciliation
After Core recovery, ogc-core reconciles and uploads emergency records, marks the bypass as degraded evidence, and triggers the required policy re-evaluation.
FAQ
Questions security and platform teams ask first.
Does every platform provide the same hardware-backed guarantee?
No. Oten can claim non-exportable, hardware-backed device keys only for the platforms, enrollment modes, and evidence paths that have been verified. Other platforms must show their actual storage and assurance state.
Does Health Score decide access by itself?
No. Health Score summarizes posture and risk with explainable contributing evidence. Resource policy and mandatory gates remain authoritative, including revocation, expired authority, failed critical posture, and confirmed security verdicts.
What happens when a device is offline?
A device may preserve only qualified, signed last-known-good authority within bounded policy and evidence leases. The UI must show last synchronization, expiry, and the current enforcement mode. It cannot invent new authority while orphaned.
Next in Oten Access
Continue the technical evaluation.
Make device evidence part of every sensitive access decision.
See how Oten Endpoint qualifies evidence and how the Access Control Plane uses it without overstating platform assurance.