# Security defaults

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/security-defaults

## Quick definition

Security defaults is a feature in Microsoft 365 and Azure that turns on important security protections for your organization without you having to configure anything complicated. It automatically requires everyone to use a second form of verification when signing in, blocks old and less secure ways of connecting, and helps protect against common attacks. This is perfect for smaller organizations or anyone who wants a basic level of security quickly.

## Simple meaning

Think of security defaults like the automatic safety features on a new car. When you buy a modern car, it comes with things like airbags, anti-lock brakes, and a backup camera already turned on. You do not have to ask for them, and you do not need to be a mechanic to use them. They are just there, working in the background to keep you safe. Security defaults does the same thing for your company’s online accounts and data.

When you set up a new office or start using Microsoft 365, security defaults automatically turns on several important protections. The most important one is multifactor authentication, or MFA. Normally, you only need a password to sign in. But passwords can be stolen or guessed. MFA adds a second step, like entering a code sent to your phone or using a fingerprint. Even if a bad guy gets your password, they still cannot get in because they do not have your phone.

Another thing security defaults does is block old login methods. In the past, some apps and email programs used simple passwords that were easy for hackers to break. Security defaults says no to those old methods. It only allows modern, more secure ways to connect. This is like a building that no longer accepts a simple key but instead requires a fingerprint scan or a smart card.

Security defaults also targets common attacks like password spray, where a hacker tries a few common passwords against many accounts. To stop this, it can challenge users with extra verification if a login looks suspicious, like coming from a different country or a new device. This is similar to your bank calling you to confirm a large purchase if you are spending money in a city you have never visited before.

The best part is that you do not have to be a security expert to turn this on. It is a single switch in the settings. For small businesses or anyone who just wants a solid baseline of security without spending hours on configuration, security defaults is a lifesaver. It gives you a strong starting point, and you can always add more advanced protections later if you need them. It is the simplest way to say, I want my accounts to be safe from the most common attacks.

However, it is important to know that security defaults is very strict. It applies to everyone in your organization, including administrators and regular employees. You cannot pick and choose who uses MFA. This can be a problem if you have some users who cannot use a phone for verification. Also, it turns off some advanced features that big companies might need, like custom password policies or the ability to bypass MFA from trusted locations. So while it is great for simplicity, it is too basic for large organizations with complex needs.

## Technical definition

Security defaults is a feature within Microsoft Entra ID (formerly Azure Active Directory) that provides a preconfigured set of security controls designed to protect organizations from common identity-related attacks, such as password spray, replay attacks, and phishing. It was introduced by Microsoft to address the reality that many organizations, particularly small to medium-sized businesses, fail to enable basic security protections. Security defaults essentially enforces a baseline security posture without requiring administrators to understand or configure each individual component.

When enabled, security defaults automatically enforces several policies at the tenant level. The most prominent is the requirement for multifactor authentication (MFA) for all users. This is not a conditional access policy in the traditional sense; rather, it is a tenant-wide setting that overrides other authentication policies. The MFA requirement applies to all users, including guest accounts, and cannot be selectively excluded. Microsoft recommends that organizations using security defaults do not create or manage Conditional Access policies, as these would conflict and be overridden. The authentication methods supported include the Microsoft Authenticator app, SMS text codes, phone call verification, and, in some configurations, OATH hardware tokens and FIDO2 security keys.

Another core component is the enforcement of modern authentication protocols. Security defaults blocks legacy authentication, which includes protocols such as POP3, IMAP4, SMTP AUTH, and older versions of ActiveSync. Legacy authentication does not support MFA, making it a prime vector for attackers. By blocking these protocols, security defaults forces all clients to use modern authentication methods like OAuth 2.0 OpenID Connect or SAML, which can enforce MFA and device compliance checks. This is critical because many brute force and credential stuffing attacks exploit legacy protocols that ignore MFA prompts.

Security defaults also implements risk-based protections. For example, the system can trigger MFA challenges when sign-ins are detected from unfamiliar locations or devices, or when there are multiple failed login attempts within a short period. While this is similar to Conditional Access risk policies, it is simpler and less customizable. The underlying logic uses Microsoft’s threat intelligence and machine learning models to detect anomalies, but administrators cannot adjust the sensitivity or scope of these detections under security defaults.

From a technical implementation perspective, security defaults is managed through the Microsoft Entra admin center, the Azure portal, or via Microsoft Graph API. When you toggle the setting on, the changes propagate across all authentication flows within the tenant within minutes. There is no granular control over which users are affected or which applications are protected; it is an all-or-nothing approach. This is by design, as the goal is to ensure that no user or application becomes a weak link.

For organizations that need more flexibility, Microsoft offers Conditional Access policies, which allow for fine-grained control based on user, location, device, application, and risk level. However, Microsoft explicitly states that security defaults and Conditional Access are mutually exclusive for most scenarios. If you enable security defaults, you cannot create or use Conditional Access policies unless you first disable security defaults. For organizations that outgrow security defaults, the recommended path is to create equivalent Conditional Access policies tailored to their specific needs.

Security defaults also integrates with Microsoft 365 Defender and Microsoft Sentinel to provide audit logs and alerts. While the configuration is simple, the logging remains detailed. Administrators can review sign-in logs to see when MFA was enforced, when legacy authentication was blocked, and when risk detections triggered additional verification. This data is crucial for understanding the security improvements and for compliance reporting.

One technical nuance is that security defaults does not apply to technical authentication flows like service principals or daemon applications, which use client credentials or certificates. These non-interactive flows are not subject to the same MFA requirements. An organization should still secure these using other mechanisms such as certificate-based authentication or managed identities.

security defaults is a powerful but rigid security baseline. It is technically simple but operationally restrictive. It is the right choice for organizations that lack the expertise or resources to build their own security controls, but it should be seen as a starting point, not a permanent solution for complex environments.

## Real-life example

Imagine you live in a neighborhood where several houses have been broken into recently. The local police department decides to offer a free home security kit to every resident. The kit comes with a few simple but effective items: a deadbolt lock for your front door, a doorbell camera, a motion-sensing light, and a sticker that says This home is protected. You do not have to install anything complicated or pay a monthly fee. You just put the deadbolt on your door, stick the camera by your entrance, and hang the sign in your window. The kit is designed to stop the most common types of break-ins, like thieves who try the door handle or smash a window at night.

This home security kit is exactly like security defaults in the digital world. The deadbolt lock is like multifactor authentication. A simple lock on a door is like a password: it can be picked or bypassed. But a deadbolt requires something extra, like a key from the inside or a combination. In the same way, MFA requires a second factor, like a code from your phone, so even if someone steals your password, they still cannot open the door.

The doorbell camera is like the risk detection feature in security defaults. It watches for suspicious activity, like someone lurking around your door at 3 a.m., and then alerts you. In security defaults, if someone tries to sign in from a strange country or from a device they have never used before, the system prompts them for extra verification. It is like the camera sending you a notification to check who is at the door.

The motion-sensing light is like the blocking of legacy authentication. Old, rickety windows and back doors are the equivalent of old email protocols like POP3 and IMAP. A burglar might try to get in through a flimsy window instead of the strong front door. Security defaults turns off those weak entry points, forcing everyone to use modern, secure doors. The light also discourages thieves from hanging around, just like blocking legacy auth forces apps to use secure sign-in methods.

Finally, the sticker on the window is like the policy itself. It tells potential attackers that you have basic protections in place. While a determined burglar might still find a way, most will move on to an easier target. Similarly, security defaults prevents the vast majority of common attacks, but a sophisticated, targeted attack might still succeed. The kit is not a fortress, but it is a huge upgrade from having no locks at all.

However, this basic kit also has limitations. If you live in a high-crime area or have valuable items, you might want a full alarm system with cameras, sensors, and a monitoring service. That is like Conditional Access policies, which let you customize every aspect of security. But for a small apartment or a first-time homeowner, the free kit is perfect. Security defaults is exactly that: a simple, free, effective baseline that protects against the most common threats without requiring you to become a security expert.

## Why it matters

Security defaults matters because it addresses one of the biggest problems in IT security: the failure to implement basic protections. According to Microsoft, over 99% of account compromise attacks are prevented by using MFA. Yet many organizations, especially small and medium-sized businesses, do not enable it because they find it complicated or disruptive. Security defaults eliminates that excuse by making MFA automatic and mandatory for everyone.

For IT professionals, this means a dramatic reduction in the risk of password-based attacks. Password spray, credential stuffing, and phishing are the most common ways attackers gain access. Security defaults directly counters these by requiring a second factor and by blocking legacy protocols that bypass MFA. Without security defaults, an administrator would need to manually configure Conditional Access policies, which can be error-prone and time-consuming.

Another reason it matters is compliance. Many regulatory frameworks, such as HIPAA, GDPR, and SOC 2, require organizations to implement MFA where possible. Security defaults provides a simple way to meet this requirement without deploying third-party solutions. For auditors, seeing security defaults enabled is a strong indicator that the organization has a baseline security posture.

However, the rigid nature of security defaults also means it is not suitable for every environment. Organizations with legacy applications that require basic authentication, or those with users who cannot use mobile devices, will find it too restrictive. In those cases, the choice to disable security defaults must be accompanied by a deliberate effort to build equivalent protections through Conditional Access. This is why understanding security defaults is critical: it is a decision point that forces organizations to evaluate their security maturity.

For exam takers, security defaults is a key concept that tests your understanding of identity security fundamentals. It appears in multiple Microsoft exams and is often the answer to scenario questions about enforcing MFA quickly. Knowing when to recommend security defaults versus Conditional Access is a common exam skill.

## Why it matters in exams

Security defaults is a directly testable concept in several Microsoft certification exams, including SC-900 (Microsoft Security, Compliance, and Identity Fundamentals), MS-102 (Microsoft 365 Administrator), MD-102 (Microsoft 365 Endpoint Administrator), and AZ-104 (Microsoft Azure Administrator). It also has supporting relevance in security-focused exams like Security+ and CySA+ because authentication controls are a core domain.

In the SC-900 exam, you can expect at least one question specifically about security defaults. The exam objectives include describing the capabilities of Microsoft Entra ID, and security defaults is often used as the simplest method to enforce MFA. A typical question might describe a small business that wants to secure user sign-ins without additional licensing. The correct answer would be to enable security defaults. The trap is that learners might suggest a Premium P2 license with Conditional Access, but security defaults is free and included with all Microsoft 365 subscriptions.

In the MS-102 exam, which covers Microsoft 365 administration more deeply, security defaults appears in scenarios where you need to choose between security defaults and Conditional Access. The exam might present a company with regulatory requirements that need more granular control, such as excluding a specific non-interactive service account from MFA. In that case, security defaults would not work because it applies to all users. The correct answer would be to disable security defaults and configure Conditional Access policies with exclusions. Understanding this distinction is critical.

The AZ-104 exam sometimes touches on security defaults in the context of identity management. While the exam focuses more on Azure resources, questions about Azure AD (now Entra ID) settings can include security defaults as a method to enforce MFA for all users in an Azure tenant. The question might also test the limitation that security defaults cannot be used alongside Conditional Access policies.

For Security+ and CySA+, security defaults is not directly in the objectives but appears in context as a real-world implementation of MFA enforcement. You might see a scenario question where a company wants to reduce successful phishing attacks. The answer could involve implementing MFA, and security defaults is a concrete example of how that is done in a Microsoft environment.

In the ISC2 CISSP exam, security defaults relates to the Identity and Access Management domain (IAM) and the concept of default deny. While the term itself may not appear, the principle of enforcing a baseline security posture is relevant to the Protect and Secure domain. Understanding that security defaults is a practical implementation of the principle of least privilege and defense in depth can help you reason through scenario questions.

the key exam takeaway is that security defaults is the quick, free, all-or-nothing MFA enforcement mechanism in Microsoft Entra ID. It is the right answer when the scenario involves a simple need for basic security, no budget for extra licensing, and no need for granular control. It is the wrong answer when any form of customization or exclusion is required.

## How it appears in exam questions

Security defaults appears in exam questions in several common patterns. The most frequent type is a scenario question where a small organization needs to improve security quickly with minimal cost. The question will describe a company with 25 users, no IT administrator, and a limited budget. They want to enforce MFA for all sign-ins. The correct answer is to enable security defaults. The distractor choices often include purchasing Azure AD Premium P2 licenses, configuring Conditional Access policies, or deploying a third-party MFA solution.

Another pattern is the compatibility question. The exam might state that Security defaults is enabled and then ask which feature is not available. The correct answer is Conditional Access policies. The question might also ask what happens to legacy authentication clients when security defaults is enabled. The answer is that they are blocked. For example, an app using IMAP4 for email will fail to connect because it does not support modern authentication.

A more advanced question type involves a company that currently has security defaults enabled but needs to exclude a specific service account from MFA. The question tests whether you know that security defaults does not allow exclusions. The correct action would be to disable security defaults and create a Conditional Access policy that requires MFA for all users except that service account. The trap is that some learners might try to create a Conditional Access policy while security defaults is still enabled, which is not allowed.

There are also matching questions where you need to pair security requirements with the appropriate solution. For example, enforce MFA for all users with no extra licensing: security defaults. Require MFA only for administrators: Conditional Access with a Premium license. Block legacy authentication only for external users: Conditional Access based on location. These questions test your ability to differentiate between the tools available.

Troubleshooting questions are also common. The scenario might describe users who cannot sign in using an old email client after an administrator enabled security defaults. The cause is that legacy authentication is blocked. The fix would be to update the email client to a modern version that supports OAuth, or to disable legacy protocols on the client side. Another troubleshooting scenario might involve users being prompted for MFA repeatedly, even from trusted locations. The reason is that security defaults has no trusted IP exclusions, so every sign-in is challenged.

Finally, some questions ask about the logging and monitoring implications. For instance, how can an administrator verify that security defaults is working? The answer is to check the Azure AD sign-in logs for the MFA requirement and legacy authentication blocks. Understanding that these logs are available even though the configuration is simple is an important exam point.

## Example scenario

A small veterinary clinic called Paws & Claws has 15 employees. They use Microsoft 365 Business Basic for email, calendar, and shared documents. The owner, Dr. Miller, has read about increased phishing attacks targeting small businesses. She wants to protect the clinic’s email accounts because they contain sensitive client information, including pet medical records and payment details.

Dr. Miller has no IT staff and is not very technical. She opens the Microsoft 365 admin center and sees a recommendation to enable security defaults. She clicks the button and confirms. The next day, all employees receive instructions to set up the Microsoft Authenticator app on their personal phones. Some employees complain that they now have to do an extra step when signing in. Dr. Miller explains it is a safety measure.

Two weeks later, an employee receives a phishing email that looks like it is from a food delivery service. The employee enters their work email and password on the fake website. The attacker now has the password. However, when the attacker tries to sign in from a foreign country, the system prompts for MFA. The attacker does not have the employee’s phone. The sign-in attempt is blocked and logged as a failed attempt. Later, the employee receives a notification that an unusual sign-in was prevented.

Without security defaults, the attacker would have successfully accessed the employee’s email and all the client data inside. But because MFA was enforced, the attack failed. This scenario shows exactly why security defaults matters: it stops the most common attack path with very little effort. For Dr. Miller, it was the right solution because it was free, simple, and effective. If the clinic later grows and needs more control, they can hire an IT consultant to switch to Conditional Access.

## How Security Defaults Enforce Baseline Security Policies

Security defaults are a set of Microsoft-recommended security settings that apply to all tenants created after October 22, 2019, or manually enabled for older tenants. Their primary purpose is to protect organizations from common identity attacks such as password spray, replay, and phishing by enforcing a baseline security posture without requiring additional licensing. For exam contexts like MS-102, SC-900, and AZ-104, understanding the enforcement mechanisms is critical because security defaults automatically activate several key policies: requiring multi-factor authentication (MFA) for all users, blocking legacy authentication protocols, requiring privileged users to complete MFA for every interactive session, and providing risk-based conditional access policies when combined with Azure AD Identity Protection.

The enforcement of MFA in security defaults is not configurable in granular detail; it applies uniformly to all users, including administrators and end users. When a user signs in from a new device or location, they are prompted to register for MFA using the Microsoft Authenticator app, phone call, or SMS. This registration is mandatory and cannot be bypassed. For privileged roles such as Global Administrator, Exchange Administrator, or Security Administrator, the system enforces additional verification: they must use MFA for every sign-in, not just when risk is detected. This contrasts with standard conditional access policies, where you can scope MFA to specific users or apps.

Blocking legacy authentication is another core enforcement mechanism. Legacy protocols like POP3, IMAP, SMTP, and older Office client versions that do not support modern authentication are automatically blocked. This prevents attackers from using brute force or password spray attacks against these vulnerable endpoints. In exam scenarios, this is often tested as a reason why an application stops working after enabling security defaults-for instance, a mail client configured with basic authentication will fail. The exam expects you to recommend updating the client to support OAuth 2.0 or enable SMTP AUTH if absolutely necessary, though the latter reduces security.

Finally, security defaults integrate with Azure AD Identity Protection to provide risk-based conditional access. When enabled, the system automatically detects risky sign-ins (e.g., from anonymous IP addresses, unfamiliar locations) and requires MFA or blocks access. This is a simplified version of the full conditional access feature available with Azure AD Premium P1 or P2. The key exam distinction is that security defaults are designed for tenants without premium licenses, making them a cost-effective security baseline. Understanding these mechanisms helps candidates answer questions about why certain policies apply automatically and how to transition from security defaults to more granular conditional access policies when moving to a premium license.

## The Critical Role of Legacy Authentication Blocking in Security Defaults

When security defaults are enabled, one of the most impactful policies is the automatic blocking of legacy authentication protocols. Legacy authentication refers to protocols that do not support modern authentication methods like OAuth 2.0, SAML, or WS-Federation. This includes Basic Authentication used by older versions of Microsoft Office (2010 and earlier), IMAP, POP3, SMTP, and other clients that send credentials in plaintext or use simple password-based authentication. For exams like Security+, CySA+, and CISSP, understanding why this block is necessary and how it impacts operations is essential.

From a security perspective, legacy authentication is a primary vector for credential-based attacks. Attackers frequently target these protocols because they bypass MFA requirements-if a protocol does not support MFA, even with security defaults, the system cannot enforce it. By blocking these protocols at the tenant level, security defaults reduce the attack surface dramatically. In fact, Microsoft reports that over 99% of password spray attacks use legacy authentication. This statistic is a common exam point: candidates are expected to know that enabling security defaults is the simplest way to mitigate this attack vector without additional licensing.

The technical implementation is straightforward: when security defaults are enabled, Azure AD creates an authentication policy that denies any sign-in request using a legacy protocol. This is enforced via the "Allow legacy authentication" setting in the Azure portal, which is set to "Block" by default. This setting cannot be individually overridden while security defaults are active unless you disable security defaults and create a custom conditional access policy. For exam scenarios, you might be asked why a user with a legitimate need for SMTP AUTH (e.g., a network scanner sending emails) fails to authenticate. The solution is to either disable security defaults, enable SMTP AUTH for that specific mailbox, or upgrade the device to support modern authentication.

It is also important to note that the block applies to all users, including administrators. For example, if an admin attempts to use PowerShell with Basic Authentication to manage Exchange Online, the connection will be rejected. The exam will test your ability to recognize these failures and recommend corrective actions. The key takeaway is that legacy authentication blocking is non-negotiable when using security defaults, and organizations must plan for client upgrades before enabling this feature. This is a frequent topic in MS-102 and AZ-104 exam questions, where you are given a scenario of an existing application breaking and must identify the root cause as legacy authentication blocked by security defaults.

## Transitioning from Security Defaults to Custom Conditional Access Policies

While security defaults provide a robust baseline for small to medium organizations, larger enterprises or those with compliance requirements often need more granular control over authentication policies. The transition from security defaults to custom conditional access policies is a critical topic for exams like MS-102, SC-900, and AZ-104, as well as the ISC2 CISSP, which emphasizes the principle of least privilege and defense in depth. Security defaults are effectively a set of predefined conditional access policies that Microsoft manages. When you disable security defaults, you must manually recreate equivalent policies to maintain security, but you gain the ability to exclude specific users, target only certain applications, or require device compliance.

The process begins by disabling security defaults in the Azure AD Properties blade. This action immediately removes all automatic enforcement of MFA and legacy authentication blocking. The organization then becomes vulnerable if no alternative policies are in place. Therefore, the exam stresses the importance of preparing custom conditional access policies before disabling security defaults. For example, you should create a policy that requires MFA for all users, another that blocks legacy authentication, and potentially a third for risk-based sign-ins if you have Azure AD Premium P2. These policies can be scoped to specific groups, allowing you to pilot changes before broad rollout.

A common exam scenario involves a company that has grown from a small tenant using security defaults to an enterprise requiring Azure AD Premium licenses for conditional access. The question might ask: what steps are needed to ensure a seamless transition? The correct answer involves creating baseline policies before disabling security defaults, testing with a pilot group, and then disabling security defaults. You must consider the impact on service accounts or break-glass accounts. With security defaults, service accounts that rely on legacy authentication will fail. With custom policies, you can exclude emergency access accounts from MFA requirements, though this must be done carefully to avoid security gaps.

Another important nuance is that security defaults enforce MFA for every sign-in for administrators, while custom conditional access policies can use risk-based policies to reduce friction. For example, you can configure a policy that requires MFA only for high-risk sign-ins, rather than every time. This trade-off between security and usability is a theme in the CySA+ and CISSP exams. Understanding when to use security defaults versus custom policies is a key differentiator. Security defaults are free and simple; custom policies require licensing but offer flexibility. The exam often tests your ability to recommend the right approach based on organizational size, budget, and compliance needs.

## Security Defaults Licensing and Cost Implications for Exam Candidates

One of the most frequently tested aspects of security defaults in exams like SC-900, MS-102, and AZ-104 is their licensing model. Security defaults are available to all Azure AD tenants, including those on the Free tier. This is a significant departure from full conditional access, which requires Azure AD Premium P1 or P2 licenses. For organizations with limited budgets, security defaults provide a cost-effective way to implement baseline security without purchasing premium licenses. Understanding this cost implication is crucial for exam questions that ask you to recommend a security solution for a small business with no premium licensing budget.

The Free tier of Azure AD includes basic features like user and group management, single sign-on for SaaS apps, and security defaults. When security defaults are enabled, the tenant effectively gets MFA for all users, blocking of legacy authentication, and risk-based detection at no additional cost. This is a classic exam trick: a question might describe a scenario where a company needs to enforce MFA but cannot afford Azure AD Premium. The correct answer is to enable security defaults, not to purchase licenses. Conversely, if the scenario requires exclusion of certain users (e.g., service accounts) or more granular control (e.g., location-based policies), then security defaults are insufficient and premium licenses are required.

Another cost-related nuance is that while security defaults themselves are free, they may force operational costs. For example, blocking legacy authentication may require upgrading legacy applications or purchasing new client software. These upgrade costs are not directly licensing costs but should be factored into total cost of ownership. The exam may present a situation where an organization uses an older email client that does not support modern authentication. Enabling security defaults will break that client, forcing an upgrade. The exam expects you to weigh the security benefit against the upgrade cost.

security defaults can be seen as a stepping stone to premium licensing. When an organization outgrows the capabilities of security defaults, they can transition to conditional access without losing the security baseline they had. This transition is seamless if planned properly. In the ISC2 CISSP and AWS SAA contexts, this concept relates to the trade-off between simplicity and granularity in security controls. For AWS SAA, the analogous concept is using AWS Config rules to enforce baseline security vs. more complex IAM policies. The key exam point is that security defaults are zero-cost and require no configuration, making them ideal for resource-constrained environments. Candidates should memorize that security defaults are always available on the Free tier and are the recommended first step for any new tenant.

## Common mistakes

- **Mistake:** Thinking security defaults is only for Azure AD Premium licensed tenants.
  - Why it is wrong: Security defaults is available for free with all Microsoft Entra ID editions, including the free tier included with Microsoft 365 subscriptions. No additional licensing is needed.
  - Fix: Remember that security defaults is a free feature. You do not need Azure AD Premium P1 or P2 to use it. It is designed for organizations without premium licensing.
- **Mistake:** Believing you can use Conditional Access policies together with security defaults.
  - Why it is wrong: Microsoft explicitly states that security defaults is mutually exclusive with Conditional Access. If you enable security defaults, you cannot create or use Conditional Access policies. You must disable security defaults before using Conditional Access.
  - Fix: Understand that security defaults and Conditional Access are two separate paths. Security defaults is an all-or-nothing baseline. Conditional Access requires a Premium license and provides granular control. You cannot mix both.
- **Mistake:** Assuming security defaults allows you to exclude certain users, such as service accounts or break-glass accounts.
  - Why it is wrong: Security defaults applies MFA to all users in the tenant, including administrators, guest users, and service accounts. There is no option to exclude anyone. This can cause problems for non-interactive accounts that cannot complete MFA.
  - Fix: If you have accounts that cannot use MFA, such as service accounts for applications, you must disable security defaults and use Conditional Access policies with exclusions. Plan for this before enabling security defaults.
- **Mistake:** Thinking security defaults only enforces MFA and nothing else.
  - Why it is wrong: Security defaults also blocks legacy authentication protocols, enforces risk-based MFA challenges, and provides baseline security alerts. It is not just about forcing MFA; it is a comprehensive set of security controls.
  - Fix: Study the full list of protections security defaults provides: MFA for all users, blocking legacy authentication, and risk-based verification. This helps you answer exam questions about its capabilities.
- **Mistake:** Believing security defaults is the best solution for all organizations.
  - Why it is wrong: Security defaults is ideal for small organizations with simple needs. But for large enterprises with legacy apps, custom MFA requirements, or regulatory exceptions, it is too restrictive. Using security defaults in such environments can cause business disruption.
  - Fix: Evaluate your organization's needs. If you need to exclude any user, use Conditional Access, or customize MFA frequency, then security defaults is not appropriate. Choose the right tool for the scale.
- **Mistake:** Assuming security defaults automatically applies to on-premises resources like Active Directory.
  - Why it is wrong: Security defaults only applies to cloud-based authentication in Microsoft Entra ID. It does not protect on-premises Active Directory or hybrid identities unless they are configured to use Entra ID for authentication (e.g., via Seamless SSO or Pass-through Authentication).
  - Fix: Remember the scope: security defaults protects cloud identity in Microsoft Entra ID. On-premises resources require separate protections, such as on-premises MFA or Azure AD Application Proxy.

## Exam trap

{"trap":"An exam question describes a company that needs to enforce MFA for all users immediately because of a security breach. The company uses Microsoft 365 Business Basic with no premium licenses. The answer choices include enabling security defaults, purchasing Azure AD Premium P1 and using Conditional Access, or implementing a third-party MFA solution. Learners often choose Conditional Access because they think security defaults is too basic or because they recall that Conditional Access offers more features. However, without a premium license, Conditional Access is not available.","why_learners_choose_it":"Learners often overthink the question. They see MFA enforcement and immediately think of Conditional Access because it is the more powerful tool. They might also believe that security defaults is only for small businesses or that it is not robust enough. Another reason is that some study materials emphasize Conditional Access heavily, leading learners to forget that security defaults exists as a free alternative.","how_to_avoid_it":"When you see a question about enforcing MFA quickly, inexpensively, and for all users, your first thought should be security defaults. Only consider Conditional Access if the scenario mentions Premium licensing, the need to exclude users, or granular policies. Also, memorize that security defaults is free with any Microsoft Entra ID edition. Practice the mental checklist: Is there a budget for Premium licensing? No → security defaults. Are there any special requirements like exclusions? Yes → Conditional Access (with license). This will help you avoid the trap."}

## Commonly confused with

- **Security defaults vs Conditional Access:** Conditional Access is a policy engine in Azure AD Premium that allows granular, rule-based access controls. You can exclude users, target specific applications, enforce location-based policies, and require device compliance. Security defaults is the free, simplified version that applies MFA to all users with no customizations. Think of security defaults as the easy button, and Conditional Access as the professional tool. (Example: Security defaults is like a store that requires everyone to show ID at the door. Conditional Access is like a VIP club that only checks ID for guests arriving after 10 PM who are not on a special list.)
- **Security defaults vs Azure AD Identity Protection:** Azure AD Identity Protection is a Premium P2 feature that uses machine learning to detect and automate responses to identity risks, like leaked credentials or anonymous IP addresses. Security defaults includes a basic form of risk-based MFA, but it is far less sophisticated. Identity Protection lets you create risk-based Conditional Access policies, while security defaults uses fixed Microsoft-defined triggers. (Example: Security defaults is like a smoke alarm that goes off for any smoke. Identity Protection is like a smart fire detection system that differentiates between burnt toast and a real fire.)
- **Security defaults vs MFA (Multifactor Authentication):** MFA is the general concept of requiring more than one factor to authenticate. Security defaults is a specific feature that enforces MFA for all users, but it also includes other protections like blocking legacy authentication. MFA can be enabled independently through other methods, such as per-user MFA or Conditional Access. Security defaults is one particular way to implement MFA. (Example: MFA is like wearing a seatbelt. Security defaults is like a car that automatically locks your seatbelt when you start the engine, while also disabling the car’s ability to run on old leaded gasoline.)
- **Security defaults vs Per-user MFA (legacy MFA configuration):** Per-user MFA is an older method where an administrator manually enables MFA for each user in the Azure AD portal. It is less secure than security defaults because it does not block legacy authentication and can be bypassed. Microsoft recommends against using per-user MFA and suggests security defaults or Conditional Access instead. (Example: Per-user MFA is like asking each person in an office to lock their own desk drawer. Security defaults is like installing a single keycard system that locks all drawers automatically and also changes the locks on the windows.)

## Step-by-step breakdown

1. **Decision to enable security defaults** — An administrator decides whether security defaults is appropriate for the organization. This usually happens when the organization wants to increase security but lacks the expertise or licensing for advanced controls. The decision should consider whether there are any users or applications that cannot use MFA or modern authentication.
2. **Navigating to the security defaults setting** — The administrator logs into the Microsoft Entra admin center (formerly Azure Active Directory admin center). They navigate to Identity > Overview > Properties. There is a section labeled Manage Security defaults. This is the only place where the toggle is available.
3. **Enabling security defaults** — The administrator sets the Enable Security defaults toggle to Yes and confirms the change. The system warns that this will enable MFA for all users and block legacy authentication. This action cannot be undone by simply toggling off in some cases without planning.
4. **Propagation of policies** — The change is applied tenant-wide within minutes. All future authentication requests will now be subject to the new policies. Existing sessions may remain active until their tokens expire, but new sign-ins are immediately affected.
5. **User registration for MFA** — When a user signs in for the first time after security defaults is enabled, they are prompted to register for MFA. They must provide a phone number for SMS or voice calls, or install the Microsoft Authenticator app. They complete the registration process during that sign-in session.
6. **Ongoing enforcement** — Every subsequent sign-in requires MFA. The user enters their password, and then must approve a notification on their phone, enter a code from an SMS or app, or use a hardware token. Sign-ins from unfamiliar locations or devices may trigger additional verification steps configured by Microsoft’s risk engine.
7. **Blocking legacy authentication** — Any application or client attempting to connect using legacy protocols like POP3, IMAP4, or SMTP AUTH is denied access. The user sees an error message. This forces administrators and users to update their email clients and applications to modern versions that support OAuth 2.0.
8. **Monitoring and review** — The administrator can review the sign-in logs and audit logs in the Microsoft Entra admin center. They can see which users have registered for MFA, which sign-ins were blocked due to legacy authentication, and any risk-based challenges that were triggered. This data is essential for understanding the security improvements.
9. **Considering upgrade to Conditional Access** — If the organization later needs more control, the administrator may decide to disable security defaults and purchase Azure AD Premium licenses. They then create Conditional Access policies to replicate and extend the protections. This step is optional but often needed as the organization grows.

## Practical mini-lesson

Security defaults is one of the most powerful tools for quickly improving identity security in a Microsoft environment. For IT professionals working with small to medium-sized organizations, it is often the first step in a security improvement plan. The key to using it effectively is understanding both its strengths and its limitations.

When you enable security defaults, you are essentially saying yes to a series of best practices that Microsoft has defined based on years of threat research. The most important practice is forcing every user to use MFA. This alone prevents the majority of account takeovers. But you also get the benefit of blocking legacy authentication, which is a huge win because many data breaches start with attackers exploiting old protocols that do not support MFA.

In practice, the biggest challenge with security defaults is user friction. Employees who are used to signing in with just a password may resist the extra step. As an IT professional, you need to plan for this. Communicate the change in advance, provide clear instructions on how to set up the Microsoft Authenticator app, and be ready to help users who do not have smartphones. You can also encourage users to use the Microsoft Authenticator app because it supports push notifications and number matching, which are faster than typing codes from text messages.

Another practical concern is the impact on service accounts. Many organizations have automated scripts or applications that authenticate using a simple username and password. These accounts cannot complete MFA. There are two solutions: either change these accounts to use modern authentication with certificates or managed identities, or disable security defaults and create a Conditional Access policy that excludes those specific accounts. The latter requires premium licensing.

What can go wrong? The most common issue is that an organization enables security defaults without checking whether all their applications support modern authentication. Legacy line-of-business applications that use SMTP or IMAP for email sending will stop working. This can cause disruptions in business operations, such as printers that scan to email or CRM systems that send emails. Always inventory your applications before turning on security defaults. If you find any critical legacy apps, you must either update them or choose a different approach.

Another issue is that security defaults does not allow trusted IPs. For organizations with a physical office, this means users are prompted for MFA even when they are inside the office network. This can be annoying for users who are already in a secure location. Conditional Access is needed to skip MFA from trusted IPs.

Despite these limitations, security defaults remains an excellent choice for organizations with simple needs. It is free, it is easy to enable, and it dramatically reduces risk. For the exams, focus on remembering that it is an all-or-nothing feature, it is free, and it cannot coexist with Conditional Access. Professional practice involves making an informed choice based on organizational requirements.

## Commands

```
Connect-MsolService -Credential $cred
```
Connects to Microsoft Online Services with admin credentials. Used before querying security defaults settings via PowerShell.

*Exam note: Tests ability to use MSOnline module for checking legacy authentication status. Exam may ask why this command fails when security defaults block legacy authentication.*

```
Get-MsolCompanyInformation | Select-Object DisplayName, SecurityDefaultsEnabled
```
Retrieves tenant information and displays whether security defaults are enabled.

*Exam note: Direct way to verify security defaults state in an exam scenario. Often used in MS-102 to confirm configuration.*

```
Set-MsolCompanySecurityDefaults -Enabled $true
```
Enables security defaults for the tenant using PowerShell. Requires Global Administrator role.

*Exam note: Command to enable security defaults programmatically. Exam tests syntax and ability to execute with proper permissions.*

```
Get-AzureADPolicy | Where-Object {$_.Type -eq 'ClaimsMappingPolicy'}
```
Lists claims mapping policies in Azure AD, often used to inspect custom policies after disabling security defaults.

*Exam note: Relevant after transition from security defaults to custom policies. Tests understanding of policy management in Azure AD.*

```
Set-AzureADDirectorySetting -Id $settingsId -Values @("LegacyAuthenticationDisabled","True")
```
Disables legacy authentication explicitly in directory settings, similar to what security defaults do.

*Exam note: Shows how to replicate security defaults behavior. Exam may ask for equivalent command to block legacy auth.*

```
New-AzureADConditionalAccessPolicy -DisplayName 'Require MFA for All Users' -State Enabled -Conditions @{Users = @{IncludeUsers = 'All'}} -GrantControls @{BuiltInControls = 'Mfa'}
```
Creates a custom conditional access policy requiring MFA for all users, replicating security defaults' MFA requirement.

*Exam note: Common exam scenario: replacing security defaults with custom policies. Tests ability to create equivalent policies.*

```
az rest --method get --uri 'https://graph.microsoft.com/v1.0/organization' --query 'value[0].securityDefaults'
```
Uses Azure CLI to query security defaults status via Microsoft Graph API.

*Exam note: Cross-platform command for checking security defaults. Tests familiarity with Graph API and Azure CLI syntax.*

## Troubleshooting clues

- **MFA registration prompt loop** — symptom: Users are repeatedly prompted to register for MFA even after completing registration.. This occurs when security defaults are enabled and the user's registration is not recognized due to stale session state or device trust issues. Security defaults require fresh MFA registration for new devices. (Exam clue: Exam scenarios test whether you know that resetting MFA registration or clearing browser cache resolves this. Often appears in MS-102.)
- **Legacy email client connection failure** — symptom: A user reports that Outlook 2010 cannot connect to Exchange Online after enabling security defaults.. Security defaults automatically block legacy authentication protocols, which Outlook 2010 uses. The client does not support modern authentication. (Exam clue: Classic exam question: identify that security defaults block legacy auth. Solution is to upgrade or use a client with modern auth support.)
- **Service account SMTP AUTH broken** — symptom: A network scanner configured to send emails via SMTP stops working after security defaults are enabled.. SMTP AUTH is a legacy protocol blocked by security defaults. The scanner cannot authenticate because it uses Basic Authentication. (Exam clue: Tests ability to recommend enabling SMTP AUTH for specific mailboxes or disabling security defaults for such devices. Common in AZ-104.)
- **Admin PowerShell connection rejected** — symptom: An administrator gets 'Access Denied' when using Connect-MsolService with Basic Authentication.. Security defaults block legacy authentication, so PowerShell modules using Basic Authentication fail. Modern authentication with PowerShell is required. (Exam clue: Tests knowledge that PowerShel must use OAuth. Exam may ask for the correct module or connection method.)
- **Inconsistent MFA enforcement for admins** — symptom: Global Administrators are sometimes not prompted for MFA when signing in from trusted locations.. Security defaults enforce MFA for every sign-in for privileged roles, but if the user has already registered MFA and the session is still valid, they may not be prompted. This is by design. (Exam clue: Exam tests understanding that MFA is prompted per session, not per login. May appear in SC-900.)
- **Conditional access policy conflict after disabling security defaults** — symptom: Users experience unexpected access blocks after admins disable security defaults and enable custom conditional access policies.. If security defaults are disabled without first creating equivalent policies, there is a temporary security gap. Custom policies may overlap or conflict with remaining legacy settings. (Exam clue: Tests troubleshooting sequence: always create custom policies before disabling security defaults. Common in MS-102.)
- **Break-glass account lockout** — symptom: Emergency access account cannot sign in because it is forced to register MFA, but it is a shared account.. Security defaults require MFA registration for all users, including break-glass accounts. This is problematic for accounts that should be accessible without personal MFA device. (Exam clue: Tests need to exclude break-glass accounts from MFA via custom policies by disabling security defaults first. Appears in CISSP and AZ-104.)
- **Risk-based sign-in failure after security defaults** — symptom: Users from unknown locations are blocked even though they have MFA registered.. Security defaults include risk-based policies that block sign-ins from anonymous IPs or unfamiliar locations even after MFA. This is an extra security measure. (Exam clue: Tests understanding that security defaults go beyond MFA. Often contrasted with basic MFA in exam questions.)

## Memory tip

Think "Free, All, Block", Security defaults is Free, applies to All users, and Blocks legacy authentication. It is the simplest path to force MFA.

## FAQ

**Is security defaults free?**

Yes, security defaults is available at no additional cost with any Microsoft Entra ID edition, including the free tier included with Microsoft 365 subscriptions. You do not need Azure AD Premium licenses.

**Can I use security defaults and Conditional Access at the same time?**

No. Microsoft explicitly states that security defaults and Conditional Access are mutually exclusive. If you need granular control, you must disable security defaults and use Conditional Access with a premium license.

**Does security defaults protect on-premises resources?**

No, security defaults only protects cloud authentication in Microsoft Entra ID. On-premises Active Directory requires separate security measures, such as on-premises MFA or Azure AD Application Proxy.

**What happens to service accounts when I enable security defaults?**

Service accounts (non-interactive accounts) cannot complete MFA challenges. They will be blocked from signing in. You must either update these accounts to use modern authentication (like certificates) or disable security defaults and use Conditional Access with exclusions.

**Can I turn off security defaults after enabling it?**

Yes, you can disable security defaults at any time by toggling the setting off in the Entra admin center. However, once disabled, the protections are removed. You should have an alternative security plan in place before disabling it.

**How do I check if security defaults is active?**

You can check the status in the Microsoft Entra admin center under Identity > Overview > Properties. You can also review sign-in logs to see whether MFA was enforced and legacy authentication was blocked.

**Will security defaults affect my users who cannot use a smartphone?**

Yes, all users must register for MFA. If a user does not have a smartphone, they can use a hardware OATH token or receive codes via SMS or voice call to a landline. If no method is possible, you may need to consider Conditional Access with exclusions.

## Summary

Security defaults is a foundational security feature in Microsoft Entra ID that provides a quick, free, and effective way to enforce baseline protections against common identity attacks. It automatically enables multifactor authentication for every user in the tenant, blocks legacy authentication protocols that do not support MFA, and includes basic risk-based verification. The best part is that it requires no additional licensing, making it accessible to organizations of all sizes, especially small businesses with limited budgets and no dedicated IT security team.

For the exams, the key takeaway is that security defaults is the easy button for MFA enforcement. It is the correct answer when the scenario describes a need to improve security quickly, without premium licensing, and without the requirement for granular controls. It is the wrong answer when the scenario includes any need to exclude users, customize policies, or use Conditional Access. Understanding this distinction directly maps to exam questions across SC-900, MS-102, AZ-104, and other Microsoft exams.

In professional practice, security defaults is a great starting point but not a permanent solution for complex environments. As organizations grow and develop specific requirements, they should plan to migrate to Conditional Access. However, for many small businesses, security defaults is perfectly adequate and provides a substantial improvement over having no MFA at all. By studying this term thoroughly, you are not only preparing for exam questions but also building practical knowledge that will help you protect real-world environments.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/security-defaults