Skip to main content
View as MarkdownOpen in ChatGPTOpen in Claude

Identity Mesh — August 14, 2026

Release Date: August 14, 2026
Release Type: Mixed (New Features, Improvements, Bug Fixes)

Overview​

This release makes data collection auditable end to end, and opens your software and cryptographic inventory to external reporting tools:

  • Data source sync history — a new view covering every connector synchronization: what it collected, how long it took, and why it failed.

  • Software and cryptographic inventory in the analytics feed — component hierarchy, dependency relationships, and per-component cryptographic detail are now queryable through the analytics API.

It also makes compliance answers in the AI assistant reflect your tenant's real configuration instead of generic background material, and fixes identity provider onboarding for providers that require proof-of-possession on token requests.

New features​

Data source sync history​

Every data source synchronization is now recorded as an audit event and surfaced in a dedicated Data source syncs view, across all connector types and for both scheduled and manual runs.

What you get:

  • Per-sync records — connector, sync type (full or incremental), what triggered the run, start and end time, duration, and the number of records attempted, succeeded, and failed. Each synchronization appears as a single row rather than as separate start and finish entries.

  • A breakdown of what was synced — successful runs show which categories of data they collected, not only a total.

  • Failure reasons in place — failed runs show a classified reason instead of a bare status badge, including failures that occur before collection begins. A breakdown panel lets you search, sort, and page through the individual failures behind one run.

  • Filtering and export — narrow by connector, sync type, status, and time range, then export the matching events to CSV. The summary figures above the table follow the same filters as the table itself.

Why it matters: when an identity or an asset looks stale, the first question is whether the last synchronization actually ran and what it brought back. This view answers that without a support request.

For what the underlying records contain, see Audit logging.

Software and cryptographic inventory in the analytics feed​

The analytics API now exposes your software bill of materials and cryptographic inventory, so you can report on them in external business intelligence tools alongside your machine assets.

What you get:

  • Component hierarchy and dependencies — software components carry their parent project and application, and a new dependency entity makes the relationships between components directly queryable.

  • Per-component cryptographic detail — cryptographic elements now expose the primitive in use and a quantum security level, and a new entity links each software component to the cryptographic material it carries, along with its owner.

  • Standard query support — the new fields work with the same filtering, selection, and ordering options as the existing entities, and results remain scoped to your tenant and paginated.

Why it matters: post-quantum migration planning and software supply chain review usually happen in tools you already run. Exposing this inventory through the analytics feed means you don't have to reproduce it by hand.

Action required — page with $skiptoken, not $skip: $skip is now deprecated and will be removed in a future release. It is capped at 1,000,000 records, and requests that use it come back with a Deprecation: true response header. Page instead by following the cursor in @odata.nextLink, which supplies $skiptoken. Tools that already page by following @odata.nextLink are unaffected; custom scripts that build their own $skip offsets should be updated.

Historical entities require a snapshot_date filter; each row is the state as of that date. For the full entity list, fields, and query options, see the Analytics OData API Reference.

Improvements​

Compliance answers reflect your actual configuration​

Asking the AI assistant about compliance policies returned generic background material about what such policies typically govern, and suggested checking your own configuration — even though the configuration was correct and retrying could never succeed.

  • Compliance policy lookups now read from the service that owns them, so answers come from your tenant's real policies.

  • When a lookup genuinely fails, the assistant now states that the capability is unavailable and stops, instead of filling the gap with generic content or attributing the failure to your configuration.

Bug fixes​

Identity provider onboarding failed against providers that require proof-of-possession​

Saving credentials for an identity provider failed outright when the provider's organization required a proof-of-possession (DPoP) token on token requests — a security policy that a growing number of providers enforce. Mesh had no way to satisfy it, and there was no workaround short of turning the policy off.

Mesh now generates and attaches proof-of-possession tokens on outbound token requests, both during credential verification and on the ongoing sign-in and refresh path, including the challenge-and-retry exchange these providers use.

Identity provider onboarding was hard to diagnose when it failed​

Configuring an identity provider could fail with an opaque error that gave no indication of which step was wrong or what to correct.

  • Connection testing now verifies the provider through its published configuration and reports a specific reason when a check fails, rather than one generic failure.

  • Credential verification now checks the client credentials directly and recognizes the standard error responses providers return, so an invalid client identifier or secret is reported as such.

  • Provider addresses are built and compared consistently, and deployments that use a custom authorization server are handled end to end.