A standing grant is access that remains active after the moment it was approved. In SaaS and identity environments, it often comes from OAuth consent, delegated permissions, or service accounts that persist long after the original business need has faded. Standing grants increase blast radius and complicate revocation.
What standing grants are, and why they matter
A standing grant is not a one-time approval; it is durable access that remains active until someone explicitly removes it. That persistence makes it operationally convenient, but it also means the access path can outlive the business need, the employee, the project, or the integration it was meant to support.
In practice, standing grants often appear in SaaS permissions, delegated OAuth consent, API access, and service accounts. The security issue is not simply that access exists, but that it continues to exist without repeated validation of need, scope, or ownership.
How standing grants change the access-risk profile
The main difference between a standing grant and a temporary grant is lifecycle. A temporary grant ends on its own or is designed to be reviewed again; a standing grant depends on later human action for revocation. That creates a larger window for misuse, drift, and forgotten access.
Standing grants also expand blast radius because they preserve access after context has changed. If the original task is complete, the access still remains available to the same user, application, or integration, which can turn a narrow approval into a long-lived privilege.
This is especially important in environments where access is granted through consent screens, delegated scopes, or non-user credentials. The access may look routine at approval time, but the control weakness is persistence, not initial legitimacy.
Where standing grants commonly appear
Standing grants are most visible in identity and SaaS environments, but the pattern is broader. Any approval that creates durable access can become a standing grant if it is not tied to an expiry, a renewal gate, or a clear deprovisioning step.
- OAuth consent that remains valid after the original use case ends.
- Delegated permissions that continue to authorize actions long after the requestor changes role.
- Service accounts or automation credentials that are left in place after an integration, pipeline, or vendor relationship has changed.
- Entitlements that were granted for a project and never revisited.
The practical problem is that standing grants are easy to overlook because they often look like normal access. Their risk becomes visible only when ownership, purpose, or revocation is tested.
Why standing grants are difficult to remove cleanly
Standing grants are often embedded in workflows that favour continuity over review. Removing them can break automations, interrupt integrations, or require coordination across application owners, SaaS administrators, and business teams. That makes revocation slower than approval, and slower revocation is what lets dormant access accumulate.
They can also be hard to inventory because the approval event and the active permission may live in different systems. A consent record, a cloud permission, and an application-specific role may all need to be reconciled before an organization can be confident the grant is still justified.
Risk and Threat Considerations
Standing grants create a durable exposure window that attackers, ex-employees, compromised accounts, and over-privileged integrations can exploit. The longer access remains active without a fresh need check, the more likely it is that a forgotten permission becomes an unauthorized entry path.
Failure mechanism: Access is approved once, then left active while the business purpose, user role, or integration context changes. Revocation depends on later review, so stale permissions, excessive scopes, and abandoned service access can persist unnoticed.
Impact: Persistent access increases blast radius, weakens least-privilege assumptions, and can enable data exposure, unauthorized actions, and lateral movement through trusted SaaS or identity-controlled systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST SP 800-63, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Standing grants persist after access should end, matching offboarding and removal risk. |
| NHI-05 — Overprivileged NHI | Standing grants often leave non-human and delegated access broader than current need. | |
| NHI-07 — Long-Lived Secrets | Persistent access commonly relies on durable credentials or tokens that outlast need. | |
| Recommendation — Revoke standing grants promptly when the business purpose or owner changes. Reduce standing grants to the minimum scopes needed for current operations. Rotate or retire long-lived credentials that keep standing grants alive. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Standing grants are an account lifecycle and revocation issue within access governance. |
| AC-6 — Least Privilege | Standing grants increase access beyond current need and conflict with least privilege. | |
| IA-5 — Authenticator Management | Persistent grants often depend on secrets, tokens, or credentials that remain valid too long. | |
| Recommendation — Review accounts and entitlements regularly and remove access that no longer has a valid owner or purpose. Limit persistent access to the smallest set of permissions required for the task. Set rotation and expiration rules for credentials that support standing access. | ||
| NIST SP 800-63 | Digital Identity Guidelines | The guidelines inform strong authentication and lifecycle handling for persistent identity-backed access. |
| Recommendation — Apply stronger lifecycle and reauthentication expectations to durable access paths. | ||
| CIS Controls v8 | CIS-5 — Account Management | Standing grants are controlled through account and entitlement lifecycle management. |
| Recommendation — Audit active access regularly and disable permissions that no longer have a business need. | ||
| NIST CSF 2.0 | PR.AA-05 — Least Privilege | Standing grants conflict with least-privilege access that should remain tightly scoped over time. |
| Recommendation — Enforce least-privilege access for all enduring permissions and consents. | ||
Practitioner Guidance
Governance implication: Treat standing grants as a lifecycle problem, not just an approval problem. The question is not whether access was justified at issuance, but whether the same justification still exists today.
What to watch for: Long-lived delegated permissions, dormant service accounts, and consents with no expiry or owner are the clearest warning signs. If the access cannot be easily explained in terms of current business purpose, it probably needs review.
Practitioner takeaway: The safest standing grant is the one that has an explicit owner, a documented purpose, and a defined path to removal when that purpose ends.
Related resources from NHI Mgmt Group
- Standing Trust
- How should security teams grant external agencies access without creating standing privilege on shared accounts?
- What is the difference between treating access as a standing grant and treating it as dynamic trust for AI agents?
- How should security teams grant sudo access in Ubuntu without creating unnecessary standing privilege?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
