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.
Editorial analysis by NHI Mgmt Group, based on content published by Oasis Security: “Best Practices to Secure Non Human Identity Data Access in Snowflake”.
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.
Q: Why do OAuth tokens and certificates increase Snowflake NHI risk?
A: They create different persistence and recovery profiles from interactive logins.
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.
Practitioner guidance
- 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.
- 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.
- Rotate machine credentials on a defined cadence Reset and rotate OAuth tokens, certificates, and any remaining password-based machine credentials on a regular schedule.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
06/06/2026 3:14 am
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.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
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.
👉 Read our full editorial: Best practices for Snowflake NHI data access and credential control
This post was modified 1 day ago by NHI Mgmt Group