Deployment Notes

January 2026

January 22

Snowflake data policy impersonation: Impersonation is now compatible with the most updated version of Immuta's Snowflake integration, which leverages low-row access policy mode for improved overall performance.

With this update, impersonation is now available for data policy access only. Administrators can impersonate others to see the row- and column-level restrictions their users are subject to. When impersonating another user, the impersonator’s subscription policy access will remain unchanged.

The release of this feature will follow Immuta’s behavior change release process. The specific dates for each phase in that process are outlined below.

• Opt-in period: 1/22 - 2/22

• On by default: 2/23 - 3/22

• Enabled for all accounts: 3/23

January 20

Security improvement to Immuta's webhook signature scheme: Immuta is updating the webhook signature scheme to use HMAC-SHA256 instead of HMAC-SHA1.

This change aligns Immuta with current cryptographic best practices and NIST guidance. The webhook payload format and shared secret remain unchanged; only the hashing algorithm used to generate the signature has been updated.

What is changing

Currently, Immuta sends a webhook signature signed with HMAC-SHA1 via the x-immuta-webhook-signature HTTP header. Immuta has begun sending an additional webhook signature signed with HMAC-SHA256 via a new HTTP header, x-immuta-webhook-signature-sha256. As of today, you are able to opt-in to stop receiving webhook signatures using HMAC-SHA1.

Impact to you

Customers that validate webhook signatures must ensure their verification logic supports HMAC-SHA256.

No action is required for customers who do not perform signature validation.

Timeline

The release of this change will follow Immuta’s behavior change release process. The specific dates for each phase in that process are outlined below.

• 1/20: Customers can opt-in to stop receiving a webhook signature signed with HMAC-SHA1.

• 2/20: Immuta will stop sending webhook signatures signed with HMAC-SHA1 by default, but customers can opt-out of this change for this time period.

• 3/20: The change will be generally enabled. It will no longer be possible for webhook signatures to be signed using HMAC-SHA1, and nothing will be sent over the x-immuta-webhook-signature header.

Why this change

While HMAC-SHA1 has not been shown to be practically exploitable in this context, SHA-1 is deprecated and no longer recommended for new designs. This update is a proactive security-hardening measure.

January 13

Trino connections: Connections is Immuta’s enhanced way of efficient data object management that offers the following benefits:

• Reduced complexity by having just one connection in Immuta for both metadata onboarding and policy application with your data platform.

• Increased scalability by onboarding all your objects at once instead of repetitive patterns.

• Improved performance to manage and track metadata changes.

Connections can now be used with Trino (and Starburst) integrations. Reach out to your Immuta support professional to enable it on your tenant. Once enabled, a banner will direct you to the upgrade manager where you can initiate the process to upgrade your existing Trino integration.

The release of this feature will follow Immuta’s behavior change release process. The specific dates for each phase in that process are outlined below.

• Opt-in period: 1/13-2/12

• On by default: 2/13-3/12

• Enabled for all accounts: 3/13

January 9

Advanced masking exceptions: Advanced masking exceptions allow data governors to consolidate complex masking matrices containing hundreds of rules into a single policy.

The new advanced masking policy options in the global data policy builder allow you to create dynamic exception rules that let users see just a subset of sensitive columns in the clear instead of an all-or-nothing approach for granting access to restricted data, which would often be too broad and create a security risk. The two policies below illustrate how advanced masking exceptions transform a policy.

• Basic masking exception (static): "Mask columns tagged sensitive except when a user is a member of group Finance or group HR."

  • Users that are either part of the Finance or HR department will always see all sensitive columns unmasked everywhere.

• Advanced masking exception (dynamic): "Mask columns tagged sensitive for everyone except when columns are tagged with the department the user currently belongs to.”

  • Users that are part of the Finance or HR department will only see a subset of sensitive columns unmasked, depending on what has been cleared for use for their department.

This dynamic approach helps you maintain a high security baseline without sacrificing business agility: global masking rules protect your organization from broad data leaks and advanced masking exceptions ensure that security doesn't become a bottleneck.

See a demo of this new feature in the Immuta Changelog.