Azure Tenant Hardening: Fix Insecure Default Settings

What Is Azure Tenant Hardening?

When a new Microsoft 365 or Azure tenant is created, it comes with a set of default configurations that are designed for ease of use — not security. Legacy authentication is enabled, Security Defaults may be off, guest access is unrestricted, and no Conditional Access policies are configured.

Tenant hardening is the process of systematically reviewing and correcting these defaults. It is not glamorous work, but it is foundational: every other Azure security control — Conditional Access, PIM, Identity Protection — depends on the tenant configuration being correct.

This article covers the most critical Azure tenant configuration checks and how to validate and fix them.

How It Works

Azure tenant configuration is managed across multiple locations:

• Entra ID > Properties — tenant-wide settings including Security Defaults
• Entra ID > External Identities — guest and B2B collaboration settings
• Entra ID > Authentication Methods — which MFA methods are allowed
• Exchange Online Admin Center — legacy auth settings for email protocols
• Microsoft 365 Admin Center — service-level security settings

Misconfigurations in any of these can create attack surface that bypasses all other controls. A perfectly configured Conditional Access policy is irrelevant if legacy authentication is still enabled at the Exchange level.

The Attack Chain

Exploiting Security Defaults Disabled

When Security Defaults are off and no Conditional Access policies fill the gap:

# Password spray against M365 with no MFA baseline
o365spray --spray -U users.txt -P passwords.txt --domain corp.com

# Legacy auth bypass — IMAP access ignores Conditional Access
curl -u [email protected]:Password1 imaps://outlook.office365.com/INBOX

Exploiting Open B2B Settings

# With any member account — invite attacker-controlled external identity
New-MgInvitation -InvitedUserEmailAddress "[email protected]" `
    -InviteRedirectUrl "https://myapps.microsoft.com" `
    -SendInvitationMessage $false

Configuration Audit Checklist

1. Security Defaults Status

Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgPolicyIdentitySecurityDefaultEnforcementPolicy | Select-Object IsEnabled
# Should be True (if no CA policies in place)

2. Legacy Authentication Status

# Check Exchange Online legacy auth policies
Connect-ExchangeOnline
Get-AuthenticationPolicy | Select-Object Name, AllowBasicAuth*
# All AllowBasicAuth* values should be False

3. Guest Invitation Settings

# Check who can invite guests
Get-MgPolicyAuthorizationPolicy | Select-Object AllowInvitesFrom
# Should be: adminsAndGuestInviters or adminsOnly

4. Authentication Methods Policy

# List enabled authentication methods
Get-MgPolicyAuthenticationMethodPolicy | Select-Object -ExpandProperty AuthenticationMethodConfigurations |
    Where-Object {$_.State -eq "enabled"} | Select-Object Id, State
# Verify SMS is not the only MFA method (phishable) — prefer Authenticator App or FIDO2

5. Cross-Tenant Access Settings

# Check if cross-tenant access is open to all external organizations
Get-MgPolicyCrossTenantAccessPolicyDefault | Select-Object -ExpandProperty B2BCollaborationInbound
# InboundTrust should not be "AllExternalOrganizations" without restrictions

Detection

Microsoft 365 Secure Score

Microsoft 365 Secure Score provides an automated assessment of tenant configuration against Microsoft's recommended baseline. Check it at security.microsoft.com > Secure Score.

Key actions that impact score:

• Enable Security Defaults or require MFA for all users (+5-15 points)
• Block legacy authentication (+10 points)
• Restrict guest invitation (+5 points)
• Enable Privileged Identity Management (+10 points)

Entra ID Audit Logs

# Detect Security Defaults being disabled
azure.auditlogs.operation_name: "Update security defaults" AND
azure.auditlogs.properties.target_resources.modified_properties.new_value: "false"

💡 Tip: Monitor your Microsoft Secure Score weekly. A significant drop is often the first indicator that a configuration change introduced a new security gap.

Remediation

💡 Quick Win: Run the audit checklist above and fix any finding where legacy auth is enabled or Security Defaults are off with no CA replacement.

Enable Security Defaults (If No Conditional Access)

Entra ID > Properties > Manage Security Defaults > Enabled = Yes

Disable Legacy Authentication Globally

# Create authentication policy blocking all basic auth
New-AuthenticationPolicy -Name "Block Basic Auth"
Set-AuthenticationPolicy -Identity "Block Basic Auth" `
    -AllowBasicAuthImap $false -AllowBasicAuthPop $false `
    -AllowBasicAuthSmtp $false -AllowBasicAuthWebServices $false `
    -AllowBasicAuthRpc $false -AllowBasicAuthMapi $false

# Apply to all users
Get-User -ResultSize Unlimited | Set-User -AuthenticationPolicy "Block Basic Auth"

Restrict Guest Invitations

Entra ID > External Identities > External collaboration settings:
Guest invite settings = "Only users assigned to specific admin roles can invite"

Enable Phishing-Resistant MFA Methods

Entra ID > Authentication methods > FIDO2 security keys = Enabled (for all or admins)
Entra ID > Authentication methods > Microsoft Authenticator = Enabled
Entra ID > Authentication methods > SMS = Disabled (phishable, replace with Authenticator)

How EtcSec Detects This

EtcSec audits your complete Azure tenant configuration on every scan, checking every setting that affects the security baseline.

AZ_SECURITY_DEFAULTS_DISABLED identifies tenants where Security Defaults are off without equivalent Conditional Access coverage — a fundamental baseline gap.

CA_NO_LEGACY_AUTH_BLOCK flags the absence of a Conditional Access policy blocking legacy authentication protocols, leaving an MFA bypass open for any attacker with a stolen password.

B2B_CROSS_TENANT_OPEN detects overly permissive cross-tenant access settings that allow unrestricted external collaboration without security controls.

ℹ️ Note: EtcSec audits Azure tenant configuration automatically. Run a free audit to validate your tenant hardening posture.

Review Priorities

Azure Tenant Hardening: Fixing the Insecure Defaults That Ship Out of the Box should be handled as a real exposure inside your Entra ID and Azure tenant, not as a single isolated setting. Start by defining the review perimeter: which admins, guests, service principals, app registrations, policy exclusions, and break-glass accounts are affected, which business workflows depend on them, which privileges they expose, and which emergency exceptions were added over time. That scoping step prevents shallow remediation, because the technical symptom is often smaller than the operational blast radius. By documenting the full path from configuration to privilege, the team can prioritize changes that reduce risk quickly without breaking production access. This also creates a defensible baseline for later validation and gives leadership a clear explanation of why the issue matters now.

Adjacent Controls to Review

When attackers reach your Entra ID and Azure tenant, they rarely stop at the first weak point. Around Azure Tenant Hardening: Fixing the Insecure Defaults That Ship Out of the Box, they normally test whether the exposed path can be chained with legacy authentication, weak guest governance, broad app consent, stale emergency accounts, and roles that were never reviewed. That means defenders should review not just the headline weakness but every nearby dependency that turns access into persistence or privilege escalation. Confirm which identities, roles, permissions, and trust assumptions can be reused by a motivated operator. If a fix closes only one object while leaving adjacent privilege paths untouched, the effective risk barely changes. A disciplined review of chaining opportunities is what turns this article topic into a practical hardening exercise rather than a one-time checkbox.

Evidence and Telemetry to Pull

A strong response to Azure Tenant Hardening: Fixing the Insecure Defaults That Ship Out of the Box needs evidence that can be reviewed by both engineering and detection teams. Pull sign-in logs, audit logs, role assignment changes, consent events, application credential changes, and risky sign-in signals, compare recent changes with known maintenance windows, and isolate accounts or systems that changed behavior without a clear business reason. Use that evidence to answer three questions: when the risky path appeared, who can still use it, and whether similar exposure exists elsewhere in your Entra ID and Azure tenant. Good telemetry review also helps you separate inherited technical debt from active misuse. That distinction matters, because the remediation plan for stale misconfiguration is different from the plan for a path that already shows attacker-like activity or repeated policy exceptions.

Adjacent Weaknesses Worth Reviewing

Very few environments contain Azure Tenant Hardening: Fixing the Insecure Defaults That Ship Out of the Box alone. In practice, the same tenant or directory segment often contains legacy authentication, weak guest governance, broad app consent, stale emergency accounts, and roles that were never reviewed, and those neighboring weaknesses decide whether the issue is merely noisy or truly critical. Review shared owners, inherited permissions, duplicated exceptions, and long-lived administrative shortcuts. Check whether the same team approved similar risky patterns in multiple places, because repeated decisions usually point to a process gap rather than a single technical bug. This broader review prevents partial cleanup and gives you a better chance of removing the entire attack path. It also improves audit readiness, because the final state is easier to explain and easier to monitor over time.

Remediation Order That Lowers Risk Fast

For Azure Tenant Hardening: Fixing the Insecure Defaults That Ship Out of the Box, remediation should follow an order that reduces exposure before it chases perfection. First remove the easiest privilege expansion paths, then lock down the highest-value identities or objects, and only after that clean up secondary hygiene gaps. Use Conditional Access, PIM, least privilege, access reviews, application ownership checks, approval workflows, and strong MFA as the control set that defines the target state. Each change should have an owner, a rollback note, and a validation step. This prevents long projects from stalling after the first technical fix. If a full redesign is not immediately possible, document interim controls that reduce abuse potential today and schedule the structural work inside the next weekly operational review and monthly hardening review. The important point is measurable risk reduction, not cosmetic compliance.

Validation After Each Change

After changing any setting related to Azure Tenant Hardening: Fixing the Insecure Defaults That Ship Out of the Box, validate the outcome from both an administration view and an attacker-path view. Confirm that intended users and systems still work, then prove that the dangerous path no longer grants the same leverage. Re-run the evidence collection on sign-in logs, audit logs, role assignment changes, consent events, application credential changes, and risky sign-in signals, review approval records, and check whether neighboring objects still preserve a workaround. Validation should also include a simple written statement of success criteria, so the team knows what closure means. In mature teams, this step is what prevents regressions: the fix is accepted only when the risky path is closed, the business service still functions, and the resulting state matches the hardening target you actually want.

Azure Tenant Hardening: Validation Before Sign-Off

A strong review of Azure Tenant Hardening should end with production evidence, not with an assumption that the risky path disappeared. Before you close the finding, recheck role assignments, policy scope, app permissions, or guest settings, sign-in, audit, or risk evidence from the real tenant, and the exception path that could silently recreate the exposure. Confirm that the safer state applies to the scope that actually matters: the production OU, the effective role assignment, the application path, or the trust and delegation path an attacker would really abuse. Record the technical owner, the business dependency, and the rollback condition so the next review can tell whether the safer state was maintained.

Use a short sign-off checklist:

• verify the risky state is gone from the attacker's point of view, not only from an admin screenshot
• keep one before/after export or log sample that proves the affected scope changed
• document the owner and the exception decision if the control could not be fully enforced

For adjacent exposure, cross-check the result with AD and Azure Compliance: NIS2, ISO 27001, CIS Controls, Azure Conditional Access: MFA Bypass With Stolen Passwords, Azure Privileged Access: Too Many Global Admins, and Active Directory Security Audit Tools: What to Compare Before You Choose. The same control gap often reappears in nearby identity paths, logging gaps, or delegated permissions, which is why the final validation step matters as much as the initial finding.

Azure Tenant Hardening: Evidence to Keep for the Next Review Cycle

The next reviewer should not have to rebuild the case from memory. Keep the evidence that originally justified the finding, the proof that the change was applied, and the note that explains why the final state is acceptable. For this topic, the most useful evidence usually combines the tenant export or screenshot that shows the affected scope, the sign-in, audit, or policy evidence proving the control now applies, and the owner, approval, and exception note for the final state. That compact pack makes quarterly or post-change reviews much faster and helps explain whether the issue was removed, reduced, or formally accepted.

If a later admin, policy, or application change reopens the path, this historical evidence also makes it easier to prove what drifted. That is what turns Azure Tenant Hardening from a one-time check into a repeatable assurance process.

Related Reading

Review this topic together with Azure Conditional Access: MFA Bypass With Stolen Passwords, Azure Privileged Access: Too Many Global Admins, Azure Guest Accounts: The Forgotten Attack Surface in Your Tenant, Azure App Registrations: Over-Privileged Tenant Apps, and Azure Identity Protection: Blocking Leaked Credentials. Those adjacent posts show how the same identity weaknesses usually chain together in a real assessment instead of appearing as isolated findings.

• Azure Conditional Access: MFA Bypass With Stolen Passwords
• Azure Privileged Access: Too Many Global Admins
• Azure Guest Accounts: The Forgotten Attack Surface in Your Tenant
• Azure App Registrations: Over-Privileged Tenant Apps
• Azure Identity Protection: Blocking Leaked Credentials

Using those references keeps the remediation discussion focused on the full attack path rather than a single control gap.

Validate the Hardening Baseline Over Time

Default settings should be treated as a starting point, not as the final hardening outcome. After applying safer tenant defaults, confirm which teams still rely on broad exceptions, whether new applications or users can bypass the intended controls, and how drift is monitored over time. A hardened tenant stays resilient only when ownership, review cadence, and exception handling are as disciplined as the initial rollout.