Skip to content

Identity and Access (Microsoft Entra ID)

⚠ Note: These controls live in your Microsoft Entra tenant, not in SenseOn. SenseOn ingests Entra sign-in and audit telemetry through Data Connectors and will detect and escalate suspicious authentication activity, but it cannot enforce Conditional Access or MFA policy for you.

Identity is where most of the cases SenseOn escalates begin. In practice a compromised account is cheaper for an attacker than a compromised endpoint: it needs no malware, it survives a device rebuild, and it is often indistinguishable from legitimate access until something is exfiltrated. The controls on this page are ordered by how often their absence turns a phishing email into an incident.

Entra ID admin centre navigation and policy names change frequently. Verify against the linked source before deploying. Where a control needs a licence above Microsoft Entra ID P1, that is called out.

Before you change anything

Emergency access accounts

Create these first. Everything else on this page can lock you out of your own tenant.

Microsoft's guidance is at least two cloud-only emergency access accounts, sometimes called break-glass accounts:

  • Cloud-only, using the .onmicrosoft.com domain, so they do not depend on federation or on-premises synchronisation.
  • Permanently assigned Global Administrator, not eligible through Privileged Identity Management, so they work when PIM does not.
  • Excluded from every Conditional Access policy, including the ones you have not written yet. Build the exclusion into your policy template.
  • Not tied to any individual employee, with credentials split and held in physical escrow.
  • Monitored. Any sign-in from one of these accounts should raise an alert, because a legitimate use is rare and an illegitimate one is critical. SenseOn will surface these once Entra sign-in logs are connected.

⚠ Test them on a schedule. An untested break-glass account is an assumption, not a control. Validate a sign-in at least every 90 days, and always immediately after a significant Conditional Access change. Note that excluding an account from MFA policy means it must have a long, randomly generated password.

Use report-only mode

Every Conditional Access policy supports Report-only state. It evaluates the policy against real sign-ins and records what would have happened without affecting the user. Deploy every new policy this way first, review the results in Sign-in logs under the Report-only tab, then switch to On.

The What If tool under Protection > Conditional Access lets you model a specific user and application against your policy set before you deploy at all. Use both.

Block legacy authentication

This is the single highest-value identity control, and it is the prerequisite for every other one.

Legacy authentication refers to protocols that do not support modern authentication: older mail clients using POP, IMAP or SMTP AUTH, and older Office clients. These protocols cannot present an MFA challenge. If they remain enabled, an attacker with a valid password can authenticate through them and never encounter your MFA policy, which makes the rest of this page decorative.

Protection > Conditional Access > Create new policy

Setting Value
Users All users, excluding emergency access accounts
Target resources All resources (formerly All cloud apps)
Conditions > Client apps Exchange ActiveSync clients, and Other clients
Grant Block access

Before you enable it, filter your sign-in logs by the Client app column for legacy values to find what is still using it. The usual survivors are multifunction printers and scan-to-email devices, application service accounts sending SMTP, and a small number of long-forgotten mail clients. Move printers and applications to SMTP AUTH with an authenticated submission account, or better, to Microsoft Graph.

💡 The direction of travel: Microsoft has retired Basic authentication for Exchange Online protocols and is progressively disabling legacy authentication paths by default. Confirm the current position for your tenant rather than assuming either that it is already blocked or that you still have time. See Email and Collaboration for the Exchange side of the same problem.

Require multi-factor authentication

Baseline policy

The minimum defensible position is MFA for all users accessing all resources. If you have no Conditional Access policies at all, Microsoft's security defaults enforce a reasonable baseline at no additional cost, and are a much better starting point than nothing. They are all-or-nothing though, with no exclusions, which is why most organisations move to Conditional Access.

Microsoft is also progressively rolling out mandatory MFA for administrative portal access, and Microsoft-managed Conditional Access policies appear in many tenants in report-only state. Review those rather than ignoring them: they are usually close to what you would have written.

Setting Value
Users All users, excluding emergency access accounts
Target resources All resources
Grant Require multi-factor authentication, or an authentication strength

Not all MFA is equal

Push notification and one-time code MFA stops password spraying and credential stuffing. It does not stop an adversary-in-the-middle phishing kit, which proxies the real login page, harvests the session token after the user completes MFA, and replays it. This is now routine, not exotic, and it is the mechanism behind most of the M365 account compromise cases SenseOn works. See the M365 Compromised Account playbook.

Method Resists phishing Position
SMS or voice call No Also vulnerable to SIM swap and interception. Remove it as an option, or restrict it to a documented exception group.
Authenticator app, push approval No Acceptable as a general baseline once number matching and additional context are on.
Authenticator app, one-time code No Equivalent to push. Useful where push is impractical.
Passkeys in Microsoft Authenticator Yes Phishing-resistant and requires no additional hardware. The easiest upgrade path for most users.
FIDO2 security keys Yes The strongest widely deployable option. Recommended for administrators.
Windows Hello for Business Yes Phishing-resistant and already present on managed Windows devices. Low friction if you are hybrid or Entra joined.
Certificate-based authentication Yes Where a PKI and smart cards already exist, typically government and regulated sectors.

Number matching and additional context are enabled by default for Microsoft Authenticator push. Confirm they are on. Number matching defeats MFA fatigue attacks, where an attacker with a valid password repeatedly triggers prompts until the user approves one to make them stop. Additional context shows the application name and sign-in location in the prompt, which gives the user something to judge.

Enforce it with authentication strengths

Rather than requiring generic MFA everywhere, use authentication strengths in the Grant control to require phishing-resistant methods where they matter. Entra ships built-in strengths for multi-factor, passwordless, and phishing-resistant, and you can define custom ones.

A workable split:

Scope Strength
All users, all resources Multi-factor authentication
Users holding any privileged role Phishing-resistant MFA
Access to the Microsoft admin portals and Azure management Phishing-resistant MFA
Registration of new security information Phishing-resistant MFA, or restricted to a trusted network or compliant device

That last row matters more than it looks. If an attacker with a stolen password can register their own authenticator, MFA has been added to their session rather than yours. Use the Register security information user action as the target resource.

Conditional Access policies worth having

Beyond MFA and legacy authentication, these are the policies that recur in our recommendations. Build each in report-only mode first.

Policy Configuration What it addresses
Require compliant or hybrid joined device Grant: Require device to be marked as compliant, or Require Microsoft Entra hybrid joined device A stolen token is far less useful if it must also come from a managed device. The strongest single control after phishing-resistant MFA, provided your device management is in good order.
Require MFA for Azure management Target resources: Microsoft Admin Portals or the Windows Azure Service Management API Protects the control plane specifically, and catches administrative access that a general policy might exclude.
Sign-in risk and user risk policies Grant: require MFA on medium and above sign-in risk; require secure password change on high user risk. Requires Microsoft Entra ID P2 Catches impossible travel, anonymous IP, leaked credentials and token anomalies. The highest-value P2 feature.
Sign-in frequency and persistent browser Session: sign-in frequency for privileged roles, and disable persistent browser session on unmanaged devices Shortens the useful life of a stolen token. Be measured here, as aggressive values generate their own helpdesk load and prompt fatigue.
Block access from unexpected locations Conditions: Locations, with a named location covering the countries you operate in Blunt but effective for organisations with a genuinely bounded geography. Not a substitute for the controls above, since VPNs and residential proxies are cheap.
Require terms of use, or block unmanaged access to specific apps Varies Useful for scoping high-value applications more tightly than the tenant default.

💡 Continuous Access Evaluation shortens the window between a revocation event, such as a disabled account or a password reset, and the token actually failing. It is on by default for supported services. Confirm you have not disabled it in a session policy.

Manage privileged identities

Privileged role sprawl is one of the most common findings when SenseOn reviews a tenant after an incident.

  • Count your Global Administrators. Microsoft's guidance is fewer than five. Most tenants we see have considerably more, usually through historic assignment rather than current need. Every one is a full tenant compromise if taken.
  • Use least-privileged roles. Most administrative work does not need Global Administrator. Exchange Administrator, User Administrator, Security Reader and Intune Administrator cover the majority of day-to-day tasks.
  • Separate administrative accounts from user accounts. Administrative work should not happen from the identity that reads email and opens attachments.
  • Use Privileged Identity Management to make roles eligible rather than active, with approval, justification and a time limit. Requires Microsoft Entra ID P2. Standing privilege is the thing PIM removes, and standing privilege is what an attacker inherits.
  • Review access on a schedule. Access reviews, also P2, automate the recertification. Without them, role membership only ever grows.
  • Do not synchronise on-premises privileged accounts to the cloud. A compromise of Active Directory should not automatically become a compromise of Entra. Keep cloud administrative identities cloud-only. See Active Directory.

Consent phishing is the attack that most often defeats a well-configured MFA deployment, because it never attempts to authenticate as the user at all. The user is asked to grant a malicious registered application permission to their mailbox or files. They approve it. The application now holds its own OAuth refresh token, which is unaffected by a password reset and, in many configurations, unaffected by MFA.

Identity > Applications > Enterprise applications > Consent and permissions

Setting Recommended Effect
User consent for applications Allow user consent for apps from verified publishers, for selected permissions The balanced position. Blocking consent entirely is defensible but generates real friction. Allowing all consent is not defensible.
Admin consent workflow Enabled, with named reviewers Gives users a route that does not involve them finding a way around you, and gives you visibility of what is being requested.
Group owner consent Disabled, or restricted Group owners granting application access to group data is an easily overlooked path.

Also restrict who can create applications in the first place, under Identity > Users > User settings: set Users can register applications to No, and Restrict access to Microsoft Entra admin centre to Yes. Neither is a security boundary on its own, but both reduce noise and remove an easy persistence mechanism.

⚠ Review existing consent, not just future consent. Tightening the policy does nothing about applications already consented to. Audit current enterprise applications and their granted permissions, paying particular attention to any with Mail.Read, Mail.Send, Files.ReadWrite.All or Directory.ReadWrite.All, and to applications nobody can account for.

Passwords, guests and the rest

Passwords. Follow NCSC password guidance: length over complexity, and no forced periodic expiry, which drives predictable increments. Enable Microsoft Entra Password Protection with a custom banned password list including your organisation name, local sports teams, and product names. The on-premises agent extends the same list to Active Directory, which is where the weak passwords usually are.

Self-service password reset. Enable it with a strong registration policy and password writeback. It reduces helpdesk social engineering, which is itself an attack path.

Guest access. Under External Identities > External collaboration settings, restrict guest permissions to the most limited option, and restrict who can invite guests. Guests inherit far more directory visibility by default than most administrators expect.

Verifying with SenseOn

Once Entra sign-in and audit logs are connected through Data Connectors, the following are worth checking after each change:

  • Sign-ins still succeeding through legacy client apps after the block policy is enforced.
  • Sign-ins satisfying MFA with SMS or voice after you intended to retire those methods.
  • Security information registration events from unexpected locations or unmanaged devices.
  • New enterprise application consent grants, particularly to applications with mail or file permissions.
  • Any authentication activity from an emergency access account.

Hunt Lab queries this telemetry directly. The relevant tables are cloud_ms_sign_in_log and cloud_ms_directory_audit_log.

Go live checklist

  • [ ] At least two emergency access accounts created, excluded from all Conditional Access policies, and sign-in tested
  • [ ] Legacy authentication usage identified from sign-in logs and remediated at source
  • [ ] Legacy authentication block policy enforced
  • [ ] MFA required for all users, enforced
  • [ ] Phishing-resistant MFA required for all privileged roles
  • [ ] Security information registration protected by a policy of its own
  • [ ] SMS and voice removed or restricted in the authentication methods policy
  • [ ] Number matching and additional context confirmed enabled
  • [ ] Global Administrator count reviewed and reduced
  • [ ] Administrative accounts separated from day-to-day user accounts
  • [ ] User consent restricted, admin consent workflow enabled, existing consent grants audited
  • [ ] Entra sign-in and audit logs flowing into SenseOn

Sources

All URLs verified on 19 August 2026.