Snowflake Security Guide: Service Users and Key Pair Auth

The best-known Snowflake compromises started with a valid credential, not a software flaw, so Snowflake security is largely Snowflake identity hardening: who and what can sign in, from where, with which role. The 2024 UNC5537 campaign proved the point, using passwords harvested by infostealers years earlier against accounts with no MFA and no network allow list. Snowflake now offers service user types, named key pairs, programmatic access tokens, workload identity federation, authentication policies and Trust Center, and is phasing out single-factor password sign-ins. This guide covers the identity model, service users and credentials, policies, role design, data masking, integrations and session monitoring, for data platform engineers, Snowflake administrators and the security teams who monitor them.

Key takeaways

• Type every user. Set TYPE = PERSON for humans and TYPE = SERVICE for pipelines and tools; SERVICE users cannot use passwords, which removes the credential class UNC5537 exploited.
• Prefer federation, then key pairs, over secrets that can be replayed. Workload identity federation removes stored secrets entirely; where it does not fit, use key pair authentication with encrypted private keys and scheduled rotation.
• Put every account behind a network policy. Mandiant found no allow lists on the 2024 victim instances; add an account-level policy, tighter user-level policies for service users, and note that service user PATs will not work without one.
• Treat ACCOUNTADMIN as break-glass. Few holders, MFA on all of them, never a default role, never used by automation, and blocked from OAuth and PAT role restrictions.
• Monitor with the views you already have. LOGIN_HISTORY, SESSIONS, QUERY_HISTORY and ACCESS_HISTORY keep a year of data, and Trust Center scanners flag password-only sign-ins, missing network policies and dormant users.

The Snowflake identity model

A Snowflake account (the Snowflake data warehouse tenant) holds users, roles and securable objects. Privileges are granted to roles, roles to users and other roles, and a session runs with one primary role at a time. Every user holds the PUBLIC role. Authentication is governed by four policy types that Snowflake evaluates in a fixed order: network policy first, then authentication policy, then password policy, then session policy. Where a policy is set on both the account and a user, the user-level policy wins.

Snowflake's rollout plan for the deprecation of single-factor password sign-ins runs in three estimated phases: MFA for Snowsight password logins (September 2025 to January 2026), a second factor on every surface for newly created human users and no new LEGACY_SERVICE users (May to July 2026), and a second factor for all human password logins with LEGACY_SERVICE fully deprecated (August to October 2026, rolling per account).

What UNC5537 changed

Mandiant and Snowflake notified approximately 165 potentially exposed organisations in 2024. Mandiant found that most credentials came from historical infostealer infections, the earliest dating to November 2020, and that at least 79.7% of the accounts the actor used had prior credential exposure. Mandiant named three reasons the campaign worked: the accounts had no MFA, the stolen credentials "had not been rotated or updated", and the instances "did not have network allow lists in place". The actor used a custom reconnaissance utility Mandiant tracks as FROSTBITE and a public database management tool, so client application strings in session records became key indicators. Mandiant found no evidence of a breach of Snowflake's own enterprise environment. See the Snowflake Breach 2024 analysis for the incident itself and the Infostealer Threat Guide for the credential supply chain behind it. MITRE ATT&CK maps the pattern to T1078.004 Valid Accounts: Cloud Accounts and T1213.006 Data from Information Repositories: Databases, which names Snowflake as an example.

Service users and authentication methods

A Snowflake service user (the Snowflake service account) is a TYPE = SERVICE user owned by a team, scoped to one workload and one role. The question is which credential it holds.

• Small estates: a few SERVICE users on key pairs, each with a strict network policy, need no extra tooling.
• Large estates: standardise on workload identity federation, keep remaining private keys in a secrets manager, and create service users from code so owners and policies are never missing. See the Service Account Security Guide for ownership and lifecycle practices that apply across platforms.

Key pair authentication done properly

Snowflake key pair authentication needs a 2048-bit RSA key pair at minimum, with RS256, RS384 and RS512 supported. Snowflake's documentation says "Generally, it is safer to generate encrypted keys", using PKCS#8 with AES-256-CBC; it advises against Triple DES. The Spark and Kafka connectors and the Go driver accept only unencrypted keys, so protect those files harder.

1. Create the user correctly: TYPE = SERVICE, a narrow DEFAULT_ROLE, a COMMENT naming the owner and workload, and a user-level network policy.
2. Register the key as a named key pair: Snowflake now recommends ALTER USER ... ADD KEY PAIR because named key pairs support role restriction and expiry. The older RSA_PUBLIC_KEY property still works but "does not support role restriction or expiration". Restrict MODIFY PROGRAMMATIC AUTHENTICATION METHODS, which (with OWNERSHIP) allows setting keys.
3. Verify the fingerprint: compare RSA_PUBLIC_KEY_FP from DESC USER with the SHA-256 fingerprint of your public key.
4. Store the private key in a secrets manager: inject it at runtime, never in a repository or image. See the Secrets Management Guide.
5. Rotate on a schedule: ALTER USER ... ROTATE KEY PAIR keeps the previous key valid for 24 hours by default (EXPIRE_ROTATED_KEY_PAIR_AFTER_HOURS, where 0 expires it immediately). With the legacy properties, load the new key into RSA_PUBLIC_KEY_2, switch the client, then UNSET RSA_PUBLIC_KEY.
6. Roll back safely: while two keys are valid a failed deployment can fall back to the old key; expire it immediately only for a suspected compromise.

Programmatic access tokens

A Snowflake programmatic access token (PAT) authenticates calls to the REST and SQL APIs and can stand in for a password in drivers and tools. Use its guardrails as designed:

• Network policy: service users must be subject to a network policy to generate or use a PAT (PAT_POLICY NETWORK_POLICY_EVALUATION defaults to ENFORCED_REQUIRED). Human users can create one without a policy but cannot authenticate with it.
• Expiry: the default is 15 days and the default maximum 365 days; lower MAX_EXPIRY_IN_DAYS in the authentication policy. Expiry cannot be extended after creation.
• Role restriction: mandatory for service users by default. Use BLOCKED_ROLES_LIST to stop ACCOUNTADMIN and SECURITYADMIN ever being chosen. Secondary roles are ignored for PAT sessions.
• Lifecycle: ALTER USER ... ADD, ROTATE and REMOVE PROGRAMMATIC ACCESS TOKEN; the secret is shown once; 15 per user. Disabling a user disables their PATs, and re-enabling does not restore them.
• Inventory: query ACCOUNT_USAGE.CREDENTIALS where type = 'PAT' and join LOGIN_HISTORY where first_authentication_factor = 'PROGRAMMATIC_ACCESS_TOKEN' to see which are used.

MFA and authentication policies

Snowflake MFA supports passkeys (recommended), authenticator apps using TOTP and a third-party push option. For people, SSO with MFA at your identity provider is stronger, with Snowflake MFA as a backstop for remaining password sign-ins. The Snowflake authentication policy is the control point:

• AUTHENTICATION_METHODS: which methods are allowed, for example SAML or OIDC only for people, and only key pair, OAuth or programmatic access tokens for services.
• MFA_ENROLLMENT = REQUIRED: forces enrolment; CLIENT_TYPES must then include SNOWFLAKE_UI because enrolment happens in Snowsight.
• MFA_POLICY: ALLOWED_METHODS = ('PASSKEY', 'TOTP') narrows factors; ENFORCE_MFA_ON_EXTERNAL_AUTHENTICATION = 'ALL' extends MFA to SSO users too.
• CLIENT_TYPES: limits Snowsight, SnowSQL, Snowflake CLI or drivers. Snowflake calls it "best-effort" and notes it does not restrict the REST APIs, so never treat it as a security boundary.
• Targeting: ALTER ACCOUNT SET AUTHENTICATION POLICY ... FOR ALL SERVICE USERS applies a service-only policy, so people and pipelines can follow different rules.

Keep a less restrictive policy on two monitored administrator users so a broken SAML integration cannot lock everyone out. ALLOW_CLIENT_MFA_CACHING creates MFA tokens valid for up to four hours, and MINS_TO_BYPASS_MFA should be a recorded recovery step. The MFA Guide covers factor choice in more depth.

Snowflake network policies

A Snowflake network policy references network rules in ALLOWED_NETWORK_RULE_LIST and BLOCKED_NETWORK_RULE_LIST; the rules group identifiers of TYPE IPV4, IPV6, AWSVPCEID (AWS PrivateLink endpoint), AZURELINKID (Azure Private Link) or COMPUTE_POOL, with MODE INGRESS for the service or INTERNAL_STAGE for internal stages. If an address appears in both lists, the block wins. The most specific policy applies: a user-level policy overrides the account policy, and a policy on a security integration overrides both.

• Account level: allow corporate egress ranges, VPN ranges and private endpoints. Trust Center flags a missing account policy but not over-wide ranges.
• Service users: a user-level policy allowing only the workload's hosts, NAT gateways or private endpoints, so a stolen key fails elsewhere.
• Integrations: set NETWORK_POLICY on OAuth and SaaS integrations to the provider's published egress ranges.
• Testing and rollback: include your current IP or endpoint, pilot on a test user, confirm in LOGIN_HISTORY, then activate on the account; keep an admin path that can UNSET NETWORK_POLICY.

Roles, RBAC and ACCOUNTADMIN

Snowflake RBAC uses system roles in a hierarchy. ACCOUNTADMIN sits on top but Snowflake stresses it "is not a superuser role". SECURITYADMIN holds the global MANAGE GRANTS privilege, USERADMIN creates users and roles, and SYSADMIN creates warehouses, databases and objects. Snowflake's guidance: few ACCOUNTADMIN holders but at least two, MFA for all, never a default role, and never used to create objects or run automated scripts.

• Access and functional roles: grant object privileges to access roles, access roles to job-based functional roles, and those to users. Grant the top of every custom hierarchy to SYSADMIN, or even ACCOUNTADMIN cannot drop objects a custom role owns.
• Managed access schemas and future grants: only the schema owner or a MANAGE GRANTS role can grant, and new objects inherit the design.
• Service user roles: one Snowflake role per workload, holding only what that pipeline needs.
• Review: query GRANTS_TO_USERS and GRANTS_TO_ROLES regularly for holders of ACCOUNTADMIN, SECURITYADMIN and MANAGE GRANTS. See the Role Mining and Role Design Guide.

Masking and row access policies

Data policies limit what a compromised identity can read. Both need Enterprise Edition or higher.

• Masking policy: a Snowflake masking policy uses Dynamic Data Masking to mask column values at query time without changing stored data. Write conditions with IS_ROLE_IN_SESSION rather than CURRENT_ROLE so role hierarchies behave as expected. Tag-based masking attaches a policy to a tag, such as a PII classification tag, so new columns are covered when tagged; a policy set directly on a column takes precedence.
• Row access policy: a Snowflake row access policy returns a Boolean per row, usually by looking up the querying role in a mapping table, so one table can serve several regions or business units. A column can appear in a masking policy signature or a row access policy signature, not both.
• Who applies policies: in Snowflake's hybrid model a governance role writes policies and data teams apply them with APPLY MASKING POLICY.
• Audit: ACCESS_HISTORY records the policies enforced on each query in policies_referenced.

For classification and data-centric controls across platforms see the Data Security Guide.

OAuth, the MCP server and Openflow

• Snowflake OAuth: integration type oauth, code grant flow, for interactive partner tools. By default Snowflake blocks ACCOUNTADMIN, ORGADMIN, GLOBALORGADMIN and SECURITYADMIN from OAuth; leave OAUTH_ADD_PRIVILEGED_ROLES_TO_BLOCKED_LIST at its default. Block more with BLOCKED_ROLES_LIST and set a NETWORK_POLICY on the integration.
• External OAuth: type external_oauth, tokens from your own identity provider, the better fit for programmatic clients. OAuth logins show FIRST_AUTHENTICATION_FACTOR = OAUTH_ACCESS_TOKEN in LOGIN_HISTORY. See the OAuth 2.0 and OpenID Connect Guide.
• Snowflake MCP server: the Snowflake-managed MCP server, created with CREATE MCP SERVER, exposes Cortex Agents, Cortex Search, Cortex Analyst, custom functions and SYSTEM_EXECUTE_SQL as tools to AI agents. Snowflake recommends OAuth and warns that "Using hardcoded tokens can lead to token leakage." USAGE on the server does not grant the tools; each needs its own privilege, so expose SQL execution only to tightly scoped roles. See the MCP Security Guide.
• Snowflake Openflow: the Apache NiFi based integration service runs on Snowpark Container Services or as BYOC in your cloud. Runtimes authenticate with Snowflake Managed Token by default; KEY_PAIR is available only for BYOC and should be the exception. Pull connector credentials from AWS Secrets Manager, Azure Key Vault or Google Cloud Secret Manager, and give each runtime its own narrow role.

Session monitoring and detection

Snowflake session monitoring relies on Account Usage views, which keep one year of history. Grant a monitoring role IMPORTED PRIVILEGES on the SNOWFLAKE database rather than giving analysts ACCOUNTADMIN, and export the views to your SIEM. See the SIEM Guide.

Snowflake query history records do not always appear in Snowflake access history, so keep both. Metrics:

• Password-only human logins: percentage of PERSON logins in LOGIN_HISTORY with no second factor or SSO; target zero.
• Service user coverage: percentage of non-human users with TYPE = SERVICE and a user-level network policy.
• Credential age: median and maximum age of key pairs and PATs, against your rotation standard.
• ACCOUNTADMIN holders: count, and days since each last used the role.
• Trust Center and dormancy: open high-severity violations, and enabled users with no login in 90 days.

A phased rollout plan

1. Inventory: list users with type, last login, default role and the authentication methods seen in LOGIN_HISTORY; find every non-human user still using a password.
2. Quick wins: create an account-level network policy, enable the Trust Center CIS Benchmarks and Threat Intelligence packages, reduce ACCOUNTADMIN holders, and disable users dormant for 90 days.
3. Retype users: set TYPE = PERSON on humans and push them to SSO; set TYPE = SERVICE on integrations, moving each to workload identity federation or a named key pair. Test each with a duplicate service user first.
4. Apply policies: authentication policies for service users and for people, then user-level network policies, piloting on a few users.
5. Protect data: classify and tag sensitive columns, apply tag-based masking and row access policies, and move schemas to managed access.
6. Operate: automate detections on the views above, rotate keys and PATs on schedule, and review grants quarterly. Rollback is an ALTER ... UNSET of the policy or property, so record each change.

Framework mapping

In NIST CSF 2.0 these sit in PR.AA, PR.DS and DE.CM.

Common failure patterns

• Service accounts on passwords: integrations left as LEGACY_SERVICE or untyped users with a password stored in a BI tool, the exact path in the Snowflake breach.
• Wide account-level network policy only: 0.0.0.0/0 passes the Trust Center check but blocks nothing.
• ACCOUNTADMIN as a default role: every session, scripted ones included, runs with full reach.
• Unencrypted private keys in repositories: keys committed to code or images become static secrets.
• Long-lived PATs with no role restriction: year-long convenience tokens usable with any role the user holds.
• Logs never read: nobody alerts on new client applications or password-only logins until an extortion email arrives.

Practitioner checklist

• Set TYPE on every user and remove all LEGACY_SERVICE users before your phase 3 enforcement date.
• Move cloud workloads to workload identity federation; elsewhere use named, encrypted key pairs held in a secrets manager.
• Apply an account-level network policy and a user-level policy for every service user.
• Require SSO for people, MFA_ENROLLMENT = REQUIRED for password users, and a service-only authentication policy.
• Keep ACCOUNTADMIN to a small group (at least two), all with MFA, never as a default role.
• Restrict PATs: low MAX_EXPIRY_IN_DAYS, role restriction, BLOCKED_ROLES_LIST for admin roles.
• Apply tag-based masking and row access policies to sensitive data and use managed access schemas.
• Enable Trust Center packages and alert on LOGIN_HISTORY, SESSIONS and QUERY_HISTORY anomalies.
• Scope MCP server tools and Openflow runtimes to dedicated, least-privilege roles.

Standards and references

• Snowflake Documentation: Key-pair authentication and key-pair rotation
• Snowflake Documentation: Planning for the deprecation of single-factor password sign-ins
• Snowflake Documentation: Authentication policies
• Snowflake Documentation: Using programmatic access tokens for authentication
• Snowflake Documentation: Controlling network traffic with network policies
• Snowflake Documentation: Workload identity federation
• Google Cloud (Mandiant): UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion
• MITRE ATT&CK: T1213.006 Data from Information Repositories: Databases

Related NHI Mgmt Group resources: SaaS Security Guide · Service Account Security Guide · NHI Authentication Guide · Database Security Guide · Snowflake Breach 2024