Microsoft 365 Security Baseline: Security Defaults or Conditional Access?
Every Microsoft 365 tenant starts with a security posture whether or not anyone chose one. The decision is between security defaults, which need no additional licence but cannot be customised, and Conditional Access, which requires Microsoft Entra ID P1 and deliberate policy design.
Every Microsoft 365 tenant has a security posture from the day it is created, whether or not anyone deliberately chose one. The practical question for a Malaysian organisation is not whether to have a baseline, but which of two mechanisms is appropriate — and what the switch between them involves.
The two mechanisms, and the licence line between them
Microsoft's security defaults documentation sets out the comparison directly:
- Security defaults — required licences: none. Customisation: "No customization (on or off)". Described as simple to use.
- Conditional Access — required licences: at least Microsoft Entra ID P1. Fully customisable to the organisation's requirements.
Microsoft is explicit about who should be on which: "If you're an organization with Microsoft Entra ID P1 or P2 licenses, security defaults are probably not right for you," and organisations with complex security requirements should consider Conditional Access.
That makes the first question a licensing one. An organisation already holding Entra ID P1 — whether purchased directly or included in a bundle — is likely leaving capability unused by remaining on security defaults.
The gap during the switch is the real risk
This is the operationally important point, and it is easy to get wrong.
Microsoft states that after administrators disable security defaults, organisations should immediately enable Conditional Access policies to protect the organisation. Disabling one before configuring the other leaves a window in which neither is enforcing.
Microsoft-managed Conditional Access policies exist to maintain equivalent protection, covering blocking legacy authentication, requiring multifactor authentication for Azure management, for administrators, and for all users. Planning the switch means having the replacement policies ready — not disabling defaults and then starting the design work.
Create emergency access accounts before enforcing anything
Microsoft's guidance describes emergency access — or "break glass" — accounts as highly privileged accounts not assigned to specific individuals, limited to scenarios where normal accounts cannot be used or all other administrators are accidentally locked out.
The lockout scenario is not hypothetical. A Conditional Access policy requiring compliant devices, applied before device compliance is actually working, can exclude the very administrators who would fix it. Establish emergency access accounts, and exclude them from the policies being deployed, before enforcement begins.
Phase the deployment rather than enabling everything
Microsoft's Conditional Access deployment plan sets out a phased approach and records the licence requirement against each policy. Two points matter for planning:
- Foundation policies — blocking legacy authentication, securing the MFA registration page — require Entra ID P1.
- Risk-based policies — restricting high-risk sign-ins and high-risk users — require Entra ID P2.
An organisation holding P1 can therefore implement a substantial baseline, but risk-based conditional access is a separate licence decision. Confirm which tier is actually held before designing policies that depend on P2.
Malaysian context worth settling alongside
Access control interacts with the organisation's obligations under the Personal Data Protection Act 2010. Restricting who can reach personal data, and from where, is a technical control that supports those obligations — but enabling a policy does not by itself establish compliance. Classification decisions, retention periods and breach-response procedures remain the organisation's responsibility and should be confirmed with its own legal or compliance advisers.
Where staff work across multiple sites or travel regularly, location and device conditions need to reflect how people actually work, or the policy will be bypassed through exception requests.
What to establish before changing anything
- Confirm which Microsoft Entra ID tier the organisation actually holds — this determines what is available.
- Create and test emergency access accounts, excluded from the policies being deployed.
- Where moving off security defaults, have replacement Conditional Access policies configured before disabling.
- Deploy in report-only mode first where available, and review the impact before enforcing.
- Identify legacy authentication still in use — blocking it is foundational, and it breaks older clients.
- Record who approved each policy and why, so exceptions can be assessed against a stated position.
Where the wider tenant configuration is in scope, that is addressed under SCSB's Microsoft 365 implementation service.
General-information limitation
This article is general information about Microsoft security configuration options, not security, legal or data-protection advice for a particular organisation. It does not determine the appropriate security posture for any tenant, nor establish compliance with the PDPA 2010 or any other requirement. Licence requirements and available policies are set by Microsoft and change over time. Confirm the current position against Microsoft's own published material.
To discuss your requirements, contact SCSB.
Microsoft product references source checked: 25 July 2026.
Microsoft, Microsoft 365, Microsoft Entra ID and Microsoft Azure are trademarks of the Microsoft group of companies.