Getting Ahead of Snowflake Security Updates

Data EngineeringData MigrationsSnowFlake

If you’ve been using Snwoflake and integrating multiple upstream or downstream tools, there are important security-related changes to the way Snowflake is allowing Service Users to operate. If you need help evaluating or migrating your service users, this guide is a great start to helping you understand what needs to be done to comply and be secure using Snowflake Service Users moving forward. Don’t wait before getting your integrations updated to be more secure! Blue Orange can help!.

To improve the security posture, Snowflake is disallowing passwords for all service users. To prepare for this change, we must assess all current integrations and define a secure, sustainable authentication approach for each system.

Estimated Date

Milestone

Notes

Nov. 2025 – Jan. 2026

All non-human users created after the behavior change bundle is enabled must be of type SERVICE, which prevents them from using a password. The LEGACY_SERVICE type is no longer available when creating a new user object. In addition, administrators cannot change the type of an existing user to LEGACY_SERVICE.

Jun. 2026 – Aug. 2026

The LEGACY_SERVICE user type is fully deprecated. All existing user objects with TYPE=LEGACY_SERVICE are migrated to TYPE=SERVICE, which prevents them from using a password.

Evaluation Logic for Healthy Users

System Inventory & Assessment

We begin by cataloging all tools, scripts, and platforms that connect to Snowflake using service accounts. For each one, we evaluate:

  • Whether it currently uses username/password auth

  • Whether it supports OAuth natively or via Snowflake partnership

  • Whether the client has or plans to implement an Identity Provider (IdP)

  • The most appropriate future-proof authentication method

Decision Tree: Selecting the Right Auth Method

To ensure both security and long-term maintainability, we prioritize authentication methods based on the client’s current stack and future roadmap. Use the following logic to determine the best fit per system:

Decision Logic

  1. Use Key Pair Authentication if:

    • The system is a scripting or orchestration tool (e.g., Airflow, Python, dbt) and

    • There’s no Identity Provider (IdP) in place or planned.

  2. Use OAuth if:

    • The system is a BI tool or SaaS platform with native Snowflake OAuth support (e.g., Looker, Tableau, dbt Cloud, Alation, Thoughtspot, Collibra), or

    • The client has already implemented an Identity Provider (IdP) (e.g., Okta, Cognito, Azure AD) or

    • The client plans to standardize authentication across systems using an IdP and is willing to configure OAuth endpoints.

  3. Fallback: Re-evaluate tooling or use service account + Key Pair if:

    • The tool doesn’t support OAuth and no IdP is available.

    • Use as a temporary or legacy-compatible approach with strong key management practices.

Implementation Plan

We propose a 5-phase rollout that combines security compliance with client flexibility, including the option to plan around Identity Provider integration where needed.

Phase 1: System Inventory & Client Assessment

  • Complete inventory of tools and scripts using service accounts.

  • Identify OAuth support, client Identity Provider status, and urgency per system.

  • Categorize into 3 groups:

    • Immediate switch to Key Pair

    • Immediate switch to OAuth

    • Strategic migration to OAuth (pending IdP readiness)

Phase 2: Auth Strategy Alignment

  • Confirm with stakeholders which systems should adopt:

    • Key Pair Auth (for code-based workflows without IdP)

    • OAuth (for tools with built-in OAuth or strategic IdP usage)

  • Finalize mappings per system.

  • Document security ownership (e.g., who rotates keys, manages client secrets).

Phase 3: Configuration & Testing

  • Implement and validate chosen auth method in non-prod/staging environments:

    • Generate Snowflake key pairs

    • Register OAuth clients or configure Snowflake external OAuth integrations

  • Store credentials in a secure vault (e.g., AWS Secrets Manager, Azure Key Vault)

Phase 4: Production Cutover

  • Schedule cutover windows per system.

  • Monitor for failed auth attempts and regressions.

  • Disable password auth for migrated users once validated.

Phase 5: Documentation & Compliance

  • Document new authentication setup per system (owners, method, rotation policy)

  • Archive system logs showing deprecation of user/password usage

  • Report status to Snowflake security stakeholders and platform owners

References