Platform integrity
Secure Boot, TPM or Secure Enclave availability, supported OS state, and Agent release integrity.
DEVICE TRUST
Know which device is requesting access and whether its evidence is still trustworthy.
Device Trust binds user identity to a distinct device identity, qualifies posture evidence, and exposes a resource-aware trust state to policy. It is an access input, not a passive compliance report.
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
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.
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.
ON MACOS · PROFILE B
Signing in to the Mac is the first device-trust touchpoint.
For groups with Custom Login UI and Desktop MFA enabled, Platform SSO is the authentication backbone and the OGC Login Plugin owns the UI and the MFA gate. Every screen maps to an exact mechanism in the authorization pipeline: FileVault (EFI) → OGCLoginPlugin:ui → builtin:authenticate → OGCLoginPlugin:mfa → session. Four platform components cooperate behind every screen.
Oten Access
The unified access experience: one Oten ID for the computer, internal apps, and internal networks, with device trust, posture checks, and Zero Trust policy running continuously in the background.
Oten IdP
The identity provider. It verifies the Oten ID and keeps the local Mac password in sync with the identity password through Platform SSO.
Oten Pass
The mobile authenticator. Push approvals and TOTP codes, including offline codes that need no Internet connection on either device.
Oten Endpoint
The on-device agent. It holds device trust, runs posture checks, and renders the login plugin screens.
ONE TIME ONLY
Onboarding happens once, then never repeats.
IT enrolls the Mac into OGC MDM. The Platform SSO payload and Login Plugin deploy automatically; the user installs nothing. On first login, Platform SSO registration asks the user to authenticate with Oten IdP and syncs the password down to the local account and FileVault.
MDM enroll
IT enrolls the Mac and the Extensible SSO payload is deployed through the approved management channel.
Platform SSO registration
Inside the first session, the user authenticates with Oten IdP and the local account password is bound to the Oten ID password.
Enroll MFA
The user scans a QR with Oten Pass to enable push approvals and offline TOTP as second factors.
AUTHORIZATION PIPELINE
One credential moves through a hardened pipeline.
Each stage is a distinct mechanism with its own boundary. The local password equals the Oten ID password, and the pipeline hands off between Apple-native and Oten-owned stages without exposing the credential outside its stage.
FileVault unlock (EFI)
Power-on shows Apple's default FileVault pre-boot screen taking the local password. No plugin and no network reach this stage; it is a hard boundary nothing can customize.
Branded login window
The OGC Login Plugin replaces the default UI with company branding and Oten ID plus password fields. The daemon verifies credentials against Oten IdP or the offline cache, then unlocks the local session.
Desktop MFA
Acting as Relying Party, the daemon calls Oten Pass push-auth/request. The user reviews the request on the phone and confirms with Face ID; the Mac continues automatically within one to two seconds.
- High-security groups override DisableFDEAutoLogin so the custom UI appears on every boot and the password is entered twice.
- Push not preferred: “Use code instead” switches to a six-digit TOTP from Oten Pass. FIDO2 security key is a fast-follow.
- The MFA challenge is signed by the device key on Oten Pass with replay protection (nonce) and auto-cancels after two minutes.
- Standard Shut Down, Restart, and Help controls remain, plus a policy-controlled Local login break-glass option.
Unlock during the day takes just the password.
Inside a grace period (default twelve hours), unlocking is identical to stock macOS: password only, no MFA. The daemon keeps a last-MFA timestamp per user and re-prompts for MFA once the grace period expires.
- Within grace: password unlock only, the same as standard macOS.
- Past grace (overnight, left behind): password plus MFA, as in the machine-login flow.
- Break-glass convenience paths such as Touch ID and Apple Watch unlock are disabled when MFA is enforced at the screensaver.
CONTINUOUS VERIFICATION
Access follows trust in seconds, not all day.
Morning sign-in is not an all-day ticket. The Agent keeps a posture gate running in the background, and the session is bound to the identity token and the device key, never to an IP address. If posture slips or Endpoint Defense detects compromise, the trust tier drops and every door opened at sign-in closes at once.
Internal apps open like public ones
Right after sign-in, internal addresses (Git, ERP, a staging database) simply load. No VPN button, no second login. Each connection is its own encrypted tunnel, and the user reaches only what policy allows; the rest of the infrastructure is invisible.
Anywhere feels the same
Close the lid at the office, open it at a café. Tunnels re-negotiate automatically (direct P2P first, TURN relay as fallback), and the local network sees only encrypted noise.
Trust can drop mid-session
The trust tier moves FULL → PARTIAL → BLOCKED. Tunnels are cut and Oten Gateway refuses the device, with a clear message and a remediation step rather than a cryptic error.
OFFLINE & FAIL-SAFE
Nobody gets locked out, whether offline or on failure.
The login experience degrades predictably. Offline, credentials verify against a local cache within its TTL and MFA falls back to offline TOTP. On any system failure, the experience falls back to Apple's native loginwindow while device trust records the consequence.
Offline
The custom UI still renders from cached assets. Credentials verify against the offline cache within TTL; push is unavailable, so MFA switches to a six-digit offline TOTP from Oten Pass. The code is replay-proof, using a ±1 step window and last-used counter, with the secret sealed in the System Keychain.
Recovery
Past the offline TTL, or with all factors lost: a one-time Recovery PIN from IT (two-minute validity) or the policy-controlled break-glass local account.
Fail-safe
Any plugin or daemon failure degrades to Apple's native loginwindow. Platform SSO still verifies silently and the user signs in with their password like on any Mac. Nobody is locked out.
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.