Deployment Notes

January 2026

January 23

Architecture improvements and updates for Databricks Unity Catalog integration: Immuta has updated the back-end architecture supporting the Databricks Unity Catalog integration, and this update will be released to Unity Catalog customers over the coming weeks. The new architecture will help customers get improved performance at a higher scale through more efficient operations between Immuta and Databricks. These are largely back-end updates to improve performance and efficiency.

In addition to the architectural updates, there are several user-facing changes included with this release:

• Updates to manual policy resync behavior: The data policy resync option in the data source health checks will be updated to resync data policies as well as subscription policies for Unity Catalog data sources. If there is any policy failure on a data source, you can manually trigger a resync through the health check, which will run for both subscription and data policies.

• Subscription logic updates: Part of the architecture updates include improvements to Immuta's subscription logic that allow Immuta to be fully additive to existing Databricks grants. Previously, Immuta would take over all grants on a data source, meaning users were revoked if they were not explicitly granted access through an Immuta subscription policy. Now, Immuta-managed grants and Databricks-managed grants will coexist harmoniously.

• Catalog and schema revokes: By default, Immuta will revoke Immuta users' USE CATALOG and USE SCHEMA privileges if they do not have access to any underlying securable within that catalog/schema. If users have any Immuta or Databricks-managed grants to a securable, Immuta will not revoke that catalog/schema access. You can update this default behavior to not revoke catalog/schema access at all.

• Databricks integrations fully managed through connections: For all actions related to editing and managing Databricks integrations, users must go through connections. Databricks integrations will no longer be present in Immuta's integrations app settings page.

• Deprecating integration error banners: Immuta will no longer show the integration error banners when an integration validation is failing. Those error messages will be migrated to a new user experience through Immuta connections.

• New Immuta schemas: Immuta will create new immuta_policies schemas in your Databricks environments and manage all policies through the new schemas. The original policy schemas will still be present in your Unity Catalog environment, but Immuta will no longer use those.

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.