SC-500 Cheat Sheet

An eligible assignment supplies no standing role access until the assignee completes its configured activation steps; an active assignment supplies the role without activation. Use eligible assignments when privileged access should exist only just in time.

Trap Create a permanent active assignment and rely on an access review to make each use temporary.

Enable Require approval to activate and designate approvers when an eligible user's request must be explicitly approved before the role becomes active. Requiring justification records a reason but does not create an approval gate.

Trap Require justification on activation.

Set Activation maximum duration to limit how long an approved activation remains active before expiring. Assignment expiration controls how long an eligible or active assignment exists, not the duration of each activation.

Trap Configure Expire eligible assignments after for a four-hour elevation window.

PIM role settings apply to one role at one Azure resource scope, and every assignment for that role at that resource follows them. Settings configured at a subscription do not inherit to the same role at a child resource group.

Trap Configure the role policy once at the management group and expect child-resource policies to inherit it.

PIM role settings can require MFA or a Conditional Access authentication context when an eligible user activates a role. A prior strong or MFA authentication in the session can satisfy the ordinary MFA setting; to require reauthentication for each activation, target the authentication context with a Conditional Access sign-in frequency of Every time, noting that a 10-minute reauthentication window still applies across eligible role activations.

Create PIM access reviews for Microsoft Entra or Azure resource roles to confirm that privileged access is still required. Select eligible assignments only, active assignments only, or all active and eligible assignments according to which grants must be recertified, then apply the review decisions to remove access that is no longer justified.

Configure each role's activation notifications by selecting its default recipients and adding other recipient email addresses as needed. Select Critical emails only when those recipients should receive messages requiring immediate action rather than every message of that notification type.

Review or download PIM audit history when evidence of privileged-role assignments and activations is required. PIM makes this history available for internal or external audit.

Microsoft Entra evaluates all Conditional Access policies that apply to the identity and target resource and grants access only when all applicable requirements are met. A block control in any applicable policy prevents access rather than being canceled by a grant in another policy.

Trap Place a permissive grant policy at higher priority so it overrides a separate block policy.

For policies targeting all users, exclude emergency or break-glass accounts so administrators can recover from a lockout. Within one policy, an explicit identity exclusion overrides that identity's inclusion.

Trap Include every Global Administrator so no privileged identity can bypass the policy.

Use report-only mode and inspect the Conditional Access results in sign-in logs to validate expected impact before switching a policy on. Report-only evaluation neither blocks users nor prompts them to satisfy grant or session controls.

Trap Enable the policy for all users and use the audit logs only after enforcement begins.

Calls made by service principals are not blocked by Conditional Access policies scoped to users. Use Conditional Access for workload identities when a policy must target service principals, and replace script credentials with managed identities where supported.

Trap Add the application's owner account to an all-users policy and assume the service principal is covered.

Assign a Conditional Access policy to the intended users, groups, or workload identities and target resources, then refine applicability with signals such as IP location, device platform or state, and user or sign-in risk. Choose block access or grant access with the required controls, such as MFA, authentication strength, or a compliant device.

A Conditional Access authentication strength can require the built-in multifactor, passwordless MFA, or phishing-resistant MFA strength, or a custom set of allowed combinations. Requiring generic MFA does not guarantee that a phishing-resistant method was used.

Trap Use the Require multifactor authentication grant control when only phishing-resistant credentials are acceptable.

The built-in phishing-resistant MFA strength includes passkeys such as FIDO2 security keys, Windows Hello for Business or platform credentials, and multifactor certificate-based authentication. Password plus an SMS code can satisfy MFA strength but not phishing-resistant MFA strength.

Trap Microsoft Authenticator push notification with number matching.

Issue a Temporary Access Pass so a user can perform initial sign-in or recover access and register a passwordless method such as a passkey. A TAP can satisfy MFA strength, but it is not included in the passwordless or phishing-resistant built-in strengths.

Trap Send the user a permanent password and exempt the registration session from MFA.

Enable an authentication method in the Microsoft Entra authentication methods policy and target the intended groups before users can register and use it. Configuring a Conditional Access authentication strength does not itself enable or provision the underlying credentials.

Trap Create a phishing-resistant authentication strength and skip enabling passkeys for the target users.

Choose a method only for the roles its capability table supports: primary authentication, secondary MFA, SSPR, or account recovery. Microsoft Authenticator passwordless supports primary authentication but not secondary MFA or recovery, whereas Authenticator push notifications support primary authentication, MFA, and SSPR; Verified ID supplies account-recovery proof but cannot perform sign-in or MFA.

The application object stores the global definition configured under App registrations. An enterprise application is the service principal in a tenant, where administrators manage local access settings, assignments, and consent for that tenant instance.

Trap Edit the enterprise application's service principal to change the multitenant application's global definition.

Use delegated permissions when an application accesses an API on behalf of a signed-in user; effective access is constrained by both the grant and the user's authorization. Use application permissions for app-only background access, and obtain administrator consent because no user context exists.

Trap Convert an interactive on-behalf-of workload to application permissions merely to suppress its user prompt.

When user consent is disabled, grant tenant-wide administrator consent to the required delegated Microsoft Graph permissions so users can sign in without an interactive consent prompt. Adding permissions to the registration alone does not create the OAuth permission grant.

Trap Configure the delegated permissions and rely on each user to consent during sign-in.

Set Assignment required to Yes and assign permitted users or groups when only selected identities may use an enterprise application. This access control is not a substitute for granting API consent; applications that require assignment need administrator consent rather than user consent.

Trap Require user assignment and assume the setting grants the application's Microsoft Graph scopes.

Use a certificate or federated identity credential instead of a client secret for a production confidential client; federation lets supported external workloads obtain tokens without managing a secret. If a client secret is temporarily unavoidable, set and track its expiration for replacement before it expires: its lifetime cannot exceed 24 months, and Microsoft recommends less than 12 months.

Apply the low-impact user-consent policy so users can consent only to selected low-impact permissions for verified-publisher applications or applications registered in the tenant. Enable the admin-consent workflow so requests outside that policy can be submitted for administrator review instead of being granted by the user.

An enterprise application's group assignment grants access only to users directly in the assigned group; it does not cascade through nested groups. Assign a nested group or its intended users directly when they must receive the application's access or app role.

Code running on a supported Azure host can use its managed identity through Azure Identity or MSAL to request a token without storing a client secret or certificate. The target service must support Microsoft Entra authentication, and the identity still needs authorization to the target resource.

Trap Create an app registration and store its client secret in the workload configuration.

Enabling a system-assigned identity creates a service principal tied to that Azure resource, and deleting the resource causes Azure to delete the identity. Only its parent resource can use that identity to request tokens.

Trap Share one system-assigned identity across a web app and a virtual machine.

Create a user-assigned identity as an independent Azure resource when several hosts need the same permissions or authorization must exist before workload deployment. Removing or deleting a host does not automatically delete this identity.

Trap Enable a separate system-assigned identity on every ephemeral instance when permissions must be precreated and shared.

Assign the managed identity a role that permits the required data operation at the narrowest target scope; enabling the identity on the source host authenticates it but grants no target access. Anyone able to run code on the source can exercise permissions of identities attached to that source.

Trap Grant Contributor on the source application and expect it to read a destination key vault automatically.

Deploy Azure Key Vault to centrally store secrets such as connection strings, cryptographic keys, and certificates with their private keys. Applications should reference vault objects instead of embedding sensitive values in source code or configuration.

Trap Store the connection string in an App Service setting and protect only the deployment slot.

Use separate key vaults for different applications, regions, and environments such as development and production when their security boundaries differ. Combining unrelated secrets in one vault broadens the impact of an identity or network compromise.

Trap Place every environment in one vault and separate access only by secret name prefixes.

Key Vault soft delete retains deleted vaults and objects during a configurable 7-to-90-day retention period so they can be recovered. A normal delete does not immediately make the name reusable because the item remains in the deleted state.

Trap Use a resource lock as the mechanism for recovering a deleted secret version.

Enable purge protection after soft delete when even highly privileged callers must be unable to purge deleted vault content before retention expires. Purge protection protects against malicious or accidental permanent deletion; soft delete alone still permits an authorized purge.

Trap Enable soft delete only and grant purge permission to the vault administrators.

Deploy a separate Key Vault for each tenant in a multitenant SaaS solution. A per-tenant vault boundary preserves isolation between customer data and workloads.

Use Key Vault for keys, secrets, and certificates, not as a scalable store for customer content or general service configuration. Place customer content in a data service such as Azure Storage or Azure Cosmos DB and use an appropriate configuration store for nonsensitive settings.

Key Vault control-plane permissions manage the vault resource, while data-plane permissions operate on keys, secrets, and certificates. A principal can therefore create or configure a vault yet remain unable to read a secret unless separately authorized for the data plane.

Trap Assign Key Vault Contributor to an application that only needs to retrieve secret values.

With the RBAC permission model, grant data access through Azure role assignments at the vault or narrower object scope; legacy vault access policies are a different authorization model. Do not create an access policy for a vault configured to use RBAC authorization.

Trap Add a legacy access policy to repair access on an RBAC-authorized vault.

Assign Key Vault Secrets User to read secret contents, Key Vault Crypto User to perform cryptographic operations with keys such as sign, verify, encrypt, decrypt, wrap, and unwrap, or Key Vault Certificates Officer to manage certificates, according to the required object type. An Officer role performs any action on its object class, so Key Vault Crypto Officer is the role for managing keys, not for using them, and broad management roles are not required merely to consume one class of vault data.

Trap Assign Owner at the resource-group scope to every application that retrieves one secret.

Enable a managed identity on the Azure workload and assign that identity the required Key Vault data role when an application must retrieve objects without stored credentials. Network reachability alone, including a private endpoint, does not authenticate or authorize the application.

Trap Create only a private endpoint because the application already resides in the connected virtual network.

Use a vault-level Azure RBAC assignment for Key Vault administrative operations such as object management, monitoring, and network access control. An object-scope assignment is not read-only - it grants the role's full data actions on the one key, secret, or certificate it names, so a Key Vault Secrets Officer scoped to a single secret can update or delete that secret - but it cannot reach operations that have no object path, such as creating a new secret, enumerating the vault's objects, or changing vault resource settings. Microsoft therefore states that assigning roles on individual keys, secrets, and certificates is not recommended, with exceptions such as a user who must read their own SSH private key to authenticate to a virtual machine through Azure Bastion.

A vault with its firewall disabled accepts requests from public networks by default, but each caller must still authenticate with Microsoft Entra ID and pass data-plane authorization. Enabling a firewall narrows network reachability and does not replace RBAC or access policies.

Trap Leave public access open because a firewall is unnecessary once the application has a managed identity.

To permit a subnet through a Key Vault virtual-network firewall rule over the public endpoint, enable the Microsoft.KeyVault service endpoint on that subnet and add the subnet rule. An NSG allow rule by itself does not place the subnet on the vault firewall allowlist.

Trap Add only an outbound HTTPS NSG rule from the subnet to the vault's public address.

Create a private endpoint, integrate name resolution with the privatelink.vaultcore.azure.net private DNS zone, and disable public network access for private-only data-plane connectivity. A private endpoint does not by itself disable the vault's public endpoint.

Trap Create the private endpoint but leave public network access enabled for all networks.

Allow trusted Microsoft services to bypass the Key Vault firewall only when the required integration appears on the documented trusted-services list. The option is not a blanket allow for every Azure service; for example, Azure DevOps still needs another permitted network path.

Trap Enable trusted-services bypass and assume any Microsoft-hosted build agent can reach the vault.

When a required client must use the public endpoint and has a public static IPv4 address or known CIDR range, enable access from selected networks, add that address or range to the Key Vault firewall allowlist, and keep the default action set to Deny. Sources not matched by an allowed IP, virtual-network rule, trusted-service exception, or other permitted path remain blocked.

Associate Key Vault with a Network Security Perimeter when it must share a logical isolation boundary with supported PaaS resources and admit public inbound access only through explicit perimeter rules. In Secure by perimeter mode, perimeter rules govern all non-private-endpoint traffic and override the Key Vault trusted-services firewall bypass.

A per-key rotation policy can automatically generate a fresh version at a configured interval or before expiration. Consumers should use a versionless key URI to discover the newest version while retaining versioned references needed to decrypt or unwrap data protected by older material.

Trap Delete every previous key version immediately after automatic rotation completes.

Key Vault rotation creates new wrapping-key material; the target service must rewrap its data-encryption keys with the new version. Keep old and new versions enabled until rewrapping finishes because existing data can still depend on the prior version.

Trap Assume Key Vault automatically decrypts and re-encrypts all application data when the key version changes.

Configure the certificate policy with issuer, validity, key, and lifetime-action settings to control creation and renewal. Integrated certificate authorities and self-signed certificates can support automatic renewal; renewing an integrated-CA certificate creates a new secret version and identifier.

Trap Store the PFX as a generic secret and expect Key Vault certificate autorenewal to manage it.

Set expiration metadata, monitor approaching expiry, and create a new secret version when a credential changes; Key Vault does not automatically rotate arbitrary application secrets. Update or reload consumers before disabling the old version to avoid an outage.

Trap Enable a cryptographic key rotation policy and expect it to rotate database passwords stored as secrets.

Store a service-owned certificate as a Key Vault certificate object, not as a generic secret, when Key Vault must manage issuance and autorenewal. A generic secret can hold certificate data but does not provide the managed certificate lifecycle.

Use Key Vault native backup for keys, secrets, and certificates that cannot be recreated from another source. Regularly restore test copies to verify the recovery procedure; object backup is a separate recoverability control from retaining a deletion through soft delete.

Enable agentless machine scanning in Defender CSPM to identify supported exposed credentials on Azure, AWS, and GCP virtual-machine disks without installing an agent or affecting machine performance. Defender for Servers Plan 2 can also provide machine secrets scanning, but Defender CSPM is required for the broader posture scenario.

Trap Deploy the Log Analytics agent and search only Key Vault diagnostic logs for secrets embedded on VM disks.

Use cloud-deployment resource scanning to find secrets in multicloud infrastructure-as-code deployment resources and code-repository scanning for connected DevOps repositories. These scanning surfaces complement, rather than duplicate, Key Vault's storage protections.

Trap Enable Defender for Key Vault and expect it to inspect plaintext credentials committed to a repository.

Review discovered secrets through affected-resource inventory and Defender for Cloud recommendations, then use cloud security explorer or attack-path analysis to understand reachable assets and lateral-movement risk. Merely moving a detected credential into Key Vault is insufficient if the exposed value remains valid elsewhere.

Trap Dismiss the finding after deleting the plaintext file without rotating the exposed credential.

Enable Microsoft Defender for Key Vault to detect unusual or potentially harmful attempts to access vaults and produce contextual security alerts. It adds threat detection, not network prevention, so firewall restrictions, least-privilege authorization, and diagnostic logging remain separate controls.

Trap Use Defender for Key Vault instead of configuring the vault firewall because alerts block suspicious requests automatically.

Enable Key Vault audit logging to record vault operations and configure log alerts for security-relevant events such as access failures or secret deletions. Use Event Grid subscriptions for change notifications about keys, secrets, and certificates; lifecycle events do not replace operation audit logs or security alerts.

A policy definition contains the condition and effect applied to matching resources; Microsoft supplies built-ins for common controls, while custom definitions implement organization-specific requirements. Group related definitions into an initiative when they should be assigned and tracked together.

Trap Create separate role assignments for every resource instead of defining a repeatable configuration rule.

Assign a policy at the management group or subscription that is the common ancestor of all intended resources, and use notScopes to exclude a resource group that must remain outside applicability. Assigning at one subscription cannot cover sibling subscriptions in the management group.

Trap Assign the definition to one subscription and expect it to govern every subscription under the same management group.

Use deny to reject noncompliant create or update requests, audit to record noncompliance without blocking, and modify or deployIfNotExists when Azure should alter or deploy a related configuration. A policy's effect, not merely its assignment, determines whether a new deployment is prevented.

Trap Choose Audit when a prohibited public endpoint must be blocked at deployment time.

A CanNotDelete lock allows authorized modifications but blocks deletion, whereas ReadOnly also blocks updates; parent-scope locks are inherited and the most restrictive lock wins. Locks affect Azure control-plane operations, not service data-plane writes or deletes.

Trap Apply a ReadOnly lock to a storage account to prevent deletion of blobs through the data-plane endpoint.

Use an assignment's notScopes for a permanent, broad bypass such as an environment that does not require the governance rule. Use a policy exemption for a waiver or mitigation that must remain visible as Exempted in compliance reporting and can expire through expiresOn without modifying the assignment.

A modify or deployIfNotExists assignment needs a system-assigned or user-assigned managed identity with the minimum Azure roles required by the policy's roleDefinitionIds. After assignment, create a remediation task to apply the modify operations or deployment template to existing noncompliant resources; assignment alone corrects resources only when the effect is triggered during applicable create or update activity.

Save a custom policy definition at a subscription or management group that is an ancestor of every intended assignment target, because the definition can target only resources within its location's hierarchy. Use a shared management group as the definition location when assignments must span multiple descendant subscriptions.

Define variable compliance values as parameters in a policy or initiative definition, then provide the required values in each assignment. This keeps the rule logic reusable while allowing different assignment scopes to enforce different business values or outcomes.

Regulatory compliance standards in Defender for Cloud are backed by Azure Policy initiatives and are continuously assessed at their assigned scopes. The dashboard reports compliant and noncompliant resources by standard and links failed assessments to remediation guidance.

Trap Treat a displayed compliance score as an external certification issued by Microsoft.

Enable a standard on the relevant management group or subscription so nested resources are aggregated and assessed consistently, supplying any required initiative parameters. Owner or Policy Contributor permission is required to add a standard.

Trap Enable the standard independently on every resource group to obtain management-group aggregation.

When cloud accounts are onboarded, Defender for Cloud enables the Microsoft Cloud Security Benchmark and assesses resources against its controls. Add regulatory or custom standards when the organization needs mappings beyond that default security baseline.

Security recommendations provide actionable fixes from continuous assessments and rank risk using factors such as internet exposure, sensitive data, lateral movement, and attack paths. Review affected resources and business impact before remediating or granting an exemption; severity alone is not the full contextual risk score.

Select the narrowest built-in role that contains the required actions, assign it to the user, group, service principal, or managed identity, and scope it no higher than necessary. Assignments at management group, subscription, and resource-group levels flow to descendant Azure resources.

Trap Grant Owner at the subscription because the task spans two resources in one resource group.

Define control-plane permissions in Actions and data-plane permissions in DataActions, then constrain where the role can be assigned with AssignableScopes. NotActions and NotDataActions subtract from wildcard grants in that role definition; they are not explicit deny rules against permissions obtained from another assignment.

Trap Add an operation to NotActions and expect it to override the same operation granted by another role.

Use a Microsoft Entra custom role for supported directory permissions and object scopes, and an Azure custom role for Azure Resource Manager and service data actions. A custom directory role does not become assignable at an Azure subscription or resource group.

Trap Create a Microsoft Entra custom role containing Storage blob DataActions.

Use Defender for Cloud identity and access recommendations to identify risky patterns such as service principals holding administrative roles at subscription or resource-group scope. Validate the workload's required operations, replace the assignment with the least-privileged role and scope, and remove unused privileged grants.

Trap Leave the administrative assignment in place and add Reader because the combined roles include least privilege.

Microsoft Entra Global Administrator does not itself grant access to Azure resources because directory roles and Azure RBAC are separate authorization systems. For emergency recovery, enabling Azure resource access assigns that administrator User Access Administrator at root scope (/); remove the root assignment or turn the setting off as soon as the required role assignments are repaired.

Use Azure Backup built-in roles and narrow vault scopes to grant only the backup management operations each operator needs. Subscription Owner is unnecessary for routine backup or restore duties and expands the impact of compromised credentials.

Trap Assign Owner on the subscription to every backup operator so all vault actions succeed.

Enable multi-user authorization on a Recovery Services vault or Backup vault so protected operations also require applicable authorization on a separate Resource Guard. A backup administrator who lacks sufficient permissions on that guard cannot perform those critical actions despite vault permissions.

Trap Use a CanNotDelete lock on the backup vault as a substitute for independent approval of security-setting changes.

Use secure-by-default soft delete when deleted backup data must remain recoverable for the retention period even after an account compromise. All newly created vaults have soft delete permanently enabled, and it cannot be disabled in regions where secure-by-default assurance is in preview or general availability.

Trap Assume soft delete can still be disabled before deleting backup data in a secure-by-default region.

Enable vault immutability to block operations that could shorten retention or delete protected backup data, and lock the setting when the protection must be irreversible. Pair immutable or always-on soft-delete protection with MUA for Azure Backup's maximum security posture.

Trap Rely on encryption at rest to prevent a privileged operator from deleting recovery points.

Azure Backup encrypts backup data at rest with platform-managed keys by default and requires no enablement action for that baseline. Configure customer-managed keys stored in Azure Key Vault when the organization must control the encryption key for workloads backed up to a Recovery Services vault.

Use a Recovery Services vault private endpoint when supported servers in a virtual network must back up and restore without exposing that virtual network to public IP addresses. Supported scenarios include SQL and SAP HANA databases in Azure VMs and on-premises servers using the MARS agent; do not assume every Azure Backup workload uses this private-endpoint path.

Configure Azure Backup's built-in monitoring and alerts for backup events, and use Backup Reports to audit backup and restore activity, track usage, and identify trends. These monitoring and reporting channels help surface unauthorized, suspicious, or malicious administrative and recovery activity.

Store custom policy and initiative definitions, assignments, parameters, and exemptions in source control and deploy them through a controlled pipeline. This approach provides change history and consistent promotion across environments instead of one-off portal edits.

Trap Export only a compliance report after manually recreating each policy assignment in production.

Deploy a changed definition to a test assignment, use enforcement mode disabled where appropriate to evaluate impact, and inspect compliance results before promoting it to broad production scope. Versioned rollout avoids turning an untested deny rule into an organization-wide deployment outage.

Trap Assign a new custom deny definition directly at the tenant root management group.

Run Microsoft Security DevOps in GitHub Actions or Azure Pipelines with the IaC category to analyze supported ARM, Bicep, Terraform, Kubernetes, and related templates. Resolve the resulting infrastructure-as-code findings in the repository rather than waiting only for postdeployment assessment.

Trap Enable runtime threat alerts and omit template scanning because both controls inspect deployed resources.

Express controls such as managed identities, private access, diagnostic settings, purge protection, and role or policy assignments in the ARM, Bicep, or Terraform deployment so repeated environments converge on the intended posture. Keep plaintext secrets out of templates and parameter files; use secure parameters with Key Vault references or a credential-free deployment identity.

Trap Pass production passwords as plain-text Terraform variables so the same template can configure every environment.

Enabling Secure transfer required makes Azure Storage REST operations require HTTPS and rejects HTTP requests. The setting is enabled by default for newly created storage accounts.

Trap Setting the minimum TLS version alone, which controls protocol version but does not replace the secure-transfer requirement.

Azure Storage supports TLS 1.2 and TLS 1.3, but a storage account can currently enforce only TLS 1.2 as the recommended minimum. Compatible clients can still negotiate TLS 1.3 automatically.

Trap Configuring TLS 1.3 as the account minimum because the service supports TLS 1.3 negotiation.

Azure Storage encrypts persisted data at rest by default with Microsoft-managed keys. Configure a customer-managed key in Azure Key Vault or Managed HSM when the organization must control rotation and revocation of the account or encryption-scope key.

Trap Enabling Secure transfer required, which protects requests in transit rather than changing ownership of the at-rest encryption key.

Infrastructure encryption causes Azure Storage data to be encrypted twice, once at the service level and again at the infrastructure level with different keys. Use it when policy requires double encryption rather than merely customer ownership of one encryption key.

Trap A customer-managed key by itself, which changes control of the service-level key but does not add the infrastructure-encryption layer.

Blob soft delete retains a deleted or overwritten blob so it can be restored during the retention interval. It is a recoverability control, not a write-once retention control.

Trap A time-based immutability policy, which prevents protected versions from being modified or deleted instead of making ordinary deletions recoverable.

When blob versioning is enabled, Azure Storage automatically creates and retains previous versions as a blob changes. Versioning protects blob revisions, but container soft delete must be enabled separately to recover a deleted container.

Trap Container soft delete alone, which can recover a removed container but does not retain every prior version of each changing blob.

Immutable storage for blobs provides WORM protection through time-based retention policies and legal holds. A locked time-based policy remains enforced until its retention period expires, whereas a legal hold remains until its tags are explicitly cleared.

Trap Blob soft delete, which permits recovery after deletion but does not prevent an authorized deletion from occurring.

Point-in-time restore for block blob data requires blob versioning, blob change feed, and blob soft delete to be enabled. Its restore window must be shorter than the soft-delete retention period.

Trap Geo-redundant replication, which provides regional durability but does not rewind a container to a selected earlier time.

To restrict a storage account public endpoint to selected networks, set the default network action to Deny and then add the required virtual network, public IPv4, resource-instance, or trusted-service allowances. Merely adding allow entries while the default action is Allow does not create a restrictive firewall boundary.

Trap Creating an NSG rule on an unrelated subnet, which does not change who can reach the storage account public endpoint.

Allowing a subnet through the Azure Storage firewall requires a virtual-network rule on the account and a Microsoft.Storage or Microsoft.Storage.Global service endpoint on that subnet. The portal can create the endpoint while the rule is added, but command-line deployments must ensure both sides are configured.

Trap Adding only the Microsoft.Storage service endpoint to the subnet, which does not by itself authorize that subnet on the account firewall.

Azure Storage IP firewall rules accept public IPv4 addresses and do not restrict requests from Azure clients in the same region as the storage account. Use a virtual-network rule or private connectivity when same-region Azure workload access must be selected.

Trap Adding the workload's private RFC 1918 address to an IP rule, because storage IP rules require public internet addresses.

Azure Storage firewall rules are enforced for data-plane protocols such as REST and SMB, but they do not restrict Azure Resource Manager control-plane operations. Network admission also does not grant data authorization; an allowed caller still needs valid credentials and permissions.

Trap Treating a trusted-service exception as an RBAC assignment, even though the exception permits a network path rather than a data operation.

To authorize blob, queue, table, or file data operations with Microsoft Entra ID, assign an appropriate Storage data role at the narrowest required scope. A control-plane role such as Contributor can manage the account but does not by itself authorize data access through Microsoft Entra credentials.

Trap Storage Account Contributor, which manages storage accounts but is not a Storage data-plane role.

For Blob Storage, a user delegation SAS is secured with Microsoft Entra credentials and a user delegation key. Microsoft recommends it over a service SAS or account SAS when delegated blob access can use Microsoft Entra authorization.

Trap An account SAS, which is signed with a storage account key and can delegate service-level operations across supported services.

A stored access policy can define start time, expiry, and permissions for one or more service SAS tokens and allows those constraints to be changed or revoked centrally. Stored access policies are not supported for account SAS or user delegation SAS tokens.

Trap Associating a user delegation SAS with a stored access policy, which that SAS type does not support.

Setting AllowSharedKeyAccess to false rejects requests authorized with the storage account keys, including service SAS and account SAS requests. Microsoft Entra authorization and user delegation SAS remain the preferred alternatives for supported Blob Storage operations.

Trap Rotating both account keys, which replaces credentials but continues to permit Shared Key authorization.

Enable Defender for Storage at subscription scope when all current and newly created storage accounts should inherit protection. Turn on Override Defender for Storage subscription-level settings on an individual account before giving that account different feature or malware-cap settings.

Trap Changing the subscription-wide malware cap to customize one account, which also changes the inherited setting for every other account.

Configure an Event Grid custom topic to deliver every Defender for Storage malware scan result for near-real-time automation. Configure a Log Analytics workspace when every result must instead be retained centrally for query, audit, or compliance.

Trap Azure Event Hubs as the native malware-result automation destination, rather than the documented Event Grid custom topic.

On-upload malware scanning uses a per-storage-account monthly data cap, with 10,000 GB as the default. Set an account override for a different local cap, or use -1 in supported deployment interfaces for unlimited scanning.

Trap A Microsoft Sentinel workspace daily cap, which limits analytics ingestion rather than Defender for Storage scanning volume.

When the optional soft-delete-malicious-blobs setting is enabled, Defender for Storage soft deletes blobs found malicious by on-upload or on-demand scanning and keeps them recoverable for investigation. The feature is off by default and enables blob soft delete if the account did not already have it.

Trap Blob index tags alone, which record scan results but do not remove access to a malicious blob.

Defender for Storage sensitive data threat detection uses agentless smart sampling and Microsoft Purview sensitive information types and labels to add data-sensitivity context to suspicious activity. It is a configurable feature separate from malware scanning.

Trap On-upload malware scanning, which examines uploaded objects for malware rather than classifying sensitive business data.

Defender for Storage continuously analyzes data-plane and control-plane telemetry from protected storage accounts to detect suspicious access patterns and behavior. Resource logs do not need to be enabled for this activity-monitoring protection.

Full malware scanning uses Microsoft Defender Antivirus to inspect Blob content and includes hash reputation analysis, but it is a paid feature available only with the new Defender for Storage plan. Hash reputation compares newly uploaded Blob storage and Azure Files object hashes with known malware, is available in all plans, and can miss unsupported operations such as SMB uploads and Put Block with Put Block List.

Apply Microsoft Entra ABAC role-assignment conditions to Defender for Storage malware scan-result blob index tags when users and applications must access only blobs whose scan result is clean. This preventive pattern blocks unscanned or malicious blobs instead of waiting for a later remediation workflow.

Create the Event Grid custom topic for Defender for Storage malware results in the same region as the protected storage account because cross-region delivery is unsupported. The topic must allow public IP access; a private-endpoint-only topic cannot receive Defender for Storage events.