Identity-first security for hybrid Microsoft 365 environments

If your organisation runs Microsoft 365 with on-premises Active Directory synchronised to Entra ID via Entra Connect, your security perimeter is the identity layer. Endpoint security matters, network controls matter, but the workload that authentication controls is doing — every M365 sign-in, every SaaS SSO, every API call, every admin operation — makes the identity layer the highest-leverage place to invest.

Most mid-market M365 environments we review are running on identity configurations that were stood up in 2018 and haven’t been seriously revisited since. The feature set has moved substantially in seven years. The configurations have not.

This post is the catch-up: the elements of an identity-first security baseline for a hybrid M365 environment, in roughly the order to address them.

1. MFA enforcement, properly

Every user, every sign-in, no exceptions. Specifically:

• Phishing-resistant MFA for any administrative or privileged account. Authenticator app number-matching is the minimum; FIDO2 keys are better. SMS and voice are not acceptable for privileged identities.
• No legacy authentication anywhere. Block legacy auth at the conditional access layer — entire protocol classes (POP3, IMAP, SMTP basic, ActiveSync basic) are MFA-incompatible and should be off.
• No “users excluded from MFA” lists. The break-glass account is the only exception, secured separately with a long random password in physical custody.

If you find legacy auth still enabled, that’s the first item to fix.

2. Conditional access policies that mean something

Conditional access is the policy engine. The default config is permissive. The hardened config has a small number of policies that cover most scenarios:

• All users, all cloud apps, MFA required — the baseline.
• Admins, all cloud apps, phishing-resistant MFA required, compliant device required — the privileged path.
• All users, all cloud apps, block from countries the organisation does not operate in — geographic constraint.
• All users, high-risk sign-ins, block — risk-based response, requires Entra ID Premium P2.
• All users, sensitive applications (finance, HR, legal), additional context required — application-tier protection.
• Mobile devices, M365 apps, app protection policy required — mobile device handling without full MDM.

Plus an exclusion-style policy specifically for break-glass accounts so they can sign in if everything else is broken.

The number of policies is small. Each is documented. Changes are deliberate and reviewed. The policy hygiene is more important than the policy proliferation.

3. Privileged Identity Management for admin roles

Privileged Identity Management (PIM) makes administrative roles activatable rather than permanent. A user with Global Administrator becomes a user eligible for Global Administrator, who must request elevation, which is granted for a defined window with logged justification.

For mid-market environments, the PIM-eligible roles to configure first:

• Global Administrator
• Privileged Authentication Administrator
• Authentication Administrator
• User Administrator
• Exchange Administrator
• SharePoint Administrator
• Teams Administrator
• Conditional Access Administrator
• Security Administrator
• Compliance Administrator

Permanent assignment to any of these roles for a human user is unusual. Service principals have their own role assignments and are managed separately.

Approval requirements are calibrated to the role. Global Administrator activation requires approver sign-off, multi-factor, justification, and a four-hour window maximum. Lower roles may be self-activated with shorter windows.

PIM requires Entra ID Premium P2 (or Microsoft Entra ID Governance). For most mid-market organisations doing serious identity work, P2 is justified.

4. Entra Connect: the on-prem hinge

Entra Connect is the synchronisation between on-prem AD and Entra. Two things matter:

The Entra Connect server is itself a tier-0 identity asset. It’s privileged in both directions. Treat it as such — dedicated server, restricted network access, admin access tightly controlled, monitoring instrumented.

The synced attributes and password hash sync configuration are deliberate. Most environments synchronise everything by default. A more deliberate scope reduces what’s exposed. Password hash sync is generally appropriate (allows leaked credential detection), but the trade-offs are worth understanding.

Hybrid environments often also have AD FS or pass-through authentication. Either path should be evaluated against staying with cloud authentication via password hash sync — the latter has the simplest security model and the best feature support.

5. Microsoft Defender XDR (or equivalent) wired up

The detection and response layer:

• Defender for Identity monitors AD and Entra for typical attack patterns — golden tickets, password spray, brute force, suspicious replication. Requires the on-prem sensor.
• Defender for Office 365 for email-borne threats. Phishing protection, attachment sandboxing, link rewriting.
• Defender for Cloud Apps for SaaS visibility and shadow IT discovery.
• Defender for Endpoint for the endpoint side. EDR + ASR rules + attack surface reduction.

Most mid-market organisations license a portion of Defender XDR through M365 E3 or E5. The components that matter most for identity-first security are Defender for Identity (anomalous AD activity), Defender for Cloud Apps (SaaS visibility), and Defender for Office 365 (phishing).

6. Audit log retention and the SIEM connection

The Microsoft Purview audit log retains 180 days of activity by default, extendable to one year (10 years with the right SKU). For most mid-market security programs, the audit log goes to a SIEM (Sentinel is the natural fit; Splunk / Chronicle / Elastic also work) where the retention is independent and the alerting/hunting capability is richer.

The events to forward — at minimum — include sign-ins (interactive and non-interactive), audit logs (admin operations), Defender alerts, and the Unified Audit Log from Office 365.

7. Service principals and app registrations

The under-attended part of M365 identity security. Every Entra app registration is an identity that can be granted permissions. A misconfigured app registration with consented Mail.ReadWrite or Sites.ReadWrite.All is the path most “M365 breach via OAuth consent” incidents take.

The discipline:

• App registrations are inventoried.
• High-permission consents (anything ending in .All) are reviewed.
• App registration creation is restricted to administrators (default M365 lets users create them).
• App registration consent for high-permission scopes is admin-approval-required.
• Stale app registrations are removed.

A practical first move

The single highest-leverage item for an under-attended M365 environment: review your conditional access policies. If there are zero (the default), you have an MFA gap to close. If there are dozens, you have a policy hygiene gap to close. If there are five well-chosen ones with documented exclusions, you are in a defensible place.

The Security Posture Assessment covers M365 identity configuration as part of the standard scope, with specific reference to the conditional access policy set, the privileged role configuration, and the audit log forwarding architecture.