Disabling a user account stops that identity from logging in, ends existing sessions, and aborts running or scheduled queries. Revoking a secret removes the credential that may have enabled the access in the first place, which is often the stronger long-term fix for service accounts or integrations. In practice, teams often need both to contain and prevent re-entry.
Why Suspected User Disabling and Secret Revocation Solve Different Problems
Disabling a suspected Snowflake user and revoking a suspected secret are not interchangeable because they interrupt different trust paths. A user disable action targets an interactive or assigned identity, while secret revocation targets the credential that may still authenticate an application, script, pipeline, or API integration. If the suspected access path is unclear, treating only one side as sufficient can leave the other route open.
For Snowflake environments, that distinction matters because access is often shared across humans, service accounts, and automation. A disabled user may stop fresh logins, but a still-valid secret can continue to authenticate through a separate workload path if it is tied to an integration or non-interactive process. The inverse is also true: revoking a secret does not necessarily remove a human identity that already has other permitted ways to connect. NHI Management Group recommends thinking in terms of which authentication object is actually in circulation, not just which account name looks suspicious. Ultimate Guide to NHIs
In practice, many teams discover the gap only after an incident response action appears to work on one path while the real access path remains active elsewhere.
How the Two Controls Work in Practice
User disabling is an account-level containment step. It is useful when the suspect is a named human account, a shared login that should no longer exist, or any identity whose continued use would be inappropriate. In Snowflake, that can stop new sessions and disrupt active use of that identity, which makes it a fast first response when an operator needs to reduce live exposure.
Secret revocation is a credential-level containment and cleanup step. It matters when the suspect access may be driven by a password, key pair, token, OAuth secret, or other stored credential that can be replayed by automation. This is often the stronger long-term fix because the secret itself is the reusable object, and rotating or revoking it removes the ability to authenticate even if the account definition still exists.
The practical decision is usually tied to the access pattern:
- If the activity is tied to a named interactive user, disable the account first to cut off direct access.
- If the activity is tied to an integration, scheduled job, service account, or code-stored credential, revoke or rotate the secret to remove the reusable authentication path.
- If you cannot prove which path was used, do both, then re-establish access through a controlled replacement.
That sequence aligns with the real problem in NHI-heavy environments: the same credential can be copied into scripts, CI/CD jobs, vaults, and connection strings, so account state alone does not equal access state. The underlying control objective is to remove every authentication path that still works, not merely to make one login surface look closed. Guide to the Secret Sprawl Challenge OWASP Non-Human Identity Top 10
These controls tend to break down when secrets are duplicated across multiple systems because the revocation reaches only the source credential while copies in pipelines, caches, or deployed apps remain usable.
Where the Difference Matters Most in Real Incidents
Tighter containment often increases operational disruption, requiring teams to balance immediate access shutdown against service continuity. The main tradeoff is between stopping suspicious activity quickly and avoiding unnecessary outages in production workflows that may depend on the same identity or secret.
The difference becomes most important in mixed environments where human administration and automation overlap. A user account may look suspicious because it was the visible login, but the actual abuse path may have been a leaked secret used by a job runner or integration. In that case, disabling the user only removes one front door. Likewise, revoking a secret without understanding whether the associated account is still valid can leave an attacker or insider free to switch to another permitted method.
Current guidance suggests treating the account and the secret as separate objects with separate lifecycles. That means investigators should ask three questions: who or what authenticated, what credential did it use, and where else is that credential stored or referenced. When those answers are unclear, the safer posture is to contain both and then restore legitimate access through a newly issued credential under tighter ownership and monitoring. NHI Lifecycle Management Guide
Practitioner takeaway: Disable the account to stop the identity, revoke the secret to kill reuse, and assume you need both until you can prove the suspected path is the only path.
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 and MITRE ATT&CK address the attack and risk surface, while 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 — Secrets and Credential Management | Secret revocation addresses the reusable credential path directly. |
| NHI-02 — Identity Lifecycle and Offboarding | Disabling a suspected user is an offboarding and containment action. | |
| Recommendation — Revoke and rotate the exposed secret to eliminate reusable authentication access. Disable the suspected account and confirm all associated access is withdrawn. | ||
| CIS Controls v8 | 6.3 — Access Rights and Account Management | Account disablement and access removal are core account-control actions. |
| 5.6 — Account Management | This question hinges on distinguishing account state from credential state. | |
| Recommendation — Remove the account's access paths immediately and verify the change propagated. Treat accounts and credentials as separate assets and manage each on its own lifecycle. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Compromised or abused valid accounts and secrets enable authenticated misuse. |
| Recommendation — Map the suspected access path to valid-account abuse and hunt for credential misuse. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | The topic is about which authentication control actually blocks access. |
| Recommendation — Enforce separate controls for account disablement and credential revocation. | ||
Related resources from NHI Mgmt Group
- What is the difference between rotating a secret and revoking access?
- What is the difference between runtime protection and NHI lifecycle management?
- What is the difference between rotation and deprovisioning for NHIs?
- What is the difference between disabling a user in the IdP and fully offboarding access?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
