Microsoft 365 + Entra: the governance setup we deploy on day one

When we embed with a new mid-market client, the Microsoft 365 and Entra setup is almost always under-configured. Not insecure exactly — multi-factor is usually on for everyone, the basics work — but missing the second-order controls that turn a tenant from "running" into "auditable, recoverable, and resilient."

Here is the minimum-viable Entra and M365 configuration we deploy in the first two weeks of every engagement. None of it is exotic. All of it survives an auditor.

Conditional Access: the four policies you actually need

Every tenant should have these four Conditional Access policies, in this priority order:

1. Block legacy authentication. SMTP-AUTH, IMAP, POP — none of these support modern auth, all of them are heavily targeted by password-spray attacks. Block them at the tenant level. If a workload still requires legacy auth, scope an exception to that one service principal, document it, and put a quarterly review on the calendar to remove the exception.

2. Require MFA for all users, all cloud apps. Yes, even admins. Yes, even the CEO. The exemption pattern ("the CEO does not want to deal with MFA") is how breaches start. If MFA is genuinely too painful for a role, fix the experience (passkeys, FIDO2 keys, Authenticator number-matching) — do not exempt the user.

3. Require compliant device for privileged roles. Global admin, security admin, exchange admin, billing admin — these accounts should only sign in from devices marked compliant in Intune. If a privileged role tries to sign in from an uncompliant device, the policy blocks them. This stops the most common privilege-escalation chain cold.

4. Block sign-in from outside trusted countries. If your team is in the US and Europe, why is a Tuesday-morning sign-in coming from Vietnam? Use Named Locations to define your trusted countries, then block everything else. Travel exceptions are handled via temporary access policy or VPN-back-to-corporate.

Named Locations: name them properly

Most tenants we open have one Named Location called "Office" with the public IP of the office router. That is fine, as far as it goes — but it does not scale. Define Named Locations for:

• Each office building (helpful for audit, "this sign-in came from the Atlanta office")
• The corporate VPN egress IPs (so VPN'd users get the trusted treatment)
• Trusted countries (broad — US, UK, EU, your engineering team's country if different)

Then layer Conditional Access on top of named locations: trusted IP gets fewer challenges, trusted country gets normal MFA, anywhere else gets blocked or requires a privileged access workstation.

Break-glass accounts: have two, test them quarterly

When MFA breaks (and it will — the federation provider has an outage, your authenticator app updates badly, your conditional access policy has a typo), you need an out. Break-glass accounts are local admin accounts that bypass conditional access and sit in a sealed envelope.

Ours look like this: two accounts named bg-emergency-01@ and bg-emergency-02@. Both are excluded from every conditional access policy. Both have 64-character random passwords stored offline (literally printed and locked in two different physical safes). Both are in a custom directory role with global admin privilege. Both have FIDO2 keys as their MFA — not the Authenticator app, because if the Authenticator service is down, that is exactly when you need the break-glass account.

Test them quarterly. Sign in, do nothing, sign out, log it. If you cannot sign in, fix it before you need it.

Privileged Identity Management: just-in-time elevation

By default, anyone who is a global admin is always a global admin. That is wrong. Privileged Identity Management lets you make eligible-for-the-role the default, and require explicit activation (with reason logging and approval) when you actually need it.

Make every standing privileged role eligible-only. Make activation require:

• A justification text field
• A time limit (1 hour by default; 8 hours for incidents)
• An approver for the most sensitive roles (global admin, security admin)

The audit trail this generates is what auditors want. The reduction in standing privilege is what attackers hate.

Logging: send sign-in logs to Log Analytics

Default Entra retention for sign-in logs is 30 days. That is below the audit floor for most frameworks (SOC 2 wants 1 year minimum, HIPAA wants 6 years). Stand up a Log Analytics workspace, point Entra diagnostic settings at it, and set retention to your audit horizon.

This single configuration change is the highest-ROI security control we deploy. It gives you the forensic trail to investigate any incident, and it gives auditors the evidence they need to pass you.

What we did NOT include

Notable omissions that are worth doing eventually but are not day-one critical:

• B2B/B2C external collaboration policies — only matters if you actually have external collaboration; many mid-market teams do not, yet
• Cross-tenant access settings — only matters if you have multiple Entra tenants, common in companies post-acquisition
• Identity Protection risk policies — included in P2 license; great if you have it, do not block on buying it just for this
• Customer Lockbox — overkill until you have actual compliance commitments

That is the day-one configuration. We deploy it as a baseline in every Foundation engagement, layered on whatever the client already has. It usually takes a week and survives the first audit.

If you want this deployed on your tenant, book a discovery call and we will scope it.