When security defaults are enabled without conditional access, Microsoft applies baseline protections automatically to tenants that lack a stronger policy framework. That can improve minimum control coverage, but it also signals a governance gap if the organisation has not designed access policy intentionally. Teams should review whether those defaults align with their authentication, exception handling, and zero-trust requirements.
How security defaults behave when conditional access is missing
security defaults are a tenant-level safety net, not a substitute for policy design. When conditional access is absent, Microsoft’s baseline protections can still raise the floor for authentication and tenant hardening, but the organisation is effectively accepting a generic control set instead of enforcing access rules that match its own users, apps, devices, and risk appetite. That difference matters most in hybrid environments and any tenant with exceptions, privileged users, or regulated access paths.
Because the default posture is broad and opinionated, it can help close obvious gaps quickly, especially in tenants that have not yet built a mature access policy stack. The trade-off is flexibility: the more an organisation relies on defaults, the less it can express nuanced requirements such as step-up authentication for sensitive apps, location-based restrictions, device compliance, or separate treatment for administrators and third parties.
A useful way to think about the situation is that security defaults answer the question “what baseline protection should every tenant get?” while conditional access answers “what should this organisation require, under these conditions, for this identity, device, or application?” The former is a stopgap; the latter is a policy model. If the tenant still depends on the stopgap long after onboarding, that usually points to an access governance backlog rather than a finished design.
Why the gap matters for access control and zero trust
Without conditional access, the tenant cannot consistently express policy decisions at the point of sign-in and session evaluation. That limits the organisation’s ability to use zero trust identity controls as an operating model, because zero trust depends on continuous policy decisions, not just a one-time baseline. In practice, the control gap shows up wherever access should vary by risk, sensitivity, or assurance level.
This is also where authentication and access policy become inseparable. Identity provider and SSO security helps prevent weak sign-in paths from becoming the only protection left, but it does not replace conditional access logic. If policy is missing, the organisation may still authenticate users well and yet fail to enforce the right access decision for the session that follows.
For teams that want to move beyond a default posture, authorisation models are the natural next layer, because they show how policy can encode context, exceptions, and least privilege more precisely than blanket defaults. The practical distinction is simple: defaults harden the tenant, while conditional access and related policy models govern who can enter, from where, and under what assurance conditions.
When security defaults are a signal of unfinished governance
Security defaults are often enabled in tenants that have not yet designed their access policy intentionally. That can be acceptable as an interim state, but it becomes a governance problem if the organisation treats the default as a permanent operating model. In that case, the tenant may look protected while still lacking documented exception handling, role-specific sign-in rules, or a clear decision on which identities require stricter enforcement.
The gap is especially visible when a team has remote access, privileged administration, or cloud services that deserve differentiated treatment. A baseline can improve minimum control coverage, but it cannot express the organisation’s full operating intent. That is why a tenant can be “safer than before” and still not be “governed well.”
For Microsoft-centric environments, the strongest practical test is whether the organisation can explain which access decisions are intentional, which are inherited from defaults, and which are still unresolved. If that answer is vague, the tenant is probably relying on platform baseline protection to compensate for missing policy ownership.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Security defaults vs conditional access directly affects continuous policy enforcement and trust decisions. |
| Recommendation — Adopt policy-driven access decisions for each sign-in and session, not tenant-wide baseline settings alone. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | The question concerns governing tenant access states and exception handling for identities. |
| IA-2 — Identification and Authentication (Organizational Users) | Security defaults and conditional access both shape how user authentication is enforced. | |
| Recommendation — Define account access states and review them so defaults do not substitute for explicit access governance. Enforce stronger authentication requirements where user risk or sensitivity justifies them. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The topic is fundamentally about choosing and governing access control policy rather than relying on a vendor baseline. |
| A.8.5 — Secure authentication | Security defaults are an authentication baseline, while conditional access refines how authentication is applied. | |
| Recommendation — Set and document access control rules that reflect organisational requirements instead of inherited defaults. Apply secure authentication controls consistently and strengthen them for higher-risk access paths. | ||
Practitioner Guidance
What to verify: Confirm whether the tenant has an explicit policy owner, a documented exception process, and a written decision on which identities or apps require conditional access rather than defaults. If those answers do not exist, the current posture should be treated as transitional, not final.
Decision rule: If the organisation has sensitive applications, privileged administrators, or third-party access, treat security defaults as a temporary baseline and prioritise conditional access design before broadening the tenant further. If the environment is simple and low risk, defaults may be acceptable short term, but only with a dated migration plan.
What practitioners underestimate: The main failure mode is not that security defaults are weak, it is that they mask the absence of policy intent. The tenant may appear “covered” until an exception, privileged workflow, or compliance requirement exposes the missing control logic.
Practitioner takeaway: Use security defaults as a floor, not a destination, and move to conditional access as soon as the organisation needs differentiated sign-in assurance, exception handling, or zero trust enforcement.
Related resources from NHI Mgmt Group
- What happens when organisations rely on two-factor authentication without stronger password and access policies?
- What happens when organisations deploy more AI agents without policies and oversight?
- What happens when organisations try to manage sensitive cloud data without lifecycle policies and access governance?
- How should security teams use conditional access policies to reduce standing access without slowing urgent work?
