Identity security begins with the actor, the intended resource and the action. A successful login does not prove that the user or workload should be able to read a secret, change a storage policy or administer a subscription. Strong controls combine identity evidence, explicit resource permissions, privileged-access limits and observable results.

Separate sign-in, entitlement and resource authorization

Microsoft Entra ID can evaluate sign-in identity and session risk; Azure role-based access control determines many management-plane permissions; individual services may apply additional data-plane rules. These mechanisms answer different questions. A user might pass multifactor authentication yet still be forbidden to export Key Vault secrets or modify a production resource.

Start a security review with one request: who is the principal, which tenant and directory supplied the identity, which resource is involved, what operation is requested and which policy can permit it? Then verify that the resource itself enforces the decision. Do not rely solely on a portal screen showing that a group has a particular label.

Use Conditional Access and multifactor authentication proportionately

Conditional Access can use signals such as user, application, device condition and sign-in risk to require additional controls or deny access according to the supported configuration. A policy should be designed for the actual user population, with clear exclusions and emergency access. An excessive policy can lock administrators out; an overly broad exemption can preserve standing exposure.

Test a permitted sign-in, a user missing the required assurance and an emergency-administrator recovery scenario in a controlled tenant. Record the effective policy and the outcome rather than assuming that an enabled rule matched every request. Authentication-strength and phishing-resistant methods should be selected according to current Entra capabilities and organizational risk.

Constrain Azure RBAC scope and role assignments

Azure RBAC roles define allowed management operations at scopes such as management group, subscription, resource group or resource. Assign a role at the smallest scope that supports the task; a Reader role on one resource group is materially different from Contributor on the subscription. Data-plane access for services such as Storage and Key Vault may require additional role families and service-specific configuration.

A reviewable lab creates two test identities. Give the first only the permission to inspect a resource and verify a read succeeds. Attempt an unauthorized write and record its denial. For the second, assign a narrowly scoped operational role and confirm that unrelated groups or subscriptions remain inaccessible. The demonstration should explain why broader roles were rejected.

Treat privileged identity as a time-bound operation

Microsoft Entra Privileged Identity Management supports eligible assignments, activation conditions and access reviews in supported plans and roles. This can reduce permanent standing administrative access. It does not replace careful role selection: a time-limited subscription Owner assignment still has broad consequences while active.

Design the approval, reason, activation duration, multifactor requirement and logging based on the task. Before changing an active tenant, confirm emergency access and the team responsible for recovery. Test that privilege expires and that the intended audit trail records the activation and sensitive operation. A screenshot of eligibility alone does not prove an activation was used correctly.

Protect workload identities and application access

An application or automation job needs its own scoped identity. Managed identities can avoid embedding a long-lived credential in application code, but authorization still depends on which resources the identity can access. A workload trusted to read one Key Vault secret should not automatically have rights to rotate all keys or manage every secret in the tenant.

Review identity lifecycle as well as initial setup. Test token acquisition, denied resource access, rotation or revocation, and whether an old deployment retains permissions after a job is retired. Store only necessary identity telemetry and protect log access so audit evidence does not become a secondary path to sensitive data.

Evaluate a complete incident and recovery path

A practical challenge starts with an employee leaving a privileged team. The safe result requires revoking or changing group membership, reviewing eligible and active roles, invalidating inappropriate application access and verifying that future requests are denied. Consider propagation delays and cached tokens when defining when the revocation must become effective.

For an access outage, collect the user, application, timestamp, Conditional Access decision, effective resource roles and service-side error. Change one cause at a time; do not grant subscription-wide privileges merely to prove the failure is authorization related. Restore the least privileged working state and retain an incident record that explains the resolution.

Carry the historical learning into a current credential path

AZ-500 retired on August 31, 2026. Its identity content is a useful technical snapshot, not the latest Microsoft exam objective list. Product names also changed: Azure Active Directory is now Microsoft Entra ID, and capabilities and licensing vary by date and tenant. Verify the chosen features against current Microsoft documentation before applying procedures.

A current study plan for SC-500 current Azure cloud and AI security objectives should include evidence for identity decisions, cloud-workload safeguards, logs and operational recovery. Unlike the retired AZ-500, its active issuer guide defines the tasks a new candidate must prepare for; older AZ-500 examples are historical exercises, not a new assessment blueprint.

Case study: an unauthorized support vendor

A support supplier needs to inspect a fault in one resource group for two days. A broad subscription Contributor role would expose unrelated resources and allow operations outside the task. First identify the exact logs, configuration and monitoring views required; then assign the minimum eligible role and expiration mechanism supported by the environment. Do not use a shared administrator identity to avoid designing a scoped account.

The acceptance evidence is a successful authorized read, a failed attempt to modify an unrelated resource and an audit entry naming the acting identity and permission boundary. At the end of the access period, remove or expire the grant and repeat the denied-access test. If the required information cannot be read without broader privilege, record that as a design question rather than granting it silently.

Case study: a compromised automation identity

Suppose a workload identity that reads one protected configuration value is suspected of compromise. A response should identify its current role assignments, tokens and dependents, then limit access with the least disruptive effective revocation supported by the application. An identity-only change can break a dependent job or fail to invalidate an existing authorization token immediately.

Create a synthetic environment to test the sequence: confirm the identity currently works, record a denied operation outside scope, revoke the intended assignment or credential, test effective denial, rotate or replace access if needed and restore service through an approved principal. Keep evidence without exposing the secret itself. The goal is traceable containment and recovery, not a visually impressive security dashboard.