Notifications
Clear all
Topic starter
06/06/2026 1:52 am
TL;DR: Snowflake treats human and machine access through the same user model, which makes NHI governance harder when service accounts rely on OAuth tokens, certificates, or legacy passwords and cannot use MFA, according to Oasis Security. The practical issue is not Snowflake alone, but the broader identity assumption that program access can be governed like human access without lifecycle, rotation, and contextual visibility controls.
NHIMG editorial — based on content published by Oasis Security: Best Practices to Secure Non Human Identity Data Access in Snowflake
Questions worth separating out
Q: How should security teams govern Snowflake access for service accounts?
A: Security teams should treat service accounts as NHIs with their own lifecycle, ownership, and privilege rules.
Q: Why do NHIs complicate Snowflake access management?
A: NHIs complicate Snowflake access management because they cannot use the same human-centric controls as employees.
Q: What breaks when stale Snowflake service accounts are left in place?
A: Stale service accounts create hidden access paths that survive ownership changes, integration retirement, and personnel offboarding.
Practitioner guidance
- Classify Snowflake identities by actor type Separate human users, service accounts, and integration identities before assigning MFA, rotation, and review rules.
- Attach owners and consumers to every NHI Maintain a live inventory that records who owns each account, which application uses it, and what data it can reach.
- Reduce standing privilege before rotation gaps matter Review Snowflake entitlements for program accounts and remove access that is not required for the current integration task.
What's in the full article
Oasis Security's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step Snowflake setup for a dedicated user and role used to connect an NHI security platform
- How the integration surfaces contextual information about consumers, owners, and access patterns for each account
- Operational workflow for automated credential rotation and posture violation detection across Snowflake NHIs
- Incident-response view of how access patterns and interactions are examined during an active compromise
👉 Read Oasis Security's best practices for securing Non Human Identity data access in Snowflake →
Snowflake NHI access controls: what IAM teams need to tighten now?
Explore further
06/06/2026 3:14 am
Snowflake access governance fails when teams assume a user is a user. That assumption is built for human identity programmes, where MFA, SSO, and user lifecycle processes are the baseline. It breaks as soon as service accounts, tokens, and certificates are in scope, because non-human access has different authentication methods, different review cadence, and different failure modes. The implication is not just that more controls are needed, but that identity classification must happen before control design.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Organisations maintain an average of 6 distinct secrets manager instances, which creates fragmentation that undermines centralised control.
A question worth separating out:
Q: Who should be accountable for Snowflake NHI offboarding and rotation?
A: 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.
👉 Read our full editorial: Best practices for Snowflake NHI data access and credential control
