Remote identity provisioning can fail because macOS High Sierra ties FileVault control to a Secure Token that is granted through a local chain of trust. If users are created by directory tools instead of locally, they may never receive that token. The result is a governance gap where identity workflow and disk encryption policy no longer align.
Why local trust matters before FileVault can be enforced
In High Sierra, FileVault is not just a disk setting, it is part of a local trust path. The Secure Token that unlocks FileVault is granted through the first local user context that macOS can trust. If provisioning bypasses that path, the encryption policy may exist on paper while the effective unlock authority never lands on the account that needs it.
That makes remote provisioning risky in practice: it can create a gap between directory-driven account creation and the local authorization state that FileVault depends on. The result is not only a setup failure, but a governance failure, because the organisation believes a user has been onboarded into an encrypted workflow when the platform has not actually accepted that trust chain.
For teams comparing provisioning approaches, the important distinction is whether the process can establish the local state macOS expects, not whether the account appears in directory services. A remote workflow that only creates the directory identity may still leave disk unlock, recovery access, and first-login behaviour unresolved.
Where the workflow breaks and why that matters operationally
Remote identity provisioning usually breaks at the boundary between account presence and local privilege elevation. FileVault activation depends on a secure, local chain of trust, so any onboarding model that assumes directory membership alone is enough can leave the user unable to unlock the disk, or leave recovery steps dependent on manual intervention.
That risk is especially important when the onboarding sequence is automated. If the provisioning system creates users before the local macOS trust relationship exists, the account may never receive the token needed for FileVault control. In that case, encryption and access control drift apart: the device can still be encrypted, but the intended user workflow is no longer self-consistent.
For a deeper identity lifecycle view, the issue is the same class of failure discussed in IAM and IGA Basics and the Joiner-Mover-Leaver (JML) Guide: provisioning must align with the authority actually required on the endpoint, not just with directory state.
How to interpret the risk in a FileVault onboarding design
The main design question is whether the provisioning model preserves local macOS trust while still meeting central identity governance requirements. If it does not, the organisation can end up with inconsistent states across devices, where some users are fully able to unlock FileVault and others need exception handling, manual fixups, or one-off credential resets.
That inconsistency is more than an inconvenience. It complicates support, weakens assurance that encryption is enforceable at scale, and makes troubleshooting depend on endpoint-specific knowledge that the provisioning workflow should have encoded up front. It also means the control objective is being met indirectly rather than deterministically, which is a poor posture for any security workflow that depends on repeatable device enrolment.
Remote provisioning should therefore be judged by its effect on the full identity-to-device chain, not by whether the account exists centrally. If the onboarding process cannot reliably produce the local trust artefacts macOS requires, the workflow is not just fragile, it is architecturally misaligned with the control it is supposed to enable.
Risk and Threat Considerations
Remote provisioning creates exposure when organisations assume a centrally created account will automatically inherit the local trust needed for FileVault. The weakness is a governance and access-control mismatch: the identity may be valid in the directory, but the local token that governs disk unlock may never be issued.
Failure mechanism: Directory-based account creation bypasses the local trust path that grants the Secure Token, so FileVault access and recovery behaviour can fail even though the user appears provisioned.
Impact: Devices can be left in an inconsistent state, with encryption enabled but unlock authority missing, leading to onboarding failures, support escalations, and exception-driven administration.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Secure Token handling depends on managed credential lifecycle and issuance control. |
| IA-2 — Identification and Authentication (Organizational Users) | FileVault onboarding depends on authenticating the user through a trusted local identity path. | |
| Recommendation — Ensure token issuance and recovery steps are governed so FileVault access is not left to ad hoc handling. Require trusted user authentication before relying on FileVault-enabled access. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The issue is a control-alignment problem between provisioning and endpoint access enforcement. |
| Recommendation — Align access-control policy with the actual macOS trust path used to grant disk unlock authority. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The workflow needs consistent provisioning and revocation behaviour across accounts and devices. |
| Recommendation — Standardise account provisioning so endpoint access states are created and verified consistently. | ||
Practitioner Guidance
What to verify: Confirm that the onboarding sequence creates the local user state first, or otherwise explicitly establishes the token path macOS expects before you treat FileVault as operational. Do not rely on directory presence as evidence that unlock authority exists.
Decision rule: If the provisioning flow cannot prove that the Secure Token was granted, treat the endpoint as not fully enrolled and handle it as a remedial access state, not a successful standard join.
Practitioner takeaway: The key test is whether the workflow produces the local trust outcome FileVault needs, because a directory identity without that local state is only partially provisioned.
Related resources from NHI Mgmt Group
- Why do manual provisioning workflows create identity governance risk?
- When does zero touch provisioning create more risk than it reduces in identity workflows?
- Why do authentication bypass flaws combined with remote code execution create such high risk for identity and access systems?
- Why does low assurance in voice biometrics create risk for high-value identity workflows?
