Identity security — the system that decides who is allowed into your company's digital front door and what they can touch once inside. For the SC-100 exam, you must understand how to design this system at a high level because a single misconfiguration can let an attacker walk in as if they own the place. Microsoft Entra ID is the tool you design with, and this chapter shows you how to think about it like an architect rather than a technician.
Jump to a section
A simple way to picture Designing Identity Security Strategies with Microsoft Entra ID
12 cars queue for the Express Wash Bay at a busy petrol station. Each car has a driver with a key fob. The wash bay must check two things: first, is this key fob authorised to enter the bay? Second, which wash programme does this specific car get — basic rinse, triple foam, or underbody blast?
The station owner installs a system called the "Bay Manager". Every car pulls up to a scanner. The scanner reads the key fob's unique ID, consults a master list, and instantly decides: "Yes, Car #7 is a Gold Member — it gets the full wax package and a 20% discount on tyres." It also checks: "Car #2 is not in the database. Raise the security barrier and flash a red light." The Bay Manager does not wash the cars itself. It only grants the right kind of access to the wash equipment.
Now imagine the petrol station has 200 branches across the country, and a gold member from Manchester should get the same treatment in a branch in Brighton. The Bay Manager must share that member's privileges across all locations, update them in real time if their subscription changes, and refuse entry to a stolen key fob immediately. It also lets the branch manager define special rules — for example, "Loyalty programme cars always skip the queue."
This is exactly how Microsoft Entra ID works. The cars are users. The key fobs are their identities. The Bay Manager is the identity and access management (IAM) system that decides who gets in, what they can do, and automatically blocks anyone who does not belong — all while keeping a unified list across every part of the organisation.
Microsoft Entra ID is a cloud-based identity and access management (IAM) service. IAM is the practice of making sure the right people have the right level of access to the right resources at the right time. Before cloud computing, companies managed this with on-premises Active Directory (AD) — a server in a closet that held a list of every employee and their computer permissions. You had to be inside the office network to use it, and managing permissions for remote workers was a nightmare.
Entra ID (formerly called Microsoft Entra ID) solves that by living in Microsoft's cloud. You log in from anywhere — home, coffee shop, airport — and Entra ID verifies your identity against its central database. It does not store your actual password. Instead, it issues a token, which is a small encrypted file that acts like a digital wristband. That token says, "This person is Sarah, and she is allowed to read the sales reports but not delete them." Every time Sarah clicks a protected resource (like a SharePoint site or a finance app), her browser presents that token, and the resource checks with Entra ID: "Is this token still valid?" This is called authentication (proving who you are) and authorisation (what you are allowed to do).
Why does this matter for an architect? Because you must design how identities are created, protected, and governed. Here are the key building blocks you need to know for SC-100:
Identities: Every human user (employee, contractor, partner) gets a digital identity in Entra ID. That identity is a set of attributes — name, email, job title, department, phone number. It is like a digital passport. Devices (laptops, phones, IoT sensors) also get identities so the system can decide if a device is healthy enough to access company data.
External Identities: Partners, vendors, and customers are not your employees. You can invite them as guests using Entra ID External Identities. They use their own credentials (like a Google account or a personal Microsoft account) to sign in. This is called B2B (business-to-business) collaboration. You control exactly which folders or apps the guest can see without giving them a full employee account.
Conditional Access: This is the most powerful policy engine in Entra ID. Think of it as an if-then rule for every sign-in attempt. The rule says: "IF the user is in Sales AND IF they are signing in from a trusted device AND IF they are in the office network, THEN allow access to the CRM without a second factor. If any condition fails, block access or require multifactor authentication (MFA)." You chain together signals — user group, location, device state, application risk, sign-in risk — to make a real-time decision. This is how you enforce zero-trust architecture, where no one is trusted automatically just because they are inside the network.
Privileged Identity Management (PIM): Some users need super-admin powers temporarily — for example, a helpdesk person who resets passwords for executives. With PIM, you give them time-limited roles that they have to activate, often with an approval from a manager and a justification note. This stops the problem of permanent standing access. If an attacker steals a regular user's password, they do not automatically get admin rights because those rights are not always active.
Identity Governance: This is the process of reviewing who has access to what, regularly. Entra ID provides access reviews where managers are sent a list of their team members and asked: "Does John still need access to the financial database? Yes or No?" If a manager does not respond, the access is automatically removed. This is how organisations stay compliant with regulations like GDPR or HIPAA. You also use entitlement management to create packages of access — for instance, a "New Marketing Lead" package that automatically gives access to the marketing folder, the design tool, and the campaign calendar for 90 days.
Identity Protection: Entra ID uses Microsoft's threat intelligence to detect risky behaviour. If an account tries to sign in from New York and five minutes later from Tokyo, that is flagged as impossible travel. If a user logs in from a known malicious IP address, that session gets blocked or challenged with MFA. Identity Protection assigns a risk score to users and sign-ins. You can automate responses — for example, "If user risk is high, force a password reset the next time they sign in."
All of these pieces work together. You do not set up each one in isolation. You design a strategy where identities are created from a human resources system (when someone joins the company, their identity is automatically provisioned), governed through access packages and reviews, protected by conditional access and risk policies, and finally monitored for anomalies. The SC-100 exam tests whether you can choose the right combination of these services for a given business requirement.
1. Identify Identity Sources
Map all sources of identities: HR system (Workday, SAP), on-premises AD, external partners, and customers. Decide which identities will be cloud-only (new hires) and which will synchronise from on-prem systems using Microsoft Entra Connect Sync. This step is critical because you cannot design policies until you know where every identity comes from and how it gets updated.
2. Plan Authentication Methods
Choose which authentication methods your organisation will support: password (with MFA), passwordless (Windows Hello, FIDO2, Authenticator app), or federated (using an external identity provider). For high-security roles (finance, IT admins), mandate phishing-resistant methods like FIDO2 security keys. This choice directly affects how Conditional Access policies are written later.
3. Design Conditional Access Policies
Write if-then rules for every application and user group. Define the conditions: user group, device compliance, location (IP or country), application, and sign-in risk. Define the controls: block, require MFA, require device compliance, require approved client app. Organise policies in a specific order (most restrictive first) because only the first matching policy applies per session.
4. Configure Privileged Identity Management (PIM)
Identify all roles that can cause damage if misused — Global Admin, User Admin, Security Admin, Application Admin, and Azure resource roles. Configure PIM for each role: require activation with justification, approval workflow, and a maximum activation time (e.g., 4 hours). Also set up alerts for any unauthorised activation attempts.
5. Implement Identity Governance
Create access packages for common roles and projects — e.g., "New Sales Rep" package grants access to CRM, email shared mailbox, and sales training site for 90 days with auto-expiry. Schedule recurring access reviews for sensitive applications and high-privilege roles. Set up automatic removal of access if the reviewer does not respond within 30 days. This ensures no orphaned accounts accumulate.
6. Enable Identity Protection and Monitoring
Turn on Identity Protection risk policies for sign-in risk and user risk. Configure automated responses: automatically block high-risk sign-ins, force password reset for medium-risk user accounts. Integrate with Microsoft Sentinel or a SIEM tool to receive alerts for repeated risk events. Create a playbook for responding to users whose accounts are flagged as compromised.
A mid-sized retail company called "GreenLeaf Organics" is migrating its HR and finance systems to the cloud. They have 1,200 employees, 200 seasonal warehouse workers, and 50 external accountants who handle quarterly audits. The IT director asks you to design the identity security strategy. Here is exactly what you do as an architect:
First, you map out every identity type. You plan to synchronise employee identities from their on-premises HR system (Workday) into Entra ID using Microsoft Entra Connect Sync. This way, when HR hires a new store manager, the identity is created automatically without an IT person typing it in. You create a separate group for warehouse workers because they only need access to the inventory app and a shared calendar. You invite the external accountants as Microsoft Entra B2B guest users — they authenticate with their own email accounts, and you scope their access to exactly one finance folder and no other data.
Second, you configure conditional access policies. You write this rule: "For all users in the Finance group, require MFA and a compliant device (a device that has antivirus enabled and the latest OS patches) when accessing the financial management app. Block access if the sign-in comes from any country outside the US and UK — the company only operates in those two countries." You also create a policy for the warehouse workers: "Allow access to the inventory app from warehouse IP addresses only, between 6am and 10pm." Any login outside those conditions is blocked or challenged.
Third, you set up Privileged Identity Management (PIM). You identify three roles that are especially dangerous: Global Administrator, User Administrator, and Application Administrator. You configure PIM so that any user who needs one of those roles must request activation, write a short justification, and get approval from the IT manager. You set the maximum activation time to 4 hours. This means if an attacker compromises a Global Admin's regular user account, they cannot use the admin powers because those powers are not active. They would need to also bypass the approval process.
Fourth, you plan identity governance. You schedule quarterly access reviews for the finance app — the head of finance receives an email asking to approve or remove each user. If they ignore the review for 30 days, access is automatically removed. You also create an access package for the seasonal warehouse workers that expires in 90 days, matching the length of the seasonal contract. When the 90 days are up, their access is automatically revoked.
Finally, you enable Identity Protection. You set a policy that automatically blocks sign-ins with a high risk score and forces a password reset for medium-risk users. The auditors from the external accounting firm are excluded from this policy to avoid disrupting their work, but their session duration is limited to 2 hours before they must re-authenticate.
As an architect, you document all of these decisions in a blueprinted design document and explain to the IT director that this strategy reduces the risk of a data breach by eliminating standing admin access, automating access removal for former employees, and verifying every sign-in attempt with real-time risk analysis. You do not configure the technical settings yourself (that is the job of an implementation engineer), but you provide the design that the engineers follow.
The SC-100 exam (Microsoft Cybersecurity Architect) is not a how-to-click-through-the-UI exam. It tests your ability to design solutions at a conceptual level. For objective 2.1 (Design solutions for identity and access management), expect scenario-based questions where you are given a business requirement and must choose the correct combination of services and policies. Here are the specific things they love to test:
Conditional Access policy order and conditions: You will get a scenario with multiple user groups, locations, and applications. They will ask: "Which conditional access policy meets the requirement?" The trick is that policies are evaluated in a specific order — if a policy applies, subsequent policies do not run. So if you have a policy that blocks all access for users from a risky IP and another policy that requires MFA for the same users, the block policy will prevent the MFA policy from ever triggering. You must understand that conditional access policies are combined as an OR for each user.
The difference between Authentication Strength and Conditional Access MFA: Authentication Strength is a newer concept that lets you specify exactly which MFA methods are acceptable (e.g., only FIDO2 security keys, no SMS codes). Conditional Access just says "require MFA". The exam expects you to know when to use Authentication Strength (high-security environments like finance) versus basic MFA.
Entra ID licensing tiers: Not all features are available in all editions. P1 (free with most Microsoft 365 subscriptions) gives you basic conditional access and MFA. P2 (paid) adds Identity Protection, PIM, and identity governance. The exam will give you a scenario where a company has a limited budget and you must recommend what they can achieve with P1 versus what requires P2. Common trap: they ask for "risk-based conditional access" which requires P2 because Identity Protection is a P2 feature.
External Identities vs. B2B vs. B2C: They will test that B2B is for inviting external users (partners, vendors) who already have their own identity provider (Google, Microsoft, Facebook). B2C is a separate service for customer-facing applications — it allows millions of consumers to sign up with email or social accounts. The exam might describe a scenario where a company wants to let customers sign in with their own social media accounts — that is B2C, not B2B.
Delegated administration and administrative units: They love to test that you can scope admin roles to specific parts of the organisation. For example, a helpdesk admin for the UK office should only be able to reset passwords for UK users, not for users in other countries. The solution is Administrative Units — you create an AU for "UK Employees" and assign the helpdesk admin role scoped to that AU.
Passwordless authentication methods: The exam expects you to know the three main passwordless methods: Windows Hello for Business (biometric on a device), Microsoft Authenticator app (push notification with number matching), and FIDO2 security keys (hardware tokens). They will ask which one is appropriate for different device types (shared kiosk devices need FIDO2 keys because you do not want biometric data stored on a shared machine).
Identity Protection risk types: You must memorise the two main risk types: sign-in risk (something suspicious about the sign-in attempt itself, like an anonymous IP address) and user risk (the user's account may have been compromised, indicated by leaked credentials or impossible travel). They test which policy you apply to each: sign-in risk policies act on the session (block or require MFA), while user risk policies act on the account (force password reset or block further sign-ins until an admin intervenes).
Trap pattern: A question will say "A company wants to ensure that employees can only access the CRM app from company-managed laptops." The answer is Device Compliance policy combined with Conditional Access requiring compliant device — not simply requiring MFA. Another common trap: "Require Multi-Factor Authentication for all users" is not the most secure or practical answer — they want you to use Conditional Access to apply MFA based on risk, not a blanket policy that covers every single login, because that would frustrate low-risk internal users on a trusted network. The correct pattern is always "risk-based conditional access" over blanket MFA.
Key terms to memorise exactly for the exam: Zero-Trust (verify explicitly, least privilege, assume breach), Conditional Access (if-then engine), PIM (just-in-time access), Identity Governance (access reviews, entitlement management), Identity Protection (risk scoring), and External Identities (B2B vs B2C). Every answer must align with the Zero-Trust principle — if an answer suggests implicitly trusting users because they are on the corporate network, it is always wrong on SC-100.
Microsoft Entra ID is an identity and access management (IAM) service for cloud and SaaS apps, completely separate from on-premises Active Directory in both protocol and architecture.
Conditional Access is the core policy engine that enforces zero-trust by making real-time access decisions based on user, device, location, application, and risk signals.
Privileged Identity Management (PIM) implements just-in-time (JIT) access for administrative roles, eliminating permanent standing admin privileges that attackers target.
Identity Protection uses machine learning to detect risky sign-ins and compromised accounts, and can automatically block or remediate threats without human intervention.
External Identities (B2B) allow partners and vendors to use their own credentials to access your resources, avoiding the need to manage separate accounts and passwords for them.
Identity Governance with access reviews and entitlement management ensures that access is regularly certified and automatically removed when no longer needed, keeping the organisation compliant.
Passwordless methods like FIDO2 keys and Windows Hello for Business reduce the risk of phishing attacks because there is no password to steal.
You must map each business requirement to a specific Entra ID feature — blanket 'turn on MFA' is rarely the architecturally correct answer on SC-100.
These come up on the exam all the time. Here's how to tell them apart.
Conditional Access (CA)
Creates if-then rules based on user, device, location, app.
Enforces actions like block, require MFA, or require device compliance.
Works on every sign-in attempt regardless of risk signal.
Identity Protection (IP)
Analyses sign-in behaviour and user activity for anomalies (impossible travel, leaked credentials).
Assigns risk scores (low, medium, high) to sign-ins and user accounts.
Takes automatic actions only when risk reaches a defined threshold.
Privileged Identity Management (PIM)
Microsoft's specific service for managing admin role activation in Entra ID.
Supports approval workflows, reason justification, and time-bound roles.
Can apply to both Entra ID roles and Azure resource roles.
Just-in-Time (JIT) Access
A general security principle of granting access only when needed.
Can be implemented through PIM or through other tools (e.g., Custom Role definitions).
The opposite of standing access (permanent rights).
B2B External Identities
Designed for partners, vendors, and contractors who already have an identity.
Guest users authenticate with their own corporate or social ID.
Managed within the same Entra ID tenant as employees.
B2C Customer Identities
Designed for consumers signing up to your own custom application.
Users create a new account or authenticate with social logins (Facebook, Google).
Operates in a separate Azure AD B2C tenant, isolated from employee identities.
Password Authentication
Requires a memorised string that can be phished, guessed, or stolen.
Users must provide the password at every sign-in unless SSO caches it.
Supported by all legacy applications and devices.
Passwordless Authentication
Biometric (fingerprint, face), FIDO2 key, or mobile app push notification replaces the password.
Resistant to phishing because there is no shared secret to steal.
Not all older applications support passwordless yet — requires conditional access to enforce.
Mistake
Microsoft Entra ID is just a cloud copy of the old on-premises Active Directory (AD). You can treat them the same way and just move your domain controllers to the cloud.
Correct
Entra ID is a completely different technology. On-premises AD is based on LDAP and Kerberos protocols. Entra ID uses REST APIs and OAuth 2.0 / OpenID Connect. You cannot join computers to Entra ID the same way you join them to an on-prem domain. Entra ID is for identity and access management in cloud and SaaS apps, not for managing network logon to a Windows PC inside a building.
The name 'Azure Active Directory' created a false equivalence. People assumed it was a hosted version of the on-prem AD product they already knew, so they tried to apply the same concepts and got confused when it did not work.
Mistake
If I enable Multi-Factor Authentication (MFA) for all users, my organisation is completely secure and I do not need anything else.
Correct
MFA is a critical layer, but it is not a silver bullet. Attackers can still use MFA fatigue attacks (sending endless push notifications until the user accidentally approves), or they can steal session tokens after the user has authenticated. You must also use Conditional Access policies (like blocking sign-ins from unexpected locations) and Identity Protection risk policies to catch anomalies even after MFA is completed.
Many vendors and cybersecurity awareness campaigns over-simplify security to 'just turn on MFA', so beginners internalise that as the ultimate solution. They do not understand that MFA protects the password but does not protect against token theft or social engineering of the MFA process itself.
Mistake
When I invite a guest user using External Identities (B2B), I need to create a full user account for them in my Entra ID tenant with a password.
Correct
B2B guest users do not get a new account in your tenant — they use their existing identity from their own organisation (Google, Microsoft, or another Entra ID tenant). You simply invite their email address, and when they accept, a lightweight guest object is created that references their external identity. They authenticate against their own home identity provider, not your tenant.
People are used to the old model of 'create a user in directory X, give them a password, and tell them the password'. The concept of federation and external identity providers is unfamiliar, so beginners assume a new account is always necessary.
Mistake
Conditional Access policies are applied the same way to every user regardless of their group membership, as long as they are connected to the network.
Correct
Conditional Access policies are applied per user, per session, based on a combination of signals including user group membership, location (IP address range or country), device state (compliant vs non-compliant), application being accessed, and sign-in risk. Two users sitting in the same office at the same time can have completely different access decisions depending on which groups they belong to and which app they are trying to open.
Beginners think of network-level security ('if you are on the VPN, you are trusted') and try to apply that logic to a modern identity system. They do not grasp the granular, user-centric nature of Conditional Access, which is central to zero-trust architecture.
Mistake
Privileged Identity Management (PIM) is only useful for assigning the Global Administrator role, because that is the most powerful role.
Correct
PIM can be applied to any Azure AD role (User Admin, Billing Admin, Security Admin, etc.) and even to Azure resource roles (like Contributor or Owner on a subscription or resource group). The most useful application of PIM is often for lower-level but still dangerous roles like User Administrator (who can reset passwords for non-admins) or Application Administrator (who can grant app permissions without admin consent).
Beginners think only the top-level role matters because they do not understand the chain of compromise. Attackers often target lower-level admins because their actions are less monitored, and from there they can escalate privileges. PIM for all admin roles is the correct approach.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
On-premises AD is a directory service that manages Windows computers and network logon inside a corporate network using LDAP and Kerberos. Entra ID is a cloud IAM service that manages access to web applications (SaaS apps, Azure resources) using REST APIs and OAuth 2.0. They use different protocols and are not interchangeable — you typically need both in a hybrid setup.
No. Conditional Access basic features are available with Entra ID P1 (included in most Microsoft 365 E3/E5 plans). However, risk-based Conditional Access (using Identity Protection signals) requires Entra ID P2. P2 also includes Privileged Identity Management and Identity Governance features. Check your license tier before designing policies.
Yes, but you should carefully scope the policy. Create separate Conditional Access policies for external users because they may have different device compliance requirements and you cannot enforce device compliance policies on a guest's device. It is safer to target external users with policies that require MFA and limit session duration instead of requiring a compliant device.
B2B guest users are used for business partners and vendors who already have an existing identity (Microsoft, Google, or another corporate ID). You invite them, they accept, and they access your apps. B2C is a separate service for building customer-facing applications where customers sign up with social accounts (Facebook, Gmail) or email. B2C is for external consumers, not partners.
JIT access means users do not have permanent admin rights. Instead, they activate an admin role only when they need it, for a limited time (e.g., 4 hours), and with an approval if required. If an attacker steals the user's normal credentials, they cannot use admin powers because those powers are not always active. This is the opposite of 'standing access' where the user has the role permanently.
Do not reuse the old account. When the employee leaves, remove or block their Entra ID account and remove their group memberships using a lifecycle workflow. If they return, create a fresh identity through the HR system provisioning process. Reusing old accounts can lead to orphaned security groups and stale permissions that violate compliance requirements.
Impossible travel is a risk detection that flags a sign-in where the user authenticates from one location and then attempts a second sign-in from a faraway location within an impossibly short time. For example, a sign-in from New York, then 5 minutes later from London. This usually indicates that an attacker has stolen the user's credentials and is using them from a different location, while the legitimate user is elsewhere.
You've finished Designing Identity Security Strategies with Microsoft Entra ID. Continue through the SC-100 study guide to build a complete picture of the exam.
Done with this chapter?