Microsoft AZ-500 Retirement: Moving to SC-500

AZ-500 and the Microsoft Certified: Azure Security Engineer Associate certification retired on August 31, 2026. Microsoft replaced that path with Cloud and AI Security Engineer Associate, earned through SC-500.

The transition is significant because SC-500 expands the security-engineer role beyond securing traditional Azure infrastructure. Identity, Key Vault, storage, databases, networking, compute, Defender for Cloud, and governance remain important, but the new role also includes protecting AI platforms, data, agents, and AI-related access paths.

Anyone who already studied AZ-500 has a strong foundation. The right transition is to keep the durable Azure security skills and add the AI security, Microsoft 365 familiarity, agent identity, data exposure, and modern posture-management topics that SC-500 now expects.

What AZ-500 taught that still matters

AZ-500 built strong foundations in identity and access, platform protection, security operations, data protection, networking, Key Vault, and Microsoft Defender for Cloud. Those areas did not disappear when the certification retired.

Least privilege is still central. Administrators and applications should receive only the permissions required. Managed identities remain preferable to distributing long-lived credentials. Private connectivity, firewalling, segmentation, encryption, vulnerability management, and logging remain core security controls.

The change is that these controls now need to protect a broader technology surface, including AI applications and agents.

SC-500 starts with identity, access, and governance

The current SC-500 blueprint gives 20–25% to identity, access, and governance. Candidates should understand Microsoft Entra ID, Privileged Identity Management, Conditional Access, multifactor and passwordless authentication, app registrations, enterprise applications, OAuth consent, and managed identities.

The important skill is reducing standing privilege. PIM can make administrative roles eligible rather than permanently active. Conditional Access can enforce controls based on user, device, risk, application, and other signals.

The Conditional Access model is worth understanding deeply because identity is the control plane for both people and many modern workloads.

Key Vault remains the boundary for secrets, keys, and certificates

SC-500 explicitly includes deploying and securing Azure Key Vault, configuring access, network restrictions, and managing keys, secrets, and certificates.

The design principle is to avoid embedding secrets in source code, images, configuration files, pipelines, or agent instructions. Applications should use managed identities where possible and retrieve only the credentials they genuinely need.

Key management also includes rotation, logging, recovery, and separation of duties. Encrypting data is not useful if the same broad group can freely access the key that protects it.

Storage, databases, and networking form the largest current domain

SC-500 assigns 25–30% to securing storage, databases, and networking. That reflects how much sensitive data and application exposure lives in these layers.

Candidates should be able to secure storage accounts, Azure SQL and other database services, private access, firewall rules, network security groups, Azure Firewall, Web Application Firewall, DDoS protections, and related monitoring.

Private endpoints can reduce public exposure, but secure architecture still requires DNS, authorization, and data-layer controls. A service reachable only through a private IP can still be misused by an overprivileged identity.

Compute security now includes more platform services

SC-500 includes servers and VMs as well as Azure Container Instances, Container Apps, Functions, Logic Apps, App Service, API Management, and application-delivery controls.

Each compute model changes responsibility. A VM gives the customer operating-system control and patching responsibility. A platform service reduces infrastructure management but still requires identity, network access, application settings, and secure deployment.

Security engineers should understand how Defender plans, vulnerability management, application authentication, network restrictions, and workload identities differ across these services.

AI security is the major new responsibility

Threat modeling for AI should include the complete path from user identity to model, knowledge source, tools, and downstream systems. Prompt injection is only one possible problem. Overbroad retrieval, unsafe tool permissions, exposed secrets, insecure APIs, or weak approval boundaries can all turn a harmless-looking conversational interface into a route to sensitive data or consequential actions. Security engineers should therefore review the agent as an application architecture, not as an isolated model.

The new exam explicitly includes security for AI platforms and agents. Microsoft’s current objectives mention Microsoft Copilot, Copilot Studio agents, Microsoft Entra Agent ID, Microsoft Foundry, API Management AI Gateway, Defender for AI Service, and AI-related data exposure.

This expands the security question from “who can access this VM or database?” to “what data can this model retrieve, which tools can this agent invoke, what identity acts on its behalf, and how large is the blast radius if that identity is compromised?”

The AI governance and risk discipline becomes directly relevant because agents can create consequences beyond ordinary content generation.

Agent identities need least privilege just like human administrators

An AI agent may need an identity to call APIs, query data, or execute business actions. That identity should be scoped as narrowly as possible and should not inherit broad permissions merely because the developer used an administrator account during testing.

Microsoft Entra Agent ID and related controls are becoming part of the modern security model. Security engineers need to evaluate access, consent, conditional controls, and the relationships between an agent, its tools, and the data it can reach.

Human approval remains appropriate for high-impact actions. Security architecture should distinguish between an agent being allowed to recommend an action and being allowed to execute it automatically.

Data exposure is now an AI security problem

Generative AI can surface information users did not realize was broadly accessible. If sensitive SharePoint content, documents, or data stores have weak permissions, an AI assistant can make that overexposure easier to discover.

SC-500 therefore includes Microsoft Purview Data Security Posture Management and other controls that help organizations understand data and AI risk.

This is an important shift: AI security is not only about protecting a model endpoint from attack. It is also about governing the enterprise information the model or agent can retrieve.

Defender for Cloud remains central to posture management

The current exam gives 20–25% to managing and monitoring security posture. Microsoft Defender for Cloud remains a central platform for cloud security posture management, compliance assessment, workload protection, and vulnerability visibility.

Defender CSPM can identify misconfigurations and exposure paths, while workload protection plans add deeper monitoring for supported services. Multicloud and hybrid connections extend some of that posture management beyond Azure.

A good security program assigns owners and remediation expectations to findings. A Secure Score that is reviewed once a quarter without operational follow-through is not a security process.

Monitoring needs to connect configuration risk with active threats

Cloud security engineering sits between preventive controls and security operations. Azure Monitor, Defender products, vulnerability management, activity logs, identity signals, and Microsoft Sentinel can provide different views of risk and attack activity.

The security engineer should know which telemetry demonstrates a configuration weakness and which telemetry indicates an active incident. These signals may ultimately feed security operations teams, but the engineering role is responsible for making the platform observable and defensible.

Security controls should also be tested as systems, not merely enabled individually. A private endpoint can be undermined by an unexpected public path, an application identity can bypass network restrictions through excessive permissions, and a secure Key Vault can still expose risk if secrets are copied into application settings. Threat modeling helps engineers follow an attacker’s possible path across identity, network, compute, data, and AI components before production incidents reveal the gaps.

The cloud security posture management model is useful because prevention begins with knowing which controls have drifted from the intended state.

What to keep from old AZ-500 study material

Keep Microsoft Entra ID fundamentals, RBAC, managed identities, Key Vault, private networking, NSGs, Azure Firewall, WAF, DDoS protection, storage and database security, Defender for Cloud, vulnerability management, policy, logging, and security monitoring.

Discard material that presents Azure Security Engineer Associate or AZ-500 as an active credential. Update old terminology such as Azure Active Directory to Microsoft Entra ID and Azure Security Center to Microsoft Defender for Cloud.

The AZ-500 transition mistakes are especially useful for identifying legacy study assumptions that no longer match the current role.

A practical SC-500 transition lab

Build a small Azure environment with a VNet, storage account, application workload, Key Vault, managed identity, and private access. Configure Conditional Access and least-privilege Azure roles. Enable Defender for Cloud and review the security posture findings.

Then add one simple AI or agent scenario. Give it access to a constrained data source and one narrowly scoped action. Review what identity the agent uses, what data it can retrieve, how tool calls are authorized, and what telemetry is available.

Finally, deliberately create an overbroad permission or public network exposure and trace how the posture tools reveal the risk. That exercise connects the durable AZ-500 foundation to the AI security responsibilities SC-500 adds.

SC-500 broadens rather than erases the Azure security role

AZ-500 retired because Microsoft expanded what a cloud security engineer is expected to protect. Azure infrastructure remains part of the job, but security now extends into AI data, agents, model platforms, and Microsoft 365-connected experiences.

The new certification reflects that broader attack surface. Identity, network, compute, database, and posture skills remain essential; AI simply adds new identities, tools, data paths, and consequences.

If you already prepared for AZ-500, keep the core cloud-security knowledge and add the AI-focused objectives. If you are starting now, prepare directly for SC-500 and the Cloud and AI Security Engineer Associate role.