AB-900 Microsoft Entra ID Security Features: Conditional Access, SSO, PIM, Secure Score and Logs

Microsoft Entra ID is the cloud identity and access management service behind every Microsoft 365 tenant: it holds the users, groups and app identities, authenticates every sign-in, and decides whether that sign-in gets access. Exchange Online, SharePoint, Teams, Copilot and thousands of connected SaaS apps all trust the tokens Entra ID issues, so securing Entra ID secures access to all of them.

Its core capabilities, all managed in the Microsoft Entra admin center, are:

• Identities — member users, guest users, groups, devices, and app identities (application objects and service principals).
• Authentication — passwords, multifactor authentication (MFA), passwordless methods and self-service password reset.
• Access control — security defaults, Conditional Access, single sign-on (SSO) to cloud apps, and admin roles.
• Protection and governance — ID Protection (risky users and sign-ins), Privileged Identity Management (PIM), access reviews and entitlement management.
• Monitoring — sign-in logs, audit logs, provisioning logs and Identity Secure Score.

Which features a tenant can use depends on its Entra ID licence, and many Microsoft 365 plans include one (for example, Microsoft 365 E3 and Business Premium include P1; E5 includes P2).

Security defaults: the free baseline

Security defaults are a free, one-switch set of protections available in every tenant. When turned on, they require every user to register for MFA, prompt users for MFA when needed (always for administrators), protect privileged activities such as access to the Azure portal, and block legacy authentication protocols that cannot do MFA. They suit a small organization on Entra ID Free that wants MFA for everyone without buying anything.

Security defaults are all-or-nothing: you cannot exclude a user or add conditions. Organizations that need that flexibility use Conditional Access, which needs P1 — and the two cannot run together, so security defaults are turned off when Conditional Access policies take over.

The right security object depends on who the person is and what the group must do: employees are member users, external people who keep their own company account are guest users, and access and licences are granted through security groups rather than one user at a time.

User types

A guest is invited by email and becomes a user object in your tenant that authenticates against its home organization. You decide what the guest can reach (for example one SharePoint site); the partner manages the password. Creating a second member account for an outsider gives them yet another password and makes offboarding your job.

Group types

Exchange and SharePoint groups for email and site permissions are covered in the lesson on core Microsoft 365 objects; here the question is which object controls access.

Assigned vs dynamic membership

Membership is either assigned (admins add and remove members by hand) or dynamic: a rule such as user.department -eq "Engineering" evaluates user attributes and adds or removes members automatically as attributes change. A dynamic security group assigned to an app means access follows the person's job with no manual work. Dynamic membership needs Entra ID P1.

Several features automate or scope access in different ways, so match the feature to the need:

A Conditional Access policy is an if–then statement evaluated at every sign-in: if the sign-in matches the policy's assignments and conditions, then its access controls apply. It is Entra ID's policy engine for Zero Trust "verify explicitly" decisions and needs Entra ID P1.

Conditions are signals that arrive with the sign-in: where it comes from, which device and client app it uses, and how risky it looks. A policy can only test what the sign-in request carries. The common patterns are requiring MFA for everyone or for admins, blocking legacy authentication, requiring a compliant device for sensitive apps, and restricting sign-ins from unexpected countries.

Report-only mode and the What If tool

Every policy has a state: On, Off or Report-only. Two tools let you see a policy's effect before it blocks anyone, and they answer different questions.

What If evaluates only policies that are On or in Report-only; an Off policy is ignored. A policy switched On enforces for everyone it targets, even a small pilot group, so impact is measured in report-only first and enforcement follows once the results look right.

Single sign-on (SSO) lets a user sign in once with one work identity and reach every connected app without separate passwords, because each app trusts the token Microsoft Entra ID issues instead of keeping its own accounts. Entra ID supports SSO to Microsoft 365, gallery SaaS apps (using SAML or OpenID Connect), your own registered apps, and on-premises web apps published through application proxy.

The benefits fall on both sides:

• For users: one password to remember, fewer sign-in prompts, fewer resets — less password fatigue and less password reuse.
• For admins: one control point. Because every sign-in passes through Entra ID, the same MFA and Conditional Access policies protect every connected app, sign-ins appear in one set of logs, and the help desk handles fewer reset calls.
• For offboarding: blocking sign-in for one Entra ID account (and revoking its sessions so existing tokens stop working quickly) cuts off every connected app at once, instead of removing the person app by app.

SSO has limits worth knowing. It does not remove MFA — Entra ID still requires MFA where policy says so. It does not license SaaS apps; those subscriptions are bought and assigned separately. And removing a user's Microsoft 365 licence does not stop the account signing in to other apps that trust Entra ID.

App registrations is where you create and define your own application's identity; Enterprise applications is where you manage how any app — yours, a gallery app or another company's — is used in your tenant. Behind the two pages are two different objects.

Registering an app creates its application object and a service principal in the home tenant. When an admin in another organization consents to a multitenant app, Entra ID creates a service principal in that customer's tenant from the vendor's application object. The customer has no App registrations entry for the vendor's app; it restricts sign-in (for example to the Finance group) and reviews the permissions it granted under Enterprise applications in its own tenant. The vendor's objects govern nothing in the customer's tenant.

Two related features have pages of their own: managed identities give Azure resources an identity without any secret to manage, and application proxy publishes on-premises web apps for remote access. A new app that a developer is building starts in App registrations.

The first tool for any failed sign-in is the Microsoft Entra sign-in logs: each entry records whether the attempt succeeded, the error code and failure reason, the app and client app used, the location and device, the authentication details (including MFA), and a Conditional Access tab listing every policy evaluated and its result. A generic error on the user's screen becomes a specific cause in the log.

Legacy authentication failures

Legacy protocols such as IMAP, POP and SMTP with basic authentication send a password and cannot perform MFA, which is why security defaults and most Conditional Access baselines block them. When the sign-in log shows a legacy client app failing because of such a policy, the cause is the protocol, not the password. So the fix belongs on the client side: the policy keeps applying to everyone, and the user moves to a modern-authentication client such as current Outlook.

MFA method problems

When a user replaces or loses the device that holds their MFA method, the password still works but the second factor does not. On the user's Authentication methods page, the admin selects Require re-registration of multifactor authentication, so the user registers a new method at next sign-in. A password reset leaves the lost method in place, and revoking sessions only signs the user out everywhere — useful if the lost device is a risk, but it does not give the user a working factor. (A Temporary Access Pass can also help a user register a new method; it is covered with authentication methods in the security principles lesson.)

Microsoft Entra ID Protection detects identity risk using Microsoft's threat intelligence and reports it as risky sign-ins, risky users and risk detections. It is the feature that answers "was this sign-in really made by the account owner?" Full reports and risk-based policies need Entra ID P2.

Risk-based policies are configured as Conditional Access policies using the user-risk or sign-in-risk condition (the older policies inside ID Protection were retired in October 2026). For high user risk, Microsoft now recommends the Require risk remediation grant control: users with passwords complete MFA and then a secure password change, and passwordless users have their sessions revoked and sign in again. The older Require password change grant still works for password users. For users to fix risk themselves without a help-desk call, they must already be registered for MFA (and self-service password reset helps). A policy that simply blocks high-risk users protects the account but cannot be self-remediated: an admin must reset the password or dismiss the risk.

Each identity feature in this lesson answers its own question:

Identity Secure Score is a percentage showing how closely a tenant's identity configuration follows Microsoft's recommended security practices — a score of 48% means about half the available points from those recommendations have been earned. It is the identity part of Microsoft Secure Score, found in the Microsoft Entra admin center under Entra ID > Identity Secure Score (also reachable from the Overview's Recommendations with the Security filter), and is recalculated about every 24 hours.

The score is built from improvement actions such as requiring MFA for administrators, blocking legacy authentication, enabling self-service password reset, and using fewer Global Administrators. Each action is worth points and some can be partially earned (for example when MFA covers only some users). The score measures configuration against recommendations, which is different from predicting whether an attack will succeed, and because it adds up many actions, any one setting moves it only by that action's points.

Use the "resolved" statuses only when the control really exists, so the score reflects your true posture. Some actions need a paid licence (for example risk-based policies need P2), so the score can also reveal where licensing limits what you can adopt.

Which log you open depends on the question: Entra audit logs answer "who changed what in the directory", Entra sign-in logs answer "who signed in and how did it go", and Microsoft Purview Audit answers "what did users and admins do across Microsoft 365" over a longer period.

Audit (Standard) comes with Microsoft 365 E3 and similar plans. Because the unified audit log combines workloads and keeps records longer, it is the place to find, for example, an Entra role change and a SharePoint file deletion from several months ago when nothing was exported — the Entra audit log would have dropped the role change after 30 days and never recorded the file deletion. To keep Entra logs longer, export them to a Log Analytics workspace, storage account or SIEM.

Privileged Identity Management (PIM) gives administrators just-in-time, time-bound and approval-based access to privileged roles, so nobody holds powerful roles permanently "just in case". It applies Zero Trust least privilege to Entra ID roles (such as Global Administrator or Exchange Administrator), Azure resource roles and privileged groups, and needs Entra ID P2 or Microsoft Entra ID Governance.

Both eligible and active assignments can be time-bound with start and end dates, so access ends automatically. An eligible assignment with approval required is how you make someone ask for a role and wait for a manager's sign-off each time; a time-bound active assignment simply grants the role until it expires.

PIM also sends notifications when roles are activated, runs access reviews of who still needs a role, raises alerts about risky privileged-role configuration, and keeps an audit history of activations. Groups that can be assigned to roles (role-assignable groups) use assigned membership only, so privileged access is always granted deliberately rather than by a changing attribute.