Zero Trust Identity Lab in Entra ID

Configure Conditional Access, MFA, and SSPR in Microsoft Entra ID.

Introduction

30 Second Summary

Every time you unlock your phone with your face or enter a verification code, you're experiencing identity security. Companies use the same principles at a massive scale to protect their cloud systems, and the people who configure these protections are in high demand.

In this project, you will build a Zero Trust identity lab in Microsoft Entra ID. You'll create users and security groups for a fictional company called Northwind Security, enforce multi-factor authentication through Conditional Access policies, and configure Self-Service Password Reset so employees can reset their own passwords without calling IT.

What You'll Build

You will configure a complete cloud identity environment in Microsoft Entra ID, simulating the access controls and user lifecycle management for a 10-person organization.

By the end of this project, you'll have:

A Microsoft Entra ID tenant with P2 trial activated, four test user accounts across three security groups modelling real departments.
Two Conditional Access policies enforcing Zero Trust principles: requiring MFA for all users and blocking legacy authentication.
Self-Service Password Reset configured and validated for the Developers group, demonstrating a direct help desk efficiency improvement.
Secret Mission: Create an emergency access (breakglass) account following Microsoft best practices and exclude it from your Conditional Access policies to prevent tenant lockout.

Are there any prerequisites?

This project assumes you have completed an Active Directory project and are familiar with users, groups, and domain concepts. You will also need a personal email address and a phone number for identity verification during Azure account signup.

Before We Start

Before We Start...

Create Your Azure Account and Activate the Entra ID P2 Trial

Every Zero Trust identity lab starts with a foundation. Your foundation is a Microsoft Entra ID tenant. This is the cloud-based identity service where you'll create users, groups, and access policies.

In this step, you'll create a free Azure account and activate the Entra ID P2 trial. P2 unlocks Conditional Access and Self-Service Password Reset, the two core features you'll configure throughout this project.

In this step, get ready to:

Create a free Azure account.
Activate the Entra ID P2 trial license.
Confirm your tenant is ready.

Create a free Azure account

Azure is Microsoft's cloud platform. Creating a free account gives you access to the Entra admin center, where you'll do all your identity configuration work.

Open your web browser and navigate to azure.microsoft.com/free.
Click Start free.
Sign in with a personal Microsoft account or create a new one using your personal email address.

What happens during signup?

Azure's signup process has four sections: personal information, phone verification (via SMS or voice call), credit/debit card verification, and agreement to terms.

Microsoft places a temporary hold of approximately $1 USD on your card to confirm it is active. This is refunded automatically. You will not be charged for anything in this project.

Complete the phone verification step using your phone number.
Enter your credit or debit card details for identity verification.
Review and accept the agreement, then click Sign up.

Once signup completes, you'll land on the Azure portal.

Open a new browser tab and navigate to entra.microsoft.com.
Sign in with the same Microsoft account you just used for Azure signup.

You should see the Microsoft Entra admin center home page with your account name in the top-right corner.

Already have an Azure account?

If you already have a personal Azure account, skip the signup and sign in directly at entra.microsoft.com. You can still activate the P2 trial in the next substep as long as you haven't used it before.

Can't complete signup?

If phone verification fails, make sure you're using a mobile number that can receive SMS messages. VoIP numbers are not supported.

If card verification fails, check that your billing address matches what your bank has on file. Prepaid cards are not accepted.

Help me troubleshoot my Azure account signup.

Activate the Entra ID P2 free trial

The Entra ID Free tier only covers basic user and group management. You need P2 to access Conditional Access policies and Self-Service Password Reset. The P2 trial is free for 31 days with up to 100 licenses.

In the Entra admin center, expand Identity in the left sidebar.
Click Licenses.
Click All products.
Click + Try/Buy in the top toolbar.
Find Microsoft Entra ID P2 in the list.
Click Free trial under Microsoft Entra ID P2.
Click Activate.

A confirmation banner appears at the top of the page. Your P2 trial is now active.

What does P2 unlock?

The P2 tier gives you access to Conditional Access, which lets you create policies that control who can sign in and under what conditions. It also enables SSPR, which allows users to reset their own passwords without contacting IT.

After 31 days, the trial expires automatically. Your tenant reverts to the Free tier with no charges. Users and groups you create will remain intact.

Don't see the Try/Buy button?

Make sure you're on the All products page under Licenses. If you navigated to a different Licenses sub-page, the button won't appear.

If you've previously activated a P2 trial on this tenant, you won't see the option again. You'll need to create a new Azure account with a different email.

Help me find the P2 trial activation option.

Verify your tenant is ready

Before moving on, confirm that your tenant is set up correctly and note the key identifiers you'll reference later.

In the left sidebar, click Identity.
Click Overview.
Locate your Primary domain on the overview page. It will look something like yourname.onmicrosoft.com.
Find the Tenant ID field and note this value somewhere safe. You'll reference it later in the project.

What is a tenant?

A tenant is your dedicated instance of Microsoft Entra ID. Think of it as your organization's private directory in the cloud. Every user, group, and policy you create lives inside this tenant.

The .onmicrosoft.com domain is automatically assigned to every new tenant. In a real organization, you would add a custom domain like northwindsecurity.com.

Navigate back to Licenses then All products to confirm Microsoft Entra ID P2 appears in your license list with available units.

You should see Microsoft Entra ID P2 listed with 100 available licenses and an expiration date 31 days from today.

Your Azure account is live and your Entra ID P2 trial is active. Next up, you'll build the organizational structure for Northwind Security by creating users and security groups.

Build Your Organizational Structure

Your Microsoft Entra ID tenant is live and licensed. Now you need something to protect.

In this step, you will build the organizational structure for Northwind Security, a fictional 10-person company. You will create security groups representing departments and populate them with test users. This structure is the foundation that your Zero Trust policies will target in later steps.

In this step, get ready to:

Create three security groups representing Northwind Security departments.
Create four test users and assign each to their department group.
Assign the Entra ID P2 license to all test users.

Create three security groups

Security groups let you apply policies to collections of users instead of managing each person individually. You will create one group per department at Northwind Security.

In the Entra admin center, expand Identity in the left navigation menu.
Select Groups, then All groups.
Click + New group at the top.

You will create three groups one at a time. For the first group, fill in these fields:

Set Group type to Security.
Enter NW-HelpDesk in the Group name field.
Set Membership type to Assigned.
Click Create.

Repeat the same steps to create two more groups:

NW-Developers (Group type: Security, Membership type: Assigned).
NW-Managers (Group type: Security, Membership type: Assigned).

Why security groups instead of assigning policies per user?

In a real company, employees join and leave constantly. Security groups let you assign a policy once to a group, and every current and future member inherits it automatically.

This is a core Zero Trust principle. Access decisions are based on group membership, not individual identity.

After creating all three, you should see NW-HelpDesk, NW-Developers, and NW-Managers listed under All groups.

Don't see your new groups?

Click the Refresh button at the top of the groups list. New groups can take a few seconds to appear.

If you see a permissions error, make sure you are signed in with the Global Administrator account you created during Azure signup.

Still stuck? Help me troubleshoot why my security groups aren't appearing in the Entra admin center.

Create four test users and assign them to groups

Each user represents an employee at Northwind Security. You will assign them to the correct department group during creation.

In the left navigation, select Users, then All users.
Click + New user at the top.
Select Create new user.

For the first user, fill in the following on the Basics tab:

In the User principal name field, enter alex. The domain portion will auto-fill with your tenant name.
In the Display name field, enter Alex Thompson.
Leave Auto-generate password checked, or set a password manually. Either way, copy the password and save it somewhere temporary. You will need it later.

Next, click the Properties tab:

In the Job title field, enter Help Desk Technician.

Now click the Assignments tab to assign this user to a group:

Click + Add group.
Search for and select NW-HelpDesk.
Click Select.
Click Review + create, then click Create.

Repeat the full user creation process for the remaining three users. Use the details in this table:

Jordan Lee: User principal name jordan, Job title Software Developer, Group NW-Developers.
Sam Patel: User principal name sam, Job title Software Developer, Group NW-Developers.
Morgan Chen: User principal name morgan, Job title IT Manager, Group NW-Managers.

Save all four passwords

You will need Jordan Lee's password in Step 4 when you test Self-Service Password Reset. Keep all four passwords in a temporary note so you can sign in as any test user later.

After creating all four users, navigate back to Users > All users. You should see Alex Thompson, Jordan Lee, Sam Patel, and Morgan Chen listed alongside your admin account.

A user is missing from the list?

Click Refresh at the top of the user list. If the user still does not appear, click + New user and re-create them. The most common issue is clicking away before hitting Create on the final screen.

Need more help? Help me figure out why my test user didn't save in Microsoft Entra ID.

Assign the P2 license to your test users

Conditional Access and Self-Service Password Reset require a Premium license on each user account. Without this, your policies will not apply to the test users.

In the left navigation, expand Billing and select Licenses.
Click All products.
Click Microsoft Entra ID P2 in the list.
Click + Assign.
Click + Add users and groups.
Select all four test users: Alex Thompson, Jordan Lee, Sam Patel, and Morgan Chen.
Click Select.
Click Review + assign, then click Assign.

Why do test users need the P2 license?

Conditional Access policies only evaluate users who have a Premium P1 or P2 license. Self-Service Password Reset also requires a Premium license for cloud-based accounts.

Without the license, your test users would silently bypass your policies. The P2 trial gives you up to 100 licenses at no cost for 30 days.

You should see a notification confirming the licenses were assigned successfully.

License assignment failed?

Make sure your users have a Usage location set on their profile. Licenses cannot be assigned without one. Edit each user, go to Properties, and set a location (your country).

Still stuck? Help me fix a license assignment error in Microsoft Entra ID.

To confirm everything is set up correctly, verify your groups have the right members:

Navigate to Identity > Groups > All groups.
Click NW-Developers and confirm Jordan Lee and Sam Patel are listed as members.
Click NW-HelpDesk and confirm Alex Thompson is a member.
Click NW-Managers and confirm Morgan Chen is a member.

Your organizational structure is complete. You have three department groups populated with test users, all licensed for premium features. Next up, you will build the Conditional Access policies that enforce MFA and block legacy authentication across this entire organization.

Disable Security Defaults and Create Conditional Access Policies

Your organizational structure is in place. Four users span three departments, giving you a realistic company to secure. Now it's time to define exactly how those users prove their identity when they sign in.

In this step, you'll replace the tenant's built-in Security Defaults with custom Conditional Access policies. These policies are the backbone of a Zero Trust approach: every sign-in is evaluated against rules you define, rather than a one-size-fits-all default.

In this step, get ready to:

Disable Security Defaults on the tenant.
Create a Conditional Access policy requiring MFA for all users.
Create a Conditional Access policy blocking legacy authentication.

Disable Security Defaults

Security Defaults and Conditional Access cannot be active at the same time. Before you can create custom policies, you need to turn off the built-in defaults.

In the Entra admin center, click Identity in the left sidebar.
Click Overview.
Click Properties in the left menu.
Click Manage security defaults at the bottom of the page.
Set Security defaults to Disabled.
Select a reason from the dropdown (choose My organization is using Conditional Access).
Click Save.

Why Conditional Access instead of Security Defaults?

Security Defaults provide a fixed baseline that you cannot customize. They enforce MFA for all users and block legacy authentication, but you have no control over which users, apps, or conditions trigger those rules.

Conditional Access gives you granular control. You can target specific groups, exclude emergency accounts, and respond to risk signals. This is the skill that IAM analysts use daily in production environments.

Don't see Manage security defaults?

Make sure you navigated to Identity > Overview > Properties. The link appears at the bottom of the Properties page. If you still don't see it, confirm you are signed in as the Global Administrator account you used to create the tenant.

help me find the Manage security defaults option in the Entra admin center

Create a policy to require MFA for all users

Your first Conditional Access policy will require Multi-Factor Authentication (MFA) for every user signing into any cloud app. You'll set it to Report-only mode first so it doesn't lock anyone out before MFA methods are registered.

In the left sidebar, expand Protection.
Click Conditional Access.
Click Policies in the left menu.
Click + New policy.
In the Name field, type NW-Require-MFA-AllUsers.
Under Assignments > Users, click the link to configure users.
On the Include tab, select All users.
Under Target resources > Cloud apps, click the link to configure apps.
On the Include tab, select All cloud apps.
Scroll down to Access controls > Grant.
Select Grant access.
Check the box for Require multifactor authentication.
Click Select.
At the bottom of the page, set Enable policy to Report-only.
Click Create.

Why Report-only mode?

If you enforced MFA immediately, you could lock yourself out of the tenant before registering your own MFA methods. Report-only mode logs what the policy would do without actually blocking anyone. You can switch it to On later after everyone has registered their MFA.

Don't see Conditional Access in the sidebar?

Conditional Access requires an Entra ID P1 or P2 license. Confirm your P2 trial is active by navigating to Identity > Billing > Licenses > All products. You should see Microsoft Entra ID P2 listed with available licenses.

help me find the Conditional Access option in my Entra admin center

Create a policy to block legacy authentication

Legacy authentication protocols (like older Exchange ActiveSync and POP3 clients) do not support MFA. Attackers exploit these protocols in over 97% of credential stuffing attacks. This second policy blocks them entirely.

Return to the Policies page under Conditional Access.
Click + New policy.
In the Name field, type NW-Block-Legacy-Auth.
Under Assignments > Users, click the link to configure users.
On the Include tab, select All users.
Under Target resources > Cloud apps, click the link to configure apps.
On the Include tab, select All cloud apps.
Scroll down to Conditions and click Client apps.
Set Configure to Yes.
Uncheck Browser and Mobile apps and desktop clients if they are checked.
Check only Exchange ActiveSync clients and Other clients.
Scroll down to Access controls > Grant.
Select Block access.
Click Select.
Set Enable policy to On.
Click Create.

Why is this policy set to On instead of Report-only?

This policy is safe to enforce immediately. Your tenant is brand new and all your users sign in through modern authentication (web browsers and current apps). There are no legacy clients to disrupt, so blocking legacy protocols right away closes the door on attackers without affecting anyone.

What are Exchange ActiveSync clients and Other clients?

Exchange ActiveSync clients are older email protocols used by some mobile mail apps. Other clients covers protocols like POP3, IMAP, and SMTP that don't support modern authentication. Together, these two checkboxes target every legacy sign-in method that cannot perform MFA.

Confirm both policies appear in your Policies list. Navigate to Protection > Conditional Access > Policies. You should see NW-Require-MFA-AllUsers with state Report-only, and NW-Block-Legacy-Auth with state On.

Only seeing one policy?

If a policy didn't save, you may have missed a required field. Click + New policy again and ensure you configured both the Users assignment (All users) and the Target resources (All cloud apps). The Create button stays greyed out until all required sections are filled.

help me figure out why my Conditional Access policy didn't save

Your tenant now enforces Zero Trust principles through custom Conditional Access policies. Next up, you'll configure Self-Service Password Reset so your developers can reset their own passwords without calling the help desk.

Configure Self-Service Password Reset

Your Conditional Access policies are ready to enforce Zero Trust sign-in rules. Now it's time to tackle a different challenge: what happens when an employee forgets their password?

Without self-service options, every forgotten password becomes a help desk ticket. Self-Service Password Reset (SSPR) lets users securely reset their own passwords using a verified recovery method. In this step, you will enable SSPR for the Developers group and test the full reset flow as Jordan Lee.

In this step, get ready to:

Enable SSPR for the NW-Developers security group.
Configure authentication methods and registration settings.
Test the password reset flow with a developer account.

Enable SSPR for the Developers group

SSPR can be enabled for all users or a selected group. Enabling it for a single group first lets you validate the configuration safely before rolling it out to the whole organization.

In the Entra admin center, navigate to Entra ID > Password reset.
On the Properties page, set Self service password reset enabled to Selected.
Click Select group.
Browse for and select NW-Developers, then click Select.
Click Save.

Why enable SSPR for only one group?

Microsoft Entra ID only allows one group to be enabled for SSPR at a time through the admin center. Starting with a single department (Developers) lets you test the workflow before expanding it company-wide.

In production, you would use a broader group or nested groups to cover the entire organization.

Don't see the Password reset option?

Make sure you are navigating within Entra ID (not Azure AD or another section). The option appears in the left navigation panel under the Identity section. If it is greyed out, confirm your P2 trial license is still active under Licenses > All products.

Help me find the Password reset settings in the Entra admin center.

Configure authentication methods for SSPR

Authentication methods define how users prove their identity before a password reset is allowed. You will also configure registration settings so users are prompted to set up their recovery method on their next sign-in.

In the Password reset section, select Authentication methods from the left menu.
Set Number of methods required to reset to 1.
Under the available methods, enable Email.
Click Save.

Now configure the registration settings so users are prompted to register their recovery method.

Select Registration from the left menu.
Set Require users to register when signing in to Yes.
Set Number of days before users are asked to reconfirm their authentication information to 180.
Click Save.

What do these settings do?

Requiring only 1 method keeps the reset process quick for this lab. In production environments, you would typically require 2 methods for stronger security.

The registration enforcement means Jordan Lee and Sam Patel will be asked to register a recovery email the next time they sign in. The 180-day reconfirmation ensures their recovery info stays current.

Test SSPR with a developer account

The best way to confirm SSPR is working is to walk through the full flow as one of your developer users. You will sign in as Jordan Lee, register a recovery email, and then perform an actual password reset.

Open a new InPrivate (Edge) or Incognito (Chrome) browser window.
Navigate to https://aka.ms/ssprsetup.
Sign in as Jordan Lee using the UPN jordan@yourdomain.onmicrosoft.com and the password you set during user creation.
When prompted to register authentication information, add a personal email address as a recovery method.

Why use an InPrivate or Incognito window?

Your main browser session is signed in as the tenant administrator. Using a private window lets you sign in as Jordan Lee without conflicting with your admin session.

Now test the actual password reset flow.

In the same private browser window, navigate to https://aka.ms/sspr.
Enter Jordan Lee's UPN (jordan@yourdomain.onmicrosoft.com) and complete the CAPTCHA.
Choose Email my alternate email as the verification method.
Check the personal email you registered for a verification code, enter it, and set a new password.

You should see a confirmation message that the password has been successfully reset.

What just happened?

Jordan Lee proved their identity using the registered email method and set a brand-new password without any admin involvement. In a real company, this saves the help desk from handling routine password reset tickets.

Now verify the reset event is logged in the Entra admin center.

Switch back to your main browser window (the admin session).
Navigate to Entra ID > Password reset > Audit logs.
Confirm you see a reset event for Jordan Lee. The activity should show Reset password (self-service) with a status of Success.

Not seeing the reset event in audit logs?

Audit log entries can take a few minutes to appear. Wait 2-3 minutes and refresh the page. If the Service filter is active, make sure it is set to Self-service Password Management.

If Jordan Lee was unable to reset their password at all, confirm the P2 license is assigned to them under Users > Jordan Lee > Licenses. Without a P2 license, SSPR will not work.

Help me troubleshoot why SSPR is not working for my test user.

SSPR is live for your Developers group. Next up, you will use the Conditional Access What If tool to simulate sign-in scenarios and confirm all your policies work together as designed.

Test and Validate with the What If Tool

Your SSPR configuration is live and tested. Jordan Lee can now reset their own password without calling IT.

But how do you know your Conditional Access policies are actually doing what you designed them to do? In this step, you will use the What If tool to simulate sign-in scenarios and confirm each policy triggers correctly.

In this step, get ready to:

Simulate a modern authentication sign-in and confirm the MFA policy applies.
Simulate a legacy authentication sign-in and confirm it gets blocked.
Document your What If results for your portfolio.

Simulate a modern authentication sign-in

The What If tool lets you test Conditional Access policies without actually signing in as a user. You provide a simulated scenario, and it tells you which policies would fire.

In the Entra admin center, navigate to Entra ID > Conditional Access > Policies > What If.
Under User, select Jordan Lee.
Under Cloud apps, select All cloud apps.
Leave all other conditions at their defaults.
Click What If.

Review the results that appear below the form.

What should I see?

The results page splits into two sections. Under Policies that will apply, you should see NW-Require-MFA-AllUsers. This confirms that a modern sign-in would require MFA.

Under Policies that will not apply, you should see NW-Block-Legacy-Auth. This makes sense because the simulation used a modern client, not a legacy one.

What is the What If tool?

The What If tool is a policy simulation engine built into Conditional Access. It shows which policies would apply to a given sign-in scenario, which would not apply (along with the reason), and whether grant or session controls must be satisfied.

In production environments, administrators use it to troubleshoot sign-in failures and validate new policies before enforcing them.

Not seeing your MFA policy listed?

Make sure you selected All cloud apps under the Cloud apps section. If you left it blank, the tool does not have enough information to evaluate the policy.

Also confirm that your NW-Require-MFA-AllUsers policy is set to Report-only (not Disabled). Report-only policies still appear in What If results.

Help me troubleshoot my What If results.

Simulate a legacy authentication sign-in

Now you will test the opposite scenario. Legacy authentication protocols like Exchange ActiveSync are exactly what your blocking policy targets.

In the What If tool, keep Jordan Lee as the user and All cloud apps as the target resource.
Expand Conditions > Client apps.
Select Exchange ActiveSync clients.
Click What If.

What should I see?

This time, NW-Block-Legacy-Auth should appear under Policies that will apply. The access control is set to Block, meaning this sign-in attempt would be denied.

Your two policies are now validated. Modern clients get prompted for MFA. Legacy clients get blocked entirely. This layered approach is a core principle of Zero Trust security.

NW-Block-Legacy-Auth not showing as applied?

Double check that you selected Exchange ActiveSync clients under Conditions > Client apps. If no client app condition is set, the tool defaults to modern authentication.

Also verify that your NW-Block-Legacy-Auth policy has its Enable policy set to On (not Report-only or Disabled).

Help me figure out why my legacy auth policy is not applying.

Document your results for your portfolio

These What If results are concrete proof that you can design, implement, and validate Zero Trust policies. This is exactly what employers look for in IAM and security portfolios.

Take a screenshot of the What If results for Simulation 1 (modern authentication). Make sure the Policies that will apply section showing NW-Require-MFA-AllUsers is visible.
Take a screenshot of the What If results for Simulation 2 (legacy authentication). Make sure NW-Block-Legacy-Auth is visible under Policies that will apply.

Recreate the simulations for clean screenshots

If you need to retake a screenshot, run the What If simulation again. The tool does not save previous results, so you will need to re-enter the inputs each time.

Secret mission

Create an Emergency Access (Breakglass) Account

What happens if your Conditional Access policies accidentally lock out every administrator in your tenant? In production environments, organizations create emergency access accounts that bypass all policies. Your mission is to create and validate one following Microsoft best practices.

Clean Up Your Resources

This project runs entirely in your Microsoft Entra ID tenant, so there are no ongoing costs. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

1 Azure free account (no ongoing charges unless you create paid resources).
1 Entra ID P2 trial license (auto-expires after 31 days with no charges, reverts to Free tier).
Entra ID tenant containing test users, security groups, Conditional Access policies, and SSPR configuration (no cost).

Keep everything running

No action needed. Choose this if you are still actively building or plan to explore more Entra ID features while the P2 trial is active.

Your tenant persists indefinitely on the Free tier after the P2 trial expires.
Users and groups remain intact even after the trial ends.
Conditional Access policies will stop being enforced once P2 expires, but the policy configurations remain saved.
SSPR will no longer function for cloud users after P2 expires, since it requires a Premium license.

Pause - I'll come back to this later

There is nothing to pause. The P2 trial auto-expires after 31 days with no action needed on your part.

Your tenant and all configurations stay in place at no cost.
If you return after 31 days, your tenant will be on the Free tier. You can reactivate a P2 trial or purchase a license to re-enable Conditional Access and SSPR.

Delete - I don't want to use this again

Remove all project resources by deleting the entire tenant. This permanently removes all users, groups, policies, and configurations.

In the Entra admin center, navigate to Entra ID > Overview > Properties.
Click Manage tenants.
Select your tenant, then click Delete.
Follow the prompts to confirm deletion. This action is irreversible and removes all data associated with the tenant.

What about the Azure free account?

Deleting the Entra ID tenant removes all identity resources, but your Azure free account subscription remains. Since the free account incurs no charges on its own, you can leave it in place.

If you want to close the Azure account entirely, sign in to the Azure portal at portal.azure.com, navigate to Subscriptions, select your free subscription, and click Cancel subscription.

Nice Work!

Nice work! You just built a complete Zero Trust identity lab in Microsoft Entra ID, simulating the identity infrastructure for a real organization from scratch.

You've learned how to:

Built an organizational structure with security groups and test users modelling real company departments (Northwind Security).
Disabled Security Defaults and implemented two Conditional Access policies enforcing Zero Trust principles: requiring MFA for all users and blocking legacy authentication.
Configured and tested Self-Service Password Reset for the Developers group, then validated all policies using the What If tool to simulate real sign-in scenarios.
Secret Mission: Created an emergency access (breakglass) account following Microsoft best practices and excluded it from Conditional Access policies to prevent tenant lockout.

Ready to quiz yourself?