Elastic Cloud Serverless breaking changes

For more information, check #285645.

Impact
The following routes now require the workflowsManagement:read privilege in addition to workflowsManagement:readExecution:

GET /api/workflows/workflow/{workflowId}/executions
GET /api/workflows/workflow/{workflowId}/executions/steps
		

This change is transparent for the UI, which already requires the workflow:read privilege.

Action
API users with only the workflowsManagement:readExecution privilege must also be granted workflowsManagement:read to use these APIs.

For more information, check #282130.

Impact
Custom Elasticsearch roles that only grant privileges on the old security_* patterns will get 403 when querying the new neutral names (such as .entities.v2.latest.*, .entities.v2.latest.{space}, concrete -00001 indices, updates or metadata streams) until those roles are updated. Compatibility aliases preserve access for callers that still target the old names and enable or install privilege checks that accept either naming scheme during the transition.

Action
Existing deployments migrate automatically on Kibana upgrade (background task) and on Entity Store install.

For more information, check #282404.

Impact
Package policies with additional_datastreams_permissions values that do not match the documented <type>-<suffix> datastream grammar (for example logs* without a dash) are now rejected.

Action
Update any non-matching additional_datastreams_permissions values to the <type>-<suffix> form (for example logs-nginx-*).

Clients that create, update, upgrade, or copy managed integrations through the package policy and agent policy APIs receive a 400 error.

For more information, check #280959.

Impact
Affects automation and API clients that manage agentless Fleet integrations through legacy package policy or agent policy endpoints.

Action
Update integrations to use the managed integrations API instead of legacy package policy and agent policy endpoints for agentless integrations.

Endpoint response action APIs now validate the length of request fields, including comments, IDs, commands, file paths, and script content.

For more information, check #274987.

Impact
Requests that exceed the new field-length limits are rejected.

Action
Update endpoint response action API clients to keep request fields within the documented limits.

Endpoint metadata, policy response, protection note, and script listing APIs now validate request field lengths.

For more information, check #275711.

Impact
Requests that exceed the new field-length limits are rejected.

Action
Update endpoint metadata, policy response, protection note, and script listing API clients to keep request fields within the documented limits.

Script library APIs now validate the length of script names, descriptions, instructions, examples, executable paths, versions, and script IDs.

For more information, check #275710.

Impact
Requests that exceed the new field-length limits are rejected.

Action
Update script library API clients to keep request fields within the documented limits.

Endpoint artifact exception list validators now enforce maximum string lengths on entry fields (for example blocklist, trusted applications, trusted devices, and event filters). Values longer than the limit are rejected.

For more information, check #274803.

Impact
Creating or updating endpoint exception list items with string values longer than the new limits fails validation. Other exception list types are unaffected.

Action
Shorten entry values that exceed the limits before saving. Typical limits are 4096 characters for entry values and 1024 characters for field names in advanced trusted apps and event filters.

For more information, check #153309.

Impact
The Inference API incorrectly allowed users to override values within secret_parameters with the contents of task_settings.parameters during a POST request. This change prevents that behavior, ensuring that secret_parameters cannot be overridden.

Action
If you relied on the previous behavior to override secret_parameters, you will need to create a new inference endpoint with the secret_parameters moved to task_settings or no longer rely on the ability to override the secret_parameters within a POST request.

The response envelope for the Dashboards API search endpoint changed from { dashboards, page, total } to { data, meta }, where the pagination fields (page, per_page, and total) move under meta. The endpoint also enforces a maximum per_page of 1000.

For more information, check #268951 #267607.

Impact
Requests that set per_page above 1000 are rejected. Clients that read dashboards, page, or total from the top level of the response no longer receive those fields.

Action
Update Dashboards API search clients to read results from data and pagination from meta, and keep per_page at or below 1000. Refer to the Dashboards API reference for the updated schemas.

The duration format used in visualization configuration now uses short-hand unit values aligned with ES|QL conventions for its from and to options. This affects the api/visualizations and api/dashboards APIs, for both by-value and by-reference panels. For example, minutes becomes min, humanize becomes auto-approximate, and humanizePrecise becomes auto.

For more information, check #274792 #265849.

Impact
API requests that configure duration formats with the previous verbose unit names (for example, minutes, humanize, or asMilliseconds) are rejected.

Action
Update the duration from and to values in your visualization and dashboard panel API payloads to the new short-hand units. Refer to the Dashboards API reference for the updated schemas.

For more information, check #266410.

Impact
Integrations and automations that call v1 /api/entity_store/* routes or rely on v1 engine management must migrate to Entity Store v2.

Action
Update integrations to use Entity Store v2 APIs provided by the entity_store plugin. Remove references to v1 routes such as /api/entity_store/engines* and /entities*.

For more information, check #272894.

Impact
Changes POST /api/fleet/agentless_policies to return a new dedicated AgentlessPolicy response model instead of the internal PackagePolicy shape. Removes the format query parameter. The following request body fields are no longer accepted: description, var_group_selections, additional_datastreams_permissions, and condition.

Action
External API clients that consume PackagePolicy fields such as policy_ids, revision, supports_agentless, secret_references, output_id, fleet_server_host_id, or enabled from the response must migrate to the new model.

For more information, check #272414.

Impact
The Elastic APM instrumentation is deprecated and will be removed in a future version.

Action
Use the OpenTelemetry instrumentation when collecting traces and metrics from Kibana. Refer to Instrumenting with OTel Traces for more information.

The entity store reads entity data from a new set of indices. Roles that grant access to the Entity Analytics features must now include read on the following index patterns:

• .entities.v2.latest.security_*
• .entities.v2.updates.security_*
• entities-latest-*
• risk-score.risk-score-*
• .entity_analytics.*

The built-in Security roles have been updated to grant these privileges. Custom roles created against the v1 index patterns (.entities.v1.latest.security_*) are not updated automatically.

Impact:

Users assigned a custom role that does not include the index patterns above will see the Entity Analytics page load in a degraded state — without entity data and without the standard "insufficient privileges" message. Users assigned built-in Security roles are not affected.

Action: If you use custom roles to control access to Entity Analytics, add read on the following entity store and risk score index patterns to each affected role:

- names:
    - ".entities.v2.latest.security_*"
    - "entities-latest-*"
    - "risk-score.risk-score-*"
    - ".entity_analytics.*"
  privileges:
    - read
		

For more information, view #255800.

Osquery scheduled-pack result documents correlate using stable UUIDs (pack_id and schedule_id) instead of the name-derived action_id. action_id is no longer populated for scheduled results; it remains populated for live queries. This applies when using the Osquery Manager integration v1.23.0 or later.

Impact:

Any dashboard, saved search, detection rule, or ingest pipeline that groups or filters scheduled Osquery results by action_id returns no data — including the default dashboards bundled with the Osquery Manager integration. Live query results are unaffected. No data is lost: the underlying result data remains fully queryable through the new fields.

Action:

Update any custom (user-authored) dashboards, saved searches, detection rules, and ingest pipelines that reference action_id for scheduled results to use schedule_id or pack_id instead.

For more information, check #271572.

For indices in time series mode, Elasticsearch trims sequence numbers when they are no longer needed for replication. This reduces storage overhead (for example, a substantial share of space for OpenTelemetry Protocol metrics) and lowers the cost of segment merging.

When sequence numbers are disabled for an index, optimistic concurrency control no longer applies. Index, update, and delete requests that use if_seq_no and if_primary_term return an error, and searches that request seq_no_primary_term receive sentinel values for those fields. update_by_query and delete_by_query proceed without conflict detection, so concurrent modifications can overwrite documents without version conflict errors. For typical metrics workloads, concurrent updates are uncommon, and the storage savings are often an acceptable tradeoff.

To retain full sequence numbers and optimistic concurrency control, set index.disable_sequence_numbers to false in your time series index templates.

Impact:

Workflows that depend on optimistic concurrency control, sequence numbers in search responses, or conflict detection for update_by_query and delete_by_query on time series indices might need changes, or you can opt out by setting index.disable_sequence_numbers to false.

For more information, view #145737.

The index and component template forms in Index Management previously saved the _source field mode (stored and synthetic) in the mappings._source.mode setting. This path is deprecated and has no effect in Elasticsearch. The form now uses the correct settings.index.mapping.source.mode setting. When you edit a template in the UI, any existing mappings._source.mode setting is automatically moved to the index settings and removed from mappings. Other _source options (enabled, includes, and excludes) remain in mappings.

Impact:

The template's JSON structure has changed: The _source mode setting (stored/synthetic) appears in the index settings, not in mappings. Options that were previously ignored when saved from the UI can now take effect for indices that match the template. Automation that only reads mappings._source.mode should read settings.index.mapping.source.mode instead. Open and save the template in the UI to automatically migrate the field.

For more information, view #255122.

The serializer and deserializer parameters have been removed from the Elastic Security Lists API. These parameters previously allowed custom parsing logic for value list items:

• serializer — Determined how uploaded list item values were parsed using regex patterns.
• deserializer — Determined how retrieved list item values were presented using Handlebars expressions.

Impact:

API requests that include serializer or deserializer parameters (in the Create List API request body or Import List Items API query string) will have those parameters silently ignored, and a warning header will be returned in the response. Users who relied on custom parsing logic will need to pre-process their list data before import, as only default parsing behavior is now supported.

For more information, view #250111.

This adds a new mapping parameter normalizer_skip_store_original_value to keyword fields. When this parameter is set and synthetic_source is enabled, keyword fields with configured normalizers will not store the original non-normalized value in _ignored_source and will instead use the normalized value to reconstruct the source. This parameter enabled by default for the built-in lowercase normalizer and is disabled by default for other custom normalizers.

Impact:

Keyword fields using the lowercase normalizer will return the normalized value in the source when synthetic source is enabled.

For more information, view #136915.

In earlier versions of Elasticsearch, ES|QL would fail the entire query if it encountered any error. ES|QL now returns partial results instead of failing when encountering errors.

Impact:

Callers should check the is_partial flag returned in the response to determine if the result is partial or complete. If returning partial results is not desired, this option can be overridden per request via an allow_partial_results parameter in the query URL or globally via the cluster setting esql.query.allow_partial_results.

For more information, view #125060.

The exclude_source_vectors setting is now enabled by default for newly created indices. This means that vector fields (for example, dense_vector) are no longer stored in the _source field by default, although they remain fully accessible through search and retrieval operations. Instead of being persisted in _source, vectors are now rehydrated on demand from the underlying index structures when needed. This reduces index size and improves performance for typical vector search workloads where the original vector values do not need to be part of the _source. If your use case requires vector fields to be stored in _source, you can disable this behavior by setting exclude_source_vectors: false at index creation time.

Impact:

Vector fields will no longer be stored in _source by default for new indices. Applications or tools that expect to see vector fields in _source (for raw document inspection) may need to be updated or configured to explicitly retain vectors using exclude_source_vectors: false. Retrieval of vector fields via search or the _source API remains fully supported.

For more information, view #131907.

This changes the default behavior for norms on text fields in LogsDB and TSDB indices. Prior to this change, norms were enabled by default, with the option to disable them via manual configurations. After this change, norms will be disabled by default. Note, because we dont support enabling norms from a disabled state, users will not be able to enable norms on text fields in logsdb and tsdb indices.

Impact:

Text fields will no longer be normalized by default in LogsDB and TSDB indices.

For more information, view #131317.

Roles with explicit read access to advanced settings but all access to SavedObjectManagement can no longer update settings via the internal advanced settings API. This update enforces explicit privileges instead of relying on saved object security checks.

For more information, view #230067.

Previously, the ES|QL grammar allowed users to individually quote constituent strings in index patterns such as "remote_cluster":"index_name". This would allow users to write complex malformed index patterns that often slip through grammar and the subsequent validation. This could result in runtime errors that can be misleading. This change simplifies the grammar to early reject such malformed index patterns at the parsing stage, allowing users to write simpler queries and see more relevant and meaningful errors.

Impact:

Users can write queries with simpler index patterns and see more meaningful and relevant errors. For more information, view #127636.