Best practices for Snowflake NHI data access and credential control

At a glance

What this is: This is a best-practices article on securing Snowflake program access by treating service accounts as NHIs with their own lifecycle, visibility, rotation, and privilege controls.

Why it matters: It matters because IAM teams cannot rely on human access patterns, MFA assumptions, or static account naming to govern machine access to sensitive Snowflake data.

Context

Snowflake user access can be authenticated with passwords, MFA, client certificates, or OAuth2 tokens, but the governance problem is that human and machine access still sits inside one user model. When service accounts and program identities are handled like ordinary users, MFA-centred controls miss the reality of how NHIs actually authenticate and persist.

The security gap is not limited to Snowflake. Any environment that stores sensitive data and allows machine access needs lifecycle-aware governance for service accounts, because contextual visibility, rotation, and privilege scoping do more than account naming conventions ever can.

This article is a typical NHI governance case: the starting point is common across enterprises, but the control gap becomes sharper where automated processes depend on wide-ranging privileges and legacy credentials.

Key questions

Q: What breaks when Snowflake service accounts are governed like human users?

A: Human-style governance breaks because service accounts do not use the same authentication and review model as people. MFA, password policy, and manual access recertification do not fully describe machine access, so ownership, expiry, and purpose become the real controls that keep the account accountable and contained.

Q: Why do OAuth tokens and certificates increase Snowflake NHI risk?

A: They create different persistence and recovery profiles from interactive logins. If a token or certificate is not rotated or revoked promptly, it can keep working long after the business need has ended, which extends the exposure window for any privileged service account that depends on it.

Q: What are the signs that Snowflake NHI governance is failing?

A: The warning signs are stale accounts, unclear ownership, wide privileges unrelated to workload function, and identities that still authenticate with legacy passwords or long-lived secrets. When those conditions exist together, teams can no longer explain who uses the identity, why it exists, or how quickly they could shut it down.

Q: How should teams respond when a Snowflake service account is no longer needed?

A: They should decommission it completely, revoke its credentials, remove its privileges, and verify that no downstream process still depends on it. Leaving orphaned accounts in place turns former operational access into persistent exposure, especially in environments where machine identities can reach sensitive data.

Technical breakdown

Why Snowflake's user model blurs human and machine governance

Snowflake does not create a separate account class for machines, so a user account may represent a person, a service, or an automated workflow. That design keeps authentication flexible, but it also collapses governance boundaries that IAM teams usually depend on, especially when human users can use MFA but NHIs cannot. Once a program identity shares the same account model as a human identity, lifecycle, ownership, and authentication method become the real control points.

Practical implication: separate governance logic for human and machine accounts even when the platform uses one user model.

Why OAuth tokens, certificates, and passwords create different NHI risk shapes

Program access in Snowflake can rely on OAuth2 tokens, client certificates, or in some legacy cases passwords. These are not interchangeable from a governance perspective, because each creates a different exposure window and different recovery burden if compromised. Long-lived secrets and unsupported authentication paths increase the chance that access survives beyond its intended business use, especially when no human-based MFA challenge exists to interrupt misuse.

Practical implication: classify each Snowflake NHI by authentication method and treat legacy passwords as a separate risk tier.

Why contextual visibility is the control that turns NHI inventory into governance

A static list of service accounts is not enough. Contextual visibility means knowing who owns the identity, what consumes it, what it can reach, and whether its activity matches its intended purpose. In practice, that turns the NHI inventory into a governance artifact rather than an asset register. It also gives security teams the evidence needed to spot stale accounts, overprivilege, and unusual usage before those conditions become incidents.

Practical implication: build ownership, consumer, and access-pattern context into every Snowflake NHI inventory record.

Threat narrative

Attacker objective: The objective is to reuse machine credentials and privilege scope to reach sensitive Snowflake data without triggering human-centric controls.

1. Entry begins when a machine or service account uses OAuth2 tokens, certificates, or a legacy password to access Snowflake without human MFA.
2. Escalation follows when the account carries broader privileges than the workload actually needs, allowing misuse or expanded access if the credential is exposed.
3. Impact occurs when stale, unrotated, or poorly tracked credentials remain valid long enough to support unauthorized access to sensitive data or downstream systems.

Breaches seen in the wild

• Snowflake breach: Snowflake breach compromised Ticketmaster, Santander and others via cloud credential abuse.
• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Snowflake-style access governance fails when programmes assume a user account is a human account. Snowflake's single user model makes that assumption easy to miss, but the control problem is structural: MFA, naming conventions, and human onboarding logic do not describe how service accounts persist, authenticate, or get offboarded. Practitioners should treat account type, not account label, as the basis for governance.

Contextual visibility is the named control gap, not a reporting feature. The article's strongest operational point is that owners, consumers, and access patterns determine whether an NHI is governable. Without that context, teams can see the account but cannot explain its purpose, its blast radius, or whether it still belongs in production. That makes lifecycle control a security prerequisite, not an administrative preference.

Long-lived machine credentials create identity blast radius in Snowflake environments. OAuth tokens, certificates, and legacy passwords each carry a persistence window that can outlast the workload they were issued for. The governance failure is not merely weak rotation, but the assumption that program access can be reviewed and contained on human timelines. Practitioners need to rethink access as an issuance-and-expiry problem, not an account-review problem.

Overprivileged NHIs turn automation into a standing-access liability. The article correctly links broad privileges to higher risk, because a compromised service account can often do more than the business process requires. That pattern is familiar across NHI programmes, but Snowflake makes it especially visible because data access and compute access meet inside one identity model. The practical conclusion is to govern every machine identity as if its worst-case reach will be tested.

Snowflake access control here is really a lifecycle discipline issue. The article's removal of stale accounts is not a housekeeping note. It is evidence that offboarding, decommissioning, and credential retirement are the difference between an active control and an abandoned identity that still opens doors. IAM teams should read this as a reminder that NHI governance fails most often at the end of life, not the start.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Top 10 NHI Issues

What this signals

Identity blast radius: Snowflake environments show why machine access must be governed as a lifecycle, not as a static account list. When a service account can authenticate with a token or certificate and reach sensitive data, the duration of that access matters as much as the privilege scope.

NHI programmes should expect review processes to miss risk if they only check whether an account exists. The more useful question is whether the identity still has an owner, an active workload, and a valid reason to keep its current authentication method.

Contextual visibility, not just inventory, is what lets teams distinguish legitimate automation from dormant exposure. That shift becomes even more important when legacy password-based access still exists beside modern authentication paths.

For practitioners

• Separate human and machine governance rules Apply different control logic to Snowflake service accounts than to human users, even though the platform presents both through the same user model. Base policy on identity purpose, authentication method, and ownership rather than on naming conventions alone.
• Inventory NHI ownership and consumers Maintain a real-time inventory that records who owns each Snowflake NHI, which applications or services consume it, and what resources it can access. Use that context to distinguish active automation from stale or orphaned identities.
• Rotate machine credentials on a defined cadence Reset and rotate OAuth tokens, certificates, and any remaining password-based machine credentials on a regular schedule. Prioritise identities that cannot use MFA and any account with broad access to sensitive data.
• Right-size privileges on program accounts Review each Snowflake service account against the minimum permissions required for the workload it supports. Remove excess access paths that widen the blast radius if the account is reused or compromised.
• Decommission stale accounts quickly Remove user or program accounts that no longer map to an active owner, workload, or business process. Treat offboarding as a security control for both human-created and machine-created identities.

Key takeaways

• Snowflake NHI risk is driven by the mismatch between human-centric access controls and machine identities that cannot rely on MFA in the same way.
• The main governance gap is not visibility alone but context, ownership, rotation, and privilege scope across the full lifecycle of a service account.
• Teams that treat stale accounts and long-lived credentials as lifecycle failures can reduce the blast radius of machine access to sensitive data.

Key terms

• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Contextual Visibility: Contextual visibility is the ability to see not only that an identity exists, but who owns it, what uses it, and what it can access. For NHI governance, this context turns a static inventory into an operational control for auditing, anomaly detection, and offboarding.
• Long-Lived Secret: A long-lived secret is a credential, token, API key, or certificate that remains valid for an extended period without frequent renewal. In NHI environments, it creates durable exposure because one leaked secret can keep granting access long after the original use case has changed.
• Privilege Right-Sizing: Privilege right-sizing is the process of reducing access to the minimum permissions required for a task or role. In multi-cloud environments, it depends on visibility into how permissions are actually used so teams can remove excess access, control risk, and maintain a more accurate least-privilege posture.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.