Microsoft Entra ID for administrators: MFA, conditional access, and single sign-on

Identity is the perimeter in Azure. Anyone who can sign in as an administrator can change anything, so Microsoft has made multifactor authentication mandatory for Azure management, in phases. Phase 1 covered signing in to the Azure portal and admin centers. Phase 2, starting October 1, 2025, extends it to resource changes made through the Azure CLI, Azure PowerShell, REST APIs, SDKs, and infrastructure-as-code tools. Read operations do not require it; create, update, and delete operations do. Scripts and pipelines that sign in as a user, without MFA, start failing as enforcement reaches their tenant.

What to check now

• People: every administrator has MFA, preferably phishing-resistant methods such as passkeys or security keys.
• Automation: scripts, scheduled jobs, and deployment pipelines that sign in with a user account should move to workload identities, such as managed identities or service principals.
• Tools: keep Azure CLI and PowerShell modules current so they handle MFA challenges properly.
• Shared accounts: any account used by several people breaks the moment MFA is required; replace it with named accounts.

Conditional access

Conditional access policies decide when and how people can sign in: require MFA for admin portals, block sign-ins from countries you never operate in, require compliant devices for sensitive apps. Microsoft recommends starting new policies in report-only mode, to see who they would affect before enforcing them. Conditional access requires Microsoft Entra ID P1 or P2 licensing.

Break-glass accounts

Keep two emergency access accounts that are excluded from normal conditional access policies, protected with strong, phishing-resistant MFA, monitored for any use, and stored where two named people can reach them. They exist for the day a policy mistake or identity provider problem locks everyone out.

Single sign-on for websites and applications

Entra ID can act as the identity provider for your CMS, staff portals, and custom applications through SAML or OpenID Connect. Users sign in with their work account, MFA and conditional access apply automatically, and access ends when their account is disabled. For Cascade authors, see single sign-on for Cascade authors; for Linux-hosted applications, see SAML single sign-on on Linux.

Giving vendors access

• Use guest accounts (B2B) for vendor staff, so they sign in with their own organization's identity and MFA.
• Grant roles only on the subscriptions or resource groups they operate, not the whole tenant.
• Use time-limited elevation for high-privilege roles where available (Privileged Identity Management, with P2 licensing).
• Review guest access regularly and remove it when work ends.

Common questions

Our deployment pipeline started failing with an MFA error. It is signing in as a user. Move it to a service principal or managed identity with only the permissions it needs.

Do read-only users need MFA? Portal sign-in already requires it under phase 1; command-line read operations do not under phase 2. Requiring MFA for everyone is still the safer policy.

Can we postpone enforcement? Microsoft offered limited postponement during the rollout; check your tenant's status in the Azure portal rather than relying on a delay.

Who owns our tenant? Your organization; see shared responsibility on Azure.

A quick admin hygiene check

1. List everyone with Global Administrator or Owner roles; keep the list short.
2. Confirm each has MFA with a strong method.
3. Confirm two break-glass accounts exist and are monitored.
4. List automation that signs in as a user, and plan its move to workload identities.
5. Review guest accounts and remove those no longer needed.

Which MFA methods are best? Passkeys and hardware security keys resist phishing; authenticator app approvals with number matching are next best. Text messages are the weakest option.

What happens if a break-glass account is used? It should trigger an alert to several people, and every use should be explained and documented.

Does single sign-on replace passwords in our CMS? For users who sign in through it, yes; keep one local administrator for emergencies, protected and monitored.

Can a policy lock everyone out? Yes, which is why report-only mode and break-glass accounts come first.

How eWay works with Entra ID

Administrative access on environments eWay manages requires MFA everywhere, with minimal standing privilege and every privileged session logged. eWay staff work in your tenant through the access you grant, scoped to what eWay operates. eWay can help configure single sign-on for your sites and applications and move automation to workload identities.

What to include in a support ticket

• The application or automation affected, and the exact error
• Your Entra ID licensing level, if conditional access is involved

eWay customers can open a ticket in the support portal or email support@ewaycorp.com. Related reading: multi-factor sign-in and passkeys.