macOS LAPS in GCC High: What Intune Admins Need to Know

Microsoft shipped macOS LAPS support in Intune in July 2025 — and for admins in GCC High, the first question was obvious: does it actually work in our tenant? Windows admins have had LAPS for years. Mac admins finally got it with service release 2507. But GCC High feature rollouts don’t follow the same timeline as commercial, and Microsoft’s documentation is silent on macOS LAPS availability in government clouds.

That’s the question this article answers.

What Is macOS LAPS?

Local Administrator Password Solution (LAPS) automatically rotates the local administrator account password on managed devices and stores it securely in Entra ID (or on-prem Active Directory for Windows). Admins retrieve the password through the Intune portal or Entra ID when they need it, and the password rotates again after use.

On macOS, LAPS works through Intune’s device management channel. The device must be running macOS 12 (Monterey) or later and enrolled via Automated Device Enrollment (ADE) — you can’t use LAPS on a Mac that was enrolled manually or through user-initiated enrollment. This is a hard requirement. And it only applies to new ADE enrollments. If your Macs are already enrolled, they’ll need to be wiped and re-enrolled through ADE to pick up LAPS.

Here’s how the two platforms compare:

	Windows LAPS	macOS LAPS
Password length	8–64 characters (configurable)	15 characters (fixed)
Complexity	Configurable (uppercase, lowercase, numbers, symbols)	Fixed: uppercase + lowercase + numbers + symbols
Passphrase support	Yes (Windows 11 24H2+)	No
Enrollment requirement	Any Intune enrollment	ADE only
Storage	Entra ID or on-prem AD	Entra ID
Default rotation	Configurable	Every 180 days (configurable 1–180)
Post-auth rotation	Yes	Yes
OS requirement	Windows 10/11	macOS 12+
GCC High	Confirmed available	Not explicitly confirmed

The fixed 15-character password with full complexity is actually fine for most compliance frameworks — it exceeds NIST minimums. The lack of configurability is more of an annoyance than a security issue.

One platform quirk worth noting: the LAPS-managed local admin account on macOS does not receive a Secure Token due to platform limitations. The first user account that signs in gets the Secure Token instead. This is by design and doesn’t affect LAPS functionality, but it’s worth understanding if you’re troubleshooting FileVault or other Secure Token-dependent features.

The ADE re-enrollment requirement is the real operational constraint. If your Macs weren’t enrolled through Apple Business Manager and ADE — or were enrolled before you configured LAPS — they’ll need to be wiped and re-enrolled. For a fleet of five machines, that’s an afternoon. For fifty, that’s a project.

The GCC High Question

This is where it gets complicated.

Microsoft’s documentation is clear that Windows LAPS is available in GCC, GCC High, and DoD tenants. The Intune government service description lists LAPS support for Windows. For macOS LAPS, the documentation is silent.

That silence is the problem.

GCC High has always lagged commercial Intune on feature availability — it’s one of the key tradeoffs when choosing between GCC and GCC High. Microsoft’s pattern is consistent: features ship to commercial first, then GCC, then GCC High, then DoD. The gap is usually weeks to months, occasionally longer for features that require backend changes to the isolated government infrastructure.

As of this writing, macOS LAPS may or may not be available in your GCC High tenant. Microsoft hasn’t published an explicit confirmation or denial. The feature might be there — it might not. It depends on when your tenant’s service ring picks it up.

What to do right now:

1. Check your tenant. Go to Devices > macOS > Configuration > Create and look for LAPS settings. If they’re there, you’re good.
2. Contact your Microsoft TAM or FastTrack rep. They can confirm feature availability for your specific tenant ring.
3. Test in a dev tenant if you have one. Don’t experiment in production with privileged account management.
4. Monitor the Microsoft 365 roadmap and the What’s New in Intune page. Microsoft typically announces GCC High feature availability there.

Why LAPS Matters for CMMC

If you’re in GCC High, you’re almost certainly pursuing or maintaining CMMC Level 2 compliance. LAPS directly supports several NIST 800-171 controls that assessors look at closely.

3.1.5 — Least Privilege. LAPS ensures local admin passwords are unique per device and not known to end users. Administrators retrieve the password only when needed through a controlled, auditable process. This is textbook least privilege for local accounts.

3.1.6 — Use of Non-Privileged Accounts. By rotating the local admin password and storing it centrally, LAPS makes it impractical for users to use local admin accounts for daily work. They’re forced to use their standard domain accounts, which is exactly what this control requires.

3.1.7 — Prevent Non-Privileged Users from Executing Privileged Functions. When local admin passwords are randomized and not known to users, they can’t elevate to admin without going through proper channels. This supports enforcement of the privileged function boundary — and it’s especially important on endpoints where personal device policies blur the line between user and admin access.

3.5.7 — Password Complexity and Rotation (from 800-171A). LAPS enforces password complexity (uppercase, lowercase, numbers, symbols) and automated rotation. On macOS, the 15-character fixed password exceeds most complexity requirements. On Windows, you can configure length up to 64 characters.

3.5.3 — Multifactor Authentication. LAPS doesn’t replace MFA — it complements it. The key is how you protect the retrieval process. When LAPS password retrieval requires MFA through Conditional Access and PIM, you’ve created a layered authentication model for privileged access.

The community view on LAPS is generally positive. C3PAOs understand it, they’ve seen it in dozens of assessments, and it’s a recognized best practice. What they care about isn’t whether you’re using LAPS — it’s how you’ve implemented the controls around it.

Making macOS LAPS Assessment-Ready in Intune

Deploying LAPS is step one. Making it pass an assessment is step two. Here’s what separates a good LAPS deployment from one that satisfies an assessor.

Create a custom RBAC role for retrieval. Here’s a detail that trips people up: the “Rotate macOS admin password” and “View macOS admin password” permissions are not included in any built-in Intune role. You need to create a custom Intune role with those specific permissions. Then use Privileged Identity Management (PIM) to require just-in-time activation of that role. Require MFA for the activation. Don’t give anyone standing access to retrieve LAPS passwords — scope it to only the people who genuinely need local admin access.

Audit everything. Every LAPS password retrieval generates an audit event in Entra ID: “Recover device local administrator password.” Make sure your audit log retention is sufficient (90 days minimum, ideally longer). Forward these logs to your SIEM — whether that’s Microsoft Sentinel, Splunk, or whatever you’re running. Non-repudiation matters.

Enable post-authentication rotation. Configure LAPS to rotate the password after it’s been used. This ensures a retrieved password has a short effective lifespan, reducing the window of exposure if someone writes it on a sticky note (they will).

Disable remote logon with local accounts. If someone retrieves a LAPS password, they should have to be physically at the machine or use a management tool that enforces identity verification. Block network logon and remote desktop for local accounts so that the LAPS password can’t be used to move laterally.

Document it. Your System Security Plan should describe the LAPS implementation, including which controls it satisfies, how retrieval is restricted, and how audit logs are retained. Assessors look for this documentation.

Workarounds If macOS LAPS Isn’t in Your GCC High Tenant Yet

If you check your tenant and macOS LAPS isn’t available, you’re not stuck. Defense contractors have been solving this problem since before Microsoft shipped native support. Here are the proven approaches.

Azure Key Vault Approach

This is the most common workaround in the community and it works well in GCC High because Azure Key Vault is fully available in Azure Government.

The concept is straightforward:

1. A shell script runs on the Mac via an Intune-deployed LaunchDaemon (or a custom compliance script)
2. The script generates a random password meeting your complexity requirements
3. It changes the local admin account password using dscl or sysadminctl
4. It stores the new password in Azure Key Vault using the device’s managed identity or a service principal with a certificate
5. The script runs on a schedule (e.g., every 24 hours) and on trigger events

Key Vault access is controlled through Azure RBAC, which means you get the same PIM + MFA + audit controls you’d have with native LAPS. The passwords are stored encrypted at rest in a FIPS 140-2 validated HSM.

The downside: you’re maintaining a custom script and deployment pipeline. It works, but it’s another thing to manage, test, and document.

Open-Source Tools

macOSLAPS (the Swift-based open-source project) predates Microsoft’s native implementation. It rotates the local admin password and can store it in Active Directory or a compatible directory service. If you have an on-prem AD in your environment, this might fit. For cloud-only GCC High environments, it’s less ideal.

LAPS4LINUX covers Linux and macOS endpoints and supports Azure AD (Entra ID) as a backend. It’s worth evaluating if you have a mixed fleet beyond just Windows and Mac.

Third-Party PAM

Solutions like CyberArk, Delinea, or BeyondTrust can manage local admin passwords across platforms. These are heavier than what most small and mid-size defense contractors need, but if you already have a PAM solution, extending it to Mac endpoints might be the path of least resistance.

The Bottom Line on macOS LAPS in GCC High

macOS LAPS in Intune is a welcome addition for mixed-fleet environments. It closes a gap that Mac admins have been working around for years. The implementation is more constrained than Windows LAPS — fixed password length, ADE-only, no passphrase support — but it gets the job done.

For GCC High tenants, the reality is that you need to check your own environment. Microsoft hasn’t published a clear statement on macOS LAPS availability in government clouds, and the feature rollout follows the standard commercial-first pattern. If it’s not there yet, the Azure Key Vault workaround is battle-tested and fully compatible with Azure Government.

Either way — native LAPS or Key Vault workaround — make sure the implementation is wrapped in the right controls: PIM for retrieval, MFA at every gate, audit logs forwarded to your SIEM, and post-use rotation enabled. That’s what makes it assessment-ready.

If you’re managing Macs in a GCC High environment and need help getting LAPS deployed — or building the Key Vault workaround — reach out. Whether it’s GCC High migration, CMMC consulting, or endpoint hardening, this is exactly the kind of gap we close for defense contractors every day.