Subscribe to the Non-Human & AI Identity Journal

Who should be accountable for Snowflake NHI offboarding and rotation?

Accountability should sit with the application owner, identity team, and security operations function together. The owner knows why the account exists, identity teams enforce lifecycle and entitlement rules, and security teams verify that stale or overprivileged accounts are removed before they become an exposure path.

Why This Matters for Security Teams

Snowflake NHIs are often created to support pipelines, integrations, and service jobs, then left behind when the underlying app, team, or vendor relationship changes. That makes offboarding and rotation a governance issue, not just a password hygiene task. The practical risk is stale access, secret sprawl, and overprivileged accounts that still authenticate long after they should have been removed. Top 10 NHI Issues and the OWASP Non-Human Identity Top 10 both highlight lifecycle control as a recurring failure point.

Accountability matters because offboarding spans more than one control owner. The application owner understands business need, identity teams manage policy and entitlement hygiene, and security operations validates that removal actually happened and that rotation closed the exposure window. Without that split, organisations tend to assume someone else is handling it. NHIMG research shows that The 2025 State of NHIs and Secrets in Cybersecurity found 91% of former employee tokens remain active after offboarding, a sign that lifecycle ownership is still routinely unclear. In practice, many security teams encounter the exposure only after an audit, an incident, or a cloud bill anomaly has already surfaced it.

How It Works in Practice

Operationally, accountability should be defined in the same way as any other control with shared execution: one named business owner, one enforcing identity function, and one verifying security function. The application owner should approve the continued need for the Snowflake NHI, confirm the systems it touches, and sign off on retirement when the integration is no longer required. Identity teams should enforce RBAC, token expiry, secret issuance rules, and revocation workflows. Security operations should monitor for stale credentials, anomalous use, and evidence that offboarding tickets have been completed. That model fits the lifecycle guidance in NHIMG’s NHI Lifecycle Management Guide and the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.

In practice, the workflow usually looks like this:

  • Owner requests offboarding or rotation when a workload, vendor, or service account is retired.
  • Identity team revokes tokens, rotates secrets, removes unnecessary grants, and checks for duplicate credentials.
  • Security verifies logs, confirms no active sessions remain, and escalates exceptions that could create lingering access.

For higher-risk environments, current guidance suggests pairing offboarding with short-lived secrets and zero standing privilege so the NHI cannot retain access between review cycles. That aligns with the spirit of the OWASP Non-Human Identity Top 10 and with Ultimate Guide to NHIs — Static vs Dynamic Secrets, which distinguishes long-lived secrets from dynamic credentials. These controls tend to break down when Snowflake service accounts are shared across multiple applications, because no single owner can safely attest to every downstream dependency.

Common Variations and Edge Cases

Tighter offboarding and rotation often increases operational overhead, requiring organisations to balance speed of change against the risk of breaking production jobs. That tradeoff is real in Snowflake estates with batch loads, data science notebooks, vendor-managed connectors, and emergency break-glass accounts. Current guidance suggests the same accountability model still applies, but the execution path may differ depending on whether the NHI is tied to a human maintainer, a CI/CD pipeline, or an external platform.

Two edge cases deserve special handling. First, shared credentials should be treated as a design flaw, not a convenience, because they blur ownership and make true offboarding impossible. Second, service accounts that are rarely used may look harmless, but they are often the easiest to miss during rotation. NHIMG’s Guide to the Secret Sprawl Challenge is useful here, especially when paired with the Guide to NHI Rotation Challenges. The practical rule is simple: if no one can name the owner, the use case, and the revocation path, the Snowflake NHI should be treated as unmanaged until proven otherwise.

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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-03 Covers rotation and revocation of NHI secrets after offboarding.
NIST CSF 2.0 PR.AC-4 Least-privilege access review fits NHI offboarding accountability.
NIST AI RMF Governance and accountability map to autonomous workload lifecycle control.

Assign a named owner and documented oversight for each autonomous or automated workload identity.