Zero Trust Identity for a Contractor Population
Tailspin has 900 employees and 250 contractors. Contractors use personal devices and need access to a partner portal (a custom app registered in Entra ID) plus SharePoint sites for their project. Employees use company-managed devices. The security team wants to adopt Zero Trust principles. Current state: contractors have permanent guest accounts in the tenant, MFA is enforced for everyone via security defaults, and there is no device compliance signal. A consultant proposes replacing security defaults with Conditional Access and requiring compliant devices for all users. Contractors push back that their personal phones and laptops are not enrolled and they will not enroll them.
1. Apply Zero Trust principles to decide how to handle contractors. Is 'require compliant device for all users' the right call? Justify using the Zero Trust model.
Read the worked answer
No - 'compliant device for all users' misapplies Zero Trust to the contractor population and will break access without improving security meaningfully.
Zero Trust principles: verify explicitly, use least privilege, assume breach. Applying them here:
- Verify explicitly - contractors should be verified with strong auth (MFA, ideally phishing-resistant for high-risk) and their access scoped to only the partner portal and their project SharePoint sites. That is least privilege; a blanket device-compliance rule is not the same as least privilege.
- Device signal must match the device reality. Employees have managed devices, so compliant-device is a valid signal for them. Contractors on personal devices cannot provide that signal; forcing enrollment is both a usability and a privacy problem (personal device management). The right control is app protection policies / app-enforced restrictions (Intune MAM) or Conditional Access granting access only to the specific app with session controls, rather than device compliance.
- Assume breach - limit what a compromised contractor account can reach: scope to the two apps, block other cloud apps, apply session controls (e.g., limited web access, no download on unmanaged devices).
So: replace security defaults with Conditional Access (good), but split policies by population - compliant device for employees, app-protection/session controls for contractors. Do not apply one device rule to everyone.
2. The consultant wants to move from security defaults to Conditional Access. What must be true before that migration is safe, and what Zero Trust gap does security defaults leave that Conditional Access closes?
Read the worked answer
Prerequisites before disabling security defaults:
- Licensing: Conditional Access requires Microsoft Entra ID P1 (or equivalent). Confirm the tenant has it; security defaults are the free baseline. Disabling security defaults without P1 leaves the tenant with no baseline controls.
- Have policies ready before disabling. Build and test Conditional Access policies (MFA for all, block legacy auth, device/app controls per population) and validate in report-only mode, then disable security defaults. Otherwise there is a gap window with no MFA.
- Break-glass accounts excluded from policies so you don't lock yourself out.
Zero Trust gap security defaults leaves: security defaults are a one-size-fits-all baseline - it enforces MFA for all users and blocks legacy auth, but it cannot scope by user, app, device, or location, and cannot express least privilege or device/session signals. Conditional Access lets you verify explicitly per population (employees vs contractors), enforce least privilege (app-scoped access), and apply device and session controls - the granular, signal-based enforcement Zero Trust requires. Security defaults is a floor, not a Zero Trust architecture.