Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Microsoft Azure / Entra ID / Microsoft 365

These findings apply to organizations using Microsoft cloud services (Azure subscriptions, Microsoft 365, Entra ID / Azure Active Directory).

Privileged Users with MFA Disabled

Severity: High

What it means

Multi-Factor Authentication (MFA) adds a second layer of security when logging in, typically a code from a phone app or a hardware key. Without MFA, if an attacker guesses or steals an admin's password (through phishing, a data breach, or brute force), they get full access to your cloud environment with nothing else stopping them.

This finding flags administrator accounts that do not have MFA enabled. These are the most sensitive accounts in your organization: a compromised admin account can lead to full control of your email, files, and infrastructure.

What the scan checks

The scan examines all users with privileged roles (Global Administrator, Application Administrator, Security Administrator, etc.) and checks whether they have registered for MFA. The alert triggers if any privileged user has MFA disabled.

How to fix

Option A: Enable Security Defaults (simplest)

If you don't already have Conditional Access policies, Security Defaults is the quickest way to enforce MFA for all users:

  1. Go to Entra ID > Identity > Overview > Properties.

  2. Click Manage security defaults.

  3. Set to Enabled.

Option B: Use Conditional Access (recommended for larger organizations)

  1. Go to Entra ID > Protection > Conditional Access.

  2. Click + New policy.

  3. Name it: "Require MFA for Admins".

  4. Under Users: select Directory roles and pick all admin roles (Global Administrator, Security Administrator, etc.).

  5. Under Grant: select Require multifactor authentication.

  6. Set the policy to On and save.

After creating the policy, each admin will be prompted to set up MFA on their next login.

Shadow Admin Users

Severity: Low

What it means

A "Shadow Admin" is a user who has administrative powers without being an obvious administrator. They hold roles like "Password Administrator" or "Helpdesk Administrator" that give them significant permissions (e.g., resetting anyone's password, managing applications), but they might not be subject to the same security controls (MFA, access reviews) as the officially recognized admins.

The risk is that these accounts fly under the radar: they don't show up in the "Global Administrators" list, but an attacker who compromises one of them can still do serious damage, like resetting a Global Admin's password and taking over the entire tenant.

What the scan checks

The scan identifies users assigned to any of these Entra ID roles:

  • Application Administrator

  • Authentication Administrator

  • Cloud Application Administrator

  • Helpdesk Administrator

  • Password Administrator

  • Privileged Authentication Administrator

  • Privileged Role Administrator

  • User Account Administrator

Users who also have the Global Administrator role are excluded (they are already visible as full admins).

How to fix

  1. Go to Entra ID > Roles and administrators.

  2. Click on each of the roles listed above.

  3. Review the list of assigned users. For each user, ask:

    • Does this person actually need this role? If not, remove them.

    • Is this a permanent assignment? Consider using Privileged Identity Management (PIM) for just-in-time access instead of permanent role assignments.

    • Is MFA enabled for this user? Shadow admins should have the same MFA requirements as full admins.

High Percentage of Privileged Users

Severity: Medium

What it means

More than 10% of your users have administrator roles in Entra ID. This is a sign that admin permissions have been granted too broadly, perhaps for convenience, or because temporary access was never revoked.

Every admin account is a potential entry point for an attacker. Reducing the number of admins limits the blast radius if one account is compromised.

What the scan checks

The scan counts the total number of users with any admin role and compares it to the total number of enabled users. The alert triggers if the ratio exceeds 10%.

How to fix

  1. Go to Entra ID > Roles and administrators.

  2. For each admin role, review who is assigned.

  3. Remove users who no longer need admin access.

  4. For users who only need admin access occasionally, use Privileged Identity Management (PIM) for just-in-time elevation.

Users with MFA Disabled

Severity: High

What it means

Some users in your organization do not have MFA enabled. Without MFA, a stolen or guessed password is all an attacker needs to access their mailbox, files, and any applications they have access to.

This is how the majority of business email compromise (BEC) attacks happen: an attacker phishes a user's password, logs in without MFA, and then sends fraudulent emails or steals sensitive data.

What the scan checks

The scan checks the MFA registration status of all enabled users. Any user with isMfaRegistered = false triggers the alert.

How to fix

The most effective approach is to enforce MFA for all users via Conditional Access or Security Defaults (see "Privileged Users with MFA Disabled" above for step-by-step instructions).

To check which users are missing MFA:

  1. Go to Entra ID > Protection > Authentication methods > User registration details.

  2. Filter by "MFA capable = No" to see who hasn't registered.

No Security Contact Set

Severity: Medium

What it means

Microsoft Defender for Cloud can detect security threats in your Azure environment (suspicious login attempts, malware, exposed services, etc.). But if no email address is configured, these alerts have nowhere to go: nobody gets notified, and attacks can go undetected.

What the scan checks

The scan checks whether at least one security contact email is configured in Microsoft Defender for Cloud's notification settings.

How to fix

  1. Go to the Azure Portal.

  2. Navigate to Microsoft Defender for Cloud > Environment settings.

  3. Select your subscription.

  4. Click Email notifications.

  5. Fill in:

    • Additional email addresses: add a distribution list (e.g., security@yourcompany.com), avoid using a single person's email.

    • Notification types: at least "High severity" alerts.

  6. Click Save.

No Administering Resource Locks Role

Severity: Low

What it means

Azure Resource Locks protect critical resources (databases, virtual networks, storage accounts) from accidental deletion or modification. Even an admin with full permissions cannot delete a locked resource without first removing the lock.

This finding means nobody in your organization has been assigned a role specifically for managing these locks. Without someone in charge, locks may not be used consistently, or critical resources may remain unprotected.

What the scan checks

The scan looks for a custom RBAC role with permissions to manage resource locks (Microsoft.Authorization/locks/*). If no such role exists or nobody is assigned to it, the alert triggers.

How to fix

  1. Go to the Azure Portal > Subscriptions > select your subscription.

  2. Go to Access control (IAM) > Roles > + Add > Add custom role.

  3. Create a role with the following permissions:

  1. Assign this role to a trusted administrator.

  2. Have that administrator apply Delete locks on critical resources (databases, storage accounts, key vaults).

Key Vault Not Recoverable

Severity: High

What it means

Azure Key Vault stores your secrets, encryption keys, and certificates. If someone accidentally (or maliciously) deletes a Key Vault, you lose all of these. Without soft-delete and purge protection enabled, a deleted Key Vault is gone forever: there is no recovery.

What the scan checks

The scan checks that both protections are enabled:

  • Soft-delete: deleted key vaults are kept for a retention period (default 90 days) and can be recovered.

  • Purge protection: even after soft-delete, the vault cannot be permanently erased during the retention period.

How to fix

  1. Go to the Azure Portal > Key vaults > select your vault.

  2. Go to Properties.

  3. Enable Soft-delete (note: this is now enabled by default on new vaults and cannot be disabled).

  4. Enable Purge protection.

  5. Click Save.

For existing vaults via Azure CLI:

HTTPS Not Enforced on App Service

Severity: High

What it means

Your Azure App Service (website or API) accepts unencrypted HTTP traffic. This means data sent between users and your application, including login credentials, personal information, and session tokens, can be intercepted by anyone on the network path.

What the scan checks

The scan checks the HTTPS Only setting on each App Service. If it is set to Off, the alert triggers.

How to fix

  1. Go to the Azure Portal > App Services > select your app.

  2. Go to Settings > Configuration > General settings.

  3. Set HTTPS Only to On.

  4. Click Save.

Insecure TLS Version on App Service

Severity: High

What it means

Your App Service accepts connections using TLS 1.0 or 1.1, which are outdated encryption protocols with known vulnerabilities. Modern browsers and security standards require TLS 1.2 or higher.

What the scan checks

The minimum TLS version configured on the App Service. The alert triggers if it is below 1.2.

How to fix

  1. Go to the Azure Portal > App Services > select your app.

  2. Go to Settings > Configuration > General settings.

  3. Set Minimum TLS Version to 1.2.

  4. Click Save.

SQL / PostgreSQL / MySQL: SSL Enforcement Disabled

Severity: High

What it means

Your database server accepts unencrypted connections. Without SSL/TLS enforcement, credentials and data sent between your application and the database can be intercepted on the network.

How to fix

For Azure Database for MySQL:

  1. Go to Azure Portal > Azure Database for MySQL > select your server.

  2. Go to Connection security.

  3. Set Enforce SSL connection to ENABLED.

  4. Click Save.

For Azure Database for PostgreSQL:

  1. Go to Azure Portal > Azure Database for PostgreSQL > select your server.

  2. Go to Connection security.

  3. Set Enforce SSL connection to ENABLED.

  4. Click Save.

Public Blob Container

Severity: High

What it means

One or more of your Azure Storage blob containers is configured for public access, meaning anyone on the internet can read the files inside without authentication. This is a common source of data leaks.

How to fix

  1. Go to Azure Portal > Storage accounts > select the account.

  2. Go to Configuration.

  3. Set Allow Blob public access to Disabled.

  4. Or, to fix individual containers: go to Containers, select the container, and change Public access level to Private.

Virtual Machine Disks Not Encrypted

Severity: High

What it means

Your virtual machine's disks are not encrypted. If the underlying physical hardware is compromised, decommissioned, or improperly disposed of, the data on those disks could be read in clear text.

How to fix

  1. Go to Azure Portal > Virtual machines > select the VM.

  2. Go to Disks > Additional settings.

  3. Enable Azure Disk Encryption (ADE) or Server-Side Encryption with customer-managed keys.

  4. For new VMs, enable encryption at creation time.

PreviousCloud Scan
NextAmazon Web Services (AWS)

Last updated

Was this helpful?