Deployment Notes

January 2026

January 30

Private networking for Google BigQuery: As part of our ongoing investment in private networking and secure access to additional data platforms, Immuta is introducing private networking for Google BigQuery.

What is changing

• Today, Immuta's services connect to BigQuery via its public endpoints.

• Starting February 23, we will enable Private Service Connect (PSC) for all Google API traffic in our SaaS environment, including BigQuery.

Why this change? The incoming caller IP seen by BigQuery will change from a public IP (e.g., 35.x.x.x) to an internal IP (e.g., 10.x.x.x). Existing allowlists that only look for public IPs will deny this new internal traffic.

Impact and timeline If you manage a BigQuery dataset or project that uses VPC Service Controls (VPC-SC) or IAM Conditions to allow specific public IPs, the connection from Immuta will stop working on February 23 unless updates are made.

In order to prevent this breakage from happening, we recommend that you update VPC-SC to allow our SaaS VPCs to access the BigQuery instance. This will allow a seamless way for both the public IPs and the VPC to connect so there is no loss of connectivity. To get the VPC information for the new VPC-SC policy, please contact Immuta Support.

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

• On by default: February 23 - March 17. Contact your Immuta representative before February 23 if you need to opt out during this period.

• Enabled for all production global segments: March 18. You will not be able to opt out.

Please contact your Immuta representative as soon as possible to review next steps and avoid disruption.

This change was also announced in the Immuta changelog.

January 26

Revolutionizing data access via the new Immuta Request app: We are excited to announce the private preview of our new catalog-integrated access workflow, which closes the gap between discovering data and actually using it. Your data consumers can now initiate access requests directly from the environments where they already work, including Atlan, Alation, Databricks Unity Catalog, Snowflake Horizon, Collibra, and more. By placing the request process exactly where discovery happens, Immuta eliminates the friction of manual ticketing and legacy identity governance hurdles.

To reflect this evolution, we are officially renaming the Immuta Marketplace to the Immuta Request app.

This isn't just a name change; it represents a strategic shift toward making the Request the central object of our ecosystem. While the previous marketplace focused on data products, the Request app is a purpose-built engine designed to handle the entire lifecycle of data access. Whether a user needs access to a full database, a specific schema or table, or even a specialized request to unmask sensitive columns, the process is now unified and automated.

By streamlining these approvals within the data flow, we are providing a modern, data-centric alternative to general-purpose Identity Governance and Administration (IGA) vendors. We are moving away from the "one-size-fits-all" approach of legacy governance tools in favor of a system that understands the nuances of data permissions. This ensures that security stays invisible to the end user while providing the business with a scalable, automated path to data democratization

Key highlights of the private preview

• Direct catalog integration: Start a request within Atlan, Alation, Databricks Unity Catalog, Snowflake Horizon, or Collibra. Extensible to other catalogs.

• Granular request support: Automate access at the database, schema, or table level.

• Advanced policy requests: Support for specialized requests, such as unmasking specific columns for approved projects.

• The Immuta Request App: A dedicated experience focused on the request lifecycle, continuing to support but no longer centering the data product marketplace view.

• Documentation: You will notice significant changes to our documentation structure to reflect this change.

If you would like access to the Immuta Request app in private preview, please reach out to your Immuta representative.

This change was also announced in the Immuta changelog.

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.

This change was also announced in the Immuta changelog.

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

This feature was also announced in the Immuta changelog.

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.

This change was also announced in the Immuta changelog.

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

This feature was also announced in the Immuta changelog.

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.