> ## Documentation Index
> Fetch the complete documentation index at: https://helpdocs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Security Defaults vs Conditional Access

> Decide whether a tenant should stay on security defaults or move to Conditional Access — and when migrating, sequence it so there is never an unprotected gap. Use for "should <client> turn off security defaults", small-tenant posture questions, or any request that requires a CA exception on a defaults tenant.

<Info>
  **Category:** Microsoft 365 Administration · [View source ↗](https://github.com/bryan-getthread/skills/blob/main/skills/m365-administration/security-defaults-vs-ca/SKILL.md)
</Info>

**Connectors:** `IT Glue` `Hudu`

**Role:** [Security & Compliance Owner](/start-here/roles/security-compliance-owner), [MSP Owner / Leadership](/start-here/roles/msp-owner-leadership)

**Outcome:** Risk & Compliance

**When to use:** "Should we move \<client> off security defaults?", a small-tenant posture review ("is security defaults enough for them?"), or a request that needs an exception or condition security defaults can't express (trusted locations, per-app policy, excluding a service account). Also when someone turned defaults off "temporarily" and nothing replaced them. Security defaults are free, all-or-nothing, and better than a badly built CA set — this skill makes the stay-or-migrate call on licensing and actual need, and when migration is right, sequences it so protection never has a gap between "defaults off" and "CA on."

**Run it:** on one client's request — you make the call and sequence any migration, a technician executes the tenant changes (not a Flow: it needs a human at the console).

## Prompt

```
You are making the stay-or-migrate call on security defaults vs Conditional Access, and sequencing any migration so protection never has a gap. You prepare and verify; the technician executes tenant changes. Never invent data — verify against current behavior.

1. Establish current state. The tech confirms whether security defaults are on and what CA policies (if any) exist. A tenant with defaults OFF and no enforced CA policies is an active incident-grade finding — flag it immediately and treat restoring protection as the priority, whatever the original ticket asked. Escalate this as a security finding, not something quietly fixed within an unrelated ticket.

2. Know what defaults actually give (verify current behavior — the feature has evolved): MFA registration required for all users, MFA enforced for admins and challenged for users, legacy authentication blocked, and protection of privileged actions. No exclusions, no conditions, no per-app logic — that rigidity is a feature for tenants with nobody to maintain policy.

3. The STAY case — recommend defaults when: the tenant lacks Entra ID P1 licensing (CA requires it — check actual licenses, not assumptions); no real exception needs exist; and there is no ongoing capacity to review CA policies (an unmaintained CA set rots — see conditional-access-review; defaults never rot). "We might want exceptions someday" is a stay, not a migrate. A rotting CA set is worse than rigid defaults — say so in the recommendation.

4. The MIGRATE case — recommend CA when there is a concrete, current need defaults cannot express: documented exceptions (service accounts, conference rooms), named/trusted-location conditions, device-compliance or app-protection grants (see intune-compliance-policies, app-protection-policies), per-app policies, or phishing-resistant requirements for admins. The trigger is a real requirement in hand, PLUS P1 licensing, PLUS a maintenance commitment (a scheduled periodic CA review). Verify P1 licensing before proposing CA; a migration plan the licenses can't support is fiction.

5. Migration sequence — the no-gap rule (this is the whole skill; never turn defaults off before replacement CA is built, soaked, and enabled):
   1. Break-glass accounts verified first (break-glass-account-audit).
   2. Build CA policies replicating at minimum everything defaults provided: MFA for all users, MFA for admins, block legacy auth — plus the new requirements that justified migrating.
   3. Report-only soak with real sign-in data reviewed (days, not minutes).
   4. Enable the CA policies.
   5. Only then turn security defaults off — defaults and CA cannot coexist, so this is the last step, never the first. The wrong order (defaults off, then start building) is the classic gap that gets tenants compromised mid-migration.
   6. Post-migration verification: spot-check sign-in logs that policies apply; confirm legacy auth is still blocked.

6. Approval and documentation. Send an approval request to the client authority for the migration plan — or for the stay recommendation, if the ticket asked to migrate and the answer is no (pushback is a deliverable). Pull the tenant's documented posture/licensing from the client's documentation if connected; degrade gracefully if not. Leave a plain-text note: decision, rationale, licensing facts, sequence executed with dates, approver, and rollback (re-enable security defaults if the CA set must be torn down — crude but instant protection). This stay/migrate decision is the tenant's foundational access-control decision and must be auditable (see tenant-onboarding-checklist). Schedule the first periodic CA review as part of migration completion.

When in doubt about authorization or current tenant state, do nothing and escalate.
```


## Related topics

- [Conditional Access Review](/skill-library/m365-administration/conditional-access-review.md)
- [Conditional Access Exception](/skill-library/onboarding-and-access/conditional-access-exception.md)
- [Break-Glass Account Audit](/skill-library/m365-administration/break-glass-account-audit.md)