What happens when a wallet or contract is authorised and then never de-authorised?

When access is never removed, the original approval can remain a standing path to funds or privileged actions long after the business need has ended. That creates hidden exposure, especially if the counterparty, contract, or signing environment is later compromised. Effective teams build routines for expiry, review, and revocation so permissions do not outlive their purpose.

What it means when approval is never withdrawn

Authorisation is supposed to be temporary, bounded by purpose, time, and ownership. When a wallet, contract, or delegated permission is never de-authorised, the approval becomes a standing right rather than a one-time business action. That means the original grant can continue to move value, call functions, or inherit trust long after the reason for granting it has disappeared.

In practice, this turns a normal workflow convenience into an access-lifecycle problem. The risk is not only that the permission still exists, but that it may exist quietly, without a fresh human review or a new technical check. That is why the issue sits alongside access governance, revocation, and entitlement hygiene, not just transaction design.

For a useful mental model, treat the approval as part of the broader authorisation lifecycle described in NHIMG’s Authorisation Models Guide, where the control question is not simply “was access granted?” but “is this access still justified now?”

Why stale approvals become dangerous over time

The main failure mode is permission persistence. If the counterparty, contract logic, signer, or connected environment later changes, the old approval can still be honoured even though the current risk picture is different. In a wallet context, that can mean an authorised spender or contract can drain assets; in a contract context, it can mean delegated authority continues to trigger privileged actions after the original intent has ended.

Stale approvals also create hidden blast radius. They are easy to miss because they do not always look active in day-to-day operations, yet they remain callable until revoked, expired, or superseded. NHIMG’s NHI Lifecycle Management Guide is useful here because the same lifecycle principle applies: if a permission can outlive its purpose, it needs an explicit offboarding point and a review cadence.

The reason this matters operationally is that many teams monitor usage, but not dormant authority. A permission that was safe when issued can become excessive later through business drift, ownership loss, contract upgrade, or compromise of the authorised party. That is the same basic pattern highlighted in NHIMG’s Top 10 NHI Issues: standing access becomes a problem when nobody owns its retirement.

What good control looks like in practice

The strongest control is not “grant carefully and hope for the best,” but “grant with a built-in end state.” That means expiry where the platform supports it, periodic review where it does not, and revocation procedures that are actually exercised. If a permission can move funds or invoke privileged actions, treat it as something that needs ongoing governance, not a one-time approval event.

Practically, the review should answer three questions: who owns this approval, why does it still exist, and what is the revocation path if the purpose has ended? NHIMG’s IAM and IGA Basics is a useful anchor for that reasoning because it frames access review, entitlement management, and least privilege as recurring controls rather than static paperwork.

For teams operating wallets or contracts at scale, a good baseline is to inventory outstanding approvals, identify approvals with no recent legitimate use, and separate business-required standing access from temporary delegated access. Where possible, the safer pattern is short-lived authority with explicit renewal, rather than indefinite approval with hoped-for cleanup.

Risk and Threat Considerations

Never-revoked approvals create a long-tail exposure: the permission can be abused long after the original business event has ended. That makes compromise, insider misuse, contract compromise, and simple organisational drift all more dangerous, because the attacker or unintended actor does not need to steal a fresh credential if the old authority still works.

Failure mechanism: A standing approval persists across ownership changes, environment changes, and trust changes, so the authorised party retains the ability to act even after the original justification has expired.

Impact: Funds can be moved, privileged functions can be invoked, and recovery becomes harder because the exposure is authorised by design rather than obviously malicious behaviour.

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 surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-2 — Account Management	Standing approvals require periodic review and removal when no longer needed.
	AC-6 — Least Privilege	Unrevoked approvals create excess authority beyond current business need.
	IA-5 — Authenticator Management	Approval lifecycle depends on rotating or revoking enabling credentials and tokens.
Recommendation — Review and disable stale approvals on a recurring schedule. Limit permissions to the minimum scope and duration required. Rotate or revoke enabling secrets and tokens when approval ends.
ISO/IEC 27001:2022	A.5.15 — Access control	Access rights should be governed and removed when the need ends.
	A.8.2 — Privileged access rights	Never-de-authorised approvals can function as persistent privileged access.
Recommendation — Enforce access control reviews and timely withdrawal of rights. Regularly review and revoke privileged access rights.
OWASP Non-Human Identity Top 10	NHI-01 — Improper Offboarding	Unused approvals that are never removed are an offboarding failure.
	NHI-05 — Overprivileged NHI	A permanent approval can leave an identity with more authority than needed.
	NHI-07 — Long-Lived Secrets	Approvals that never expire behave like long-lived enabling material.
Recommendation — Define and execute offboarding for approvals and delegated access. Continuously trim access to match current business need. Prefer short-lived approvals and enforce expiry or renewal.

Practitioner Guidance

What to prioritise: Focus first on approvals that can directly move value or trigger irreversible actions. Those are the permissions where stale authority creates the largest blast radius and the least room for remediation.

What to verify: Confirm that every standing approval has an owner, a current business justification, and a revocation path. If any of those three are missing, treat the approval as a control gap rather than an administrative leftover.

Common mistake: Teams often review active usage but ignore dormant authority. That leaves “quiet” approvals in place until a compromise, contract change, or ownership transfer turns them into an incident.

Practitioner takeaway: The key judgement is to manage authorisation as a lifecycle, not an event, because permissions that cannot expire or be actively retired will eventually outlive the purpose that made them safe.