A finance team approves an enterprise application that reads invoices from Microsoft Graph. Its administrator asks for a broad permission grant because the integration is easier to configure that way. Six months later, an automation identity still holds the same permission although the workflow changed. No suspicious login is needed to create the exposure: an ordinary application credential can become an overpowered route to sensitive data. The Microsoft SC-500 exam expects security engineers to separate authentication, delegated consent, resource authorization and continuing governance. Each is a control with a different owner and failure mode.
The application scenario is also a useful reminder that identity is not a synonym for interactive user sign-in. People, workload identities, service principals, enterprise applications and agents can obtain tokens through different flows. A good security design identifies the subject asking for a token, the intended audience, the permissions contained in that token and the controls at the resource. For the baseline principles of temporary administrator access, see Entra ID and PIM; app access requires additional decisions after that foundation.
Trace the identity involved in the request
Begin with the boundary between an app registration and the service principal that represents it in a tenant. The registration describes an application and its identities; the enterprise application is where a tenant administrator sees the service principal, assignment and some operational access policies. This distinction matters when a vendor app is multitenant: a tenant does not become safe merely because the software publisher is recognized. Administrators must review the service principal present in their tenant, its permissions, ownership, sign-in behavior and intended resource access.
For a troubleshooting exercise, draw four boxes: human or workload caller, Entra token issuance, target API, and protected data. Then write the token subject and audience on the arrows. When an auditor asks whether a user can access a document, the answer may depend on both a delegated Graph permission and that user’s SharePoint rights. When an automation runs without a user, application permissions may permit a broader data set. The defensible design makes both patterns explicit and chooses one deliberately rather than allowing a developer to switch flows just to make a failing request succeed.
Conditional Access is a decision at token issuance
Conditional Access evaluates applicable policy when a supported user or workload requests an access token. It does not act as a universal firewall around every HTTP request and does not substitute for authorization checks inside the protected service. A privileged administrator might require phishing-resistant authentication before using a sensitive application, while a service principal can be restricted under the workload identity controls that apply to it. The policy scope and supported conditions matter as much as the grant control: targeting the wrong principal creates a reassuring policy that never governs the caller at risk.
Roll out a restrictive policy using report-only evaluation and sign-in diagnostics where supported. First identify all relevant users, service principals, emergency accounts and break-glass dependencies. Then test a successful approved transaction and a realistic denied transaction. Examine policy evaluation details rather than relying on the application error message, which may merely say it could not authenticate. Agent identity and Purview controls distinguish user Conditional Access from an autonomous agent identity that may receive a different token subject.
OAuth consent is a separate approval boundary
OAuth consent grants an application permission to access an API according to the selected scope or app role; it does not mean the resulting application is harmless. A delegated scope may let an app act within a user’s privileges, whereas an application permission can give it organization-wide capability without a user present. The engineer should read the actual requested permissions, check whether they are delegated or application-only, identify the data they unlock and determine whether admin consent is necessary. Blanket tenant-wide consent makes later risk reviews and incident response harder.
A practical approval packet names the business process, owner, app publisher, expected data, exact scopes, token flow, secret or credential storage, expiration or review date and rollback method. Avoid approving a broad permission merely because a vendor says it is part of a standard integration. If a narrower permission or a resource-specific assignment can support the legitimate function, test it before accepting a wide grant. Maintain a repeatable process to remove stale grants and orphaned service principals; a one-time approval ceremony without recurring review is not governance.
Managed identities reduce credential handling, not permission review
A managed identity can spare an Azure workload from storing a long-lived client secret, because Azure participates in obtaining and rotating credentials for that identity. It does not prevent a developer from assigning the identity excessive roles to the wrong resource. System-assigned identities follow the resource lifecycle; user-assigned identities can survive an individual compute resource and be shared across explicitly approved workloads. The distinction shapes ownership, blast radius and cleanup. Map each identity to its Azure role assignments and to any application-specific privileges that are enforced beyond Azure RBAC.
Suppose a Function app writes a Key Vault secret and accesses a database. Treat those as two independent resource-authorized operations rather than granting Contributor over the subscription. Confirm the Key Vault access model, SQL identity or contained-user mappings, and network restrictions separately. The Key Vault security discussion covers why vault authorization and private connectivity have to coexist; the storage or SQL service must enforce its own data permissions. Test that the identity cannot reach an unrelated vault or database even though it is a valid Azure principal.
Review custom roles and privilege inheritance carefully
A custom Azure role should grant narrowly selected actions and, where relevant, data actions. Management-plane permissions do not imply every data-plane operation, and some seemingly harmless actions can enable powerful indirect behavior when paired with role-assignment permission. Before creating a custom role, compare built-in roles at the intended scope. Review the assignment inheritance path from management group through subscription and resource group to individual resource. A role at subscription scope may be broader than the application owner realizes even when the role name sounds modest.
The governance process should answer who may add role assignments, who may create custom roles, and how changes are reviewed. Use access reviews, PIM eligibility and monitoring for high-risk assignments rather than relying on a spreadsheet maintained by one administrator. Azure Policy and compliance adds a different layer: policy enforces or assesses resource configuration, while RBAC controls actions by principals. Treating policy as a replacement for permission design leaves a real privilege gap.
Respond to risky grants without destroying evidence
When an unfamiliar application receives an elevated Graph permission, gather facts before deleting it. Record the service principal identity, consent audit event, who approved it, sign-in history and relevant resource accesses. The exact response depends on whether there is observed misuse, a mistaken approval, or a legitimate application whose privilege is excessive. Revoke risky grants or disable access under the incident process when appropriate, but preserve evidence that can explain the path and support remediation. Rotating a certificate alone is incomplete if the same high-risk permission is immediately restored.
For each incident, inspect whether other app registrations share owners or credentials, whether client secrets are stored insecurely, and whether the application uses a delegated or app-only flow. Reevaluate Conditional Access scope after changes, and establish a documented path for vendors to request a replacement, less privileged grant. The objective is to change the conditions that enabled the error rather than produce one successful revocation event. A useful closure record includes the reviewed permissions, confirming negative tests and a named owner for the new design.
Separate identity security from application security
A valid token can arrive at a dangerously designed API. Back-end code still needs to check audience, issuer, relevant claims and authorization for the specific business transaction. A role that permits reading a customer case should not automatically allow bulk export or changing financial details. A sound design combines API authorization and perimeter controls with authentication, policy gateways and business-logic checks; no single layer replaces transaction-level authorization. Conditional Access is a valuable upstream control but is not the final authorization engine for every operation.
A reliable validation matrix includes an approved user with normal permissions, a privileged user after PIM activation, an application-only principal, a revoked credential, and an identity outside the authorized tenant or resource scope. For each case, record whether token issuance succeeds, whether the API accepts the token, and whether the business action is allowed. If those three results do not line up with policy, the system has a testable defect. This approach is more useful than a screenshot proving a new Conditional Access policy was successfully saved.
Build a governance loop the business can sustain
Security engineers often inherit an identity estate that was configured during a rush to integrate SaaS products. A monthly inventory of service principals, high-risk consent grants, long-lived credentials and privileged role assignments can reveal drift before an attacker does. Pair that inventory with a process owner: a service desk may know who approved an integration, while a finance or HR system owner can judge whether the data scope remains necessary. Record exceptions with clear expiration dates, not indefinite notes in a ticket.
A reliable access review starts by naming the caller: a person, workload or agent. Identify the token audience, Conditional Access decision, consent grant and resource-level action, then test exactly which request should be denied. Recheck those permissions after an integration is redesigned or its owner changes. That discipline prevents a successful login from becoming a substitute for meaningful authorization.