What breaks when consent is re-run with .default or adminconsent?

Why This Matters for Security Teams

Consent replay is not a harmless re-approval step. When a user, admin, or workflow re-runs consent with .default or adminconsent, the platform can reopen the static consent path and restore a broader entitlement set than the trimmed grant that teams thought was in place. That turns a one-time cleanup into an access regression, especially for service principals, app registrations, and delegated permissions that were intentionally reduced.

This is the kind of drift NHI teams miss when they focus on the visible token and not the underlying grant model. NHIMG has found that 97% of NHIs carry excessive privileges in the field, which is why permission creep remains so persistent in operational environments. The broader pattern is documented in the Ultimate Guide to NHIs, and it aligns with control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls around least privilege and configuration change management. In practice, many security teams encounter this only after a permission review or incident response reveals that a “reduced” grant was silently restored by the next consent event.

How It Works in Practice

.default is often used to request the permissions preconfigured on the app registration, while adminconsent authorizes tenant-wide permissions for an application. Both mechanisms are convenient, but they also create a rehydration path: if the original app definition still includes broader scopes, a fresh consent event can reapply them even after a team trimmed access manually. That is why the effective entitlement set must be treated as the result of the application object, service principal, and grant history together, not as a single static approval.

Practitioners should think in terms of change control, not just authentication. A consent replay can alter:

• Delegated scopes granted to users on behalf of an application
• Application permissions assigned tenant-wide to a service principal
• Admin-approved permissions that bypass ordinary user review
• Token behavior after the next refresh or client credential exchange

Operationally, this means baselining the app’s requested permissions, tracking granted permissions separately, and reviewing every consent event as a material authorization change. The Ultimate Guide to NHIs is useful here because it frames NHI governance as lifecycle control, not one-time setup. For control mapping, NIST SP 800-53 Rev 5 Security and Privacy Controls supports continuous authorization and review discipline, while EU General Data Protection Regulation (GDPR) becomes relevant where consented access processes affect personal data handling and downstream sharing.

These controls tend to break down when application owners can re-consent without a separate approval gate, because the platform treats a new consent event as authoritative even when the previous grant was intentionally narrowed.

Common Variations and Edge Cases

Tighter consent controls often increase operational overhead, requiring organisations to balance deployment speed against the risk of permission rebound.

The main edge case is that not every re-consent behaves the same way. Some tenants have more restrictive admin workflows, some apps use incremental consent patterns, and some permissions remain hidden until a new token is minted. Best practice is evolving, but current guidance suggests treating any flow that reopens the static consent path as a privileged change event, especially when the app requests .default or when adminconsent is used to restore tenant-wide access.

Another common mistake is assuming a trimmed grant is durable if the app registration still advertises the broader scope set. That assumption fails during app updates, SaaS reconfiguration, delegated admin actions, and incident recovery. Security teams should also watch for shadow approvals in testing and break-glass accounts that bypass normal review. In high-change environments, consent replay should be paired with entitlement diffing, alerting on scope expansion, and immediate revocation if the approved set no longer matches the business need. Where governance is weak, the replay problem becomes an access restoration problem rather than a consent problem.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• Why do misleading consent statements present significant risks?
• What breaks when AI agent access is not re-evaluated in real time?
• What breaks when RC4-only Kerberos accounts are migrated into AES-default Active Directory domains?