What breaks when app registrations are treated as live permissions instead of requests?

Why app registrations fail as permission records

An app registration is only the application’s declared identity and requested capabilities. The live permission comes from the grant or consent that has actually been issued, so the registration can overstate what is currently usable. If teams review the declaration instead of the grant, they will miss revoked access, partial consent, and feature checks that should fail closed.

That distinction matters because a registration is static and often broad by design, while the effective entitlement set is dynamic and often narrower. The practical question is not what the app asked for, but what the resource owner or platform has actually allowed at this moment.

When the registration is treated as authoritative, access review becomes performative: teams certify a request, not a right. This is how stale assumptions survive rotation, consent withdrawal, tenant changes, or scope reduction.

What breaks in reviews, revocation, and feature gating

Access reviews break first, because reviewers may approve or reject based on the requested scopes instead of the live grant. That can create false confidence that an app can or cannot perform a sensitive action when the truth is different. It also makes it harder to answer a simple audit question: what can this application do right now?

Revocation logic breaks in the same way. Removing or tightening a grant does not change the registration’s requested scope list, so systems that key off the registration can continue to believe access exists after it has been withdrawn. The result is lingering trust in a dead permission path, which is especially dangerous when downstream controls, approvers, or automation use the wrong source of truth.

Feature checks break when product logic equates “declared scope” with “allowed scope.” A feature flag, API call, or admin workflow should test the live grant, not the registration payload, because the registration is only a proposal. If the check is wrong, users may see access they no longer have, or be blocked when a valid grant exists.

How practitioners should model the entitlement boundary

The cleanest model is to treat the app registration as intent and the grant object as authority. That separates what the developer requested from what the platform has authorised, which is essential when reviewing least privilege, troubleshooting access failures, or designing conditional access checks.

For identity teams, the boundary should be visible in inventory, review workflows, and incident response. A registration inventory tells you what applications exist and what they were designed to ask for; a grant inventory tells you what is actually live. IAM and IGA basics is useful here because it frames the difference between request, entitlement, and reviewable access.

For cloud and platform teams, this is a permissions problem, not a naming problem. Cloud Workload Identity Guide helps illustrate why the live authentication and authorisation path, not the registered definition alone, determines what a workload can actually use. The same principle applies when applications sit behind APIs or service integrations that expose scope-like claims but enforce access through separate grants.

When a review needs to go beyond the concept and into operational control, Authorisation Models Guide is relevant because it reinforces that effective access must be evaluated at enforcement time, not merely at declaration time.

Risk and Threat Considerations

Misreading app registrations as live permissions creates a privilege blind spot. Attackers and careless operators benefit from that gap because defenders may overestimate, underestimate, or fail to notice what an application can still do after consent or grants have changed.

Failure mechanism: The control failure is a source-of-truth mismatch, where review and feature logic consult the registration while enforcement depends on the grant. That mismatch preserves stale assumptions, weakens revocation, and can allow overprivileged access to persist unnoticed.

Impact: Teams can approve the wrong access state, miss active excess privilege, and make removal actions look successful when they are not. In practice, that increases the chance of unauthorized data access, broken change control, and audit findings tied to ineffective entitlement review.

Practitioner Guidance

What to verify: Build your review process around the live grant object, not the app’s declared scopes. If the two disagree, treat the grant as the authoritative answer and investigate why the registration still advertises broader intent.

Common mistake: Do not use the registration as evidence of current privilege during access recertification, revocation, or feature gating. The registration is useful for discovery and intent, but it is the wrong object for deciding whether access is actually active.

Practitioner takeaway: The safest operational rule is simple: audit and enforce against live authorisation state, then use the registration only as context for what the application may ask for in the future.

Related resources from NHI Mgmt Group

• What breaks when compliance is treated as a periodic exercise instead of a live control model?
• What breaks when access requests are treated as broad group membership instead of specific resource and role decisions?
• What breaks when identity governance is treated as admin work instead of security work?
• What breaks when identity is treated as an administrative task instead of a control plane?