Azure / Guide 6

Security baseline: identity, Defender and Key Vault

MFA and privileged access, managed identities, Defender for Cloud, secure score, Key Vault and the logs you need.

Network controls limit where an attacker can go. Most Azure incidents, though, start with a signed-in identity: a phished admin, a leaked client secret, an old account nobody disabled. This guide covers the baseline that sits alongside the network: identity, Microsoft Defender for Cloud, Key Vault and the logs you'll need on the day something happens.

Identity comes first

MFA is mandatory for Azure now. Microsoft enforces it in two phases: the Azure portal, Entra admin center and Intune admin center first (from October 2024), then Azure CLI, Azure PowerShell, the mobile app, infrastructure-as-code tools and the REST API for create, update and delete operations (from October 2025, with postponements that ended on 1 July 2026). Managed identities and service principals aren't affected. User accounts used as service accounts are, and are the usual thing that breaks: move scheduled scripts to managed identities or service principals with certificates.

Beyond MFA:

• Conditional Access (Entra ID P1): require phishing-resistant MFA for admin roles, block legacy authentication, and require a compliant device for the portal. Start policies in report-only mode.
• Two emergency access ("break-glass") accounts: cloud-only, long random passwords or FIDO2 keys kept offline, excluded from Conditional Access so a bad policy can't lock everyone out, and an alert on every sign-in.
• Privileged Identity Management (Entra ID P2): nobody holds Owner, User Access Administrator or Global Administrator permanently. They activate it for a few hours, with a reason, and it's logged.
• Review access quarterly. Get-AzRoleAssignmentReport.ps1 lists every role assignment and flags the risky ones, and Guide 2 covers RBAC design.

Managed identities over secrets

Every client secret in a config file is a password that doesn't expire on its own and can't use MFA. For anything running in Azure, use a managed identity instead: Azure creates and rotates the credential, and nothing is stored in code.

• System-assigned identities live and die with one resource. Use them by default.
• User-assigned identities are separate resources shared by several resources, for example a scale set, or when the identity needs permissions before the resource exists.

For things outside Azure (a CI/CD pipeline, a partner's system), use a service principal with workload identity federation where the platform supports it (GitHub Actions, Azure DevOps, Kubernetes), a certificate where it doesn't, and a client secret only as a last resort, with a short expiry and an owner.

# Service principal secrets and certificates that expire in the next 30 days (Microsoft Graph PowerShell)
Connect-MgGraph -Scopes 'Application.Read.All'
$cutoff = (Get-Date).AddDays(30)
Get-MgApplication -All | ForEach-Object {
    $app = $_
    @($app.PasswordCredentials) + @($app.KeyCredentials) | Where-Object { $_ -and $_.EndDateTime -lt $cutoff } |
        ForEach-Object { [pscustomobject]@{ App = $app.DisplayName; AppId = $app.AppId; Expires = $_.EndDateTime } }
} | Sort-Object Expires

Microsoft Defender for Cloud

Defender for Cloud does two jobs: it checks your configuration (posture), and it detects attacks on running workloads (protection). They're licensed separately.

A sensible start: Servers Plan 2 and Storage on production subscriptions, Key Vault and SQL where you use them, and Defender CSPM once the free recommendations are under control. Enable plans at subscription level (or with Azure Policy at a management group) so new resources are covered automatically.

# Which Defender plans are on in this subscription
Get-AzSecurityPricing | Select-Object Name, PricingTier, SubPlan | Sort-Object Name

# Turn on Defender for Servers Plan 2
Set-AzSecurityPricing -Name 'VirtualMachines' -PricingTier 'Standard' -SubPlan 'P2'

Also set Environment settings > Email notifications so high-severity alerts go to a monitored mailbox, not only to subscription owners.

Work the secure score

The secure score is a percentage of recommendations you've addressed, weighted by how much each one matters. It's useful as a trend and as a to-do list, less so as a target in itself. Work it like this:

• Fix by control, not by resource. Controls such as "Enable MFA", "Secure management ports" and "Restrict unauthorised network access" carry the most points and usually map to the NSG and identity work in these guides.
• Use Azure Policy for the fix, so it stays fixed. Many recommendations offer Fix or Enforce, which deploys the matching policy (see Guide 3).
• Exempt, don't ignore. If a recommendation doesn't apply, create an exemption with a reason and an expiry date. The score then reflects real risk.
• Assign owners and due dates with governance rules (Defender CSPM), or at least in your own tracker.

# Unhealthy high-severity recommendations across every subscription, grouped by recommendation
Search-AzGraph -UseTenantScope -First 1000 -Query @"
SecurityResources
| where type == 'microsoft.security/assessments'
| where properties.status.code == 'Unhealthy' and properties.metadata.severity == 'High'
| summarize Resources = count() by Recommendation = tostring(properties.displayName)
| order by Resources desc
"@

Key Vault done right

Secrets, keys and certificates belong in Key Vault, not in app settings, scripts or pipelines. Settings to check on every vault:

Use one vault per application per environment. A shared vault means everyone with access to it can read everyone's secrets. Give apps Key Vault Secrets User (read only), not Key Vault Administrator.

# Vaults that miss the baseline
Search-AzGraph -UseTenantScope -First 1000 -Query @"
Resources
| where type =~ 'microsoft.keyvault/vaults'
| project name, resourceGroup, subscriptionId,
    rbac = tobool(properties.enableRbacAuthorization),
    purgeProtection = tobool(properties.enablePurgeProtection),
    publicAccess = tostring(properties.publicNetworkAccess)
| where rbac != true or purgeProtection != true or publicAccess !~ 'Disabled'
"@

Logs you will need later

Investigations fail most often because the logs were never collected, or were kept for too short a time. Send these to your Log Analytics workspace, and keep at least 90 days (longer if your auditors ask):

• Azure Activity log from every subscription: who created, changed or deleted what. Assign the built-in policy that configures it at the management group.
• Entra ID sign-in and audit logs (Entra admin center > Diagnostic settings). The portal only keeps them for 30 days at most.
• Resource logs for Key Vault, Azure Firewall, Application Gateway WAF and storage accounts that hold sensitive data.
• Virtual network flow logs for production networks (see Guide 4).
• Defender for Cloud alerts, exported continuously to the workspace.

If you need correlation and automated response on top, Microsoft Sentinel runs on the same workspace. Guide 9 covers workspaces and alerting.

A security baseline checklist