The Endpoint That Wouldn't Comply
A company manages 300 laptops with a mix of Windows, macOS, and some personally owned devices used by sales. They want to require that only compliant, managed devices can access Workspace, but a pilot shows problems: (1) personal phones used for Gmail are being blocked and sales is escalating; (2) some managed Macs show as non-compliant even though IT says they're enrolled; (3) a few users on older Windows builds can't install the required agent. Leadership wants a policy that improves security without a revolt, and needs to understand what 'context-aware access' actually enforces versus what device management enforces.
1. Distinguish what context-aware access enforces from what endpoint/device management enforces, and explain why the personal-phone block happened.
Read the worked answer
Two different layers:
- Context-aware access is an access decision layer: it evaluates attributes of the request - user, device posture/management state, IP, location - and decides whether to allow, block, or require step-up. It gates access to Workspace apps based on context.
- Endpoint/device management is a device configuration and posture layer: it enrolls devices, enforces settings (encryption, screen lock, OS updates), and reports compliance. It doesn't itself grant or deny app access - it produces the posture signal that context-aware access consumes.
Why personal phones got blocked: the pilot applied a device-based access rule (e.g., 'only managed/compliant devices') to a broad population, including BYOD phones. Personal phones aren't enrolled/managed, so they fail the device condition and access is denied. The rule was correct in mechanism but too broad in scope - it didn't distinguish managed corporate laptops from personal mobile devices.
Takeaway: context-aware access enforces policy on context; device management creates the posture. You need both, but you must scope the access rule to the devices/populations it's meant for.
2. Propose a tiered policy that protects corporate data on managed laptops while allowing reasonable personal-device use, and address the non-compliant Macs.
Read the worked answer
Tiered access policy:
- Managed corporate laptops (Windows/macOS): require device compliance for full access. These should be enrolled and compliant; enforce encryption, screen lock, OS patch level. Non-compliant = blocked or limited.
- Personal/BYOD devices: don't require full device management (that's the revolt). Instead:
- Allow access with stronger authentication (MFA) and limited scope - e.g., web/mobile access to Gmail/Calendar, but block download/sync of sensitive Drive content to unmanaged devices, or restrict to a managed browser/app container where available.
- Apply context-aware rules that step up or limit access based on device trust rather than hard-blocking.
- Sensitive apps/data: require managed device + compliant posture; BYOD gets read-only or no access to the most sensitive resources.
Non-compliant Macs:
- Diagnose first: 'IT says enrolled' but shows non-compliant usually means a posture check is failing - e.g., FileVault not enabled, OS below minimum, agent not reporting, or a stale check-in. Verify the specific failing signal rather than assuming enrollment is wrong.
- Fix the posture (enable encryption, update OS, re-check agent) or adjust the policy if the requirement is unrealistic for that fleet.
- Grace period: give a remediation window before blocking, with clear user messaging, so people aren't cut off mid-work.
Principle: protect data by what the device can do (full vs limited access) rather than a binary block that catches personal phones.
3. A few users on older Windows builds can't install the required agent. How do you handle them without either abandoning the policy or stranding users, and how do you communicate the rollout?
Read the worked answer
Handling the incompatible devices:
- Quantify the population - how many, which builds, which roles. A handful is a targeted fix; a large group signals the policy is ahead of the fleet.
- Remediation path: prioritize OS upgrades for those devices (the real fix). If upgrade isn't immediately possible, give a documented exception with compensating controls (e.g., limited access, MFA required, no sensitive-data download) and a deadline to upgrade.
- Don't silently block: stranding users mid-quarter damages trust and drives shadow IT. Time-boxed exceptions with a clear end date are better than a hard wall.
- Escalate hardware refresh if the build can't be upgraded - that's a budget/asset decision, not an admin one.
Communication/rollout:
- Phase it: pilot → announce → grace period with remediation support → enforce. Enforce on the population that's ready first.
- Tell users what's changing, why, what they must do, and the deadline - specific steps, not 'contact IT.'
- Give a self-service path to check compliance and remediate.
- Provide a help-desk script so support answers consistently.
- Publish the exception process so managers know how to request one.
Principle: a security policy that strands users gets bypassed. Pair enforcement with a remediation path, time-boxed exceptions, and clear communication so compliance is achievable, not punitive.