Entra ID Security Guide: Hardening Your Microsoft Identity Tenant

A Microsoft Entra ID tenant is only as strong as the tenant-wide settings that decide who can sign in, who can elevate, which apps can act alone and which other tenants are trusted. Most tenants accumulate them: a policy per project, permanent Global Administrators from migration, service principals with unowned secrets, unreviewed cross-tenant defaults. This guide covers the tenant-level controls that close those gaps: Conditional Access, Privileged Identity Management (PIM), workload identities, cross-tenant access, emergency access and logging. It is written for identity engineers, cloud security teams and SOC analysts who already run Entra ID. For on-premises Active Directory, hybrid sync and tier zero, see the Active Directory and Entra ID Hardening Guide; for app registrations and user consent, see the Entra ID Applications and Consent Guide.

Key takeaways

• Conditional Access is the tenant's policy engine, so design it as a small, layered set of baseline policies for all users and all resources, tested in report-only mode, rather than one policy per application.
• Standing privilege is the main tenant risk: Microsoft recommends fewer than five Global Administrators and fewer than ten privileged role assignments, with everything else eligible through PIM.
• User-scoped policies do not touch service principals. Workload identities need their own Conditional Access (block only, single-tenant apps only), credential hygiene and sign-in log monitoring.
• Cross-tenant access defaults are open for B2B collaboration and do not trust partner MFA, so decide deliberately which tenants you trust, for what, and protect those settings as privileged actions.
• Detection depends on what you export: send sign-in (all four types), audit, risk and Microsoft Graph activity logs to a workspace or SIEM, and alert on break-glass sign-ins, role activations and new credentials on apps.

How identity and access work in Entra ID

Entra ID issues the token for every Microsoft cloud request. After authentication, Conditional Access evaluates signals (user, workload identity, application, location, device, risk, authentication flow) and blocks, grants, or grants with controls such as an authentication strength. Conditional Access runs after the first factor, so a policy requiring phishing-resistant MFA does not stop a password being typed, it stops the session completing without the stronger method.

Identity types the tenant must govern

Designing the Conditional Access baseline

A maintainable tenant has a few baseline policies that target All users and All resources, with narrow, documented exclusions (the emergency access group, and nothing else wherever possible). Typical baseline policies:

• Require an authentication strength for all users: the built-in MFA strength at minimum, Phishing-resistant MFA strength (FIDO2 security key, Windows Hello for Business or platform credential, multifactor certificate-based authentication) for administrators and high-value applications. A policy cannot use both Require multifactor authentication and Require authentication strength, so pick one per policy.
• Block legacy authentication: protocols that cannot perform modern authentication cannot satisfy MFA. CISA's SCuBA baseline lists this as MS.AAD.1.1v1.
• Block device code flow and authentication transfer: Microsoft recommends getting as close as possible to a unilateral block of device code flow, allowing it only for documented legacy tooling. Use the Authentication flows condition, start in report-only, then enforce.
• Protect security information registration: target the user action Register security information, require an authentication strength outside trusted locations, and issue a Temporary Access Pass for first registration. Microsoft has announced that from 6 July 2026 these policies also apply to Windows Hello for Business and macOS Platform SSO registration, so retest them.
• Risk-based policies (Entra ID P2): block or require remediation for high user risk and high sign-in risk, configured in Conditional Access rather than legacy Identity Protection policies.

Continuous Access Evaluation (CAE) revokes Exchange Online, SharePoint Online and Teams access in near real time on critical events such as account disablement, password reset or refresh token revocation. CAE-capable tokens can last up to 28 hours and only IP-based named locations are enforced in real time, so prefer them for location policies. See the Conditional Access Guide and the Token and Session Security Guide.

Cross-tenant access

Cross-tenant access settings control B2B collaboration and B2B direct connect with other Entra tenants, in both directions. Out of the box, B2B collaboration is enabled with every tenant, partner MFA and device claims are not trusted, and B2B direct connect is blocked in both directions. Organisational settings for a named partner override the defaults.

Changes to cross-tenant access settings appear in audit logs under the CrossTenantAccessSettings category and can be guarded as protected actions. Attackers who gain admin rights may add a federated domain or partner trust to persist (ATT&CK T1484.002 Trust Modification). See the Federation and Trust Relationships Guide.

Admin roles and privileged access

Microsoft's role best practices set concrete targets: fewer than five Global Administrators (the Entra overview shows an alert card at five or more), fewer than ten privileged role assignments (a warning appears on the Roles and administrators page), roles assigned to cloud-only accounts rather than synced ones, and privileged roles identified by the PRIVILEGED label. CISA's SCuBA baseline is slightly different (two to eight Global Administrators, MS.AAD.7.1v1); either way, the point is a small, known number.

Privileged Identity Management

• Eligible, not active: make administrators eligible and require activation for a limited duration. SCuBA MS.AAD.7.4v1 requires no permanent active assignments for highly privileged roles, except emergency access accounts.
• Activation controls: require MFA (or an authentication context bound to phishing-resistant strength), a justification, and approval for Global Administrator and Privileged Role Administrator (MS.AAD.7.6v1).
• Alerts: alert on new eligible or active assignments and on every Global Administrator activation (MS.AAD.7.7v1 and 7.8v1).
• Role-assignable groups and PIM for Groups: assign roles to role-assignable groups managed in PIM so there are no standing owners or members; one group activation can grant several roles.
• Azure resource roles: PIM covers Azure RBAC as well. Owner, User Access Administrator and broad custom roles on subscriptions, Key Vaults and storage need the same just-in-time treatment, as Storm-2949 showed.

PIM requires Microsoft Entra ID Governance or P2 licensing. See the Privileged Identity Management (PIM) Guide.

Protected actions

Protected actions require a Conditional Access authentication context to be satisfied at the moment a sensitive permission is used, regardless of which role grants it. Protectable permissions include creating, updating and deleting Conditional Access policies, every cross-tenant access policy update, named location changes, and hard deletion of directory objects (microsoft.directory/deletedItems/delete). Bind them to a policy requiring phishing-resistant MFA, exclude an emergency access account (Azure PowerShell does not handle the step-up challenge). Licence: Entra ID P1.

Emergency access (break-glass) accounts

• Two or more accounts, cloud-only on the *.onmicrosoft.com domain, never federated or synchronised, with a permanent active Global Administrator assignment.
• Phishing-resistant MFA that is different from normal admin MFA: a passkey (FIDO2) or certificate-based authentication. Since Azure mandatory MFA, emergency accounts must also complete MFA to reach the Azure portal and admin centres, with no exception.
• Exclude a dedicated group (for example EmergencyAccess) from blocking Conditional Access policies only; report-only policies need no exclusion.
• Alert on every sign-in: a Log Analytics alert on SigninLogs | where UserId == "<object ID>" with threshold greater than 0 and severity 0.
• Validate at least every 90 days, and after staffing or licensing changes: sign in, perform an admin task, confirm the alert fired and that no personal MFA or SSPR details were registered.

See the Break-Glass Account Guide.

Integrations, API tokens and service accounts

Most user-focused settings do not apply to workload identities. Azure mandatory MFA, which since October 2025 also covers Azure CLI, Azure PowerShell, infrastructure-as-code tools and the Azure Resource Manager REST API for create, update and delete operations, exempts managed identities and service principals but not user accounts used as service accounts. That is a good reason to migrate scripted "service users" to managed identities or service principals rather than excluding them from MFA.

• Conditional Access for workload identities: applies only to single-tenant service principals registered in your tenant, assigned directly by object ID from Enterprise applications (group assignment is not enforced). The only grant is Block, by location (include any location, exclude known egress ranges) or by service principal risk. It needs Workload Identities Premium licences and supports report-only mode.
• Credential additions are persistence: adding a secret or certificate to an existing app (T1098.001 Additional Cloud Credentials) was used in the SolarWinds campaign and attempted by Storm-2949. Alert on the audit events for adding credentials to applications and service principals.
• Application permissions are tenant-wide: in the Microsoft Midnight Blizzard breach, a legacy test OAuth app with elevated access and the Exchange full_access_as_app permission let the actor read mailboxes without any user signing in.

See the Workload Identity Federation Guide and the Azure RBAC and Service Principals Guide.

Logging and detection

The admin center and Graph keep sign-in and audit data for a limited period, and Microsoft advises exporting anything you need for longer than 30 days. Configure Diagnostic settings (Security Administrator role) to a Log Analytics workspace or Microsoft Sentinel, to Event Hubs for a third-party SIEM, and to a storage account for archive. Allow up to three days for new categories to start flowing.

High-value alerts

• Recovery abuse: authentication methods removed and a new Microsoft Authenticator registered on the same account shortly after a self-service password reset. This is the Storm-2949 pattern.
• Privilege change: PIM activation of Global Administrator or Privileged Role Administrator, new permanent assignments, new members of role-assignable groups (T1098.003).
• Policy tampering: Conditional Access policy disabled, switched to report-only or given a new exclusion; named location edits.
• Trust changes: new federated domain, changed federation settings or new partner in cross-tenant access settings (T1484.002).
• Workload identity abuse: new credential on an app, new high-privilege application permission granted, service principal sign-in from a new country.

Metrics that show the tenant is improving

• Number of permanent active privileged role assignments outside emergency access accounts (target: zero).
• Percentage of interactive sign-ins satisfied by a phishing-resistant method, overall and for administrators (target: 100 percent for admins).
• Number of service principals with client secrets, and the median secret age.
• Count of users excluded from baseline Conditional Access policies, reviewed monthly.
• Break-glass validation completed within the last 90 days, with alert fired (yes or no).

See the ITDR Guide and the Cloud Logging and Audit Trail Guide.

Hardening baseline

CISA's Secure Cloud Business Applications (SCuBA) Entra ID baseline is a useful external yardstick; its main policies map to this guide as follows.

Rolling it out

1. Prepare recovery first: create and test two emergency access accounts with passkeys, the exclusion group and the sign-in alert before changing any blocking policy.
2. Export logs: enable all sign-in categories, audit and Graph activity logs to your SIEM so you can measure impact and detect mistakes.
3. Deploy baseline policies in report-only: run each for at least two weeks, review the report-only results and the Conditional Access insights workbook, and fix legitimate exceptions with narrow scopes.
4. Enforce in rings: IT staff first, then a pilot business group, then all users. Keep the previous state documented; rollback is switching the policy back to report-only or off.
5. Move admins to PIM and phishing-resistant MFA: convert permanent assignments to eligible, bind activation to an authentication context, add protected actions for Conditional Access and cross-tenant settings.
6. Govern workload identities and cross-tenant access: replace app secrets with federation or certificates, apply workload identity policies, then set default inbound and outbound posture and partner-specific trust.

Small versus large tenants

With Entra ID P1 alone a small organisation still gets Conditional Access, authentication strengths, protected actions, emergency access and log export; without PIM, keep very few administrators and alert on every role change. Large or multi-tenant organisations should add PIM for Groups, administrative units, scoped cross-tenant synchronisation, Workload Identities Premium and reviewed policy-as-code for Conditional Access.

Framework mapping

Common misconfigurations

• Test and legacy tenants outside the baseline: the Microsoft Midnight Blizzard breach began with a password spray on a legacy non-production test tenant account without MFA. Every tenant you own needs the same baseline and the same log export, or should be deleted.
• Recovery that trusts a single push approval: in the Storm-2949 Azure attack, the actor started self-service password reset, posed as IT support to get users to approve MFA prompts, then replaced their authentication methods. Require phishing-resistant methods for admins and executives, protect security info registration, and alert on method replacement. See the Account Recovery and Help Desk Security Guide.
• Standing Azure Owner and broad custom roles: Storm-2949's compromised users held privileged custom Azure RBAC roles and Owner on a Key Vault, so dozens of secrets were read in minutes. Directory roles in PIM do not help if Azure resource roles remain permanent.
• Exclusion creep: service accounts, executives and "temporary" pilot groups excluded from baseline policies for years. Review them monthly.
• Assuming user policies cover apps: a tenant with excellent user Conditional Access can still have service principals with client secrets usable from anywhere. Apply workload identity policies and monitor ServicePrincipalSignInLogs.

Practitioner checklist

• Create two cloud-only emergency access accounts with passkeys, a sign-in alert and a 90-day validation routine.
• Reduce Global Administrators to fewer than five and privileged assignments to fewer than ten; make the rest eligible in PIM with MFA, justification and approval.
• Bring Azure resource roles (Owner, User Access Administrator, broad custom roles) under PIM as well.
• Deploy baseline Conditional Access for all users and all resources: authentication strength, block legacy authentication, block device code flow, protect security info registration, risk policies.
• Require Phishing-resistant MFA strength for every administrative role and bind protected actions to it.
• Review cross-tenant access defaults, add partner-specific trust only where verified, and audit the CrossTenantAccessSettings category.
• Inventory service principals, replace client secrets with federation or certificates, and apply workload identity Conditional Access to single-tenant apps.
• Export all sign-in categories, audit, risk and Microsoft Graph activity logs to a SIEM with at least a year of retention.
• Alert on method replacement after password reset, role activations, policy changes, trust changes and new app credentials.

Standards and references

• Microsoft Learn: Best practices for Microsoft Entra roles
• Microsoft Learn: Manage emergency access admin accounts
• Microsoft Learn: Conditional Access for workload identities
• Microsoft Learn: Cross-tenant access overview
• Microsoft Learn: Protected actions in Microsoft Entra ID
• Microsoft Learn: Log options for streaming Microsoft Entra logs
• CISA: SCuBA Microsoft Entra ID secure configuration baseline
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Active Directory and Entra ID Hardening Guide · Entra ID Applications and Consent Guide · Microsoft Azure Security Guide · Phishing-Resistant MFA Guide · Cloud Workload Identity Guide