Entra ID Security Hardening: 15 Settings Every Tenant Should Lock Down Today

Conditional Access policies get most of the attention in Entra ID security discussions — and rightly so, they're powerful. But there is an entire layer of tenant-level settings that control user behavior, application access, external collaboration, privileged account management, and authentication methods. These settings are not covered by Conditional Access, they live in different parts of the Entra admin center, and they ship with defaults designed for ease of use rather than security. For Conditional Access hardening, see our guide on CA policy mistakes. This article covers everything else.

1. Configure Privileged Identity Management (PIM) for Just-in-Time Access

PIM is the single highest-impact control you can implement for privileged Entra ID roles. Instead of permanently assigning users to Global Administrator, Security Administrator, or other privileged roles, PIM makes those roles eligible — users must explicitly activate them for a bounded time window, with MFA enforcement and optional approval workflow.

Portal path: Entra admin center → Identity Governance → Privileged Identity Management → Entra ID roles

# Audit current permanent role assignments (should all be eligible, not active):
Connect-MgGraph -Scopes "RoleManagement.Read.Directory"
Get-MgRoleManagementDirectoryRoleAssignment |
  Where-Object { $_.AssignmentType -ne "Eligible" } |
  Select-Object PrincipalId, RoleDefinitionId, DirectoryScopeId

# Get all users with permanent Global Administrator assignment:
$gaRole = Get-MgDirectoryRole | Where-Object {$_.DisplayName -eq "Global Administrator"}
Get-MgDirectoryRoleMember -DirectoryRoleId $gaRole.Id |
  Select-Object DisplayName, UserPrincipalName

PIM configuration for each role: set maximum activation duration to 4–8 hours, require MFA on activation, require justification text, and require approval for Global Administrator and Privileged Role Administrator activations. No user should have a permanent, always-active Global Administrator assignment outside of break-glass accounts.

2. Block Users from Registering Applications

By default, any user in your tenant can register new application registrations in Entra ID. Application registrations can be granted API permissions, can hold client secrets, and can be used to obtain tokens that access organizational data. In a phishing scenario, an attacker who compromises a user account can immediately create an application with elevated permissions as a persistence mechanism.

Portal path: Entra admin center → Identity → Users → User settings → App registrations → Users can register applications → No

# Check current setting:
Connect-MgGraph -Scopes "Policy.Read.All"
$authPolicy = Get-MgPolicyAuthorizationPolicy
$authPolicy.DefaultUserRolePermissions.AllowedToCreateApps

# Set to False (only admins can register apps):
Update-MgPolicyAuthorizationPolicy -DefaultUserRolePermissions @{
  AllowedToCreateApps = $false
}

3. Block User Consent to Applications

When a user consents to a third-party application, they grant it access to their data — mail, files, contacts — on their behalf. OAuth phishing attacks (illicit consent grants) rely entirely on this permission. The attacker creates a malicious application, sends the user a link, and when the user clicks "Accept," the application is granted persistent access to the user's Microsoft 365 data without any credential theft involved.

Portal path: Entra admin center → Identity → Enterprise applications → Consent and permissions → User consent settings → Do not allow user consent

# Disable user consent entirely:
Connect-MgGraph -Scopes "Policy.ReadWrite.Authorization"
$body = @{
  "permissionGrantPolicyIdsAssignedToDefaultUserRole" = @()
}
Update-MgPolicyAuthorizationPolicy -BodyParameter $body

4. Configure the Admin Consent Workflow

After blocking user consent, enable the admin consent workflow. This gives users a path to request access to applications they need, while routing that request to an admin for review and approval. Without this, users will report that applications "don't work" and IT will enable user consent to solve the ticket — the wrong fix.

Portal path: Entra admin center → Identity → Enterprise applications → Consent and permissions → Admin consent settings → Users can request admin consent to apps they are unable to consent to → Yes

Assign specific users as reviewers. Set the email notification period to ensure timely review. This creates an auditable, controlled path for application access that doesn't require reopening user consent.

5. Restrict Cross-Tenant Access Settings

Cross-tenant access settings control how your tenant interacts with other Azure organizations — both inbound (external users accessing your resources) and outbound (your users accessing external organizations' resources). Default settings are permissive and allow collaboration with any external tenant.

Portal path: Entra admin center → External Identities → Cross-tenant access settings

• Default inbound settings: Block all access from external tenants by default; add explicit allowances only for partner organizations you trust
• Default outbound settings: Restrict your users from accessing external tenants unless specifically required
• Trust settings: Do not automatically trust MFA or compliant device claims from external tenants unless you have verified their security posture

6. Restrict External Collaboration Settings

Guest invite restrictions control who can invite external users as guests into your tenant. The most permissive setting (anyone in the organization can invite guests) is also the default for many tenant configurations.

Portal path: Entra admin center → External Identities → External collaboration settings

# Check current guest invite settings:
$authPolicy = Get-MgPolicyAuthorizationPolicy
$authPolicy.AllowInvitesFrom
# Values: adminsAndGuestInviters, adminsGuestInvitersAndAllMembers, everyone, none

# Restrict to admins and guest inviters only:
Update-MgPolicyAuthorizationPolicy -AllowInvitesFrom "adminsAndGuestInviters"

Additionally, restrict what guest users can do in your tenant. By default, guests can enumerate users, groups, and certain directory information — which provides attackers who compromise a guest account with reconnaissance data.

7. Restrict Azure AD Admin Portal Access

By default, any user can access the Entra admin center and read directory information through the portal. Restrict portal access to admins only — non-privileged users have no legitimate need to browse directory settings.

Portal path: Entra admin center → Identity → Users → User settings → Restrict access to Microsoft Entra admin center → Yes

Note: This restricts portal access but not programmatic API access. Users can still read their own directory information via the Graph API. Combine this with restricting the Directory.Read.All permission from users where possible.

8. Enable Risky Sign-In and Risky User Policies

Entra ID Protection (requires P2 licensing) evaluates every sign-in for risk signals — impossible travel, anonymous IP, malware-linked IPs, leaked credentials, unfamiliar sign-in properties. Risk policies allow you to automatically require MFA or block sign-ins when risk is detected, without requiring a Conditional Access rule for every scenario.

Portal path: Entra admin center → Protection → Identity Protection

• Sign-in risk policy: At Medium risk and above, require MFA. At High risk, block sign-in.
• User risk policy: At High risk, require password change. Do not simply block — password change forces credential rotation while allowing recovery.

# Review current risky users:
Connect-MgGraph -Scopes "IdentityRiskyUser.Read.All"
Get-MgRiskyUser -Filter "riskLevel eq 'high'" |
  Select-Object UserPrincipalName, RiskLevel, RiskDetail, RiskLastUpdatedDateTime

9. Configure Password Protection (Banned Password List)

Entra ID Password Protection allows you to define a banned password list specific to your organization — your company name, product names, location names, and variations are commonly used in passwords and easily guessable. This applies to all password changes and resets in your tenant and can be extended to on-premises AD with the password protection agent.

Portal path: Entra admin center → Protection → Authentication methods → Password protection

• Enable custom banned passwords: Yes
• Add your organization name, common abbreviations, product names, and location names to the banned list
• Lockout threshold: 10 failed attempts
• Lockout duration: 60 seconds minimum

10. Configure Authentication Methods Policy

The Authentication Methods policy controls which authentication methods are available to users and admins. The goal is to phase out SMS OTP and voice call methods in favor of phishing-resistant methods (FIDO2 security keys, Windows Hello for Business, certificate-based authentication).

Portal path: Entra admin center → Protection → Authentication methods → Policies

# Audit current authentication method registrations:
Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All"
# Get all users with SMS registered:
Get-MgUser -All | ForEach-Object {
  $methods = Get-MgUserAuthenticationMethod -UserId $_.Id
  if ($methods | Where-Object { $_.ODataType -match "phoneAuthentication" }) {
    $_.UserPrincipalName
  }
}

For privileged accounts specifically, enable FIDO2 and disable SMS/voice. Attackers can SIM-swap SMS authentication — it is not a strong second factor for high-value accounts.

11. Configure Named Locations

Named locations let you define trusted network ranges (corporate offices, VPN egress IPs) and trusted countries. This data feeds into Conditional Access policies and risk detection — sign-ins from outside named locations can be treated as higher risk, and sign-ins from blocked countries can be denied outright.

Portal path: Entra admin center → Protection → Conditional Access → Named locations

# Create a named location for corporate IP ranges:
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"
$ipRanges = @(
  @{ "@odata.type" = "#microsoft.graph.iPv4CidrRange"; cidrAddress = "203.0.113.0/24" },
  @{ "@odata.type" = "#microsoft.graph.iPv4CidrRange"; cidrAddress = "198.51.100.0/24" }
)
New-MgIdentityConditionalAccessNamedLocation -DisplayName "Corporate Networks" `
  -AdditionalProperties @{
    "@odata.type" = "#microsoft.graph.ipNamedLocation"
    isTrusted = $true
    ipRanges = $ipRanges
  }

12. Restrict Group Creation to Administrators

By default, any user can create Microsoft 365 Groups, Security Groups, and Teams. Uncontrolled group proliferation creates governance challenges and potential data exposure through overly permissive group membership and external sharing settings on Teams-connected SharePoint sites.

Portal path: Entra admin center → Identity → Groups → General settings → Users can create Microsoft 365 Groups → No

# Check current group creation settings:
$groupSetting = Get-MgGroupSetting | Where-Object { $_.DisplayName -eq "Group.Unified" }
$groupSetting.Values | Where-Object { $_.Name -eq "EnableGroupCreation" }

# Restrict to specific group:
Import-Module Microsoft.Graph.Groups
$groupCreationAllowedGroup = "GroupCreationAllowed"  # Create this group for authorized users
# Modify the group setting to reference this group

13. Configure Self-Service Password Reset Security

SSPR is valuable for operational efficiency, but its security configuration directly affects your tenant's exposure. The key controls: require at least two authentication methods for SSPR (not just one), require the same phishing-resistant methods you use for MFA where possible, and enable password writeback only if the on-premises infrastructure is hardened.

Portal path: Entra admin center → Protection → Password reset

• Number of methods required to reset: 2
• Methods available: Authenticator app notification, Authenticator app code (yes); Email, Mobile phone (avoid for privileged accounts)
• Registration: Require registration at next sign-in: Yes; Number of days before users are asked to re-confirm: 180

14. Configure Token Lifetime for High-Security Applications

Default access token lifetimes in Entra ID are 60–90 minutes. For high-security applications, reducing this limits the window during which a stolen token remains valid. Refresh token lifetimes are now managed through Conditional Access sign-in frequency settings rather than token lifetime policies.

# Create a short-lived token policy for sensitive applications:
Connect-MgGraph -Scopes "Policy.ReadWrite.ApplicationConfiguration"
$policyDefinition = @{
  definition = @(
    '{"TokenLifetimePolicy":{"Version":1,"AccessTokenLifetime":"00:30:00"}}'
  )
  displayName = "Short Access Token - High Security Apps"
  isOrganizationDefault = $false
}
$policy = New-MgPolicyTokenLifetimePolicy -BodyParameter $policyDefinition

# Assign to a specific service principal:
$sp = Get-MgServicePrincipal -Filter "displayName eq 'YourHighSecurityApp'"
$params = @{
  "@odata.id" = "https://graph.microsoft.com/v1.0/policies/tokenLifetimePolicies/$($policy.Id)"
}
New-MgServicePrincipalTokenLifetimePolicyByRef `
  -ServicePrincipalId $sp.Id -BodyParameter $params

15. Monitor and Enforce Security Defaults vs. Custom Configuration

Security Defaults is Microsoft's baseline security configuration — it enforces MFA for all users, blocks legacy authentication protocols, and requires MFA for specific admin actions. If your organization has Entra ID P1 or P2 licensing and has deployed Conditional Access policies, Security Defaults should be disabled in favor of your custom configuration. Running both simultaneously can cause conflicts.

Portal path: Entra admin center → Identity → Overview → Properties → Manage Security defaults

# Check Security Defaults status:
Connect-MgGraph -Scopes "Policy.Read.All"
$securityDefaults = Get-MgPolicyIdentitySecurityDefaultEnforcementPolicy
$securityDefaults.IsEnabled

# Disable Security Defaults (only if custom Conditional Access is fully deployed):
Update-MgPolicyIdentitySecurityDefaultEnforcementPolicy -IsEnabled $false

If you disable Security Defaults without adequate Conditional Access coverage, you remove protection. Audit your CA policies before making this change — every scenario Security Defaults covers (legacy auth blocking, admin MFA, registration security) must be explicitly covered by a CA policy before disabling.

Prioritization

If you implement none of these today, start with settings 2, 3, and 4 — blocking app registrations and user consent while enabling the admin consent workflow. These eliminate the most common OAuth phishing persistence mechanism. Then move to PIM (setting 1) to eliminate standing privileged access. Everything else is important hardening, but those three settings address the most frequently exploited misconfiguration patterns we see in Entra ID environments.