Manage identity, access, and governance
Microsoft Entra Access Controls
CoreControl privileged activation, sign-in conditions, authentication strength, application consent, and workload identity without treating every identity object as the same security principal.
Aligned to the live SC-500 guide, which publishes no skills-measured date; guide and product behavior verified September 23, 2026.
Why this matters
A strong identity perimeter reduces standing privilege and credential exposure, but a control applied to the wrong principal, resource, or token flow can leave the intended path untouched.
Must Know
- PIM makes supported roles eligible or time-bound and can require approval, multifactor authentication, justification, and activation duration; it does not replace the underlying role assignment.
- Conditional Access evaluates signals during Microsoft Entra token issuance. Start new policies in report-only mode and exclude emergency access accounts before enforcement.
- Authentication-method policy governs which methods users can register and use; Conditional Access governs when a sign-in must satisfy an authentication strength or other grant control.
- An app registration defines the application identity and credentials; the enterprise application is the tenant-local service principal where assignment, consent, and Conditional Access are enforced.
- Managed identities remove application-managed credentials. System-assigned identities share the resource lifecycle; user-assigned identities can be reused and have an independent lifecycle.
- Delegated permissions act with a signed-in user and cannot exceed that user context; application permissions act without a user and require especially careful admin consent.
Compare and Distinguish
- Eligible PIM assignment reduces standing privilege; an active or permanent assignment already grants the role.
- Authentication strength selects acceptable methods; named locations and device state are Conditional Access conditions.
- User-assigned managed identity supports reuse across resources; a service principal with a client secret returns credential ownership to the application team.
Scenario examples
- Scenario: Database administrators need a two-hour role only after approval. Think: make the role eligible in PIM and configure activation controls.
- Scenario: A daemon reads one vault with no stored secret. Think: use a managed identity and grant only the required data-plane role at that vault.
- Scenario: A multitenant app requests broad application permissions. Think: evaluate publisher, permissions, consent policy, and business need before admin consent.
Exam traps
- Registering phishing-resistant methods does not force their use unless policy requires an appropriate authentication strength.
- A Conditional Access policy in report-only mode records outcomes but does not block or grant access.
- Creating an app registration does not automatically assign users or grant resource permissions in every tenant.
- A managed identity still needs authorization at the target; removing a secret does not grant access.
Key takeaways
- Minimize standing privilege, then protect activation and token issuance.
- Identify the principal, token flow, target resource, and authorization scope before choosing a control.
- Use managed identity where Azure can own credential lifecycle.
How it works
- Microsoft Entra evaluates identity, application, resource, and policy signals before issuing a token.
- The target service then authorizes the token claims against its role or permission model.
Objects and administrative surfaces
- Microsoft Entra admin center for PIM, Conditional Access, authentication methods, enterprise apps, app registrations, and consent.
- Azure resource IAM for managed-identity role assignments at management group, subscription, resource group, or resource scope.
- Sign-in and audit logs for policy evaluation, consent activity, service-principal use, and PIM activation evidence.
When to use it
- Use PIM for just-in-time privileged roles and Conditional Access for contextual token controls.
- Use managed identities for supported Azure-hosted workloads that should not own credentials.
Security and governance implications
- Review privileged assignments, consent grants, unused applications, and service-principal credentials regularly.
- Maintain monitored emergency access accounts outside ordinary Conditional Access dependencies.
Troubleshooting signals
- Use sign-in logs and the Conditional Access result to distinguish policy exclusion, report-only outcome, and failed grant control.
- For an application denial, inspect token type, consented permissions, service-principal assignment, and target-resource role scope.
More detail
- Plan PIM activation requirements and role scope.
- Build Conditional Access safely with exclusions and report-only evaluation.
- Distinguish app registrations, service principals, delegated permissions, and application permissions.
- Select and authorize system-assigned or user-assigned managed identities.
Ready for the quiz?
- When is PIM eligibility better than a permanent assignment?
- Which object holds tenant-local enterprise app assignments and consent?
- Why can a managed identity authenticate successfully yet receive authorization denied?
Related objectives
- D1.1.S1 — Implement and configure Privileged Identity Management (PIM)
- D1.1.S2 — Implement conditional access policies
- D1.1.S3 — Implement and configure authentication methods, including multifactor authentication (MFA) and passwordless
- D1.1.S4 — Implement and configure identity for applications, including enterprise applications and app registrations
- D1.1.S5 — Manage OAuth permission grants and consent settings
- D1.1.S6 — Implement and configure managed identities for Azure resources