Ben Stegink
Very few Microsoft Entra ID tenants were designed. Most of them accumulated. A consent setting left at its default from the day the tenant was created, a per-user multifactor authentication (MFA) configuration someone enabled years ago, an enterprise application list nobody has read since. Identity is the control plane for everything in Microsoft 365, which makes those accumulated defaults the natural place to start when we review a tenant. Whether we are delivering a training session or a security assessment, the same handful of settings come up every time, and most of them cost nothing beyond the licensing you already own.
Lock Down User Consent Before It Becomes a Problem
Out of the box, users can grant applications access to organizational data on their own. The default configuration allows user consent for permissions that do not require admin approval, and older tenants sometimes still allow consent to any app from a verified publisher. The practical result is the same either way: users connect third-party tools to Microsoft 365, those tools receive Microsoft Graph permission grants, and nobody with a security hat ever evaluated them. We have reviewed tenants where the enterprise application list told a story the IT team had never read.
Our standing recommendation is to change this under Enterprise applications and Consent and permissions. Set user consent to “Do not allow user consent,” then enable the admin consent workflow so the change does not simply become a wall. With the workflow on, a user who needs an application submits a request with a business justification, designated reviewers get notified, and the request is approved or denied from a queue any admin can check. Users still get their tools. You get a decision point.
While you are in the neighborhood, put app registrations on a recurring review cadence. Certificates and client secrets expire, and when they do, the integration that depends on them breaks silently. The API permissions view also shows exactly what each registered application can reach, which is worth reading before an incident makes you read it. This discipline matters more every month as application sprawl turns into agent sprawl, a shift we covered in Agent Governance Is the New Application Governance.
Retire Per-User MFA and Build Everything on Conditional Access
The legacy per-user MFA page still exists, and it still catches people. Admins find their way into it, flip users to Enabled or Enforced, and end up with an MFA configuration that fights the modern one. That interface is deprecated. Conditional Access is where MFA policy belongs, and it gives you far more control than a per-user toggle ever did. Organizations without Microsoft Entra ID P1 should use security defaults instead; everyone else should treat Conditional Access as the foundation.
A Conditional Access policy reads like a sentence: these users, accessing these resources, under these conditions, are granted access only if they meet these controls, and their session behaves this way. Microsoft’s policy templates provide a solid starting set for a secure foundation and Zero Trust, and two habits will keep you out of trouble as you build your own.
First, always exclude an emergency access account from any policy that blocks or restricts sign-in. A misconfigured policy that locks every admin out of the tenant is not a hypothetical; it is a support case we would rather you never open. Microsoft now prompts you to exclude yourself when creating a policy, which is a good nudge, but a dedicated cloud-only break-glass account with a passkey is the real answer.
Second, validate before you enforce. Create new policies in report-only mode, run scenarios through the What If tool, and when something does get blocked, remember that the sign-in logs show exactly which policy did it, from which device, and from which location.
Two patterns come up constantly in these policies. For geographic restrictions, resist the urge to check boxes for every country you want to block. Include all locations, exclude the countries you actually operate from, and new countries are covered automatically. Handle the occasional traveling user with a temporary, group-scoped exclusion rather than reworking the policy. For device trust, use device filters on the trust type property: Microsoft Entra joined and Microsoft Entra hybrid joined devices, the managed fleet you build by moving endpoint configuration into Intune, get the full desktop clients, while unmanaged devices get browser-only access. That single distinction keeps corporate data off machines you cannot manage or wipe.
Raise the Bar for Admin Sign-Ins
Standard MFA is table stakes for regular users. For privileged roles, it is not enough. Conditional Access grant controls support authentication strengths, and our recommendation is to target the Global Administrator role (and the rest of your privileged roles) with a policy that requires the Phishing-resistant MFA strength. That limits admin sign-ins to methods like passkeys (FIDO2), Windows Hello for Business, and certificate-based authentication. An attacker can socially engineer an SMS code out of someone; they cannot phish a hardware-bound passkey.
Session controls deserve attention here too. Sign-in frequency lets you force admins to reauthenticate every few hours, or every time, so privileged sessions do not quietly persist for days. For shared workstations, think front desks, clinical floors, or shop floors, disabling persistent browser sessions means a closed browser is a signed-out browser. And continuous access evaluation, when strictly enforced, cuts sessions off almost immediately after a password change or account block instead of waiting for tokens to expire on their own schedule.
Modernize Authentication Methods, Because SMS Is on the Clock
The authentication methods policy controls what users are allowed to register: Microsoft Authenticator with push or passwordless sign-in, passkeys (FIDO2), Temporary Access Pass, and the legacy options of SMS and voice calls. Plenty of tenants still lean heavily on the legacy options, and that is no longer a posture question with an indefinite timeline. Microsoft has announced that Microsoft-provided SMS and voice authentication retire on February 1, 2027, after which users whose only method is a phone number will be forced into passkey registration at sign-in. Getting ahead of that deadline on your own schedule beats explaining it to users on Microsoft’s.
The tooling for the transition is already in the policy. Passkey settings support restricting FIDO2 registration to specific providers and models through their AAGUIDs, which matters if you standardize on particular hardware keys or a specific passkey provider. Registration campaigns let you nudge users to set up Authenticator or, as of a recent update, a passkey during their normal sign-in, with configurable snooze limits so the prompt eventually stops being optional. Temporary Access Pass covers onboarding and recovery scenarios without falling back to a phone number.
One more item while you are in this part of the portal: enable self-service password reset if you have not. It is one of the fastest help desk offloads available, and Microsoft is converging its separate authentication method registration into the same unified authentication methods policy, so the experience is only getting cleaner.
Put Cloud Sync on Your Roadmap
If you run hybrid identity, you are almost certainly running Microsoft Entra Connect Sync, and it remains fully supported. But Microsoft’s development center of gravity has moved to Microsoft Entra Cloud Sync: a lightweight agent on a server, with all configuration managed from the cloud, and new synchronization features landing there first.
This is not a drop-everything migration. Cloud Sync does not yet cover every Connect Sync scenario, device synchronization for hybrid join being the notable gap, and it carries different scale limits, so the decision guide is required reading before you commit. But if hybrid identities are staying in your environment long term, put a date on the calendar to evaluate the move. Planned migrations go better than forced ones.
Conclusion
Everything above sits inside licensing most organizations already own, and we deliberately skipped the Microsoft Entra ID P2 features like risk-based Conditional Access, Privileged Identity Management, and access reviews, which deserve their own discussion. The pattern across all five areas is consistent: Microsoft Entra ID defaults favor compatibility, and a deliberate configuration pass favors your security posture. The gap between those two is where incidents live. If it has been a while since anyone reviewed your tenant’s identity configuration, or you want help building Conditional Access policies that protect the tenant without locking you out of it, reach out and let’s talk.
