Identity is the control plane for modern Microsoft environments. Users, administrators, applications, service principals, managed identities, external partners, devices, and increasingly agents all rely on identity to reach resources. When network location is no longer a reliable trust boundary, security architecture has to decide who or what is requesting access, how strongly that identity was verified, what context is present, and how much privilege is justified.
The current SC-100 scope treats identity as a Zero Trust design problem, while SC-300 covers the implementation and administration depth of Microsoft Entra. A strong architecture connects authentication, Conditional Access, risk, privileged access, external identities, workload identities, governance, and lifecycle management instead of treating each feature as a separate project.
Make strong authentication the default trust foundation
Test recovery paths regularly so strong authentication does not depend on an unprotected fallback nobody has reviewed.
Authentication strength should match the resource and the risk, not the convenience of the oldest application. Prefer phishing-resistant methods for privileged and sensitive scenarios, retire weak legacy protocols, and document where exceptions remain. Registration and recovery are part of the same security boundary: an attacker who can take over the recovery process can bypass an otherwise strong sign-in method. Protect enrollment, recovery, help-desk procedures, and break-glass access with the same care as daily authentication.
Password-only authentication is too weak for sensitive environments. Microsoft Entra supports stronger methods such as passkeys based on FIDO2, Windows Hello for Business, certificate-based authentication, and other passwordless options. The goal is not simply “turn on MFA,” but move important users toward methods that resist phishing and replay.
Traditional push-based MFA is still better than passwords alone, yet attackers can abuse user fatigue, session theft, and social engineering. Understanding multifactor authentication is a starting point; architects should go further by defining authentication strengths for privileged and high-risk access.
Plan registration and recovery before enforcement. A security team can create an excellent policy and still cause an outage if administrators lack an accepted method or cannot recover after losing a device. Strong authentication needs staged rollout, user readiness, help-desk procedures, and protected emergency accounts.
Use Conditional Access as a policy engine, not a collection of ad hoc rules
Maintain a change process for policy updates. A small condition change can affect thousands of users or break automation, so use peer review, emergency rollback, named owners, and tested exclusions. Treat access policy as production configuration rather than an informal portal setting.
Policy sprawl creates hidden gaps and contradictory behavior. Define a small set of design intents—require strong authentication, block unsupported conditions, protect privileged access, control unmanaged devices, and respond to risk—then implement them with named policies and documented exclusions. Use report-only evaluation before broad enforcement and review exclusions on a schedule. The objective is predictable access decisions that can be explained during troubleshooting and audited after an incident.
Conditional Access combines identity, device, application, location, risk, authentication strength, and other signals to make access decisions. The architecture should begin with desired outcomes: which users and workloads may access which resources, under what conditions, and what control should be required when risk increases.
Avoid dozens of overlapping policies that nobody can reason about. Build a small baseline, document exclusions, use report-only mode for major changes, and analyze sign-in logs before enabling blocking behavior. Policies should be named by purpose and ownership so incident responders can understand them quickly.
Use authentication strength when a workload requires phishing-resistant methods rather than a generic MFA requirement. Protect high-risk administrative actions more strongly than low-risk collaboration. Zero Trust is not maximum friction; it is explicit verification that matches the sensitivity of the access request.
Use identity risk and continuous evaluation to respond to changing context
Zero Trust assumes that trust can change during a session. A user who authenticated correctly can become risky later because credentials are leaked, a device state changes, or a new signal indicates compromise. Design response paths that can require reauthentication, block access, revoke sessions, reset credentials, or escalate investigation. The operational detail matters: security teams need to know which signals are automated, which require human review, and how users recover from false positives.
Access should not be a one-time decision made at sign-in and trusted indefinitely. Microsoft Entra ID Protection can contribute user and sign-in risk signals, while Continuous Access Evaluation can help supported services react more quickly to important security events and policy changes.
Risk-based controls should be designed carefully. Automatically blocking every anomaly can create false positives, while ignoring risk loses one of the main benefits of cloud identity. Define what happens at low, medium, and high risk and which users require stronger handling because of privilege or business criticality.
Investigations should combine identity signals with endpoint and security-operations context. A suspicious sign-in from a normal device is different from a suspicious sign-in followed by endpoint malware, mailbox rules, or privilege changes. Identity security becomes stronger when signals are correlated across the environment.
Protect privileged roles with just-in-time access and emergency recovery
Separate everyday productivity identities from administrative use where risk justifies it, minimize permanent role assignment, require approval or strong authentication for elevation, and record why elevation occurred. Emergency accounts should be rare, protected, monitored, and tested rather than forgotten. Privileged access controls also need coverage for Azure resources, Microsoft 365, security tooling, and application administration; protecting only directory roles leaves other control planes exposed.
Permanent administrator privileges create standing attack paths. Microsoft Entra Privileged Identity Management can make eligible access time-bound, require approval or strong authentication, and create an auditable activation process. Use separate administrative accounts where appropriate and minimize the number of identities that can grant other privileged roles.
Emergency access accounts are different from ordinary administrators. They exist so the organization can recover when normal identity controls fail. Protect them with strong credentials, monitor their use, exclude them from controls that could lock out every administrator, and test the recovery process. An emergency account that has never been tested is only a theory.
Privileged access should also include Azure and application roles, not only Entra directory roles. Review who can change subscriptions, Key Vault, networking, security policy, and application permissions. Privilege often accumulates across platforms even when each individual role assignment looks reasonable.
Treat workload and agent identities as first-class security principals
For high-value workloads, include identity permissions in deployment review. Infrastructure-as-code and policy can detect broad role assignments before they reach production, while access reviews can catch drift later. Tie each nonhuman identity to a repository or service owner so investigators can quickly answer why it exists, what it should access, and whether disabling it will break a critical dependency.
Nonhuman identities often outnumber people in cloud estates, yet they can receive less governance. Inventory service principals, managed identities, application registrations, federated credentials, and agent identities; record ownership and intended permissions; and remove abandoned objects. Avoid broad application permissions when delegated or resource-scoped access is sufficient. Because these identities may operate continuously without an interactive sign-in, monitor anomalous token use and privilege changes rather than relying on user-focused controls alone.
Applications and automation can be more privileged than people because they operate continuously and at machine speed. Prefer managed identities or federated workload credentials over embedded secrets. Grant narrow roles and separate components that need different permissions.
AI agents add another identity question: what identity does the agent use when it calls a tool? If it always uses a highly privileged application identity, every user who can prompt the agent may gain indirect access to that privilege. If it uses delegated user permissions, the application must preserve user context and authorization correctly.
Review nonhuman identities regularly. Stale service principals, unused credentials, expired certificates, broad API permissions, and ownerless apps are common attack paths. Identity governance should cover machines and agents as deliberately as employees.
Design external identity and cross-tenant access intentionally
Guest and partner access should have a lifecycle just like employee access. Define who can invite external users, which authentication claims are trusted from another tenant, what resources guests can reach, and how dormant relationships are removed. Cross-tenant settings can reduce friction between known organizations, but they also establish trust assumptions that need owners, review dates, and a tested way to revoke access if the partnership changes.
Partners, suppliers, customers, and acquired companies need access without becoming invisible exceptions. Microsoft Entra External ID and cross-tenant access settings can control inbound and outbound collaboration, trust external MFA or device claims where appropriate, and restrict which tenants or users can participate.
Do not solve partner access by creating unmanaged local accounts indefinitely. Use B2B collaboration or other supported external-identity patterns so access has an owner, a lifecycle, and policy enforcement. Periodic access reviews are especially important because external users can remain after the business relationship changes.
Federation and trust should be explicit. A claim accepted from another tenant changes the security decision in your tenant. Document which signals are trusted, which resources are exposed, and how the relationship is removed when the partnership ends.
Use access reviews and lifecycle governance to remove stale access
Automate routine lifecycle steps where the business source is trustworthy, but retain controls for exceptional access. Contractors, emergency administrators, shared operational duties, and temporary projects often need time-bound entitlements rather than permanent group membership. Expiration and reapproval are powerful because they force access to justify itself again.
Lifecycle controls should follow real joiner, mover, and leaver events. Role changes are particularly important because people often accumulate access when old permissions are never removed. Review high-impact groups, privileged roles, external users, application access, and entitlement packages on a cadence that reflects risk. Give reviewers enough context to make a decision; a list of unfamiliar names without business ownership encourages rubber-stamping rather than governance.
Least privilege is not achieved once. People change teams, projects end, contractors leave, and emergency permissions become forgotten. Access reviews, entitlement management, and Lifecycle Workflows help organizations validate and remove access over time.
The broader concept of access control becomes operational through recurring review. Assign reviewers who understand the business need, give them enough context to make a decision, and define what happens when they do not respond. A review that always renews access by default may create an audit artifact without reducing risk.
Connect identity lifecycle to authoritative sources such as HR systems where practical. Joiner, mover, and leaver workflows should create and remove access predictably. Manual tickets can remain for exceptional cases, but they should not be the only control preventing former employees from retaining privileged access.
Reduce authentication friction without weakening assurance
Security and usability are not opposites when policy uses context well. Strong single sign-on, device trust, phishing-resistant authentication, and well-designed Conditional Access can reduce repeated prompts for normal users while increasing scrutiny for risky sessions. Measure help-desk volume, failure rates, bypasses, and risky sign-ins after policy changes. Persistent user pain can indicate a design problem that eventually drives unsafe workarounds.
Security programs fail when controls are so painful that users work around them. Single sign-on, passwordless authentication, device trust, and risk-aware Conditional Access can reduce repeated prompts while maintaining stronger assurance. A well-designed single sign-on experience centralizes policy instead of encouraging password reuse across applications.
Measure user readiness before enforcing stronger authentication. Registration campaigns, pilot groups, help-desk preparation, and clear communications are part of security architecture because they influence whether a control can be deployed safely.
Also monitor for abuse of weaker fallback methods. Attackers often target recovery, legacy protocols, help-desk processes, or temporary exceptions rather than the strongest authentication path. The secure design has to include the edges of the authentication lifecycle.
Connect Entra telemetry to the wider detection and response architecture
Prepare identity containment as an engineering capability. Document how to revoke sessions, disable or restrict an account, remove privileged roles, rotate application credentials, and preserve evidence. Some incidents require immediate containment; others require watching an attacker long enough to understand scope. Security operations and identity teams should agree on those tradeoffs before a high-impact compromise forces them to decide under pressure.
Identity signals become more valuable when correlated with endpoint, email, application, and cloud activity. A risky sign-in followed by unusual mailbox access, token use, or endpoint behavior tells a stronger story than any event alone. Route the right Entra audit, sign-in, risk, and privilege-change telemetry into the security operations workflow, define containment actions in advance, and preserve enough history to investigate slow-moving attacks that cross several identity and resource boundaries.
Identity events should feed security operations. Sign-in logs, audit logs, risky users, role activations, application consent, service-principal changes, and Conditional Access results can reveal both attack activity and control failures. Correlating those signals with Defender XDR and Sentinel improves incident context.
Train responders to recognize identity attack patterns such as token theft, MFA fatigue, suspicious consent, privilege escalation, impossible travel, and compromised service principals. The MFA fatigue threat is one example of why authentication events need behavioral context, not just success or failure status.
Identity security is strongest when the architecture can answer three questions quickly: who accessed the resource, why the policy allowed it, and how the organization can revoke that access. Microsoft Entra provides the control plane, but disciplined design and operations determine whether it actually delivers Zero Trust.