From bcaf60427ecbd9ac40e6f46ffb43f2e4564ee098 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Tue, 20 Oct 2026 14:54:10 +0200
Subject: [PATCH 01/45] Document user-managed service accounts and workflow
 execution

AI-Assisted: OpenAI Codex
---
 .../deploy/elastic-cloud/serverless-faq.md    |   4 +-
 deploy-manage/toc.yml                         |   3 +
 ...nticate-kibana-api-with-service-account.md |  65 +++++++
 .../kibana-authentication.md                  |   6 +
 .../kibana-privileges.md                      |   5 +
 .../manage-service-accounts-in-kibana.md      | 102 +++++++++++
 .../service-accounts.md                       | 170 ++++++++++++++----
 .../token-based-authentication-services.md    |  14 +-
 .../user-authentication.md                    |   2 +-
 explore-analyze/toc.yml                       |   1 +
 .../workflows/authoring-techniques.md         |   1 +
 .../workflows/authoring-techniques/anatomy.md |  12 +-
 .../authoring-techniques/manage-workflows.md  |   5 +
 .../authoring-techniques/monitor-workflows.md |   5 +
 .../run-workflow-as-service-account.md        |  88 +++++++++
 .../authoring-techniques/settings.md          |  19 +-
 explore-analyze/workflows/authorization.md    |  51 ++++--
 .../workflows/get-started/setup.md            |   9 +
 .../workflows/reference/context-variables.md  |   2 +
 .../workflows/steps/elasticsearch.md          |   2 +-
 explore-analyze/workflows/steps/kibana.md     |   2 +-
 explore-analyze/workflows/triggers.md         |   4 +-
 .../workflows/triggers/alert-triggers.md      |   2 +-
 .../triggers/event-driven-triggers.md         |   1 +
 .../workflows/triggers/manual-triggers.md     |   2 +-
 .../workflows/triggers/scheduled-triggers.md  |   2 +-
 26 files changed, 519 insertions(+), 60 deletions(-)
 create mode 100644 deploy-manage/users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md
 create mode 100644 deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
 create mode 100644 explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md

diff --git a/deploy-manage/deploy/elastic-cloud/serverless-faq.md b/deploy-manage/deploy/elastic-cloud/serverless-faq.md
index 74727e2ab1d..2db8d0a5633 100644
--- a/deploy-manage/deploy/elastic-cloud/serverless-faq.md
+++ b/deploy-manage/deploy/elastic-cloud/serverless-faq.md
@@ -32,8 +32,8 @@ User-initiated data recovery is anticipated in a future release. You can follow
 
 ## Security, compliance, and access
 
-**Q: How can I create {{serverless-full}} service accounts?**  
-A: Create API keys for service accounts in your {{serverless-short}} projects. You can create them in {{kib}}, with the {{es}} API, or as code with Terraform. Refer to [](/deploy-manage/api-keys/serverless-project-api-keys.md) for details.
+**Q: How can a non-human application authenticate to {{serverless-full}}?**<br>
+A: User-managed service accounts aren't available on {{serverless-short}}. Create a project API key instead. You can create project API keys in {{kib}}, with the {{es}} API, or as code with Terraform. Refer to [](/deploy-manage/api-keys/serverless-project-api-keys.md) for details.
 
 **Q: Can I configure {{es}} authentication realms (for example, native realm) in {{serverless-short}} projects?**  
 A: No. {{serverless-short}} uses a different authentication model and does not support [{{es}} authentication realms](/deploy-manage/users-roles/cluster-or-deployment-auth/authentication-realms.md). Project-level access is handled through [Serverless project API keys](/deploy-manage/api-keys/serverless-project-api-keys.md), and user authentication is managed at the [{{ecloud}} organization level](/deploy-manage/users-roles/cloud-organization.md) (including SAML SSO).
diff --git a/deploy-manage/toc.yml b/deploy-manage/toc.yml
index f81902200f7..1602c546894 100644
--- a/deploy-manage/toc.yml
+++ b/deploy-manage/toc.yml
@@ -627,6 +627,9 @@ toc:
               - file: users-roles/cluster-or-deployment-auth/anonymous-access.md
               - file: users-roles/cluster-or-deployment-auth/token-based-authentication-services.md
               - file: users-roles/cluster-or-deployment-auth/service-accounts.md
+                children:
+                  - file: users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
+                  - file: users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md
               - file: users-roles/cluster-or-deployment-auth/internal-users.md
               - file: users-roles/cluster-or-deployment-auth/operator-privileges.md
                 children:
diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md b/deploy-manage/users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md
new file mode 100644
index 00000000000..c41426764a1
--- /dev/null
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md
@@ -0,0 +1,65 @@
+---
+navigation_title: Authenticate to Kibana APIs
+applies_to:
+  stack: ga 9.6+
+  serverless: unavailable
+description: Create a service token and use a user-managed service account to authenticate to Kibana APIs.
+products:
+  - id: kibana
+  - id: elasticsearch
+  - id: cloud-hosted
+  - id: cloud-enterprise
+  - id: cloud-kubernetes
+  - id: elastic-stack
+---
+
+# Authenticate to the {{kib}} API with a service account [authenticate-kibana-api-service-account]
+
+Use a user-managed service account to authenticate programmatic requests to {{kib}}. The account provides a non-human identity whose privileges come from its assigned roles.
+
+## Before you begin [authenticate-kibana-api-service-account-prerequisites]
+
+- You need the `manage_security` cluster privilege to create a user-managed account and its service token.
+- Create a role that grants only the {{kib}} and {{es}} privileges required by the API operations.
+- Store the service token in a secrets manager. Service tokens don't expire and grant direct access to the account's privileges.
+
+## Create a token for your application [create-service-account-api-token]
+
+{{kib}} creates and stores a credential when you create an account in the UI. That credential is used for workload integrations and isn't displayed. For your application, create an additional service token:
+
+1. [Create a service account in {{kib}}](manage-service-accounts-in-kibana.md#create-service-account-kibana). For this example, name it `automation-client` and assign the `automation_client` role. The account's principal is `kibana/automation-client`.
+
+2. Use the [create service account token API]({{es-apis}}operation/operation-security-create-service-token) to create a token for the account:
+
+    ```console
+    POST /_security/service/kibana/automation-client/credential/token/production
+    ```
+
+3. Copy the `token.value` from the response and store it securely. You can't retrieve the value again.
+
+:::{note}
+The `elasticsearch.serviceAccountToken` {{kib}} setting has a different purpose. It configures the {{kib}} server to connect to {{es}} as the built-in `elastic/kibana` account. It doesn't provide a token for an external API client or bind a user-managed account to a workload.
+:::
+
+## Call a {{kib}} API [call-kibana-api-service-account]
+
+Send the token with the `Bearer` authentication scheme:
+
+```shell
+curl --request GET "$KIBANA_URL/api/spaces/space" \
+  --header "Authorization: Bearer $SERVICE_ACCOUNT_TOKEN"
+```
+
+Ensure that your [HTTP authentication configuration](kibana-authentication.md#http-authentication) accepts the `Bearer` scheme.
+
+The response depends on the account's roles. A `403` response means the account authenticated but doesn't have the required privilege. Add privileges by editing the assigned role rather than assigning broad administrative roles to the account.
+
+For requests that change data, also include the headers required by that API, such as `kbn-xsrf`.
+
+## Remove access [remove-service-account-api-access]
+
+Delete an individual service token to stop one client without affecting other clients that use the same account. Delete the account or set `enabled: false` to stop new authentications for all its service tokens.
+
+Deleting an account invalidates its service tokens and access tokens, but it doesn't invalidate API keys owned by the account. Rules and tasks that obtained an API key while authenticated as the account can continue to run with that key. To revoke this access, [invalidate the API keys]({{es-apis}}operation/operation-security-invalidate-api-key) explicitly.
+
+To manage an account in the UI, refer to [Create and manage service accounts in {{kib}}](manage-service-accounts-in-kibana.md).
diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md b/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md
index 431fa115996..472e2be8cff 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md
@@ -417,6 +417,12 @@ xpack.security.authc.http.schemes: [apikey, bearer, basic, something-custom]
 With this configuration, you can send requests to {{kib}} with the `Authorization` header using `ApiKey`, `Bearer`, `Basic` or `Something-Custom` HTTP schemes (case insensitive). Under the hood, {{kib}} relays this header to {{es}}, then {{es}} authenticates the request using the credentials in the header.
 
 
+:::{note}
+:applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
+You can authenticate programmatic requests as a user-managed service account. Refer to [Authenticate to the {{kib}} API with a service account](authenticate-kibana-api-with-service-account.md) to create a token and use it with the `Bearer` scheme.
+:::
+
+
 ### Embedded content authentication [embedded-content-authentication]
 
 Once you create a dashboard or a visualization, you might want to share it with your colleagues or friends. The easiest way to do this is to share a direct link to your dashboard or visualization. However, some users might not have access to your {{kib}}. With the {{kib}} embedding functionality, you can display the content you created in {{kib}} to an internal company website or a personal web page.
diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md b/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md
index f3eb573f304..526fa86acb6 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md
@@ -224,6 +224,11 @@ These privileges control specific actions on workflows. Selecting **All** includ
 | **Update managed workflows** {applies_to}`stack: ga 9.5+` | Edit the workflows that Elastic provides. |
 :::
 
+:::{warning}
+:applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
+The **Update** privilege lets a user change what a bound service account does. Adding, changing, or removing a binding, and editing or deleting a bound workflow, also requires the `manage_security` cluster privilege. Grant workflow edit access only to users you trust to use the account's privileges. For account assignment instructions and required privileges, refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
+:::
+
 ## Privileges in the Management group [kibana-privileges-management]
 
 Each of the following privileges controls access to a different feature.
diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md b/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
new file mode 100644
index 00000000000..d4eede46fc7
--- /dev/null
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
@@ -0,0 +1,102 @@
+---
+navigation_title: Manage service accounts
+applies_to:
+  stack: ga 9.6+
+  serverless: unavailable
+description: Create, review, take out of service, and delete user-managed service accounts for Kibana workloads.
+products:
+  - id: kibana
+  - id: elasticsearch
+  - id: cloud-hosted
+  - id: cloud-enterprise
+  - id: cloud-kubernetes
+  - id: elastic-stack
+---
+
+# Create and manage service accounts in {{kib}} [manage-service-accounts-kibana]
+
+Create user-managed service accounts and assign roles to control access to {{es}} and {{kib}} APIs. {{kib}} creates each account in {{es}} and securely stores its credential.
+
+## Before you begin [manage-service-accounts-before-you-begin]
+
+- You need the `manage_security` cluster privilege. Without it, the **Service accounts** page isn't available. The `manage_service_account` privilege applies only to built-in accounts in the `elastic` namespace.
+- On self-managed deployments, set [`xpack.encryptedSavedObjects.encryptionKey`](kibana://reference/configuration-reference/security-settings.md#xpack-encryptedsavedobjects-encryptionkey) in `kibana.yml`. {{kib}} uses this key to encrypt the stored credential.
+- Create the roles that you want to assign. Each account requires at least one role.
+
+% Follow-up in elastic/kibana: document xpack.security.serviceAccounts.enabled and xpack.security.serviceAccounts.requestLifetime (default 10m), then add links to the settings reference.
+
+Service accounts are enabled by default on {{ech}}, {{ece}}, {{eck}}, and self-managed deployments. Setting `xpack.security.serviceAccounts.enabled` to `false` turns off the **Service accounts** page and workload integration.
+
+## Create a service account [create-service-account-kibana]
+
+1. Find **Service accounts** in the navigation menu or use the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md). In the **Classic** solution view, select **Stack Management** → **Security** → **Service accounts**.
+2. Click **Create account**.
+3. In the **Name** field, enter a unique name of up to 128 characters. The name must start with a letter or number and can contain letters, numbers, hyphens, and underscores.
+4. Optional: In the **Description** field, describe what the account is used for.
+5. Under **Set privileges**, select one or more predefined or custom roles that grant the privileges the account needs. To create a role, click **Create new role**.
+6. Review the privileges granted by the selected roles, and click **Create account**.
+
+The new account appears with the principal `kibana/<name>`. {{kib}} creates and stores its credential. No token is displayed, and you don't need to copy a secret.
+
+{{es}} resolves the assigned roles by name whenever the account authenticates. Editing a role changes the privileges it grants to the account. Deleting a role stops that role from granting privileges.
+
+## Review service accounts [review-service-accounts-kibana]
+
+The **Service accounts** table shows each account's name, description, roles, creator, and number of bound workloads. A **Disabled** badge identifies accounts that can't authenticate. Use the **Role** filter to find accounts assigned to specific roles.
+
+When an account has bound workloads, click **View** in the **Workloads** column to review them.
+
+% TBD: Recheck the creation flyout and role selector after https://github.com/elastic/kibana/pull/296889 merges. The Workloads column and View action are verified in main after #297492.
+
+Accounts created directly through the [{{es}} API]({{es-apis}}operation/operation-security-put-user-managed-service-account) also appear in the table.
+
+:::{important}
+Don't create service accounts directly through the {{es}} API if you plan to use them with {{kib}} applications such as Workflows. Create them in {{kib}} so it can generate and securely store the credential needed to run workloads as the account.
+:::
+
+You can't edit an account on this page. To change its roles or description, [update the account through the {{es}} API](#disable-service-account), or delete the account and create another one.
+
+## Update or deactivate a service account [disable-service-account]
+
+Use the [create or replace user-managed service account API]({{es-apis}}operation/operation-security-put-user-managed-service-account) to update an account's roles or description, or to deactivate it by setting `enabled` to `false`. These actions aren't available in the {{kib}} UI.
+
+The PUT request replaces the complete account definition. Send the full definition, including every role, the description, and the `enabled` value you want to preserve. A role left out of the `roles` list is no longer assigned, and an omitted `description` is cleared. If you omit `enabled`, it defaults to `true`. The `roles` field itself is required.
+
+For example, this request deactivates an account by sending its full definition with `enabled` set to `false`:
+
+```console
+PUT /_security/service/kibana/workflow-runner
+{
+  "roles": [ "workflow_runner" ],
+  "description": "Runs incident response workflows",
+  "enabled": false
+}
+```
+
+Setting `enabled: false` prevents the account from authenticating without deleting it. To reactivate the account, send the complete definition again with `enabled` set to `true`.
+
+Workloads bound to an account that has `enabled: false` fail the next time they run. They don't fall back to the user who starts or edits the workload.
+
+## Delete a service account [delete-service-account-kibana]
+
+Delete an account when you no longer need its identity:
+
+1. On the **Service accounts** page, find the account.
+2. From the **Actions** column, click **Delete**.
+3. Review the confirmation:
+    - If no workloads are bound, click **Delete account**.
+    - If workloads are bound, review the list. To delete the account without removing the bindings, click **Force delete account**.
+
+Deleting an account removes all its service tokens, including tokens created outside {{kib}}, and the credential stored by {{kib}}. It also invalidates access tokens issued to the account. If credential cleanup fails, {{kib}} reports a warning. A service token left behind can't authenticate while the account is absent.
+
+Forced deletion leaves workload bindings in place. Those workloads fail on their next run. Creating another account with the same name doesn't restore an old binding. Bind each workload to the replacement account.
+
+:::{important}
+API keys owned by the account aren't invalidated when you delete the account. Rules and tasks that obtained an API key while authenticated as the account can continue to run with that key. To revoke this access, [invalidate the API keys]({{es-apis}}operation/operation-security-invalidate-api-key) explicitly.
+:::
+
+## Next steps [manage-service-accounts-next-steps]
+
+- [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
+- [Authenticate to the {{kib}} API with a service account](authenticate-kibana-api-with-service-account.md).
+- Learn more about [service account types and credentials](service-accounts.md).
diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md b/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
index 86233b3b72e..e4eb4497333 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
@@ -3,32 +3,42 @@ mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/service-accounts.html
 applies_to:
   stack: all
+  serverless: unavailable
+description: Learn how built-in and user-managed service accounts provide non-human identities for Elastic services and workloads.
 products:
   - id: elasticsearch
+  - id: kibana
 ---
 
 # Service accounts [service-accounts]
 
-The {{stack-security-features}} provide *service accounts* specifically for integration with external services that connect to {{es}}, such as {{fleet}} server. Service accounts have a fixed set of privileges and cannot authenticate until you create a service account token for them. Additionally, service accounts are predefined in code, and are always enabled.
+The {{stack-security-features}} provide *service accounts* specifically for integration with external services that connect to {{es}}. A service account is a non-human identity for a service or workload. Unlike a user, a service account isn't associated with a person and can't log in to the {{kib}} UI.
 
-A service account corresponds to a specific external service. You create service account tokens for a service account. The service can then authenticate with the token and perform relevant actions. For example, {{fleet}} server can use its service token to authenticate with {{es}} and then manage its own API keys.
+Service accounts authenticate with service tokens. The account defines the identity and privileges, while the token is a credential for that identity. For example, {{fleet}} server uses a service token to authenticate with {{es}} and manage its own API keys.
 
-You can create multiple service tokens for the same service account, which prevents credential sharing between multiple instances of the same external service. Each instance can assume the same identity while using their own distinct service token for authentication.
+You can create multiple service tokens for the same service account. This lets multiple instances of a service use the same identity without sharing credentials.
 
-Service accounts provide flexibility over [built-in users](built-in-users.md) because they:
+::::{important}
+Don't use service accounts to authenticate individual users. Service tokens are credentials for software and workloads, not people.
+::::
 
-* Do not rely on the [internal `native` realm](native.md), and aren’t always required to rely on the `.security` index
-* Use a [role descriptor]({{es-apis}}operation/operation-security-create-api-key) named after the service account principal instead of traditional roles
-* Support multiple credentials through service account tokens
+$$$service-accounts-explanation$$$
+
+Each service account has a unique identifier, called a principal, in the form `<namespace>/<service>`. The `namespace` groups related accounts, and the `service` name must be unique within that namespace.
 
 Service accounts are not included in the response of the [get users API]({{es-apis}}operation/operation-security-get-user). To retrieve a service account, use the [get service accounts API]({{es-apis}}operation/operation-security-get-service-accounts). Use the [get service account credentials API]({{es-apis}}operation/operation-security-get-service-credentials) to retrieve all service credentials for a service account.
 
+## Service account types [service-account-types]
+
+Service accounts can be built-in, with privileges defined by Elastic, or user-managed, with privileges determined by the roles you assign.
 
-## Service accounts usage [service-accounts-explanation]
+### Built-in service accounts [built-in-service-accounts]
 
-Service accounts have a [unique principal]({{es-apis}}operation/operation-security-get-service-accounts#security-api-get-service-accounts-path-params) that takes the format of `<namespace>/<service>`, where the `namespace` is a top-level grouping of service accounts, and `service` is the name of the service and must be unique within its namespace.
+Built-in service accounts are predefined in code, always enabled, and have fixed privileges.
 
-Service accounts are predefined in code. The following service accounts are available:
+A built-in service account corresponds to a specific service.
+
+The following built-in accounts are available:
 
 `elastic/fleet-server`
 :   The service account used by the {{fleet}} server to communicate with {{es}}.
@@ -36,54 +46,90 @@ Service accounts are predefined in code. The following service accounts are avai
 `elastic/kibana`
 :   The service account used by {{kib}} to communicate with {{es}}.
 
-::::{important}
-Do not attempt to use service accounts for authenticating individual users. Service accounts can only be authenticated with service tokens, which are not applicable to regular users.
-::::
+The `elastic` namespace is reserved for built-in accounts.
+
+You can create and delete service tokens for these accounts, but you can't change their predefined privileges.
+
+### User-managed service accounts [user-managed-service-accounts]
+```{applies_to}
+stack: ga 9.6+
+```
+
+You create these accounts and assign roles to control their privileges. Accounts created in {{kib}} have IDs such as `kibana/order-processing`.
+
+Use a user-managed service account when your application needs its own identity to access {{es}} or {{kib}} APIs. Assign the roles required by the application, and authenticate its requests with a [service account token](#service-accounts-tokens).
+
+In {{stack}} 9.6, [Workflows](/explore-analyze/workflows.md) is the only {{kib}} application that supports directly assigning a service account as the execution identity of a workload. {{kib}} manages the credential used for this integration.
+
+To manage service accounts and use them in your own applications:
 
+- [Create and manage service accounts in {{kib}}](manage-service-accounts-in-kibana.md).
+- [Authenticate to the {{kib}} API with a service account](authenticate-kibana-api-with-service-account.md).
 
+To use service accounts with {{kib}} Workflows, refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
+
+The {{es}} API reference also documents these operations:
+
+- [Create or replace an account]({{es-apis}}operation/operation-security-put-user-managed-service-account).
+- [Delete an account]({{es-apis}}operation/operation-security-delete-user-managed-service-account).
+
+% TBD: Add the query service accounts API link when elasticsearch-specification includes the endpoint from elastic/elasticsearch#159406.
+% Serverless follow-up: publish only after availability is confirmed. Reuse these pages with deployment-specific sections for the 50-role limit, creator privilege ceiling, user-only management, and cross-project role resolution.
+% Serverless follow-up: omit the encryption-key prerequisite and direct service-token API instructions. Document deletion and token expiry instead of disabling an account. Confirm mixed-project-type restrictions before documenting them.
 
 ## Service account tokens [service-accounts-tokens]
 
 A service account token, or service token, is a unique string that a service uses to authenticate with {{es}}. For a given service account, each token must have a unique name. Because tokens include access credentials, they should always be kept secret by whichever client is using them.
 
-Service tokens can be backed by either the `.security` index (recommended) or the `service_tokens` file. You can create multiple service tokens for a single service account, which enables multiple instances of the same service to run with different credentials.
-
-You must create a service token to use a service account. You can create a service token using either:
+:::{note}
+:applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
+When you create a user-managed service account in {{kib}}, {{kib}} creates and stores a service token so applications such as Workflows can run on behalf of the account. This token isn't displayed. To authenticate requests from your own application, create an additional service token with the API.
+:::
 
-* The [create service account token API]({{es-apis}}operation/operation-security-create-service-token), which saves the new service token in the `.security` index and returns the bearer token in the HTTP response.
-* Self-managed and {{eck}} deployments only: The [elasticsearch-service-tokens](elasticsearch://reference/elasticsearch/command-line-tools/service-tokens-command.md) CLI tool, which saves the new service token in the `$ES_HOME/config/service_tokens` file and outputs the bearer token to your terminal
+You can create a service token using either:
 
-We recommend that you create service tokens via the REST API rather than the CLI. The API stores service tokens within the `.security` index which means that the tokens are available for authentication on all nodes, and will be backed up within cluster snapshots. The use of the CLI is intended for cases where there is an external orchestration process (such as [{{ece}}](/deploy-manage/deploy/cloud-enterprise.md) or [{{eck}}](/deploy-manage/deploy/cloud-on-k8s.md)) that will manage the creation and distribution of the `service_tokens` file.
+* The [create service account token API]({{es-apis}}operation/operation-security-create-service-token) (recommended). The API stores the token in the `.security` index and returns the bearer token in the HTTP response. Tokens are available for authentication on all nodes and are included in cluster snapshots.
+* The [elasticsearch-service-tokens](elasticsearch://reference/elasticsearch/command-line-tools/service-tokens-command.md) CLI tool, for built-in accounts on self-managed and {{eck}} deployments. The tool stores the token in the [`$ES_HOME/config/service_tokens` file](elasticsearch://reference/elasticsearch/command-line-tools/service-tokens-command.md) and outputs the bearer token to your terminal. This method is intended for environments where an external orchestration process, such as [{{ece}}](/deploy-manage/deploy/cloud-enterprise.md) or [{{eck}}](/deploy-manage/deploy/cloud-on-k8s.md), manages and distributes the file.
 
-Both of these methods (API and CLI) create a service token with a guaranteed secret string length of `22`. The minimal, acceptable length of a secret string for a service token is `10`. If the secret string doesn’t meet this minimal length, authentication with {{es}} will fail without even checking the value of the service token.
+Both the API and CLI generate service tokens with a 22-character secret. {{es}} requires a secret of at least 10 characters and rejects shorter secrets without checking their value.
 
 Service tokens never expire. You must actively [delete]({{es-apis}}operation/operation-security-delete-service-token) them if they are no longer needed.
 
+For an overview of how service tokens, access tokens, and API keys are used for authentication, refer to [Token-based authentication services](token-based-authentication-services.md).
 
-## Authenticate with service tokens [authenticate-with-service-account-token]
 
-::::{note}
-Service accounts currently do not support basic authentication.
-::::
+### Authenticate with service tokens [authenticate-with-service-account-token]
+
+To authenticate requests to {{es}}, include the service token in the `Authorization: Bearer` header of each request. Service accounts don't support basic authentication.
+
+### Verify a service token [verify-service-account-token]
 
+You can verify a service token, for example, by calling the [authenticate API]({{es-apis}}operation/operation-security-authenticate) (`GET /_security/_authenticate`). This API returns information about the authenticated identity, including its principal, assigned roles, and authentication details.
 
-To use a service account token, include the generated token value in a request with an `Authorization: Bearer` header:
+Set `ELASTICSEARCH_URL` to your deployment's HTTPS endpoint and `SERVICE_ACCOUNT_TOKEN` to your service token:
 
-```shell
-curl -H "Authorization: Bearer AAEAAWVsYXN0aWM...vZmxlZXQtc2VydmVyL3Rva2VuMTo3TFdaSDZ" http://localhost:9200/_security/_authenticate
+```bash
+curl --request GET "$ELASTICSEARCH_URL/_security/_authenticate" \
+  --header "Authorization: Bearer $SERVICE_ACCOUNT_TOKEN"
 ```
 
-A successful authentication response includes a `token` field, which contains a `name` field for the name of the service token and a `type` field for the type of the service token:
+The following examples show the response for each type of service account:
 
-```js
+::::{tab-set}
+
+:::{tab-item} Built-in service account
+
+This example uses the `elastic/fleet-server` account, which has predefined privileges:
+
+```json
 {
   "username": "elastic/fleet-server",
   "roles": [],
   "full_name": "Service account - elastic/fleet-server",
   "email": null,
   "token": {
-    "name": "token1",                 <1>
-    "type": "_service_account_index"  <2>
+    "name": "production",
+    "type": "_service_account_index"
   },
   "metadata": {
     "_elastic_service_account": true
@@ -101,7 +147,65 @@ A successful authentication response includes a `token` field, which contains a
 }
 ```
 
-1. Name of the service account token.
-2. Type of service account token. The value always begins with `_service_account_` and is followed by a string that indicates the service token backend in use (can be either `file` or `index`).
+:::
+
+:::{tab-item} User-managed service account
+
+```{applies_to}
+stack: ga 9.6+
+```
+
+This example uses the `kibana/automation-client` account with the `automation_client` role:
+
+```json
+{
+  "username": "kibana/automation-client",
+  "roles": [
+    "automation_client"
+  ],
+  "full_name": "User-managed service account - kibana/automation-client",
+  "email": null,
+  "token": {
+    "name": "production",
+    "type": "_service_account_index"
+  },
+  "metadata": {
+    "_user_managed_service_account": true
+  },
+  "enabled": true,
+  "authentication_realm": {
+    "name": "_service_account",
+    "type": "_service_account"
+  },
+  "lookup_realm": {
+    "name": "_service_account",
+    "type": "_service_account"
+  },
+  "authentication_type": "token"
+}
+```
+
+:::
+
+::::
+
+In both responses:
+
+- `username` is the principal of the authenticated account.
+- `roles` lists the assigned role names. Built-in accounts return an empty array because their privileges are predefined.
+- `token` describes the credential used for the request. Its `name` is the service token's name, and its `type` identifies the storage backend: `_service_account_index` for tokens stored in the `.security` index, or `_service_account_file` for file-backed tokens used by built-in accounts.
+- `metadata` identifies the account type: `_elastic_service_account` for built-in accounts or `_user_managed_service_account` for user-managed accounts.
+
+{applies_to}`stack: ga 9.6+` To authenticate calls to {{kib}} with a user-managed service account, refer to [Authenticate to the {{kib}} API with a service account](authenticate-kibana-api-with-service-account.md).
+
+## Audit user-managed service account activity [audit-service-account-activity]
+```{applies_to}
+stack: ga 9.6+
+serverless: unavailable
+```
+
+{{kib}} [audit events](kibana://reference/kibana-audit-events.md) record account creation and deletion, changes to workload assignments, and attempts to run a workload as an account. The `service_account_assume` event identifies the account and workload execution. Events caused by that workload identify the service account as the acting principal.
 
+{{es}} [audit events](elasticsearch://reference/elasticsearch/elasticsearch-audit-events.md) also attribute requests that use a service account credential to the account.
 
+% Follow-up in elastic/kibana: change the service account audit event lifecycle labels from preview to GA for 9.6. The service_account_assume event is already documented after #295817 merged.
diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/token-based-authentication-services.md b/deploy-manage/users-roles/cluster-or-deployment-auth/token-based-authentication-services.md
index db39f1520b1..854a1896fd3 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/token-based-authentication-services.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/token-based-authentication-services.md
@@ -9,21 +9,27 @@ products:
 
 # Token-based authentication services [token-authentication-services]
 
-The {{stack-security-features}} authenticate users by using realms and one or more token-based authentication services. The token-based authentication services are used for authenticating and managing tokens. You can attach these tokens to requests that are sent to {{es}} and use them as credentials. When {{es}} receives a request that must be authenticated, it consults the token-based authentication services first, and then the realm chain.
+The {{stack-security-features}} authenticate requests by using realms and one or more token-based authentication services. The token-based authentication services are used for authenticating and managing tokens. You can attach these tokens to requests that are sent to {{es}} and use them as credentials. When {{es}} receives a request that must be authenticated, it consults the token-based authentication services first, and then the realm chain.
 
 The {{security-features}} provide the following built-in token-based authentication services, which are listed in the order they are consulted:
 
 *service-accounts*
-:   The [service accounts](service-accounts.md) use either the [create service account token API]({{es-apis}}operation/operation-security-create-service-token) or the [elasticsearch-service-tokens](elasticsearch://reference/elasticsearch/command-line-tools/service-tokens-command.md) CLI tool to generate service account tokens.
+:   [Service accounts](service-accounts.md) use service tokens to authenticate as non-human identities. For details about token creation, storage, and deletion, refer to [Service account tokens](service-accounts.md#service-accounts-tokens).
+
+    :::{note}
+    :applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
+    [User-managed service accounts](service-accounts.md#user-managed-service-accounts) can authenticate requests to {{es}} and {{kib}}.
+    :::
 
 To use a service account token, include the generated token value in a request with an `Authorization: Bearer` header:
 
 ```shell
-curl -H "Authorization: Bearer AAEAAWVsYXN0aWMvZ...mXQtc2VydmMTpyNXdkYmRib1FTZTl2R09Ld2FKR0F3" http://localhost:9200/_cluster/health
+curl -H "Authorization: Bearer AAEAAWVsYXN0aWMvZ...mXQtc2VydmMTpyNXdkYmRib1FTZTl2R09Ld2FKR0F3" \
+  "$ELASTICSEARCH_URL/_cluster/health"
 ```
 
 ::::{important}
-Do not attempt to use service accounts for authenticating individual users. Service accounts can only be authenticated with service tokens, which are not applicable to regular users.
+Don't use service accounts to authenticate individual users. Service tokens and credentials derived from them are for software and workloads, not people.
 ::::
 
 
diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md b/deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md
index 4ef7ea53013..bfca3e717cb 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md
@@ -53,7 +53,7 @@ If you use {{serverless-full}}, then you can only manage authentication at the [
 ### Advanced topics
 
 * Learn about [internal users](/deploy-manage/users-roles/cluster-or-deployment-auth/internal-users.md), which are responsible for the operations that take place inside an {{es}} cluster.
-* Learn about [service accounts](/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md), which are used for integration with external services that connect to {{es}}.
+* {applies_to}`stack: all` {applies_to}`serverless: unavailable` Learn about [service accounts](/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md), which provide non-human identities for applications and services that access Elastic products. {applies_to}`stack: ga 9.6+` User-managed service accounts can authenticate to both {{es}} and {{kib}}.
 * Learn about the [services used for token-based authentication](/deploy-manage/users-roles/cluster-or-deployment-auth/token-based-authentication-services.md).
 * Learn about the [services used by orchestrators](/deploy-manage/users-roles/cluster-or-deployment-auth/operator-privileges.md).
 * Manage [user profiles](/deploy-manage/users-roles/cluster-or-deployment-auth/user-profiles.md).
diff --git a/explore-analyze/toc.yml b/explore-analyze/toc.yml
index a5070765851..69c75f0f8cb 100644
--- a/explore-analyze/toc.yml
+++ b/explore-analyze/toc.yml
@@ -697,6 +697,7 @@ toc:
           - file: workflows/authoring-techniques/use-yaml-editor.md
           - file: workflows/authoring-techniques/anatomy.md
           - file: workflows/authoring-techniques/settings.md
+          - file: workflows/authoring-techniques/run-workflow-as-service-account.md
           - file: workflows/authoring-techniques/choose-the-right-step.md
           - file: workflows/authoring-techniques/pass-data-handle-errors.md
           - file: workflows/authoring-techniques/compose-workflows.md
diff --git a/explore-analyze/workflows/authoring-techniques.md b/explore-analyze/workflows/authoring-techniques.md
index a224208f8f7..5bd99c6534b 100644
--- a/explore-analyze/workflows/authoring-techniques.md
+++ b/explore-analyze/workflows/authoring-techniques.md
@@ -21,6 +21,7 @@ Techniques that apply across workflow types, regardless of which outcome you're
 - [Use the YAML editor](/explore-analyze/workflows/authoring-techniques/use-yaml-editor.md): Author and run workflows in the YAML editor in {{kib}}.
 - [Anatomy of a workflow](/explore-analyze/workflows/authoring-techniques/anatomy.md): Every top-level field in a workflow definition and the execution lifecycle.
 - [Workflow settings](/explore-analyze/workflows/authoring-techniques/settings.md): Workflow-wide settings reference, including timeout, timezone, concurrency, max step size, and global on-failure.
+- {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md): Give every run a stable, least-privilege identity.
 - [Choose the right step](/explore-analyze/workflows/authoring-techniques/choose-the-right-step.md): Decision aid for picking the right step type. Keyed by intent.
 - [Pass data and handle errors](/explore-analyze/workflows/authoring-techniques/pass-data-handle-errors.md): Move data between steps, use dynamic templating, and make workflows resilient with `on-failure`.
 - [Compose workflows from reusable parts](/explore-analyze/workflows/authoring-techniques/compose-workflows.md): Decompose long workflows into reusable child workflows, design the input and output contract, and fan out with asynchronous composition.
diff --git a/explore-analyze/workflows/authoring-techniques/anatomy.md b/explore-analyze/workflows/authoring-techniques/anatomy.md
index 9a669f35fd4..9fcfc8dda09 100644
--- a/explore-analyze/workflows/authoring-techniques/anatomy.md
+++ b/explore-analyze/workflows/authoring-techniques/anatomy.md
@@ -15,7 +15,7 @@ products:
 
 # Anatomy of a workflow [workflows-anatomy]
 
-A workflow definition has eleven top-level fields. Most of them are optional. This page is the reference for all of them.
+A workflow definition combines identity, triggers, settings, and steps in top-level fields. Most fields are optional. This page is the reference for all fields.
 
 ## The complete workflow shape [workflows-anatomy-shape]
 
@@ -115,7 +115,7 @@ steps:                               # what it does
 | [`inputs`](#workflows-anatomy-inputs) | object or `Input[]` | No | Runtime parameters the workflow accepts. Values provided at invocation time become `{{ inputs.<name> }}` inside the workflow. On 9.5+, defined under the `manual` trigger. |
 | [`consts`](#workflows-anatomy-consts) | object | No | Constant values reusable as `{{ consts.<name> }}`. Use for thresholds, index names, or other values you want to name. |
 | [`outputs`](#workflows-anatomy-outputs) | object or `Output[]` | No | Declared output schema. Required for workflows invoked through [composition](/explore-analyze/workflows/steps/composition.md) — the parent needs to know the child's output shape. |
-| [`settings`](#workflows-anatomy-settings) | object | No | Global behavior: timeout, timezone, concurrency, global error handling, output-size cap. Refer to [Workflow settings](/explore-analyze/workflows/authoring-techniques/settings.md). |
+| [`settings`](#workflows-anatomy-settings) | object | No | Global behavior: execution identity, timeout, timezone, concurrency, global error handling, and output-size cap. Refer to [Workflow settings](/explore-analyze/workflows/authoring-techniques/settings.md). |
 | [`steps`](#workflows-anatomy-steps) | `Step[]` | Yes | Ordered list of steps to execute. Refer to [Steps](/explore-analyze/workflows/steps.md). |
 
 ## `name` — workflow identity [workflows-anatomy-name]
@@ -274,7 +274,7 @@ A workflow that doesn't declare outputs can still complete successfully. `output
 
 ## `settings` — global behavior [workflows-anatomy-settings]
 
-`settings` is the grab bag for workflow-wide behavior: timeout, timezone, concurrency, and global error handling.
+`settings` controls workflow-wide behavior, such as execution identity, timeout, timezone, concurrency, and global error handling.
 
 ```yaml
 settings:
@@ -293,6 +293,11 @@ settings:
 
 Every field in `settings` is optional. The full reference with per-field semantics lives on the [Workflow settings page](/explore-analyze/workflows/authoring-techniques/settings.md).
 
+:::{note}
+:applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
+To run every execution with a user-managed service account, set `settings.run_as`. Refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
+:::
+
 ## `steps` — the body of the workflow [workflows-anatomy-steps]
 
 `steps` is an ordered list. Each step has a required `name` (unique within the workflow), a required `type` (the step type identifier), and a type-specific `with` block.
@@ -336,6 +341,7 @@ Five states are terminal: `completed`, `failed`, `cancelled`, `timed_out`, and `
 ## Related [workflows-anatomy-related]
 
 - [Workflow settings](/explore-analyze/workflows/authoring-techniques/settings.md): The full `settings` reference.
+- {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md): Assign a stable, least-privilege execution identity.
 - [Choose the right step](/explore-analyze/workflows/authoring-techniques/choose-the-right-step.md): Decision aid for picking step types.
 - [Steps overview](/explore-analyze/workflows/steps.md): The step catalog.
 - [Triggers overview](/explore-analyze/workflows/triggers.md): The trigger catalog.
diff --git a/explore-analyze/workflows/authoring-techniques/manage-workflows.md b/explore-analyze/workflows/authoring-techniques/manage-workflows.md
index 123a9384a45..4b671893975 100644
--- a/explore-analyze/workflows/authoring-techniques/manage-workflows.md
+++ b/explore-analyze/workflows/authoring-techniques/manage-workflows.md
@@ -45,6 +45,11 @@ To instantly run a workflow, click the **Run** icon {icon}`play` for a workflow,
 
 Click the **Edit** icon to open the workflow in the YAML editor. Alternatively, open the **All actions** menu ({icon}`boxes_vertical`), and click **Edit**.
 
+:::{important}
+:applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
+Editing a workflow [bound to a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md) also requires the `manage_security` cluster privilege. An editor can change what the account does, so grant edit access only to users you trust to use its privileges.
+:::
+
 ### Turn a workflow on or off [workflow-enable-disable]
 
 Use the **Enabled** toggle to control whether a workflow can run:
diff --git a/explore-analyze/workflows/authoring-techniques/monitor-workflows.md b/explore-analyze/workflows/authoring-techniques/monitor-workflows.md
index af831bc4c57..27356820d7d 100644
--- a/explore-analyze/workflows/authoring-techniques/monitor-workflows.md
+++ b/explore-analyze/workflows/authoring-techniques/monitor-workflows.md
@@ -48,6 +48,11 @@ When a workflow runs, the execution panel displays:
 - **Timestamps**: The duration of each step.
 - **Expandable details**: Click any step to examine details such as input parameters, output data, and execution timelines.
 
+:::{note}
+:applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
+For a workflow bound to a service account, **Triggered by** identifies the initiating user and **Run as** identifies the account used for authorization. Refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
+:::
+
 ## See what triggered a run [workflows-execution-trigger-source]
 
 ```{applies_to}
diff --git a/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md b/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
new file mode 100644
index 00000000000..1c47c125977
--- /dev/null
+++ b/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
@@ -0,0 +1,88 @@
+---
+navigation_title: Run as a service account
+applies_to:
+  stack: ga 9.6+
+  serverless: unavailable
+description: Assign a user-managed service account to a workflow, verify its execution identity, and troubleshoot permission errors.
+products:
+  - id: kibana
+  - id: cloud-hosted
+  - id: cloud-enterprise
+  - id: cloud-kubernetes
+  - id: elastic-stack
+---
+
+# Run a workflow as a service account [run-workflow-as-service-account]
+
+Starting with {{stack}} 9.6, you can run a workflow as a [user-managed service account](/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md#user-managed-service-accounts).
+
+Each run uses the account's roles, regardless of who starts or last edits the workflow. This is useful for shared workflows: their identity remains stable even if the person who created them leaves your organization. You can also give the account only the privileges the workflow needs, even if the people who manage it have broader access.
+
+This guide shows you how to assign a service account to a workflow and verify which identity its runs use.
+
+## Before you begin [run-workflow-as-service-account-prerequisites]
+
+- You need the **Update** [Workflows privilege](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md#kibana-privileges-workflows-subfeatures) to assign an account. To run the workflow and review its execution, you also need **Execute** and **Read Workflow Execution**.
+- You need the `manage_security` cluster privilege to add, change, or remove the workflow's service account assignment. Editing or deleting a workflow assigned to a service account also requires this privilege, in addition to the corresponding Workflows privilege.
+- An administrator must [create the account in {{kib}}](/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md) and assign the roles required by its steps.
+
+% Release check: the permissions documented here follow main at 0048598a3826081f299198d2e87e455047f71c41 (workflow_service_account_binding.ts and workflow_crud_service.ts). Confirm with Workflows whether 9.6 changes to the binding-only manage_security check described in https://github.com/elastic/docs-content-internal/issues/1733#issuecomment-6157381771.
+
+:::{warning}
+Anyone who can edit a workflow can change what its assigned service account does. Grant workflow edit privileges only to users you trust to use the account's privileges.
+:::
+
+## Assign a service account [assign-workflow-service-account]
+
+The `settings.run_as` field specifies the account that runs the workflow. Set it to the account's full principal, such as `kibana/incident-response`.
+
+:::{note}
+Workflows can run only as accounts created in {{kib}}, where the account's credential is securely stored. Accounts created directly through the {{es}} API can't be used for workflow execution, even if they use the `kibana` namespace.
+:::
+
+1. Open the workflow in the {{kib}} workflow editor.
+2. In the `settings` block, add `run_as`. Select an account from the picker or enter its principal:
+
+    ```yaml
+    settings:
+      run_as: kibana/incident-response
+    ```
+
+    If you have the required privileges, select **Create account** to create and assign an account without leaving the workflow editor.
+
+3. Save the workflow.
+
+The saved assignment applies to manual, scheduled, alert, and event-driven runs. Users who have permission to run the workflow don't need `manage_security` to start it.
+
+% TBD: Verify the final labels and interaction against https://github.com/elastic/kibana/pull/296889 before publication.
+
+## Verify the execution identity [verify-workflow-execution-identity]
+
+Run the saved workflow, then open its execution details. The overview identifies both identities:
+
+- **Triggered by** is the user who initiated the execution or whose action caused it.
+- **Run as** is the service account whose privileges authorized the workflow's actions.
+
+Steps that call {{es}} or {{kib}} (`elasticsearch.*` and `kibana.*`) use the service account's privileges. Connectors use their own stored credentials to authenticate to external systems. For details about credentials and child workflows, refer to [Workflow authorization](/explore-analyze/workflows/authorization.md).
+
+% TBD: Confirm agent credential propagation with Workflows and Agent Builder after https://github.com/elastic/kibana/issues/293019 is resolved before adding a claim about agents invoked by a bound workflow.
+
+## Test the workflow [test-bound-workflow]
+
+Save your changes before you [test the complete workflow](/explore-analyze/workflows/authoring-techniques/use-yaml-editor.md#workflows-supply-test-input). The test uses the saved definition and the service account's privileges. You can't test individual steps or unsaved definitions when `run_as` is set.
+
+## Handle permission and identity failures [handle-workflow-service-account-failures]
+
+A workflow assigned to a service account never falls back to the triggering user's privileges. If a run fails, check the account and its roles:
+
+- If the account is deactivated or deleted, the next run fails.
+- If the account lacks a privilege required by a step, that step fails with a privileges error.
+- If the account was deleted and recreated with the same principal, the old assignment no longer matches it. Remove the assignment, save the workflow, then assign the recreated account.
+
+[Update the account or its roles](/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md#disable-service-account), or assign a different account, then run the workflow again.
+
+## Remove the assignment [remove-workflow-service-account]
+
+Remove `run_as` from the workflow's `settings` block and save the workflow. Future runs return to the default [workflow authorization model](/explore-analyze/workflows/authorization.md), in which the trigger type determines whose privileges are used.
+
+Changing or removing the assignment doesn't switch the identity of a run already in progress. That run fails if it needs to renew its credential or resumes after a pause.
diff --git a/explore-analyze/workflows/authoring-techniques/settings.md b/explore-analyze/workflows/authoring-techniques/settings.md
index f3b8ea40800..860d6de7e3b 100644
--- a/explore-analyze/workflows/authoring-techniques/settings.md
+++ b/explore-analyze/workflows/authoring-techniques/settings.md
@@ -3,7 +3,7 @@ navigation_title: Workflow settings
 applies_to:
   stack: ga 9.4+
   serverless: ga
-description: Reference for workflow-wide settings. Timeout, timezone, concurrency, max step size, and global on-failure.
+description: Reference for workflow-wide settings, including execution identity, timeout, timezone, concurrency, output size, and failure handling.
 products:
   - id: kibana
   - id: cloud-serverless
@@ -26,6 +26,7 @@ The top-level `settings` block configures workflow-wide behavior. Every field is
 | `concurrency` | object | Controls what happens when a new execution would exceed the concurrency limit for its group. Refer to [Concurrency control](#workflows-settings-concurrency). |
 | `max-step-size` | byte size | Cap on per-step output size (for example `10mb`). |
 | `on-failure` | object | Global failure handling applied to every step. Same shape as per-step `on-failure`. Refer to [Pass data and handle errors](/explore-analyze/workflows/authoring-techniques/pass-data-handle-errors.md). |
+| `run_as` {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` | string | User-managed service account ID that authorizes every workflow run. Refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md). |
 
 Fields not set take the engine defaults.
 
@@ -38,6 +39,7 @@ Fields not set take the engine defaults.
 | Prevent overlapping runs from colliding on shared state | `concurrency` |
 | Keep a single step from producing 100 MB of output that bogs down the UI | `max-step-size` |
 | Apply a default retry policy to every step | `on-failure` |
+| Run with a stable, least-privilege identity {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` | `run_as` |
 
 ## `timeout` [workflows-settings-timeout]
 
@@ -79,6 +81,21 @@ settings:
 
 Steps that produce outputs exceeding this limit fail with a clear error. Useful to catch runaway {{es}} queries before they push the whole execution past the deployment limit.
 
+## `run_as` [workflows-settings-run-as]
+```{applies_to}
+stack: ga 9.6+
+serverless: unavailable
+```
+
+Assigns a user-managed service account to the workflow. Every trigger type runs the workflow with the account's current roles:
+
+```yaml
+settings:
+  run_as: kibana/incident-response
+```
+
+Setting, changing, or removing `run_as` requires the `manage_security` cluster privilege. Refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md) for setup instructions, permissions, and testing restrictions.
+
 ## Concurrency control [workflows-settings-concurrency]
 
 Use `settings.concurrency` to prevent overlapping executions from colliding. This is important for:
diff --git a/explore-analyze/workflows/authorization.md b/explore-analyze/workflows/authorization.md
index 42a9c917244..60547535a31 100644
--- a/explore-analyze/workflows/authorization.md
+++ b/explore-analyze/workflows/authorization.md
@@ -15,11 +15,11 @@ products:
 
 # Workflow authorization [workflows-authorization]
 
-Every workflow run is authorized by a specific user's privileges. Use this page to configure who runs your workflows, diagnose privileges errors, and keep your workflows' access current.
+Every workflow run uses a user's privileges by default. In {{stack}} 9.6 and later, you can run workflows as a user-managed service account instead. Use this page to understand which identity runs a workflow, diagnose privileges errors, and keep its access current.
 
 ## Whose privileges authorize a run [workflows-authorization-user]
 
-The trigger type determines which user's privileges authorize a run.
+When a workflow doesn't run as a service account, the trigger type determines which user's privileges authorize a run.
 
 | Trigger type | Whose privileges are used |
 |---|---|
@@ -29,23 +29,53 @@ The trigger type determines which user's privileges authorize a run.
 | Event-based | The user whose action produced the event. For example, a `cases.commentsAdded` event uses the privileges of the user who added the comment. |
 | `workflows.failed` (error handler trigger) | The same privileges the failed workflow ran with. |
 
+### Workflows that run as a service account [workflows-authorization-service-account]
+```{applies_to}
+stack: ga 9.6+
+serverless: unavailable
+```
+
+When you [bind a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md) with `settings.run_as`, every run uses that account's roles. The trigger type and the user who last saved or started the workflow don't change its privileges.
+
+The workflow stores a reference to the account. When a run starts, {{kib}} obtains a short-lived credential and renews it as needed. {{es}} resolves the account's roles whenever it authenticates, so changes to an assigned role apply to later credential requests without saving the workflow again.
+
+If the account is deleted, turned off, or lacks a required privilege, the run fails without falling back to a user.
+
 ## How {{kib}} records execution identity [workflows-authorization-audit]
 
-When a workflow run starts, {{kib}} records the execution identity so you can audit which privileges a run used. For a composed workflow ([`workflow.execute`](/explore-analyze/workflows/steps/composition.md#workflow-execute)), the child execution runs with the same execution identity as the parent, though the **Executions** tab doesn't visually indicate this inheritance. Refer to [](/explore-analyze/workflows/reference/context-variables.md#workflows-ctx-execution) for more information about execution context variables.
+When a workflow run starts, {{kib}} records the execution identity so you can audit which privileges it used. Refer to [](/explore-analyze/workflows/reference/context-variables.md#workflows-ctx-execution) for execution context variables.
 
 :::{note}
+:applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
+For a bound workflow, the execution details show the initiating user under **Triggered by** and the service account under **Run as**.
+:::
+
 The **Created By** filter on the **Workflows** page reflects who last saved the workflow, not necessarily who originally created it.
+
+### Execution identity in child workflows [workflows-authorization-child-identity]
+
+For workflows composed with [`workflow.execute`](/explore-analyze/workflows/steps/composition.md#workflow-execute), the execution identity depends on service account support:
+
+::::{applies-switch}
+:::{applies-item} stack: ga 9.6+
+Each saved workflow uses its own service account binding. A child doesn't automatically inherit a parent's service account. If the child has no binding, it uses the original caller's identity. When neither workflow has a binding, the child uses the same execution identity as the parent.
 :::
+:::{applies-item} { stack: 'ga 9.4-9.5, preview =9.3', serverless: ga }
+The child execution runs with the same execution identity as the parent. The **Executions** tab doesn't visually indicate this inheritance.
+:::
+::::
+
+## How steps use the execution identity [workflows-authorization-scope]
 
-## How steps use the API key [workflows-authorization-scope]
+All `kibana.*` and `elasticsearch.*` steps in a workflow share the same execution identity. There's no separate identity per step type. A step fails with a privileges error if the user or service account lacks the required privilege for that step. For example, a `createCase` step fails if the execution identity doesn't have Cases privileges.
 
-All `kibana.*` and `elasticsearch.*` steps in a workflow share a single API key. There's no separate credential per step type. The key's privileges determine what each step can do. A step fails with a privileges error if the executing user lacks the required privilege for that step. For example, a `createCase` step fails if the user doesn't have Cases privileges.
+For a workflow without a binding, credentials belong to the user identified in [Whose privileges authorize a run](#workflows-authorization-user). For a bound workflow, refer to [Workflows assigned a service account](#workflows-authorization-service-account).
 
-_Connector steps are an exception._ The connector authenticates to the third-party system using its own stored credentials, not the workflow's API key. However, {{kib}} still records the connector step as having executed under the workflow's API key for auditability. Refer to [Connector-based actions](/explore-analyze/workflows/steps/external-systems-apps.md#connector-based-actions) for details.
+_Connector steps are an exception._ The connector authenticates to the third-party system using its own stored credentials, not the workflow's credential. However, {{kib}} still records the connector step as having executed under the workflow's execution identity for auditability. Refer to [Connector-based actions](/explore-analyze/workflows/steps/external-systems-apps.md#connector-based-actions) for details.
 
-## How to keep a workflow's privileges current [workflows-authorization-updates]
+## How to keep a user's privileges current [workflows-authorization-updates]
 
-The following actions refresh the stored API key for future runs:
+For a workflow that isn't assigned a service account, the following actions refresh the stored API key for future runs:
 
 * Saving the workflow again with the desired user.
 * Toggling the workflow's **Enabled** setting off, then back on.
@@ -56,11 +86,12 @@ Deactivating a user or changing their role doesn't automatically update the stor
 
 ## Check and fix errors [workflows-authorization-troubleshoot]
 
-Two types of authorization errors can cause a workflow step to fail:
+The following authorization errors can cause a workflow step to fail:
 
 | Error type | Cause | Where it appears | How to resolve it |
 |---|---|---|---|
-| Step-level privileges error | The executing user lacks a required privilege for the step. | On the failing step in the run's **Executions** tab. | Save the workflow as a user who has the required privilege, or update the user's role and save again. |
+| Step-level privileges error | The execution identity lacks a required privilege for the step. | On the failing step in the run's **Executions** tab. | For a user identity, update the user's role and save the workflow again. For a service account, update one of its assigned roles. |
 | Stale or not-valid API key | The stored key is no longer valid, for example because an administrator deleted a role it depended on. There's no dedicated status or list-level indicator for this condition. | As an API key error on the individual `elasticsearch` or `kibana` step in the run's **Executions** tab. | Refresh the API key by saving the workflow again or toggling **Enabled** off and back on. |
+| Service account identity error {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` | The assigned account has `enabled: false`, is deleted, or no longer matches the saved assignment. | In the run's execution details. | Set `enabled: true` or assign an available account, then start a new run. |
 
 <!-- TODO: Workflows currently uses {{es}} API keys on both {{stack}} and {{serverless-short}} with no deployment-specific key type. When {{serverless-short}} enables UIAM API keys, Task Manager will use UIAM-issued keys for Serverless workflow runs. Add a "How the API key differs by deployment type" section when that ships. -->
diff --git a/explore-analyze/workflows/get-started/setup.md b/explore-analyze/workflows/get-started/setup.md
index d0f6188be1b..b2221a6a025 100644
--- a/explore-analyze/workflows/get-started/setup.md
+++ b/explore-analyze/workflows/get-started/setup.md
@@ -51,6 +51,15 @@ Access to workflows is controlled by [{{kib}} privileges](/deploy-manage/users-r
 | Access the **Workflows** page | `All` or `Read` for **Analytics → Workflows** |
 | Fully manage workflows | `All` for **Analytics → Workflows** |
 | Grant access to specific workflow actions | [Set sub-feature privileges](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md#kibana-privileges-workflows-subfeatures) for **Analytics → Workflows** |
+| Add, change, or remove a service account binding {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` | The **Update** Workflows privilege and the `manage_security` cluster privilege |
+| Edit or delete a workflow bound to a service account {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` | The corresponding Workflows privilege and the `manage_security` cluster privilege |
+
+:::{warning}
+:applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
+Workflow edit permission lets a user change what a bound service account does. Grant it only to users you trust to use the account's privileges.
+:::
+
+For details about assigning accounts and the permissions model, refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
 
 ## Show managed workflows [workflows-managed-visibility]
 
diff --git a/explore-analyze/workflows/reference/context-variables.md b/explore-analyze/workflows/reference/context-variables.md
index ec41af28583..d5d694407c9 100644
--- a/explore-analyze/workflows/reference/context-variables.md
+++ b/explore-analyze/workflows/reference/context-variables.md
@@ -125,6 +125,8 @@ Metadata about the current workflow execution.
 | `execution.startedAt` | ISO timestamp of start. |
 | `execution.isTestRun` | `true` if run from the editor's **Test** button. |
 | `execution.executedBy` | UID of the user or system that invoked the workflow. |
+| `execution.effectiveIdentity.type` {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` | Identity type. Set to `service_account` when the workflow runs as a user-managed service account. |
+| `execution.effectiveIdentity.id` {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` | ID of the user-managed service account that authorizes the workflow. |
 | `execution.triggeredBy` | Which trigger initiated this execution (`manual`, `scheduled`, `alert`, `workflows.failed`). |
 | `execution.url` | Deep link to the execution view in {{kib}}. |
 | `execution.compositionDepth` | 0 for a top-level invocation. Increments by 1 for each [`workflow.execute`](/explore-analyze/workflows/steps/composition.md#workflow-execute) level. |
diff --git a/explore-analyze/workflows/steps/elasticsearch.md b/explore-analyze/workflows/steps/elasticsearch.md
index 588662f0aa8..e0db03f264b 100644
--- a/explore-analyze/workflows/steps/elasticsearch.md
+++ b/explore-analyze/workflows/steps/elasticsearch.md
@@ -18,7 +18,7 @@ products:
 
 {{es}} actions are built-in steps that allow your workflows to interact directly with {{es}} APIs. You can search, index, update, and delete documents, manage indices, and perform any other operation supported by the {{es}} REST API.
 
-All {{es}} actions are automatically authenticated using the permissions or API key of the user executing the workflow.
+All {{es}} actions are automatically authenticated as the workflow's execution identity. Refer to [Workflow authorization](/explore-analyze/workflows/authorization.md) to understand which privileges each run uses.
 
 There are two ways to use {{es}} actions:
 
diff --git a/explore-analyze/workflows/steps/kibana.md b/explore-analyze/workflows/steps/kibana.md
index e1eca51c19c..fbd427485df 100644
--- a/explore-analyze/workflows/steps/kibana.md
+++ b/explore-analyze/workflows/steps/kibana.md
@@ -19,7 +19,7 @@ products:
 
 For Cases operations, always use the dedicated [Cases action steps](/explore-analyze/workflows/steps/cases.md). For Observability Streams, use the [Streams action steps](/explore-analyze/workflows/steps/streams.md). Everything else lives here.
 
-All {{kib}} actions are automatically authenticated using the permissions or API key of the user executing the workflow.
+All {{kib}} actions are automatically authenticated as the workflow's execution identity. Refer to [Workflow authorization](/explore-analyze/workflows/authorization.md) to understand which privileges each run uses.
 
 :::{important}
 The detection alert step type IDs use **PascalCase**, not lowercase or snake_case: `kibana.SetAlertsStatus`, `kibana.SetAlertTags`. The editor rejects lowercase variants. This is the most common authoring surprise on the {{kib}} namespace.
diff --git a/explore-analyze/workflows/triggers.md b/explore-analyze/workflows/triggers.md
index b080a19f3dd..eca29e00586 100644
--- a/explore-analyze/workflows/triggers.md
+++ b/explore-analyze/workflows/triggers.md
@@ -20,6 +20,8 @@ A trigger is an event or condition that initiates a workflow. Without a trigger,
 
 Triggers also provide initial context to the workflow. For example, a workflow triggered by an alert carries the alert's metadata, entities, and source events. This context shapes how the workflow executes.
 
+To understand whose privileges authorize a triggered run, refer to [Workflow authorization](/explore-analyze/workflows/authorization.md).
+
 ## Trigger types
 
 The following types of triggers are available:
@@ -149,4 +151,4 @@ steps:
     with:
       message: "Workflow started at {{ execution.startedAt }}"
       details: "Event data: {{ event | json:2 }}"
-```
\ No newline at end of file
+```
diff --git a/explore-analyze/workflows/triggers/alert-triggers.md b/explore-analyze/workflows/triggers/alert-triggers.md
index b51bce6d9c3..123193fc35c 100644
--- a/explore-analyze/workflows/triggers/alert-triggers.md
+++ b/explore-analyze/workflows/triggers/alert-triggers.md
@@ -16,7 +16,7 @@ products:
 
 Alert triggers run workflows automatically when detection or alerting rules generate an alert. Use alert triggers for alert enrichment, automated incident response, case creation, or notification routing.
 
-Alert-triggered workflows run with the privileges of the user who last saved the rule. For details, refer to [Workflow authorization](/explore-analyze/workflows/authorization.md).
+Alert-triggered workflows use the [workflow's execution identity](/explore-analyze/workflows/authorization.md). For workflows without a service account binding, this is the user who last saved the rule.
 
 When a rule generates an alert that triggers your workflow, the trigger provides rich context data to the workflow through the `event` field.
 
diff --git a/explore-analyze/workflows/triggers/event-driven-triggers.md b/explore-analyze/workflows/triggers/event-driven-triggers.md
index 24977a38d4d..8559c5cafff 100644
--- a/explore-analyze/workflows/triggers/event-driven-triggers.md
+++ b/explore-analyze/workflows/triggers/event-driven-triggers.md
@@ -23,6 +23,7 @@ Event-driven triggers let workflows react to events elsewhere in {{kib}}. The fo
 - **Alert episode lifecycle triggers** — Fire on specific alert episode events in the {{alerting-v2-system}}, such as when it is activated, assigned, acknowledged, or snoozed. {applies_to}`stack: experimental 9.5+` {applies_to}`serverless: experimental`
 - **{{alerting-v2-system-cap}} rule lifecycle triggers** — Fire when rules are created, updated, deleted, enabled, or disabled in the {{alerting-v2-system}}. {applies_to}`stack: experimental 9.5+` {applies_to}`serverless: experimental`
 
+For details about which identity authorizes an event-driven run, refer to [Workflow authorization](/explore-analyze/workflows/authorization.md).
 
 :::{include} ../_snippets/schema-location-legend.md
 :::
diff --git a/explore-analyze/workflows/triggers/manual-triggers.md b/explore-analyze/workflows/triggers/manual-triggers.md
index 9da3562c215..16fa4ab2a72 100644
--- a/explore-analyze/workflows/triggers/manual-triggers.md
+++ b/explore-analyze/workflows/triggers/manual-triggers.md
@@ -16,7 +16,7 @@ products:
 
 Manual triggers run workflows on-demand through the UI or API. They require explicit user action to start a workflow. Use manual triggers for testing, one-off tasks, administrative actions, or workflows that require a human decision to start.
 
-Manual runs use the privileges of the user who starts the run. For details, refer to [Workflow authorization](/explore-analyze/workflows/authorization.md).
+Manual runs use the [workflow's execution identity](/explore-analyze/workflows/authorization.md). For workflows without a service account binding, this is the user who starts the run.
 
 To define a manual trigger, use the following syntax:
 
diff --git a/explore-analyze/workflows/triggers/scheduled-triggers.md b/explore-analyze/workflows/triggers/scheduled-triggers.md
index 4008536ac19..7876527b65a 100644
--- a/explore-analyze/workflows/triggers/scheduled-triggers.md
+++ b/explore-analyze/workflows/triggers/scheduled-triggers.md
@@ -16,7 +16,7 @@ products:
 
 Scheduled triggers run workflows automatically at specific times or intervals, without requiring manual intervention. Use scheduled triggers for recurring tasks like reports, data cleanup, or periodic health checks.
 
-Scheduled workflows run with the privileges of the user who last saved the workflow. For details, refer to [Workflow authorization](/explore-analyze/workflows/authorization.md).
+Scheduled workflows use the [workflow's execution identity](/explore-analyze/workflows/authorization.md). For workflows without a service account binding, this is the user who last saved the workflow.
 
 You can configure scheduled triggers using:
 

From d227313b167c32a88a17813a4cb571f2c5880a77 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Tue, 20 Oct 2026 17:33:38 +0200
Subject: [PATCH 02/45] Preserve service account focus in Serverless FAQ

AI-Assisted: OpenAI Codex
---
 deploy-manage/deploy/elastic-cloud/serverless-faq.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/deploy-manage/deploy/elastic-cloud/serverless-faq.md b/deploy-manage/deploy/elastic-cloud/serverless-faq.md
index 2db8d0a5633..252c068b591 100644
--- a/deploy-manage/deploy/elastic-cloud/serverless-faq.md
+++ b/deploy-manage/deploy/elastic-cloud/serverless-faq.md
@@ -32,8 +32,8 @@ User-initiated data recovery is anticipated in a future release. You can follow
 
 ## Security, compliance, and access
 
-**Q: How can a non-human application authenticate to {{serverless-full}}?**<br>
-A: User-managed service accounts aren't available on {{serverless-short}}. Create a project API key instead. You can create project API keys in {{kib}}, with the {{es}} API, or as code with Terraform. Refer to [](/deploy-manage/api-keys/serverless-project-api-keys.md) for details.
+**Q: How can I create {{serverless-full}} service accounts?**<br>
+A: User-managed service accounts aren't available on {{serverless-short}}. To authenticate applications and automated processes, create a project API key. You can create project API keys in {{kib}}, with the {{es}} API, or as code with Terraform. Refer to [](/deploy-manage/api-keys/serverless-project-api-keys.md) for details.
 
 **Q: Can I configure {{es}} authentication realms (for example, native realm) in {{serverless-short}} projects?**  
 A: No. {{serverless-short}} uses a different authentication model and does not support [{{es}} authentication realms](/deploy-manage/users-roles/cluster-or-deployment-auth/authentication-realms.md). Project-level access is handled through [Serverless project API keys](/deploy-manage/api-keys/serverless-project-api-keys.md), and user authentication is managed at the [{{ecloud}} organization level](/deploy-manage/users-roles/cloud-organization.md) (including SAML SSO).

From a681fa56e276b6f02cd03e310b172eb7c52aafd3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Tue, 20 Oct 2026 17:50:10 +0200
Subject: [PATCH 03/45] Clarify service account API authentication in Kibana

AI-Assisted: OpenAI Codex
---
 .../cluster-or-deployment-auth/kibana-authentication.md         | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md b/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md
index 472e2be8cff..d9e4a48b3dd 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md
@@ -419,7 +419,7 @@ With this configuration, you can send requests to {{kib}} with the `Authorizatio
 
 :::{note}
 :applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
-You can authenticate programmatic requests as a user-managed service account. Refer to [Authenticate to the {{kib}} API with a service account](authenticate-kibana-api-with-service-account.md) to create a token and use it with the `Bearer` scheme.
+For programmatic access to {{kib}} APIs, you can authenticate as a user-managed service account using a service token with the `Bearer` scheme. Service accounts can't log in to the {{kib}} UI. Refer to [Authenticate to the {{kib}} API with a service account](authenticate-kibana-api-with-service-account.md) for instructions.
 :::
 
 

From 58e17e5a5340fea7e87daf64969627ecbcdd2bd1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Tue, 20 Oct 2026 18:00:51 +0200
Subject: [PATCH 04/45] Clarify service account implications of workflow
 editing

AI-Assisted: OpenAI Codex
---
 .../cluster-or-deployment-auth/kibana-privileges.md           | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md b/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md
index 526fa86acb6..0cacd724feb 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md
@@ -226,7 +226,9 @@ These privileges control specific actions on workflows. Selecting **All** includ
 
 :::{warning}
 :applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
-The **Update** privilege lets a user change what a bound service account does. Adding, changing, or removing a binding, and editing or deleting a bound workflow, also requires the `manage_security` cluster privilege. Grant workflow edit access only to users you trust to use the account's privileges. For account assignment instructions and required privileges, refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
+When you edit a workflow that runs as a service account, subsequent runs continue to use that account's privileges. Your changes can therefore use privileges you don't personally have. Grant workflow edit access only to users you trust to use those privileges.
+
+Adding, changing, or removing a binding, and editing or deleting a bound workflow, also requires the `manage_security` cluster privilege. For account assignment instructions and required privileges, refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
 :::
 
 ## Privileges in the Management group [kibana-privileges-management]

From 104d7e365502079d39509db0cd4378b07bbe8125 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Tue, 20 Oct 2026 18:22:38 +0200
Subject: [PATCH 05/45] Clarify workflow execution identity and service account
 guidance

AI-Assisted: OpenAI Codex
---
 .../users-roles/cluster-or-deployment-auth/kibana-privileges.md | 2 +-
 .../workflows/authoring-techniques/manage-workflows.md          | 2 ++
 .../workflows/authoring-techniques/monitor-workflows.md         | 2 +-
 .../authoring-techniques/run-workflow-as-service-account.md     | 2 +-
 explore-analyze/workflows/authorization.md                      | 2 +-
 explore-analyze/workflows/concepts.md                           | 2 +-
 6 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md b/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md
index 0cacd724feb..db47dbff0a5 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md
@@ -228,7 +228,7 @@ These privileges control specific actions on workflows. Selecting **All** includ
 :applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
 When you edit a workflow that runs as a service account, subsequent runs continue to use that account's privileges. Your changes can therefore use privileges you don't personally have. Grant workflow edit access only to users you trust to use those privileges.
 
-Adding, changing, or removing a binding, and editing or deleting a bound workflow, also requires the `manage_security` cluster privilege. For account assignment instructions and required privileges, refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
+Adding, changing, or removing a service account binding, and editing or deleting a bound workflow, also requires the `manage_security` cluster privilege. For account assignment instructions and required privileges, refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
 :::
 
 ## Privileges in the Management group [kibana-privileges-management]
diff --git a/explore-analyze/workflows/authoring-techniques/manage-workflows.md b/explore-analyze/workflows/authoring-techniques/manage-workflows.md
index 4b671893975..39254d160a6 100644
--- a/explore-analyze/workflows/authoring-techniques/manage-workflows.md
+++ b/explore-analyze/workflows/authoring-techniques/manage-workflows.md
@@ -45,6 +45,8 @@ To instantly run a workflow, click the **Run** icon {icon}`play` for a workflow,
 
 Click the **Edit** icon to open the workflow in the YAML editor. Alternatively, open the **All actions** menu ({icon}`boxes_vertical`), and click **Edit**.
 
+% Release check: confirm with Workflows whether editing a bound workflow without changing its service account binding requires manage_security in 9.6. Larry describes a binding-only requirement: https://github.com/elastic/docs-content-internal/issues/1733#issuecomment-6157381771. Update the related permissions guidance together if this changes.
+
 :::{important}
 :applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
 Editing a workflow [bound to a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md) also requires the `manage_security` cluster privilege. An editor can change what the account does, so grant edit access only to users you trust to use its privileges.
diff --git a/explore-analyze/workflows/authoring-techniques/monitor-workflows.md b/explore-analyze/workflows/authoring-techniques/monitor-workflows.md
index 27356820d7d..750650bbe06 100644
--- a/explore-analyze/workflows/authoring-techniques/monitor-workflows.md
+++ b/explore-analyze/workflows/authoring-techniques/monitor-workflows.md
@@ -50,7 +50,7 @@ When a workflow runs, the execution panel displays:
 
 :::{note}
 :applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
-For a workflow bound to a service account, **Triggered by** identifies the initiating user and **Run as** identifies the account used for authorization. Refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
+For a workflow bound to a service account, **Triggered by** identifies the user who starts the workflow or last saved it, depending on the trigger. **Run as** identifies the service account used for authorization. Refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
 :::
 
 ## See what triggered a run [workflows-execution-trigger-source]
diff --git a/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md b/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
index 1c47c125977..3096cc36a62 100644
--- a/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
+++ b/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
@@ -60,7 +60,7 @@ The saved assignment applies to manual, scheduled, alert, and event-driven runs.
 
 Run the saved workflow, then open its execution details. The overview identifies both identities:
 
-- **Triggered by** is the user who initiated the execution or whose action caused it.
+- **Triggered by** identifies the user who starts the workflow or last saved it, depending on the trigger.
 - **Run as** is the service account whose privileges authorized the workflow's actions.
 
 Steps that call {{es}} or {{kib}} (`elasticsearch.*` and `kibana.*`) use the service account's privileges. Connectors use their own stored credentials to authenticate to external systems. For details about credentials and child workflows, refer to [Workflow authorization](/explore-analyze/workflows/authorization.md).
diff --git a/explore-analyze/workflows/authorization.md b/explore-analyze/workflows/authorization.md
index 60547535a31..10fc52a530b 100644
--- a/explore-analyze/workflows/authorization.md
+++ b/explore-analyze/workflows/authorization.md
@@ -47,7 +47,7 @@ When a workflow run starts, {{kib}} records the execution identity so you can au
 
 :::{note}
 :applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
-For a bound workflow, the execution details show the initiating user under **Triggered by** and the service account under **Run as**.
+For a bound workflow, **Triggered by** identifies the user who starts the workflow or last saved it, depending on the trigger. **Run as** shows the service account used for authorization.
 :::
 
 The **Created By** filter on the **Workflows** page reflects who last saved the workflow, not necessarily who originally created it.
diff --git a/explore-analyze/workflows/concepts.md b/explore-analyze/workflows/concepts.md
index 016d09ed486..e01f4b725f4 100644
--- a/explore-analyze/workflows/concepts.md
+++ b/explore-analyze/workflows/concepts.md
@@ -18,7 +18,7 @@ products:
 Concept and reference material for Elastic Workflows, including the components that make up a workflow definition. Use this section when you need to know what a specific trigger or step accepts, what its output looks like, or how templating expressions are evaluated.
 
 - [Managed workflows](/explore-analyze/workflows/managed-workflows.md): Elastic-shipped workflows that install automatically and power product features.
-- [Authorization](/explore-analyze/workflows/authorization.md): Whose privileges authorize a workflow run and what the run's API key can access.
+- [Authorization](/explore-analyze/workflows/authorization.md): How a user or service account's privileges authorize a workflow run and determine what it can access.
 - [Triggers](/explore-analyze/workflows/triggers.md): Manual, scheduled, alert, and event-driven triggers.
 - [Steps](/explore-analyze/workflows/steps.md): Action, flow control, AI, data, and composition steps.
 - [Templating engine](/explore-analyze/workflows/templating.md): Liquid templating syntax and custom filters.

From 0979876a2c258816edbd96f38b1442ad36f5fb41 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Tue, 20 Oct 2026 18:39:42 +0200
Subject: [PATCH 06/45] Clarify authorization for alert-triggered workflows

AI-Assisted: OpenAI Codex
---
 explore-analyze/workflows/triggers/alert-triggers.md | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/explore-analyze/workflows/triggers/alert-triggers.md b/explore-analyze/workflows/triggers/alert-triggers.md
index 123193fc35c..a299ac60b85 100644
--- a/explore-analyze/workflows/triggers/alert-triggers.md
+++ b/explore-analyze/workflows/triggers/alert-triggers.md
@@ -16,7 +16,12 @@ products:
 
 Alert triggers run workflows automatically when detection or alerting rules generate an alert. Use alert triggers for alert enrichment, automated incident response, case creation, or notification routing.
 
-Alert-triggered workflows use the [workflow's execution identity](/explore-analyze/workflows/authorization.md). For workflows without a service account binding, this is the user who last saved the rule.
+By default, alert-triggered workflows run with the privileges of the user who last saved the rule.
+
+:::{note}
+:applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
+If you assign a service account to the workflow, it runs with that account's privileges instead. For details, refer to [Workflow authorization](/explore-analyze/workflows/authorization.md).
+:::
 
 When a rule generates an alert that triggers your workflow, the trigger provides rich context data to the workflow through the `event` field.
 

From 4b46564d22e8e2c95657439cefb0bac7c7177134 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Tue, 20 Oct 2026 18:50:09 +0200
Subject: [PATCH 07/45] Align authorization guidance across workflow triggers

AI-Assisted: OpenAI Codex
---
 .../workflows/triggers/event-driven-triggers.md            | 7 ++++++-
 explore-analyze/workflows/triggers/manual-triggers.md      | 7 ++++++-
 explore-analyze/workflows/triggers/scheduled-triggers.md   | 7 ++++++-
 3 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/explore-analyze/workflows/triggers/event-driven-triggers.md b/explore-analyze/workflows/triggers/event-driven-triggers.md
index 8559c5cafff..46ebfb22d10 100644
--- a/explore-analyze/workflows/triggers/event-driven-triggers.md
+++ b/explore-analyze/workflows/triggers/event-driven-triggers.md
@@ -23,7 +23,12 @@ Event-driven triggers let workflows react to events elsewhere in {{kib}}. The fo
 - **Alert episode lifecycle triggers** — Fire on specific alert episode events in the {{alerting-v2-system}}, such as when it is activated, assigned, acknowledged, or snoozed. {applies_to}`stack: experimental 9.5+` {applies_to}`serverless: experimental`
 - **{{alerting-v2-system-cap}} rule lifecycle triggers** — Fire when rules are created, updated, deleted, enabled, or disabled in the {{alerting-v2-system}}. {applies_to}`stack: experimental 9.5+` {applies_to}`serverless: experimental`
 
-For details about which identity authorizes an event-driven run, refer to [Workflow authorization](/explore-analyze/workflows/authorization.md).
+By default, event-driven workflows run with the privileges of the user whose action produced the event. Workflows triggered by `workflows.failed` use the same privileges as the failed workflow.
+
+:::{note}
+:applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
+If you assign a service account to the workflow, it runs with that account's privileges instead. For details, refer to [Workflow authorization](/explore-analyze/workflows/authorization.md).
+:::
 
 :::{include} ../_snippets/schema-location-legend.md
 :::
diff --git a/explore-analyze/workflows/triggers/manual-triggers.md b/explore-analyze/workflows/triggers/manual-triggers.md
index 16fa4ab2a72..3e04bb1c86f 100644
--- a/explore-analyze/workflows/triggers/manual-triggers.md
+++ b/explore-analyze/workflows/triggers/manual-triggers.md
@@ -16,7 +16,12 @@ products:
 
 Manual triggers run workflows on-demand through the UI or API. They require explicit user action to start a workflow. Use manual triggers for testing, one-off tasks, administrative actions, or workflows that require a human decision to start.
 
-Manual runs use the [workflow's execution identity](/explore-analyze/workflows/authorization.md). For workflows without a service account binding, this is the user who starts the run.
+By default, manual runs use the privileges of the user who starts the run.
+
+:::{note}
+:applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
+If you assign a service account to the workflow, it runs with that account's privileges instead. For details, refer to [Workflow authorization](/explore-analyze/workflows/authorization.md).
+:::
 
 To define a manual trigger, use the following syntax:
 
diff --git a/explore-analyze/workflows/triggers/scheduled-triggers.md b/explore-analyze/workflows/triggers/scheduled-triggers.md
index 7876527b65a..1ce98dbf378 100644
--- a/explore-analyze/workflows/triggers/scheduled-triggers.md
+++ b/explore-analyze/workflows/triggers/scheduled-triggers.md
@@ -16,7 +16,12 @@ products:
 
 Scheduled triggers run workflows automatically at specific times or intervals, without requiring manual intervention. Use scheduled triggers for recurring tasks like reports, data cleanup, or periodic health checks.
 
-Scheduled workflows use the [workflow's execution identity](/explore-analyze/workflows/authorization.md). For workflows without a service account binding, this is the user who last saved the workflow.
+By default, scheduled workflows run with the privileges of the user who last saved the workflow.
+
+:::{note}
+:applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
+If you assign a service account to the workflow, it runs with that account's privileges instead. For details, refer to [Workflow authorization](/explore-analyze/workflows/authorization.md).
+:::
 
 You can configure scheduled triggers using:
 

From 13a55c7e62771f8165177c839a41b9627b89f4bd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Wed, 28 Oct 2026 08:26:19 +0100
Subject: [PATCH 08/45] Apply suggestions from code review

Co-authored-by: shainaraskas <58563081+shainaraskas@users.noreply.github.com>
---
 .../authenticate-kibana-api-with-service-account.md        | 2 +-
 .../manage-service-accounts-in-kibana.md                   | 4 ++--
 .../cluster-or-deployment-auth/service-accounts.md         | 7 ++-----
 explore-analyze/workflows/authoring-techniques/anatomy.md  | 2 +-
 explore-analyze/workflows/authoring-techniques/settings.md | 2 +-
 explore-analyze/workflows/steps/kibana.md                  | 2 +-
 6 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md b/deploy-manage/users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md
index c41426764a1..09a7978e27f 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md
@@ -43,7 +43,7 @@ The `elasticsearch.serviceAccountToken` {{kib}} setting has a different purpose.
 
 ## Call a {{kib}} API [call-kibana-api-service-account]
 
-Send the token with the `Bearer` authentication scheme:
+To call the {{kib}} API using the service account identity, send the token with the `Bearer` authentication scheme:
 
 ```shell
 curl --request GET "$KIBANA_URL/api/spaces/space" \
diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md b/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
index d4eede46fc7..5a958c124a0 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
@@ -15,7 +15,7 @@ products:
 
 # Create and manage service accounts in {{kib}} [manage-service-accounts-kibana]
 
-Create user-managed service accounts and assign roles to control access to {{es}} and {{kib}} APIs. {{kib}} creates each account in {{es}} and securely stores its credential.
+Create user-managed service accounts and assign roles to control programmatic access to {{es}} and {{kib}} APIs. {{kib}} creates each account in {{es}} and securely stores its credential.
 
 ## Before you begin [manage-service-accounts-before-you-begin]
 
@@ -29,7 +29,7 @@ Service accounts are enabled by default on {{ech}}, {{ece}}, {{eck}}, and self-m
 
 ## Create a service account [create-service-account-kibana]
 
-1. Find **Service accounts** in the navigation menu or use the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md). In the **Classic** solution view, select **Stack Management** → **Security** → **Service accounts**.
+1. Find **Service accounts** in the navigation menu or use the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md). 
 2. Click **Create account**.
 3. In the **Name** field, enter a unique name of up to 128 characters. The name must start with a letter or number and can contain letters, numbers, hyphens, and underscores.
 4. Optional: In the **Description** field, describe what the account is used for.
diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md b/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
index e4eb4497333..67adde50bbf 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
@@ -12,7 +12,7 @@ products:
 
 # Service accounts [service-accounts]
 
-The {{stack-security-features}} provide *service accounts* specifically for integration with external services that connect to {{es}}. A service account is a non-human identity for a service or workload. Unlike a user, a service account isn't associated with a person and can't log in to the {{kib}} UI.
+A service account is a non-human identity for a service or workload. Unlike a user, a service account isn't associated with a person and can't log in to the {{kib}} UI.
 
 Service accounts authenticate with service tokens. The account defines the identity and privileges, while the token is a credential for that identity. For example, {{fleet}} server uses a service token to authenticate with {{es}} and manage its own API keys.
 
@@ -150,10 +150,7 @@ This example uses the `elastic/fleet-server` account, which has predefined privi
 :::
 
 :::{tab-item} User-managed service account
-
-```{applies_to}
-stack: ga 9.6+
-```
+{applies_to}`stack: ga 9.6+`
 
 This example uses the `kibana/automation-client` account with the `automation_client` role:
 
diff --git a/explore-analyze/workflows/authoring-techniques/anatomy.md b/explore-analyze/workflows/authoring-techniques/anatomy.md
index 9fcfc8dda09..d40c950b4b1 100644
--- a/explore-analyze/workflows/authoring-techniques/anatomy.md
+++ b/explore-analyze/workflows/authoring-techniques/anatomy.md
@@ -291,7 +291,7 @@ settings:
       delay: "10s"
 ```
 
-Every field in `settings` is optional. The full reference with per-field semantics lives on the [Workflow settings page](/explore-analyze/workflows/authoring-techniques/settings.md).
+Every field in `settings` is optional. The full reference with per-field semantics is available in [](/explore-analyze/workflows/authoring-techniques/settings.md).
 
 :::{note}
 :applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
diff --git a/explore-analyze/workflows/authoring-techniques/settings.md b/explore-analyze/workflows/authoring-techniques/settings.md
index 860d6de7e3b..7c4be33cdc8 100644
--- a/explore-analyze/workflows/authoring-techniques/settings.md
+++ b/explore-analyze/workflows/authoring-techniques/settings.md
@@ -26,7 +26,7 @@ The top-level `settings` block configures workflow-wide behavior. Every field is
 | `concurrency` | object | Controls what happens when a new execution would exceed the concurrency limit for its group. Refer to [Concurrency control](#workflows-settings-concurrency). |
 | `max-step-size` | byte size | Cap on per-step output size (for example `10mb`). |
 | `on-failure` | object | Global failure handling applied to every step. Same shape as per-step `on-failure`. Refer to [Pass data and handle errors](/explore-analyze/workflows/authoring-techniques/pass-data-handle-errors.md). |
-| `run_as` {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` | string | User-managed service account ID that authorizes every workflow run. Refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md). |
+| `run_as` {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` | string | User-managed service account ID that authorizes every workflow run. Refer to [](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md). |
 
 Fields not set take the engine defaults.
 
diff --git a/explore-analyze/workflows/steps/kibana.md b/explore-analyze/workflows/steps/kibana.md
index fbd427485df..5663ba356ec 100644
--- a/explore-analyze/workflows/steps/kibana.md
+++ b/explore-analyze/workflows/steps/kibana.md
@@ -19,7 +19,7 @@ products:
 
 For Cases operations, always use the dedicated [Cases action steps](/explore-analyze/workflows/steps/cases.md). For Observability Streams, use the [Streams action steps](/explore-analyze/workflows/steps/streams.md). Everything else lives here.
 
-All {{kib}} actions are automatically authenticated as the workflow's execution identity. Refer to [Workflow authorization](/explore-analyze/workflows/authorization.md) to understand which privileges each run uses.
+All {{kib}} actions are automatically authenticated as the workflow's execution identity. Refer to [](/explore-analyze/workflows/authorization.md) to understand which privileges each run uses.
 
 :::{important}
 The detection alert step type IDs use **PascalCase**, not lowercase or snake_case: `kibana.SetAlertsStatus`, `kibana.SetAlertTags`. The editor rejects lowercase variants. This is the most common authoring surprise on the {{kib}} namespace.

From 45001bc872f0a6f8a5a33e39d71c0c0b9075d166 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Wed, 28 Oct 2026 12:19:38 +0100
Subject: [PATCH 09/45] Address service account documentation feedback

Co-authored-by: Cursor <cursoragent@cursor.com>
---
 ...nticate-kibana-api-with-service-account.md | 38 +++++++++++--------
 .../kibana-authentication.md                  |  7 +---
 .../manage-service-accounts-in-kibana.md      | 34 ++++++++++-------
 .../run-workflow-as-service-account.md        |  2 +
 4 files changed, 46 insertions(+), 35 deletions(-)

diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md b/deploy-manage/users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md
index 09a7978e27f..6c453f26588 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md
@@ -19,27 +19,22 @@ Use a user-managed service account to authenticate programmatic requests to {{ki
 
 ## Before you begin [authenticate-kibana-api-service-account-prerequisites]
 
-- You need the `manage_security` cluster privilege to create a user-managed account and its service token.
-- Create a role that grants only the {{kib}} and {{es}} privileges required by the API operations.
-- Store the service token in a secrets manager. Service tokens don't expire and grant direct access to the account's privileges.
+Before you create a service token, make sure you have the following:
 
-## Create a token for your application [create-service-account-api-token]
+- You need an existing user-managed service account. If you don't have one, [create a service account in {{kib}}](manage-service-accounts-in-kibana.md#create-service-account-kibana).
+- You need the `manage_security` cluster privilege to create a service token for a user-managed account. The `manage_service_account` privilege permits token management only for built-in accounts in the `elastic` namespace.
 
-{{kib}} creates and stores a credential when you create an account in the UI. That credential is used for workload integrations and isn't displayed. For your application, create an additional service token:
+## Create a token for your application [create-service-account-api-token]
 
-1. [Create a service account in {{kib}}](manage-service-accounts-in-kibana.md#create-service-account-kibana). For this example, name it `automation-client` and assign the `automation_client` role. The account's principal is `kibana/automation-client`.
+{{kib}} creates and stores a credential when you create an account in the UI. That credential is used for workload integrations and isn't displayed. For your application, create an additional service token. The following example uses an existing account with the principal `kibana/automation-client`:
 
-2. Use the [create service account token API]({{es-apis}}operation/operation-security-create-service-token) to create a token for the account:
+1. Use the [create service account token API]({{es-apis}}operation/operation-security-create-service-token) to create a token for the account:
 
     ```console
     POST /_security/service/kibana/automation-client/credential/token/production
     ```
 
-3. Copy the `token.value` from the response and store it securely. You can't retrieve the value again.
-
-:::{note}
-The `elasticsearch.serviceAccountToken` {{kib}} setting has a different purpose. It configures the {{kib}} server to connect to {{es}} as the built-in `elastic/kibana` account. It doesn't provide a token for an external API client or bind a user-managed account to a workload.
-:::
+2. Copy the `token.value` from the response and store it securely, such as in a secrets manager. Service tokens don't expire, and you can't retrieve this value again.
 
 ## Call a {{kib}} API [call-kibana-api-service-account]
 
@@ -56,10 +51,23 @@ The response depends on the account's roles. A `403` response means the account
 
 For requests that change data, also include the headers required by that API, such as `kbn-xsrf`.
 
+## Call an {{es}} API [call-elasticsearch-api-service-account]
+
+You can use the same token to authenticate to {{es}}. For example, verify the account's identity with the authenticate API:
+
+```shell
+curl --request GET "$ELASTICSEARCH_URL/_security/_authenticate" \
+  --header "Authorization: Bearer $SERVICE_ACCOUNT_TOKEN"
+```
+
 ## Remove access [remove-service-account-api-access]
 
-Delete an individual service token to stop one client without affecting other clients that use the same account. Delete the account or set `enabled: false` to stop new authentications for all its service tokens.
+Service tokens don't expire. When an application no longer needs access, use the [delete service account token API]({{es-apis}}operation/operation-security-delete-service-token) to delete only its token:
+
+```console
+DELETE /_security/service/kibana/automation-client/credential/token/production
+```
 
-Deleting an account invalidates its service tokens and access tokens, but it doesn't invalidate API keys owned by the account. Rules and tasks that obtained an API key while authenticated as the account can continue to run with that key. To revoke this access, [invalidate the API keys]({{es-apis}}operation/operation-security-invalidate-api-key) explicitly.
+Deleting the token stops requests that use it without affecting the account or its other service tokens.
 
-To manage an account in the UI, refer to [Create and manage service accounts in {{kib}}](manage-service-accounts-in-kibana.md).
+To prevent new authentications with any of the account's service tokens, [deactivate the account](manage-service-accounts-in-kibana.md#disable-service-account). To permanently remove the identity and its associated credentials, [delete the account in {{kib}}](manage-service-accounts-in-kibana.md#delete-service-account-kibana).
diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md b/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md
index d9e4a48b3dd..3ee6d6c0f3a 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md
@@ -416,12 +416,7 @@ xpack.security.authc.http.schemes: [apikey, bearer, basic, something-custom]
 
 With this configuration, you can send requests to {{kib}} with the `Authorization` header using `ApiKey`, `Bearer`, `Basic` or `Something-Custom` HTTP schemes (case insensitive). Under the hood, {{kib}} relays this header to {{es}}, then {{es}} authenticates the request using the credentials in the header.
 
-
-:::{note}
-:applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
-For programmatic access to {{kib}} APIs, you can authenticate as a user-managed service account using a service token with the `Bearer` scheme. Service accounts can't log in to the {{kib}} UI. Refer to [Authenticate to the {{kib}} API with a service account](authenticate-kibana-api-with-service-account.md) for instructions.
-:::
-
+{applies_to}`{stack: ga 9.6+, serverless: unavailable}` User-managed service accounts provide another option for programmatic access to {{kib}} APIs. Their service tokens use the `Bearer` scheme, but they can't be used to log in to the {{kib}} UI. To create a token and authenticate a request, refer to [Authenticate to the {{kib}} API with a service account](authenticate-kibana-api-with-service-account.md).
 
 ### Embedded content authentication [embedded-content-authentication]
 
diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md b/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
index 5a958c124a0..f7a5a1f2b9c 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
@@ -19,24 +19,26 @@ Create user-managed service accounts and assign roles to control programmatic ac
 
 ## Before you begin [manage-service-accounts-before-you-begin]
 
-- You need the `manage_security` cluster privilege. Without it, the **Service accounts** page isn't available. The `manage_service_account` privilege applies only to built-in accounts in the `elastic` namespace.
-- On self-managed deployments, set [`xpack.encryptedSavedObjects.encryptionKey`](kibana://reference/configuration-reference/security-settings.md#xpack-encryptedsavedobjects-encryptionkey) in `kibana.yml`. {{kib}} uses this key to encrypt the stored credential.
-- Create the roles that you want to assign. Each account requires at least one role.
+Before you create or manage service accounts, check these requirements:
 
-% Follow-up in elastic/kibana: document xpack.security.serviceAccounts.enabled and xpack.security.serviceAccounts.requestLifetime (default 10m), then add links to the settings reference.
+- You need the `manage_security` cluster privilege. Without it, the **Service accounts** page isn't available. The `manage_service_account` privilege applies only to built-in accounts in the `elastic` namespace.
+- {applies_to}`self: ga` Set [`xpack.encryptedSavedObjects.encryptionKey`](kibana://reference/configuration-reference/security-settings.md#xpack-encryptedsavedobjects-encryptionkey) in `kibana.yml`. {{kib}} uses this key to encrypt the stored credential.
 
-Service accounts are enabled by default on {{ech}}, {{ece}}, {{eck}}, and self-managed deployments. Setting `xpack.security.serviceAccounts.enabled` to `false` turns off the **Service accounts** page and workload integration.
+% TBD: pending to add link to the setting reference as soon as the kibana PR is created and merged
+Service accounts are enabled by default on {{ech}}, {{ece}}, {{eck}}, and self-managed deployments. Set the {{kib}} `xpack.security.serviceAccounts.enabled` setting to `false` to turn off the **Service accounts** page and workload integration.
 
 ## Create a service account [create-service-account-kibana]
 
+Create a service account with the roles your workloads need:
+
 1. Find **Service accounts** in the navigation menu or use the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md). 
 2. Click **Create account**.
 3. In the **Name** field, enter a unique name of up to 128 characters. The name must start with a letter or number and can contain letters, numbers, hyphens, and underscores.
 4. Optional: In the **Description** field, describe what the account is used for.
-5. Under **Set privileges**, select one or more predefined or custom roles that grant the privileges the account needs. To create a role, click **Create new role**.
-6. Review the privileges granted by the selected roles, and click **Create account**.
+5. Under **Set privileges**, select one or more predefined or custom roles that grant the privileges the account needs. To [create a role](kibana-role-management.md), click **Create new role**.
+6. Review the selected roles, and click **Create account**.
 
-The new account appears with the principal `kibana/<name>`. {{kib}} creates and stores its credential. No token is displayed, and you don't need to copy a secret.
+The service account uses the principal `kibana/<name>`. For workloads such as workflows, rules, and scheduled tasks, {{kib}} creates and securely stores the credential for you. You don't need to copy a secret, and no token is displayed. To use the account from an external API client, [create a separate named service token](authenticate-kibana-api-with-service-account.md#create-service-token).
 
 {{es}} resolves the assigned roles by name whenever the account authenticates. Editing a role changes the privileges it grants to the account. Deleting a role stops that role from granting privileges.
 
@@ -46,8 +48,6 @@ The **Service accounts** table shows each account's name, description, roles, cr
 
 When an account has bound workloads, click **View** in the **Workloads** column to review them.
 
-% TBD: Recheck the creation flyout and role selector after https://github.com/elastic/kibana/pull/296889 merges. The Workloads column and View action are verified in main after #297492.
-
 Accounts created directly through the [{{es}} API]({{es-apis}}operation/operation-security-put-user-managed-service-account) also appear in the table.
 
 :::{important}
@@ -79,7 +79,9 @@ Workloads bound to an account that has `enabled: false` fail the next time they
 
 ## Delete a service account [delete-service-account-kibana]
 
-Delete an account when you no longer need its identity:
+Deleting a service account is permanent. If you only need to temporarily prevent the account from authenticating, [deactivate it](#disable-service-account) instead.
+
+To delete a service account:
 
 1. On the **Service accounts** page, find the account.
 2. From the **Actions** column, click **Delete**.
@@ -87,16 +89,20 @@ Delete an account when you no longer need its identity:
     - If no workloads are bound, click **Delete account**.
     - If workloads are bound, review the list. To delete the account without removing the bindings, click **Force delete account**.
 
-Deleting an account removes all its service tokens, including tokens created outside {{kib}}, and the credential stored by {{kib}}. It also invalidates access tokens issued to the account. If credential cleanup fails, {{kib}} reports a warning. A service token left behind can't authenticate while the account is absent.
+If you force delete an account, its bound workloads fail on their next run. To restore access, assign each affected workload a valid service account. This reassignment is required even if you recreate the deleted account with the same name. For Workflows, [assign a service account to each affected workflow](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md#assign-workflow-service-account).
+
+Deleting an account through {{kib}} attempts to remove every service token, including the credential it stores for workloads and tokens created outside {{kib}}. It also attempts to invalidate any short-lived access tokens used to run workloads as the account. If any credential cleanup fails, {{kib}} completes the deletion and reports a warning.
 
-Forced deletion leaves workload bindings in place. Those workloads fail on their next run. Creating another account with the same name doesn't restore an old binding. Bind each workload to the replacement account.
+A service token left behind after deletion can't authenticate, but it prevents you from creating another account with the same name until you delete the token. If you delete an account directly through the {{es}} API, short-lived access tokens already issued to the account remain valid until they expire, 20 minutes after issuance by default.
 
 :::{important}
-API keys owned by the account aren't invalidated when you delete the account. Rules and tasks that obtained an API key while authenticated as the account can continue to run with that key. To revoke this access, [invalidate the API keys]({{es-apis}}operation/operation-security-invalidate-api-key) explicitly.
+API keys owned by the account aren't invalidated when you delete the account. {{rules-ui}} and tasks that obtained an API key while authenticated as the account can continue to run with that key. To revoke this access, [invalidate the API keys]({{es-apis}}operation/operation-security-invalidate-api-key) explicitly.
 :::
 
 ## Next steps [manage-service-accounts-next-steps]
 
+Use these guides to work with service accounts and learn more about their credentials:
+
 - [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
 - [Authenticate to the {{kib}} API with a service account](authenticate-kibana-api-with-service-account.md).
 - Learn more about [service account types and credentials](service-accounts.md).
diff --git a/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md b/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
index 3096cc36a62..a609894257e 100644
--- a/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
+++ b/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
@@ -22,6 +22,8 @@ This guide shows you how to assign a service account to a workflow and verify wh
 
 ## Before you begin [run-workflow-as-service-account-prerequisites]
 
+Before you assign a service account to a workflow, make sure you meet these requirements:
+
 - You need the **Update** [Workflows privilege](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md#kibana-privileges-workflows-subfeatures) to assign an account. To run the workflow and review its execution, you also need **Execute** and **Read Workflow Execution**.
 - You need the `manage_security` cluster privilege to add, change, or remove the workflow's service account assignment. Editing or deleting a workflow assigned to a service account also requires this privilege, in addition to the corresponding Workflows privilege.
 - An administrator must [create the account in {{kib}}](/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md) and assign the roles required by its steps.

From 5258ada700b350c581ea8893dfd803d551fcfe7d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Wed, 28 Oct 2026 12:42:36 +0100
Subject: [PATCH 10/45] Clarify service account token behavior

Co-authored-by: Cursor <cursoragent@cursor.com>
---
 .../manage-service-accounts-in-kibana.md                    | 6 ++++--
 .../cluster-or-deployment-auth/service-accounts.md          | 2 +-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md b/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
index f7a5a1f2b9c..d50f1d69b3a 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
@@ -38,7 +38,7 @@ Create a service account with the roles your workloads need:
 5. Under **Set privileges**, select one or more predefined or custom roles that grant the privileges the account needs. To [create a role](kibana-role-management.md), click **Create new role**.
 6. Review the selected roles, and click **Create account**.
 
-The service account uses the principal `kibana/<name>`. For workloads such as workflows, rules, and scheduled tasks, {{kib}} creates and securely stores the credential for you. You don't need to copy a secret, and no token is displayed. To use the account from an external API client, [create a separate named service token](authenticate-kibana-api-with-service-account.md#create-service-token).
+The service account uses the principal `kibana/<name>`. For workloads such as workflows, rules, and scheduled tasks, {{kib}} creates and securely stores the credential for you. You don't need to copy a secret, and no token is displayed. To use the account from an external API client, [create a separate named service token](authenticate-kibana-api-with-service-account.md#create-service-account-api-token).
 
 {{es}} resolves the assigned roles by name whenever the account authenticates. Editing a role changes the privileges it grants to the account. Deleting a role stops that role from granting privileges.
 
@@ -73,7 +73,9 @@ PUT /_security/service/kibana/workflow-runner
 }
 ```
 
-Setting `enabled: false` prevents the account from authenticating without deleting it. To reactivate the account, send the complete definition again with `enabled` set to `true`.
+Setting `enabled: false` prevents authentication with the account's service tokens without deleting the account. It doesn't invalidate [short-lived access tokens](token-based-authentication-services.md#token-authentication-access-token) already issued to run workloads as the account. API keys already issued to the account also remain valid.
+
+To reactivate the account, send the complete definition again with `enabled` set to `true`.
 
 Workloads bound to an account that has `enabled: false` fail the next time they run. They don't fall back to the user who starts or edits the workload.
 
diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md b/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
index 67adde50bbf..9b87f7f6e4e 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
@@ -95,7 +95,7 @@ Both the API and CLI generate service tokens with a 22-character secret. {{es}}
 
 Service tokens never expire. You must actively [delete]({{es-apis}}operation/operation-security-delete-service-token) them if they are no longer needed.
 
-For an overview of how service tokens, access tokens, and API keys are used for authentication, refer to [Token-based authentication services](token-based-authentication-services.md).
+Service tokens are different from short-lived access tokens, which expire automatically. For an overview of these credential types and API keys, refer to [Token-based authentication services](token-based-authentication-services.md).
 
 
 ### Authenticate with service tokens [authenticate-with-service-account-token]

From 3268f7c9a97f30718d35997639651a4ed2f19a6d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Wed, 28 Oct 2026 13:24:04 +0100
Subject: [PATCH 11/45] Clarify service account assignments and namespaces

Co-authored-by: Cursor <cursoragent@cursor.com>
---
 .../manage-service-accounts-in-kibana.md                      | 4 ++--
 .../cluster-or-deployment-auth/service-accounts.md            | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md b/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
index d50f1d69b3a..8bc831188b8 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
@@ -77,7 +77,7 @@ Setting `enabled: false` prevents authentication with the account's service toke
 
 To reactivate the account, send the complete definition again with `enabled` set to `true`.
 
-Workloads bound to an account that has `enabled: false` fail the next time they run. They don't fall back to the user who starts or edits the workload.
+[Workflows assigned to an account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md#assign-workflow-service-account) that has `enabled: false` fail the next time they run. They don't fall back to the user who starts or edits the workflow.
 
 ## Delete a service account [delete-service-account-kibana]
 
@@ -91,7 +91,7 @@ To delete a service account:
     - If no workloads are bound, click **Delete account**.
     - If workloads are bound, review the list. To delete the account without removing the bindings, click **Force delete account**.
 
-If you force delete an account, its bound workloads fail on their next run. To restore access, assign each affected workload a valid service account. This reassignment is required even if you recreate the deleted account with the same name. For Workflows, [assign a service account to each affected workflow](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md#assign-workflow-service-account).
+If you force delete an account, workloads assigned to it fail on their next run. To restore access, assign each affected workload a valid service account. This reassignment is required even if you recreate the deleted account with the same name. For Workflows, [assign a service account to each affected workflow](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md#assign-workflow-service-account).
 
 Deleting an account through {{kib}} attempts to remove every service token, including the credential it stores for workloads and tokens created outside {{kib}}. It also attempts to invalidate any short-lived access tokens used to run workloads as the account. If any credential cleanup fails, {{kib}} completes the deletion and reports a warning.
 
diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md b/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
index 9b87f7f6e4e..02cbb043dc0 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
@@ -55,7 +55,7 @@ You can create and delete service tokens for these accounts, but you can't chang
 stack: ga 9.6+
 ```
 
-You create these accounts and assign roles to control their privileges. Accounts created in {{kib}} have IDs such as `kibana/order-processing`.
+You create these accounts and assign roles to control their privileges. Accounts created in {{kib}} use the `kibana` namespace, and their principals have the form `kibana/<name>`.
 
 Use a user-managed service account when your application needs its own identity to access {{es}} or {{kib}} APIs. Assign the roles required by the application, and authenticate its requests with a [service account token](#service-accounts-tokens).
 

From e8adeeb2c9258fb4685ea252a1d0b2b3e9ad7c87 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Wed, 28 Oct 2026 13:39:41 +0100
Subject: [PATCH 12/45] Refine service account authentication overview

Co-authored-by: Cursor <cursoragent@cursor.com>
---
 .../cluster-or-deployment-auth/user-authentication.md           | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md b/deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md
index bfca3e717cb..34cc09d70ea 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md
@@ -53,7 +53,7 @@ If you use {{serverless-full}}, then you can only manage authentication at the [
 ### Advanced topics
 
 * Learn about [internal users](/deploy-manage/users-roles/cluster-or-deployment-auth/internal-users.md), which are responsible for the operations that take place inside an {{es}} cluster.
-* {applies_to}`stack: all` {applies_to}`serverless: unavailable` Learn about [service accounts](/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md), which provide non-human identities for applications and services that access Elastic products. {applies_to}`stack: ga 9.6+` User-managed service accounts can authenticate to both {{es}} and {{kib}}.
+* Learn about [service accounts](/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md), which provide non-human identities for services and workloads.
 * Learn about the [services used for token-based authentication](/deploy-manage/users-roles/cluster-or-deployment-auth/token-based-authentication-services.md).
 * Learn about the [services used by orchestrators](/deploy-manage/users-roles/cluster-or-deployment-auth/operator-privileges.md).
 * Manage [user profiles](/deploy-manage/users-roles/cluster-or-deployment-auth/user-profiles.md).

From 9d0af123763db3c0597e7cc255de0dc1ac7f51d7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Wed, 28 Oct 2026 13:45:19 +0100
Subject: [PATCH 13/45] Document workflow run_as in settings example

Co-authored-by: Cursor <cursoragent@cursor.com>
---
 explore-analyze/workflows/authoring-techniques/anatomy.md | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/explore-analyze/workflows/authoring-techniques/anatomy.md b/explore-analyze/workflows/authoring-techniques/anatomy.md
index d40c950b4b1..d60605cb43c 100644
--- a/explore-analyze/workflows/authoring-techniques/anatomy.md
+++ b/explore-analyze/workflows/authoring-techniques/anatomy.md
@@ -278,6 +278,7 @@ A workflow that doesn't declare outputs can still complete successfully. `output
 
 ```yaml
 settings:
+  run_as: kibana/workflow-runner <1>
   timeout: "10m"
   timezone: "America/Los_Angeles"
   max-step-size: "10mb"
@@ -290,14 +291,10 @@ settings:
       max-attempts: 2
       delay: "10s"
 ```
+1. {applies_to}`{stack: ga 9.6+, serverless: unavailable}` Runs every execution with the specified user-managed service account. Refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
 
 Every field in `settings` is optional. The full reference with per-field semantics is available in [](/explore-analyze/workflows/authoring-techniques/settings.md).
 
-:::{note}
-:applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
-To run every execution with a user-managed service account, set `settings.run_as`. Refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
-:::
-
 ## `steps` — the body of the workflow [workflows-anatomy-steps]
 
 `steps` is an ordered list. Each step has a required `name` (unique within the workflow), a required `type` (the step type identifier), and a type-specific `with` block.

From 4c805a23f7a87456a98901fb5644fe90539cebaa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Wed, 28 Oct 2026 13:47:19 +0100
Subject: [PATCH 14/45] comment removed

---
 .../workflows/authoring-techniques/manage-workflows.md          | 2 --
 1 file changed, 2 deletions(-)

diff --git a/explore-analyze/workflows/authoring-techniques/manage-workflows.md b/explore-analyze/workflows/authoring-techniques/manage-workflows.md
index 39254d160a6..4b671893975 100644
--- a/explore-analyze/workflows/authoring-techniques/manage-workflows.md
+++ b/explore-analyze/workflows/authoring-techniques/manage-workflows.md
@@ -45,8 +45,6 @@ To instantly run a workflow, click the **Run** icon {icon}`play` for a workflow,
 
 Click the **Edit** icon to open the workflow in the YAML editor. Alternatively, open the **All actions** menu ({icon}`boxes_vertical`), and click **Edit**.
 
-% Release check: confirm with Workflows whether editing a bound workflow without changing its service account binding requires manage_security in 9.6. Larry describes a binding-only requirement: https://github.com/elastic/docs-content-internal/issues/1733#issuecomment-6157381771. Update the related permissions guidance together if this changes.
-
 :::{important}
 :applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
 Editing a workflow [bound to a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md) also requires the `manage_security` cluster privilege. An editor can change what the account does, so grant edit access only to users you trust to use its privileges.

From e3afa7e2bcfb3f1a991db3fbf36a6f8a98064da5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Wed, 28 Oct 2026 13:56:28 +0100
Subject: [PATCH 15/45] Clarify workflow service account assignment

Co-authored-by: Cursor <cursoragent@cursor.com>
---
 .../run-workflow-as-service-account.md        | 22 ++++++-------------
 1 file changed, 7 insertions(+), 15 deletions(-)

diff --git a/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md b/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
index a609894257e..bdba136e6e5 100644
--- a/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
+++ b/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
@@ -26,38 +26,30 @@ Before you assign a service account to a workflow, make sure you meet these requ
 
 - You need the **Update** [Workflows privilege](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md#kibana-privileges-workflows-subfeatures) to assign an account. To run the workflow and review its execution, you also need **Execute** and **Read Workflow Execution**.
 - You need the `manage_security` cluster privilege to add, change, or remove the workflow's service account assignment. Editing or deleting a workflow assigned to a service account also requires this privilege, in addition to the corresponding Workflows privilege.
-- An administrator must [create the account in {{kib}}](/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md) and assign the roles required by its steps.
-
-% Release check: the permissions documented here follow main at 0048598a3826081f299198d2e87e455047f71c41 (workflow_service_account_binding.ts and workflow_crud_service.ts). Confirm with Workflows whether 9.6 changes to the binding-only manage_security check described in https://github.com/elastic/docs-content-internal/issues/1733#issuecomment-6157381771.
-
-:::{warning}
-Anyone who can edit a workflow can change what its assigned service account does. Grant workflow edit privileges only to users you trust to use the account's privileges.
-:::
 
 ## Assign a service account [assign-workflow-service-account]
 
 The `settings.run_as` field specifies the account that runs the workflow. Set it to the account's full principal, such as `kibana/incident-response`.
 
-:::{note}
-Workflows can run only as accounts created in {{kib}}, where the account's credential is securely stored. Accounts created directly through the {{es}} API can't be used for workflow execution, even if they use the `kibana` namespace.
-:::
+You can assign an existing account or create one without leaving the workflow editor. In both cases, the account must be [created in {{kib}}](/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md) and have the roles required by the workflow steps. Accounts created directly through the {{es}} API can't be used for workflow execution, even if they use the `kibana` namespace.
 
 1. Open the workflow in the {{kib}} workflow editor.
-2. In the `settings` block, add `run_as`. Select an account from the picker or enter its principal:
+2. In the `settings` block, add `run_as`:
+
+    - To use an existing account, select it from the picker or enter its principal.
+    - To create and assign an account, select **Create account** and configure its roles.
+
+    For example:
 
     ```yaml
     settings:
       run_as: kibana/incident-response
     ```
 
-    If you have the required privileges, select **Create account** to create and assign an account without leaving the workflow editor.
-
 3. Save the workflow.
 
 The saved assignment applies to manual, scheduled, alert, and event-driven runs. Users who have permission to run the workflow don't need `manage_security` to start it.
 
-% TBD: Verify the final labels and interaction against https://github.com/elastic/kibana/pull/296889 before publication.
-
 ## Verify the execution identity [verify-workflow-execution-identity]
 
 Run the saved workflow, then open its execution details. The overview identifies both identities:

From 04fee1558aad84409cbe8869883114d2b74eb2f9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Wed, 28 Oct 2026 14:00:52 +0100
Subject: [PATCH 16/45] Integrate workflow testing with identity verification

Co-authored-by: Cursor <cursoragent@cursor.com>
---
 .../run-workflow-as-service-account.md                 | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md b/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
index bdba136e6e5..ef71f278136 100644
--- a/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
+++ b/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
@@ -52,19 +52,17 @@ The saved assignment applies to manual, scheduled, alert, and event-driven runs.
 
 ## Verify the execution identity [verify-workflow-execution-identity]
 
-Run the saved workflow, then open its execution details. The overview identifies both identities:
+[Test the complete workflow](/explore-analyze/workflows/authoring-techniques/use-yaml-editor.md#workflows-supply-test-input). The test uses the saved definition and the service account's privileges. You can't test individual steps or unsaved definitions when `run_as` is set.
+
+After the test completes, open its execution details. The overview identifies both identities:
 
 - **Triggered by** identifies the user who starts the workflow or last saved it, depending on the trigger.
 - **Run as** is the service account whose privileges authorized the workflow's actions.
 
-Steps that call {{es}} or {{kib}} (`elasticsearch.*` and `kibana.*`) use the service account's privileges. Connectors use their own stored credentials to authenticate to external systems. For details about credentials and child workflows, refer to [Workflow authorization](/explore-analyze/workflows/authorization.md).
+Steps that call {{es}} or {{kib}} (`elasticsearch.*` and `kibana.*`) use the service account's privileges. {{connectors-ui}} use their own stored credentials to authenticate to external systems. For details about credentials and child workflows, refer to [Workflow authorization](/explore-analyze/workflows/authorization.md).
 
 % TBD: Confirm agent credential propagation with Workflows and Agent Builder after https://github.com/elastic/kibana/issues/293019 is resolved before adding a claim about agents invoked by a bound workflow.
 
-## Test the workflow [test-bound-workflow]
-
-Save your changes before you [test the complete workflow](/explore-analyze/workflows/authoring-techniques/use-yaml-editor.md#workflows-supply-test-input). The test uses the saved definition and the service account's privileges. You can't test individual steps or unsaved definitions when `run_as` is set.
-
 ## Handle permission and identity failures [handle-workflow-service-account-failures]
 
 A workflow assigned to a service account never falls back to the triggering user's privileges. If a run fails, check the account and its roles:

From 0532394da1abf48e094cf4fd484632fadfd7390b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Wed, 28 Oct 2026 14:02:13 +0100
Subject: [PATCH 17/45] Clarify removing workflow service account assignment

Co-authored-by: Cursor <cursoragent@cursor.com>
---
 .../authoring-techniques/run-workflow-as-service-account.md     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md b/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
index ef71f278136..302d882dc17 100644
--- a/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
+++ b/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
@@ -75,6 +75,6 @@ A workflow assigned to a service account never falls back to the triggering user
 
 ## Remove the assignment [remove-workflow-service-account]
 
-Remove `run_as` from the workflow's `settings` block and save the workflow. Future runs return to the default [workflow authorization model](/explore-analyze/workflows/authorization.md), in which the trigger type determines whose privileges are used.
+To remove the service account assignment from a workflow, remove `run_as` from the workflow's `settings` block and save the workflow. Future runs return to the default [workflow authorization model](/explore-analyze/workflows/authorization.md), in which the trigger type determines whose privileges are used.
 
 Changing or removing the assignment doesn't switch the identity of a run already in progress. That run fails if it needs to renew its credential or resumes after a pause.

From 251e3ca36c4383de844adb1f28f84fa2a64627d9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Wed, 28 Oct 2026 14:08:11 +0100
Subject: [PATCH 18/45] Clarify workflow authorization introduction

AI-Assisted: Codex
---
 explore-analyze/workflows/authorization.md | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/explore-analyze/workflows/authorization.md b/explore-analyze/workflows/authorization.md
index 10fc52a530b..035ae913597 100644
--- a/explore-analyze/workflows/authorization.md
+++ b/explore-analyze/workflows/authorization.md
@@ -15,7 +15,12 @@ products:
 
 # Workflow authorization [workflows-authorization]
 
-Every workflow run uses a user's privileges by default. In {{stack}} 9.6 and later, you can run workflows as a user-managed service account instead. Use this page to understand which identity runs a workflow, diagnose privileges errors, and keep its access current.
+Every workflow run is authorized by:
+
+* A specific user's privileges, by default.
+* {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` The privileges of an assigned user-managed service account.
+
+Use this page to configure who runs your workflows, diagnose privileges errors, and keep your workflows' access current.
 
 ## Whose privileges authorize a run [workflows-authorization-user]
 

From eb0c0561324158ac4dd6c02f248c8de31a74830b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Wed, 28 Oct 2026 14:18:58 +0100
Subject: [PATCH 19/45] Standardize workflow service account terminology

Co-authored-by: Cursor <cursoragent@cursor.com>
---
 .../cluster-or-deployment-auth/kibana-privileges.md   |  2 +-
 .../authoring-techniques/manage-workflows.md          |  2 +-
 .../authoring-techniques/monitor-workflows.md         |  2 +-
 .../run-workflow-as-service-account.md                |  2 +-
 explore-analyze/workflows/authorization.md            | 11 ++++-------
 explore-analyze/workflows/get-started/setup.md        |  9 ++-------
 6 files changed, 10 insertions(+), 18 deletions(-)

diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md b/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md
index db47dbff0a5..1ef4c335f02 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md
@@ -228,7 +228,7 @@ These privileges control specific actions on workflows. Selecting **All** includ
 :applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
 When you edit a workflow that runs as a service account, subsequent runs continue to use that account's privileges. Your changes can therefore use privileges you don't personally have. Grant workflow edit access only to users you trust to use those privileges.
 
-Adding, changing, or removing a service account binding, and editing or deleting a bound workflow, also requires the `manage_security` cluster privilege. For account assignment instructions and required privileges, refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
+Adding, changing, or removing a service account assignment, and editing or deleting a workflow assigned to a service account, also require the `manage_security` cluster privilege. For account assignment instructions and required privileges, refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
 :::
 
 ## Privileges in the Management group [kibana-privileges-management]
diff --git a/explore-analyze/workflows/authoring-techniques/manage-workflows.md b/explore-analyze/workflows/authoring-techniques/manage-workflows.md
index 4b671893975..ea291d015e0 100644
--- a/explore-analyze/workflows/authoring-techniques/manage-workflows.md
+++ b/explore-analyze/workflows/authoring-techniques/manage-workflows.md
@@ -47,7 +47,7 @@ Click the **Edit** icon to open the workflow in the YAML editor. Alternatively,
 
 :::{important}
 :applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
-Editing a workflow [bound to a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md) also requires the `manage_security` cluster privilege. An editor can change what the account does, so grant edit access only to users you trust to use its privileges.
+Editing a workflow [assigned to a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md) also requires the `manage_security` cluster privilege. An editor can change what the account does, so grant edit access only to users you trust to use its privileges.
 :::
 
 ### Turn a workflow on or off [workflow-enable-disable]
diff --git a/explore-analyze/workflows/authoring-techniques/monitor-workflows.md b/explore-analyze/workflows/authoring-techniques/monitor-workflows.md
index 750650bbe06..4c373984a73 100644
--- a/explore-analyze/workflows/authoring-techniques/monitor-workflows.md
+++ b/explore-analyze/workflows/authoring-techniques/monitor-workflows.md
@@ -50,7 +50,7 @@ When a workflow runs, the execution panel displays:
 
 :::{note}
 :applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
-For a workflow bound to a service account, **Triggered by** identifies the user who starts the workflow or last saved it, depending on the trigger. **Run as** identifies the service account used for authorization. Refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
+For a workflow assigned to a service account, **Triggered by** identifies the user who starts the workflow or last saved it, depending on the trigger. **Run as** identifies the service account used for authorization. Refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
 :::
 
 ## See what triggered a run [workflows-execution-trigger-source]
diff --git a/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md b/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
index 302d882dc17..43b2762dfb5 100644
--- a/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
+++ b/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
@@ -61,7 +61,7 @@ After the test completes, open its execution details. The overview identifies bo
 
 Steps that call {{es}} or {{kib}} (`elasticsearch.*` and `kibana.*`) use the service account's privileges. {{connectors-ui}} use their own stored credentials to authenticate to external systems. For details about credentials and child workflows, refer to [Workflow authorization](/explore-analyze/workflows/authorization.md).
 
-% TBD: Confirm agent credential propagation with Workflows and Agent Builder after https://github.com/elastic/kibana/issues/293019 is resolved before adding a claim about agents invoked by a bound workflow.
+% TBD: Confirm agent credential propagation with Workflows and Agent Builder after https://github.com/elastic/kibana/issues/293019 is resolved before adding a claim about agents invoked by a workflow assigned to a service account.
 
 ## Handle permission and identity failures [handle-workflow-service-account-failures]
 
diff --git a/explore-analyze/workflows/authorization.md b/explore-analyze/workflows/authorization.md
index 035ae913597..9578f7ee743 100644
--- a/explore-analyze/workflows/authorization.md
+++ b/explore-analyze/workflows/authorization.md
@@ -40,7 +40,7 @@ stack: ga 9.6+
 serverless: unavailable
 ```
 
-When you [bind a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md) with `settings.run_as`, every run uses that account's roles. The trigger type and the user who last saved or started the workflow don't change its privileges.
+When you [assign a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md) with `settings.run_as`, every run uses that account's roles. The trigger type and the user who last saved or started the workflow don't change its privileges.
 
 The workflow stores a reference to the account. When a run starts, {{kib}} obtains a short-lived credential and renews it as needed. {{es}} resolves the account's roles whenever it authenticates, so changes to an assigned role apply to later credential requests without saving the workflow again.
 
@@ -50,10 +50,7 @@ If the account is deleted, turned off, or lacks a required privilege, the run fa
 
 When a workflow run starts, {{kib}} records the execution identity so you can audit which privileges it used. Refer to [](/explore-analyze/workflows/reference/context-variables.md#workflows-ctx-execution) for execution context variables.
 
-:::{note}
-:applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
-For a bound workflow, **Triggered by** identifies the user who starts the workflow or last saved it, depending on the trigger. **Run as** shows the service account used for authorization.
-:::
+{applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` For workflows assigned to service accounts, **Triggered by** identifies the user who starts the workflow or last saved it, depending on the trigger. **Run as** shows the service account used for authorization.
 
 The **Created By** filter on the **Workflows** page reflects who last saved the workflow, not necessarily who originally created it.
 
@@ -63,7 +60,7 @@ For workflows composed with [`workflow.execute`](/explore-analyze/workflows/step
 
 ::::{applies-switch}
 :::{applies-item} stack: ga 9.6+
-Each saved workflow uses its own service account binding. A child doesn't automatically inherit a parent's service account. If the child has no binding, it uses the original caller's identity. When neither workflow has a binding, the child uses the same execution identity as the parent.
+Each saved workflow uses its own service account assignment. A child doesn't automatically inherit its parent's assignment. If the child isn't assigned a service account, it uses the original caller's identity. When neither workflow is assigned a service account, the child uses the same execution identity as the parent.
 :::
 :::{applies-item} { stack: 'ga 9.4-9.5, preview =9.3', serverless: ga }
 The child execution runs with the same execution identity as the parent. The **Executions** tab doesn't visually indicate this inheritance.
@@ -74,7 +71,7 @@ The child execution runs with the same execution identity as the parent. The **E
 
 All `kibana.*` and `elasticsearch.*` steps in a workflow share the same execution identity. There's no separate identity per step type. A step fails with a privileges error if the user or service account lacks the required privilege for that step. For example, a `createCase` step fails if the execution identity doesn't have Cases privileges.
 
-For a workflow without a binding, credentials belong to the user identified in [Whose privileges authorize a run](#workflows-authorization-user). For a bound workflow, refer to [Workflows assigned a service account](#workflows-authorization-service-account).
+For a workflow that isn't assigned a service account, credentials belong to the user identified in [Whose privileges authorize a run](#workflows-authorization-user). For a workflow assigned to a service account, refer to [Workflows assigned a service account](#workflows-authorization-service-account).
 
 _Connector steps are an exception._ The connector authenticates to the third-party system using its own stored credentials, not the workflow's credential. However, {{kib}} still records the connector step as having executed under the workflow's execution identity for auditability. Refer to [Connector-based actions](/explore-analyze/workflows/steps/external-systems-apps.md#connector-based-actions) for details.
 
diff --git a/explore-analyze/workflows/get-started/setup.md b/explore-analyze/workflows/get-started/setup.md
index b2221a6a025..ce21320cff6 100644
--- a/explore-analyze/workflows/get-started/setup.md
+++ b/explore-analyze/workflows/get-started/setup.md
@@ -51,13 +51,8 @@ Access to workflows is controlled by [{{kib}} privileges](/deploy-manage/users-r
 | Access the **Workflows** page | `All` or `Read` for **Analytics → Workflows** |
 | Fully manage workflows | `All` for **Analytics → Workflows** |
 | Grant access to specific workflow actions | [Set sub-feature privileges](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md#kibana-privileges-workflows-subfeatures) for **Analytics → Workflows** |
-| Add, change, or remove a service account binding {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` | The **Update** Workflows privilege and the `manage_security` cluster privilege |
-| Edit or delete a workflow bound to a service account {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` | The corresponding Workflows privilege and the `manage_security` cluster privilege |
-
-:::{warning}
-:applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
-Workflow edit permission lets a user change what a bound service account does. Grant it only to users you trust to use the account's privileges.
-:::
+| Add, change, or remove a service account assignment {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` | The **Update** Workflows privilege and the `manage_security` cluster privilege |
+| Edit or delete a workflow assigned to a service account {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` | The corresponding Workflows privilege and the `manage_security` cluster privilege |
 
 For details about assigning accounts and the permissions model, refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
 

From 4dfbd76d4c0c35c11cba6666c0225ce798a390a3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Wed, 28 Oct 2026 14:31:09 +0100
Subject: [PATCH 20/45] Align workflow trigger authorization guidance

AI-Assisted: Codex
---
 explore-analyze/workflows/authorization.md       |  2 +-
 .../workflows/triggers/manual-triggers.md        | 16 +++++++++-------
 .../workflows/triggers/scheduled-triggers.md     | 16 +++++++++-------
 3 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/explore-analyze/workflows/authorization.md b/explore-analyze/workflows/authorization.md
index 9578f7ee743..257a22c41cd 100644
--- a/explore-analyze/workflows/authorization.md
+++ b/explore-analyze/workflows/authorization.md
@@ -18,7 +18,7 @@ products:
 Every workflow run is authorized by:
 
 * A specific user's privileges, by default.
-* {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` The privileges of an assigned user-managed service account.
+* {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` The privileges of a user-managed service account, when one is assigned to the workflow.
 
 Use this page to configure who runs your workflows, diagnose privileges errors, and keep your workflows' access current.
 
diff --git a/explore-analyze/workflows/triggers/manual-triggers.md b/explore-analyze/workflows/triggers/manual-triggers.md
index 3e04bb1c86f..35d22e7e71c 100644
--- a/explore-analyze/workflows/triggers/manual-triggers.md
+++ b/explore-analyze/workflows/triggers/manual-triggers.md
@@ -16,13 +16,6 @@ products:
 
 Manual triggers run workflows on-demand through the UI or API. They require explicit user action to start a workflow. Use manual triggers for testing, one-off tasks, administrative actions, or workflows that require a human decision to start.
 
-By default, manual runs use the privileges of the user who starts the run.
-
-:::{note}
-:applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
-If you assign a service account to the workflow, it runs with that account's privileges instead. For details, refer to [Workflow authorization](/explore-analyze/workflows/authorization.md).
-:::
-
 To define a manual trigger, use the following syntax:
 
 ```yaml
@@ -35,6 +28,15 @@ This allows you to run a workflow manually by:
 * Clicking **Run** in the Workflows UI
 * Calling the workflow execution API, either directly or from an external system
 
+## Authorization
+
+Manual runs are authorized by:
+
+* The privileges of the user who starts the run, by default.
+* {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` The privileges of a user-managed service account, when one is assigned to the workflow.
+
+For details, refer to [](/explore-analyze/workflows/authorization.md).
+
 ## Input parameters
 
 Manual triggers can accept input parameters, which you can reference in any step. When you define inputs at the workflow level, users are prompted to provide values when they run the workflow. 
diff --git a/explore-analyze/workflows/triggers/scheduled-triggers.md b/explore-analyze/workflows/triggers/scheduled-triggers.md
index 1ce98dbf378..5eb066a513a 100644
--- a/explore-analyze/workflows/triggers/scheduled-triggers.md
+++ b/explore-analyze/workflows/triggers/scheduled-triggers.md
@@ -16,18 +16,20 @@ products:
 
 Scheduled triggers run workflows automatically at specific times or intervals, without requiring manual intervention. Use scheduled triggers for recurring tasks like reports, data cleanup, or periodic health checks.
 
-By default, scheduled workflows run with the privileges of the user who last saved the workflow.
-
-:::{note}
-:applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
-If you assign a service account to the workflow, it runs with that account's privileges instead. For details, refer to [Workflow authorization](/explore-analyze/workflows/authorization.md).
-:::
-
 You can configure scheduled triggers using:
 
 * **Interval-based scheduling**: Run on a recurring interval (every _x_ minutes, hours, or days)
 * **Recurrence rule (RRule) expressions**: Run at specific times in the specified timezone (for example, daily at 2 AM EST)
 
+## Authorization
+
+Scheduled runs are authorized by:
+
+* The privileges of the user who last saved the workflow, by default.
+* {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` The privileges of a user-managed service account, when one is assigned to the workflow.
+
+For details, refer to [](/explore-analyze/workflows/authorization.md).
+
 ## Interval-based scheduling
 
 Interval-based scheduling runs a workflow repeatedly at a fixed interval.

From c688d2f6bae4cd0d1f5a5f69db2a65fb63157ecc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Wed, 28 Oct 2026 14:35:32 +0100
Subject: [PATCH 21/45] Clarify authorization for alert and event-driven
 triggers

AI-Assisted: Codex
---
 .../workflows/triggers/alert-triggers.md       | 16 +++++++++-------
 .../triggers/event-driven-triggers.md          | 18 +++++++++++-------
 2 files changed, 20 insertions(+), 14 deletions(-)

diff --git a/explore-analyze/workflows/triggers/alert-triggers.md b/explore-analyze/workflows/triggers/alert-triggers.md
index a299ac60b85..2bba92b59f5 100644
--- a/explore-analyze/workflows/triggers/alert-triggers.md
+++ b/explore-analyze/workflows/triggers/alert-triggers.md
@@ -16,13 +16,6 @@ products:
 
 Alert triggers run workflows automatically when detection or alerting rules generate an alert. Use alert triggers for alert enrichment, automated incident response, case creation, or notification routing.
 
-By default, alert-triggered workflows run with the privileges of the user who last saved the rule.
-
-:::{note}
-:applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
-If you assign a service account to the workflow, it runs with that account's privileges instead. For details, refer to [Workflow authorization](/explore-analyze/workflows/authorization.md).
-:::
-
 When a rule generates an alert that triggers your workflow, the trigger provides rich context data to the workflow through the `event` field.
 
 :::{warning}
@@ -33,6 +26,15 @@ Declaring `type: alert` on a workflow isn't enough to run the workflow when aler
 Alert triggers are different from [alert episode lifecycle triggers](/explore-analyze/workflows/triggers/event-driven-triggers.md#alert-episode-lifecycle-triggers-event-driven). An alert trigger (`type: alert`) runs a workflow when a rule generates an alert, and only when you add the workflow to that rule as an action. Alert episode lifecycle triggers are [event-driven triggers](/explore-analyze/workflows/triggers/event-driven-triggers.md) that automatically react to alert episode events (such as an alert episode being assigned or acknowledged) in the {{alerting-v2-system}}, with no rule action to configure.
 :::
 
+## Authorization
+
+Alert-triggered runs are authorized by:
+
+* The privileges of the user who last saved the rule, by default.
+* {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` The privileges of a user-managed service account, when one is assigned to the workflow.
+
+For details, refer to [](/explore-analyze/workflows/authorization.md).
+
 ## Schema [workflows-alert-trigger-schema]
 
 | Parameter | Type | Required | Description |
diff --git a/explore-analyze/workflows/triggers/event-driven-triggers.md b/explore-analyze/workflows/triggers/event-driven-triggers.md
index 46ebfb22d10..80dfd9d5c90 100644
--- a/explore-analyze/workflows/triggers/event-driven-triggers.md
+++ b/explore-analyze/workflows/triggers/event-driven-triggers.md
@@ -23,15 +23,16 @@ Event-driven triggers let workflows react to events elsewhere in {{kib}}. The fo
 - **Alert episode lifecycle triggers** — Fire on specific alert episode events in the {{alerting-v2-system}}, such as when it is activated, assigned, acknowledged, or snoozed. {applies_to}`stack: experimental 9.5+` {applies_to}`serverless: experimental`
 - **{{alerting-v2-system-cap}} rule lifecycle triggers** — Fire when rules are created, updated, deleted, enabled, or disabled in the {{alerting-v2-system}}. {applies_to}`stack: experimental 9.5+` {applies_to}`serverless: experimental`
 
-By default, event-driven workflows run with the privileges of the user whose action produced the event. Workflows triggered by `workflows.failed` use the same privileges as the failed workflow.
+## Authorization
 
-:::{note}
-:applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
-If you assign a service account to the workflow, it runs with that account's privileges instead. For details, refer to [Workflow authorization](/explore-analyze/workflows/authorization.md).
-:::
+Event-driven runs are authorized by:
 
-:::{include} ../_snippets/schema-location-legend.md
-:::
+* The privileges of the user whose action produced the event, by default.
+* {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` The privileges of a user-managed service account, when one is assigned to the workflow.
+
+Without an assigned service account, runs triggered by `workflows.failed` use the same privileges as the failed workflow.
+
+For details, refer to [](/explore-analyze/workflows/authorization.md).
 
 ## `workflows.failed`
 
@@ -39,6 +40,9 @@ Fires when any workflow execution reaches the `failed` terminal state. Use this
 
 ### Schema
 
+:::{include} ../_snippets/schema-location-legend.md
+:::
+
 | Parameter | Location | Type | Required | Description |
 |---|---|---|---|---|
 | `type` | top level | string | Yes | Must be `workflows.failed`. |

From d5aca8e7074f6cc40539083bce4d50c091a2a401 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Wed, 28 Oct 2026 14:40:19 +0100
Subject: [PATCH 22/45] Place service account assignment link in access table

AI-Assisted: Codex
---
 explore-analyze/workflows/get-started/setup.md | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/explore-analyze/workflows/get-started/setup.md b/explore-analyze/workflows/get-started/setup.md
index ce21320cff6..bb58c08329b 100644
--- a/explore-analyze/workflows/get-started/setup.md
+++ b/explore-analyze/workflows/get-started/setup.md
@@ -51,11 +51,9 @@ Access to workflows is controlled by [{{kib}} privileges](/deploy-manage/users-r
 | Access the **Workflows** page | `All` or `Read` for **Analytics → Workflows** |
 | Fully manage workflows | `All` for **Analytics → Workflows** |
 | Grant access to specific workflow actions | [Set sub-feature privileges](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md#kibana-privileges-workflows-subfeatures) for **Analytics → Workflows** |
-| Add, change, or remove a service account assignment {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` | The **Update** Workflows privilege and the `manage_security` cluster privilege |
+| Add, change, or remove a [service account assignment](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md#assign-workflow-service-account) {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` | The **Update** Workflows privilege and the `manage_security` cluster privilege |
 | Edit or delete a workflow assigned to a service account {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` | The corresponding Workflows privilege and the `manage_security` cluster privilege |
 
-For details about assigning accounts and the permissions model, refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
-
 ## Show managed workflows [workflows-managed-visibility]
 
 ```{applies_to}

From 38a29aa80cdbbc0721eb11b4bdf5c5fd6ddac8f8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Wed, 28 Oct 2026 14:54:13 +0100
Subject: [PATCH 23/45] Clarify child workflow identity by service account
 assignment

AI-Assisted: Codex
---
 explore-analyze/workflows/authorization.md | 14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/explore-analyze/workflows/authorization.md b/explore-analyze/workflows/authorization.md
index 257a22c41cd..d310d8325f3 100644
--- a/explore-analyze/workflows/authorization.md
+++ b/explore-analyze/workflows/authorization.md
@@ -56,16 +56,12 @@ The **Created By** filter on the **Workflows** page reflects who last saved the
 
 ### Execution identity in child workflows [workflows-authorization-child-identity]
 
-For workflows composed with [`workflow.execute`](/explore-analyze/workflows/steps/composition.md#workflow-execute), the execution identity depends on service account support:
+A workflow can call a child workflow with [`workflow.execute`](/explore-analyze/workflows/steps/composition.md#workflow-execute). By default, the child's execution identity depends on whether either workflow is assigned a service account:
 
-::::{applies-switch}
-:::{applies-item} stack: ga 9.6+
-Each saved workflow uses its own service account assignment. A child doesn't automatically inherit its parent's assignment. If the child isn't assigned a service account, it uses the original caller's identity. When neither workflow is assigned a service account, the child uses the same execution identity as the parent.
-:::
-:::{applies-item} { stack: 'ga 9.4-9.5, preview =9.3', serverless: ga }
-The child execution runs with the same execution identity as the parent. The **Executions** tab doesn't visually indicate this inheritance.
-:::
-::::
+* **Neither workflow is assigned a service account.** The child runs with the same execution identity as the parent.
+* {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` **A service account is assigned to at least one workflow.** When the child has a service account assignment, it uses that account's privileges. The child doesn't automatically inherit the parent's service account. If only the parent is assigned a service account, the child uses the identity associated with the [parent run's trigger](#workflows-authorization-user). For example, if a user manually starts the parent, the child uses that user's privileges even when the parent runs as a service account.
+
+{applies_to}`stack: ga 9.4-9.5, preview =9.3` {applies_to}`serverless: ga` The **Executions** tab doesn't visually indicate when a child inherits its parent's execution identity.
 
 ## How steps use the execution identity [workflows-authorization-scope]
 

From f503b77f146bddb9b1c5728833f24595d954dc67 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Wed, 28 Oct 2026 14:56:43 +0100
Subject: [PATCH 24/45] Simplify child workflow authorization explanation

AI-Assisted: Codex
---
 explore-analyze/workflows/authorization.md | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/explore-analyze/workflows/authorization.md b/explore-analyze/workflows/authorization.md
index d310d8325f3..fe16025ef90 100644
--- a/explore-analyze/workflows/authorization.md
+++ b/explore-analyze/workflows/authorization.md
@@ -56,12 +56,9 @@ The **Created By** filter on the **Workflows** page reflects who last saved the
 
 ### Execution identity in child workflows [workflows-authorization-child-identity]
 
-A workflow can call a child workflow with [`workflow.execute`](/explore-analyze/workflows/steps/composition.md#workflow-execute). By default, the child's execution identity depends on whether either workflow is assigned a service account:
+A workflow can call a child workflow with [`workflow.execute`](/explore-analyze/workflows/steps/composition.md#workflow-execute). When neither workflow is assigned a service account, the child runs with the same execution identity as the parent.
 
-* **Neither workflow is assigned a service account.** The child runs with the same execution identity as the parent.
-* {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` **A service account is assigned to at least one workflow.** When the child has a service account assignment, it uses that account's privileges. The child doesn't automatically inherit the parent's service account. If only the parent is assigned a service account, the child uses the identity associated with the [parent run's trigger](#workflows-authorization-user). For example, if a user manually starts the parent, the child uses that user's privileges even when the parent runs as a service account.
-
-{applies_to}`stack: ga 9.4-9.5, preview =9.3` {applies_to}`serverless: ga` The **Executions** tab doesn't visually indicate when a child inherits its parent's execution identity.
+{applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` When service accounts are involved, each workflow uses its own assignment by default. A child doesn't automatically inherit its parent's service account. If only the parent is assigned a service account, the child uses the identity associated with the [parent run's trigger](#workflows-authorization-user). For example, if a user manually starts the parent, the child uses that user's privileges even when the parent runs as a service account.
 
 ## How steps use the execution identity [workflows-authorization-scope]
 

From eaf701e5484a9b033318a54653540ef799aa1b1f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Wed, 28 Oct 2026 15:01:45 +0100
Subject: [PATCH 25/45] Improve introduction to running workflows as service
 accounts

AI-Assisted: Codex
---
 .../authoring-techniques/run-workflow-as-service-account.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md b/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
index 43b2762dfb5..9f69d7bcbb6 100644
--- a/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
+++ b/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
@@ -14,11 +14,11 @@ products:
 
 # Run a workflow as a service account [run-workflow-as-service-account]
 
-Starting with {{stack}} 9.6, you can run a workflow as a [user-managed service account](/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md#user-managed-service-accounts).
+By default, workflows run with a user's privileges. As an alternative, you can run a workflow as a [user-managed service account](/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md#user-managed-service-accounts).
 
-Each run uses the account's roles, regardless of who starts or last edits the workflow. This is useful for shared workflows: their identity remains stable even if the person who created them leaves your organization. You can also give the account only the privileges the workflow needs, even if the people who manage it have broader access.
+The workflow then uses the account's roles for every run, regardless of who starts or last edits it. This gives shared workflows a stable identity, even if their creator leaves your organization. You can also give the account only the privileges the workflow needs, even if the people who manage it have broader access.
 
-This guide shows you how to assign a service account to a workflow and verify which identity its runs use.
+This guide shows you how to assign a service account to a workflow and verify its execution identity.
 
 ## Before you begin [run-workflow-as-service-account-prerequisites]
 

From 84e94fadbb0feb2713bff229ab4e7ed9833b8e81 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Wed, 28 Oct 2026 15:07:14 +0100
Subject: [PATCH 26/45] Simplify service account authentication overview

AI-Assisted: Codex
---
 .../token-based-authentication-services.md    | 23 +++++++------------
 1 file changed, 8 insertions(+), 15 deletions(-)

diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/token-based-authentication-services.md b/deploy-manage/users-roles/cluster-or-deployment-auth/token-based-authentication-services.md
index 854a1896fd3..5ac20a3d3fc 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/token-based-authentication-services.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/token-based-authentication-services.md
@@ -16,23 +16,16 @@ The {{security-features}} provide the following built-in token-based authenticat
 *service-accounts*
 :   [Service accounts](service-accounts.md) use service tokens to authenticate as non-human identities. For details about token creation, storage, and deletion, refer to [Service account tokens](service-accounts.md#service-accounts-tokens).
 
-    :::{note}
-    :applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
-    [User-managed service accounts](service-accounts.md#user-managed-service-accounts) can authenticate requests to {{es}} and {{kib}}.
-    :::
-
-To use a service account token, include the generated token value in a request with an `Authorization: Bearer` header:
-
-```shell
-curl -H "Authorization: Bearer AAEAAWVsYXN0aWMvZ...mXQtc2VydmMTpyNXdkYmRib1FTZTl2R09Ld2FKR0F3" \
-  "$ELASTICSEARCH_URL/_cluster/health"
-```
-
-::::{important}
-Don't use service accounts to authenticate individual users. Service tokens and credentials derived from them are for software and workloads, not people.
-::::
+    To use a service account token, include the generated token value in a request with an `Authorization: Bearer` header:
 
+    ```shell
+    curl -H "Authorization: Bearer AAEAAWVsYXN0aWMvZ...mXQtc2VydmMTpyNXdkYmRib1FTZTl2R09Ld2FKR0F3" \
+      "$ELASTICSEARCH_URL/_cluster/health"
+    ```
 
+    ::::{important}
+    Don't use service accounts to authenticate individual users. Service tokens and credentials derived from them are for software and workloads, not people.
+    ::::
 
 $$$token-authentication-access-token$$$
 

From 2343ddbbfc992ccd86032334472fde81be70cfc2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Wed, 28 Oct 2026 17:02:54 +0100
Subject: [PATCH 27/45] service token update

---
 .../authenticate-kibana-api-with-service-account.md             | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md b/deploy-manage/users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md
index 6c453f26588..e1a290413a6 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md
@@ -24,7 +24,7 @@ Before you create a service token, make sure you have the following:
 - You need an existing user-managed service account. If you don't have one, [create a service account in {{kib}}](manage-service-accounts-in-kibana.md#create-service-account-kibana).
 - You need the `manage_security` cluster privilege to create a service token for a user-managed account. The `manage_service_account` privilege permits token management only for built-in accounts in the `elastic` namespace.
 
-## Create a token for your application [create-service-account-api-token]
+## Create a service token for your application [create-service-account-api-token]
 
 {{kib}} creates and stores a credential when you create an account in the UI. That credential is used for workload integrations and isn't displayed. For your application, create an additional service token. The following example uses an existing account with the principal `kibana/automation-client`:
 

From 76523f9241651822fc6487acb3b9b3869fab2960 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Wed, 28 Oct 2026 17:12:32 +0100
Subject: [PATCH 28/45] Clarify execution identity in workflow trigger
 monitoring

AI-Assisted: Codex
---
 .../workflows/authoring-techniques/monitor-workflows.md    | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/explore-analyze/workflows/authoring-techniques/monitor-workflows.md b/explore-analyze/workflows/authoring-techniques/monitor-workflows.md
index 4c373984a73..49c199cf676 100644
--- a/explore-analyze/workflows/authoring-techniques/monitor-workflows.md
+++ b/explore-analyze/workflows/authoring-techniques/monitor-workflows.md
@@ -48,11 +48,6 @@ When a workflow runs, the execution panel displays:
 - **Timestamps**: The duration of each step.
 - **Expandable details**: Click any step to examine details such as input parameters, output data, and execution timelines.
 
-:::{note}
-:applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
-For a workflow assigned to a service account, **Triggered by** identifies the user who starts the workflow or last saved it, depending on the trigger. **Run as** identifies the service account used for authorization. Refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
-:::
-
 ## See what triggered a run [workflows-execution-trigger-source]
 
 ```{applies_to}
@@ -62,6 +57,8 @@ serverless: ga
 
 Every execution begins with a trigger entry that shows how the run started, such as a manual run, a schedule, an alert, or an event. Expand this entry to see the input the workflow received, including the full event payload for [event-driven](/explore-analyze/workflows/triggers/event-driven-triggers.md) runs. This lets you trace an execution back to the event or action that started it, which is especially useful when workflows react to one another through event-driven triggers.
 
+{applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` For workflows assigned to a service account, **Triggered by** identifies the user associated with the run, and **Run as** identifies the account used for authorization. For details, refer to [](/explore-analyze/workflows/authorization.md#workflows-authorization-audit).
+
 ## View execution history [workflows-execution-history]
 
 To review past runs, select the **Executions** tab, then select each run to see detailed logs. Workflow runs can have the following statuses:

From 89a31e43dcd6a7552963131a4ba2bd0783f5d680 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Wed, 28 Oct 2026 17:34:04 +0100
Subject: [PATCH 29/45] manage SA in kibana intro updated

---
 .../manage-service-accounts-in-kibana.md                        | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md b/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
index 8bc831188b8..2bed5db508d 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
@@ -15,7 +15,7 @@ products:
 
 # Create and manage service accounts in {{kib}} [manage-service-accounts-kibana]
 
-Create user-managed service accounts and assign roles to control programmatic access to {{es}} and {{kib}} APIs. {{kib}} creates each account in {{es}} and securely stores its credential.
+Create user-managed service accounts and assign roles to control programmatic access to {{es}} and {{kib}} APIs.
 
 ## Before you begin [manage-service-accounts-before-you-begin]
 

From 5bba3b46ae4ec98e9fde9501a4435d92b976f80f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Thu, 29 Oct 2026 09:51:33 +0100
Subject: [PATCH 30/45] Make workflow authorization conditions explicit

AI-Assisted: Codex
---
 explore-analyze/workflows/authorization.md                | 6 +++---
 explore-analyze/workflows/triggers/alert-triggers.md      | 6 +++---
 .../workflows/triggers/event-driven-triggers.md           | 8 +++-----
 explore-analyze/workflows/triggers/manual-triggers.md     | 6 +++---
 explore-analyze/workflows/triggers/scheduled-triggers.md  | 6 +++---
 5 files changed, 15 insertions(+), 17 deletions(-)

diff --git a/explore-analyze/workflows/authorization.md b/explore-analyze/workflows/authorization.md
index fe16025ef90..50fff29bfcb 100644
--- a/explore-analyze/workflows/authorization.md
+++ b/explore-analyze/workflows/authorization.md
@@ -15,10 +15,10 @@ products:
 
 # Workflow authorization [workflows-authorization]
 
-Every workflow run is authorized by:
+The privileges used to authorize a workflow run depend on whether the workflow has an assigned service account:
 
-* A specific user's privileges, by default.
-* {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` The privileges of a user-managed service account, when one is assigned to the workflow.
+* **No service account assigned (default):** The run uses a user's privileges, determined by how the workflow starts.
+* {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` **Service account assigned:** The run uses the privileges of that account.
 
 Use this page to configure who runs your workflows, diagnose privileges errors, and keep your workflows' access current.
 
diff --git a/explore-analyze/workflows/triggers/alert-triggers.md b/explore-analyze/workflows/triggers/alert-triggers.md
index ef190e7959c..50a876d0c4a 100644
--- a/explore-analyze/workflows/triggers/alert-triggers.md
+++ b/explore-analyze/workflows/triggers/alert-triggers.md
@@ -26,10 +26,10 @@ Declaring `type: alert` on a workflow isn't enough to run the workflow when aler
 
 ## Authorization
 
-Alert-triggered runs are authorized by:
+The privileges used for each alert-triggered run depend on whether the workflow has an assigned service account:
 
-* The privileges of the user who last saved the rule, by default.
-* {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` The privileges of a user-managed service account, when one is assigned to the workflow.
+* **No service account assigned (default):** The run uses the privileges of the user who last saved the rule.
+* {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` **Service account assigned:** The run uses the privileges of that account.
 
 For details, refer to [](/explore-analyze/workflows/authorization.md).
 
diff --git a/explore-analyze/workflows/triggers/event-driven-triggers.md b/explore-analyze/workflows/triggers/event-driven-triggers.md
index 8c988fdf772..dc8f8c04e98 100644
--- a/explore-analyze/workflows/triggers/event-driven-triggers.md
+++ b/explore-analyze/workflows/triggers/event-driven-triggers.md
@@ -25,12 +25,10 @@ Event-driven triggers let workflows react to events elsewhere in {{kib}}. The fo
 
 ## Authorization
 
-Event-driven runs are authorized by:
+The privileges used for each event-driven run depend on whether the workflow has an assigned service account:
 
-* The privileges of the user whose action produced the event, by default.
-* {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` The privileges of a user-managed service account, when one is assigned to the workflow.
-
-Without an assigned service account, runs triggered by `workflows.failed` use the same privileges as the failed workflow.
+* **No service account assigned (default):** The run uses the privileges of the user whose action produced the event. For `workflows.failed`, it uses the same privileges as the failed workflow.
+* {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` **Service account assigned:** The run uses the privileges of that account.
 
 For details, refer to [](/explore-analyze/workflows/authorization.md).
 
diff --git a/explore-analyze/workflows/triggers/manual-triggers.md b/explore-analyze/workflows/triggers/manual-triggers.md
index 35d22e7e71c..2f538f3dcf7 100644
--- a/explore-analyze/workflows/triggers/manual-triggers.md
+++ b/explore-analyze/workflows/triggers/manual-triggers.md
@@ -30,10 +30,10 @@ This allows you to run a workflow manually by:
 
 ## Authorization
 
-Manual runs are authorized by:
+The privileges used for each manual run depend on whether the workflow has an assigned service account:
 
-* The privileges of the user who starts the run, by default.
-* {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` The privileges of a user-managed service account, when one is assigned to the workflow.
+* **No service account assigned (default):** The run uses the privileges of the user who starts it.
+* {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` **Service account assigned:** The run uses the privileges of that account.
 
 For details, refer to [](/explore-analyze/workflows/authorization.md).
 
diff --git a/explore-analyze/workflows/triggers/scheduled-triggers.md b/explore-analyze/workflows/triggers/scheduled-triggers.md
index 5eb066a513a..d5e1510325e 100644
--- a/explore-analyze/workflows/triggers/scheduled-triggers.md
+++ b/explore-analyze/workflows/triggers/scheduled-triggers.md
@@ -23,10 +23,10 @@ You can configure scheduled triggers using:
 
 ## Authorization
 
-Scheduled runs are authorized by:
+The privileges used for each scheduled run depend on whether the workflow has an assigned service account:
 
-* The privileges of the user who last saved the workflow, by default.
-* {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` The privileges of a user-managed service account, when one is assigned to the workflow.
+* **No service account assigned (default):** The run uses the privileges of the user who last saved the workflow.
+* {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` **Service account assigned:** The run uses the privileges of that account.
 
 For details, refer to [](/explore-analyze/workflows/authorization.md).
 

From 8e3bbca7fb0c0a91ab110b9ed4cf07cde090c22c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Thu, 29 Oct 2026 10:31:57 +0100
Subject: [PATCH 31/45] Clarify Triggered by identity and execution context
 fields

AI-Assisted: Codex
---
 .../workflows/authoring-techniques/monitor-workflows.md     | 2 +-
 .../authoring-techniques/run-workflow-as-service-account.md | 4 ++--
 explore-analyze/workflows/authorization.md                  | 2 +-
 explore-analyze/workflows/reference/context-variables.md    | 6 +++++-
 4 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/explore-analyze/workflows/authoring-techniques/monitor-workflows.md b/explore-analyze/workflows/authoring-techniques/monitor-workflows.md
index 49c199cf676..f372f49d6f9 100644
--- a/explore-analyze/workflows/authoring-techniques/monitor-workflows.md
+++ b/explore-analyze/workflows/authoring-techniques/monitor-workflows.md
@@ -57,7 +57,7 @@ serverless: ga
 
 Every execution begins with a trigger entry that shows how the run started, such as a manual run, a schedule, an alert, or an event. Expand this entry to see the input the workflow received, including the full event payload for [event-driven](/explore-analyze/workflows/triggers/event-driven-triggers.md) runs. This lets you trace an execution back to the event or action that started it, which is especially useful when workflows react to one another through event-driven triggers.
 
-{applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` For workflows assigned to a service account, **Triggered by** identifies the user associated with the run, and **Run as** identifies the account used for authorization. For details, refer to [](/explore-analyze/workflows/authorization.md#workflows-authorization-audit).
+{applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` For workflows assigned to a service account, **Triggered by** shows the identity associated with the start of the run, which can be a user or a service account. **Run as** shows the assigned service account used for authorization. For details, refer to [](/explore-analyze/workflows/authorization.md#workflows-authorization-audit).
 
 ## View execution history [workflows-execution-history]
 
diff --git a/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md b/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
index 9f69d7bcbb6..203f6dc8926 100644
--- a/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
+++ b/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
@@ -56,8 +56,8 @@ The saved assignment applies to manual, scheduled, alert, and event-driven runs.
 
 After the test completes, open its execution details. The overview identifies both identities:
 
-- **Triggered by** identifies the user who starts the workflow or last saved it, depending on the trigger.
-- **Run as** is the service account whose privileges authorized the workflow's actions.
+- **Triggered by** shows the identity associated with the start of the run, which can be a user or a service account.
+- **Run as** shows the assigned service account whose privileges authorize the workflow's actions.
 
 Steps that call {{es}} or {{kib}} (`elasticsearch.*` and `kibana.*`) use the service account's privileges. {{connectors-ui}} use their own stored credentials to authenticate to external systems. For details about credentials and child workflows, refer to [Workflow authorization](/explore-analyze/workflows/authorization.md).
 
diff --git a/explore-analyze/workflows/authorization.md b/explore-analyze/workflows/authorization.md
index 50fff29bfcb..9ef6cb4a49d 100644
--- a/explore-analyze/workflows/authorization.md
+++ b/explore-analyze/workflows/authorization.md
@@ -50,7 +50,7 @@ If the account is deleted, turned off, or lacks a required privilege, the run fa
 
 When a workflow run starts, {{kib}} records the execution identity so you can audit which privileges it used. Refer to [](/explore-analyze/workflows/reference/context-variables.md#workflows-ctx-execution) for execution context variables.
 
-{applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` For workflows assigned to service accounts, **Triggered by** identifies the user who starts the workflow or last saved it, depending on the trigger. **Run as** shows the service account used for authorization.
+{applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` For workflows assigned to service accounts, **Triggered by** shows the identity associated with the start of the run. This can be a user or a service account. **Run as** shows the assigned service account whose privileges authorize the workflow's actions.
 
 The **Created By** filter on the **Workflows** page reflects who last saved the workflow, not necessarily who originally created it.
 
diff --git a/explore-analyze/workflows/reference/context-variables.md b/explore-analyze/workflows/reference/context-variables.md
index d5d694407c9..d00562c34a8 100644
--- a/explore-analyze/workflows/reference/context-variables.md
+++ b/explore-analyze/workflows/reference/context-variables.md
@@ -124,7 +124,7 @@ Metadata about the current workflow execution.
 | `execution.id` | Execution ID. |
 | `execution.startedAt` | ISO timestamp of start. |
 | `execution.isTestRun` | `true` if run from the editor's **Test** button. |
-| `execution.executedBy` | UID of the user or system that invoked the workflow. |
+| `execution.executedBy` | Identifier of the user or service account associated with the run. |
 | `execution.effectiveIdentity.type` {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` | Identity type. Set to `service_account` when the workflow runs as a user-managed service account. |
 | `execution.effectiveIdentity.id` {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` | ID of the user-managed service account that authorizes the workflow. |
 | `execution.triggeredBy` | Which trigger initiated this execution (`manual`, `scheduled`, `alert`, `workflows.failed`). |
@@ -132,6 +132,10 @@ Metadata about the current workflow execution.
 | `execution.compositionDepth` | 0 for a top-level invocation. Increments by 1 for each [`workflow.execute`](/explore-analyze/workflows/steps/composition.md#workflow-execute) level. |
 | `execution.parentWorkflowId` | ID of the parent workflow, if this is a composed child execution. |
 
+:::{note}
+In {{kib}} execution details, the **Triggered by** field displays `execution.executedBy`. The `execution.triggeredBy` variable identifies the trigger type.
+:::
+
 For how each trigger type determines `execution.executedBy`, refer to [Workflow authorization](/explore-analyze/workflows/authorization.md).
 
 ```yaml

From 71d906022d3129e3a0af60b94bd64681cd1490a1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Mon, 2 Nov 2026 10:48:42 +0100
Subject: [PATCH 32/45] Clarify workflow service account update requirements

Co-authored-by: Cursor <cursoragent@cursor.com>
---
 .../workflows/authoring-techniques/manage-workflows.md     | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/explore-analyze/workflows/authoring-techniques/manage-workflows.md b/explore-analyze/workflows/authoring-techniques/manage-workflows.md
index ea291d015e0..5b2479dd2be 100644
--- a/explore-analyze/workflows/authoring-techniques/manage-workflows.md
+++ b/explore-analyze/workflows/authoring-techniques/manage-workflows.md
@@ -20,6 +20,8 @@ The **Workflows** page allows you to view and manage all your workflows. From th
 ::::{admonition} Requirements
 To use workflows, you must turn on the feature and ensure your role has the appropriate privileges. Refer to [](/explore-analyze/workflows/get-started/setup.md) for more information.
 
+{applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` Updating or deleting a workflow [assigned to a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md) also requires the `manage_security` cluster privilege.
+
 You must also have the appropriate subscription. Refer to the subscription page for [Elastic Cloud](https://www.elastic.co/subscriptions/cloud) and [Elastic Stack/self-managed](https://www.elastic.co/subscriptions) for the breakdown of available features and their associated subscription tiers.
 ::::
 
@@ -45,11 +47,6 @@ To instantly run a workflow, click the **Run** icon {icon}`play` for a workflow,
 
 Click the **Edit** icon to open the workflow in the YAML editor. Alternatively, open the **All actions** menu ({icon}`boxes_vertical`), and click **Edit**.
 
-:::{important}
-:applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
-Editing a workflow [assigned to a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md) also requires the `manage_security` cluster privilege. An editor can change what the account does, so grant edit access only to users you trust to use its privileges.
-:::
-
 ### Turn a workflow on or off [workflow-enable-disable]
 
 Use the **Enabled** toggle to control whether a workflow can run:

From 8660753a6500c27067d916d23e2b0e3547adf850 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Thu, 5 Nov 2026 16:06:47 +0100
Subject: [PATCH 33/45] Document Serverless support for user-managed service
 accounts

AI-Assisted: Codex
---
 .../deploy/elastic-cloud/serverless-faq.md    |  2 +-
 .../kibana-privileges.md                      |  2 +-
 .../manage-service-accounts-in-kibana.md      | 81 ++++++++++++++-----
 .../service-accounts.md                       | 58 ++++++++-----
 .../workflows/authoring-techniques.md         |  2 +-
 .../workflows/authoring-techniques/anatomy.md |  6 +-
 .../authoring-techniques/manage-workflows.md  |  2 +-
 .../authoring-techniques/monitor-workflows.md |  2 +-
 .../run-workflow-as-service-account.md        | 21 +++--
 .../authoring-techniques/settings.md          | 11 +--
 explore-analyze/workflows/authorization.md    | 17 ++--
 .../workflows/get-started/setup.md            |  4 +-
 .../workflows/reference/context-variables.md  |  4 +-
 .../workflows/triggers/alert-triggers.md      |  2 +-
 .../triggers/event-driven-triggers.md         |  2 +-
 .../workflows/triggers/manual-triggers.md     |  2 +-
 .../workflows/triggers/scheduled-triggers.md  |  2 +-
 17 files changed, 145 insertions(+), 75 deletions(-)

diff --git a/deploy-manage/deploy/elastic-cloud/serverless-faq.md b/deploy-manage/deploy/elastic-cloud/serverless-faq.md
index 252c068b591..e38e221a743 100644
--- a/deploy-manage/deploy/elastic-cloud/serverless-faq.md
+++ b/deploy-manage/deploy/elastic-cloud/serverless-faq.md
@@ -33,7 +33,7 @@ User-initiated data recovery is anticipated in a future release. You can follow
 ## Security, compliance, and access
 
 **Q: How can I create {{serverless-full}} service accounts?**<br>
-A: User-managed service accounts aren't available on {{serverless-short}}. To authenticate applications and automated processes, create a project API key. You can create project API keys in {{kib}}, with the {{es}} API, or as code with Terraform. Refer to [](/deploy-manage/api-keys/serverless-project-api-keys.md) for details.
+A: You can [create user-managed service accounts in {{kib}}](/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md#create-service-account-kibana) for use within {{kib}} applications, such as [Workflows](/explore-analyze/workflows.md). For programmatic access from external applications, use [API keys](/deploy-manage/api-keys.md).
 
 **Q: Can I configure {{es}} authentication realms (for example, native realm) in {{serverless-short}} projects?**  
 A: No. {{serverless-short}} uses a different authentication model and does not support [{{es}} authentication realms](/deploy-manage/users-roles/cluster-or-deployment-auth/authentication-realms.md). Project-level access is handled through [Serverless project API keys](/deploy-manage/api-keys/serverless-project-api-keys.md), and user authentication is managed at the [{{ecloud}} organization level](/deploy-manage/users-roles/cloud-organization.md) (including SAML SSO).
diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md b/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md
index a5dc567352f..023ed35e67d 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md
@@ -225,7 +225,7 @@ These privileges control specific actions on workflows. Selecting **All** includ
 :::
 
 :::{warning}
-:applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
+:applies_to: {"stack": "ga 9.6+", "serverless": "ga"}
 When you edit a workflow that runs as a service account, subsequent runs continue to use that account's privileges. Your changes can therefore use privileges you don't personally have. Grant workflow edit access only to users you trust to use those privileges.
 
 Adding, changing, or removing a service account assignment, and editing or deleting a workflow assigned to a service account, also require the `manage_security` cluster privilege. For account assignment instructions and required privileges, refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md b/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
index 2bed5db508d..ccece35730c 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
@@ -2,11 +2,12 @@
 navigation_title: Manage service accounts
 applies_to:
   stack: ga 9.6+
-  serverless: unavailable
+  serverless: ga
 description: Create, review, take out of service, and delete user-managed service accounts for Kibana workloads.
 products:
   - id: kibana
   - id: elasticsearch
+  - id: cloud-serverless
   - id: cloud-hosted
   - id: cloud-enterprise
   - id: cloud-kubernetes
@@ -15,17 +16,24 @@ products:
 
 # Create and manage service accounts in {{kib}} [manage-service-accounts-kibana]
 
-Create user-managed service accounts and assign roles to control programmatic access to {{es}} and {{kib}} APIs.
+Create user-managed service accounts and assign roles to control programmatic access to {{es}} and {{kib}} APIs. Accounts created in {{kib}} are ready to use with applications such as [Workflows](/explore-analyze/workflows.md), and {{kib}} automatically manages the credentials needed to run workloads as those accounts.
+
+Some service account capabilities differ between [{{serverless-full}}](/deploy-manage/deploy/elastic-cloud/serverless.md) and other [deployment types](/deploy-manage/deploy.md#choosing-your-deployment-type). This guide uses {{stack}} deployments to refer to {{ech}}, {{ece}}, {{eck}}, and self-managed deployments.
+
+:::{note}
+:applies_to: serverless: ga
+On {{serverless-short}}, user-managed service accounts can only be used within {{kib}} applications. For programmatic access from external applications, use [API keys](/deploy-manage/api-keys.md).
+:::
+
+{applies_to}`serverless: unavailable` You can also create service accounts for external applications through the [{{es}} API]({{es-apis}}operation/operation-security-put-user-managed-service-account), although accounts created this way can't be assigned to workloads in {{kib}} applications.
 
 ## Before you begin [manage-service-accounts-before-you-begin]
 
 Before you create or manage service accounts, check these requirements:
 
-- You need the `manage_security` cluster privilege. Without it, the **Service accounts** page isn't available. The `manage_service_account` privilege applies only to built-in accounts in the `elastic` namespace.
+- Sign in to {{kib}} as a user with the `manage_security` cluster privilege. Without it, the **Service accounts** page isn't available.
 - {applies_to}`self: ga` Set [`xpack.encryptedSavedObjects.encryptionKey`](kibana://reference/configuration-reference/security-settings.md#xpack-encryptedsavedobjects-encryptionkey) in `kibana.yml`. {{kib}} uses this key to encrypt the stored credential.
-
-% TBD: pending to add link to the setting reference as soon as the kibana PR is created and merged
-Service accounts are enabled by default on {{ech}}, {{ece}}, {{eck}}, and self-managed deployments. Set the {{kib}} `xpack.security.serviceAccounts.enabled` setting to `false` to turn off the **Service accounts** page and workload integration.
+- On {{stack}} deployments, make sure service accounts are enabled in {{kib}}. They're enabled by default. If they've been turned off, set [`xpack.security.serviceAccounts.enabled`](kibana://reference/configuration-reference/security-settings.md#service-account-settings) to `true` before continuing.
 
 ## Create a service account [create-service-account-kibana]
 
@@ -35,12 +43,32 @@ Create a service account with the roles your workloads need:
 2. Click **Create account**.
 3. In the **Name** field, enter a unique name of up to 128 characters. The name must start with a letter or number and can contain letters, numbers, hyphens, and underscores.
 4. Optional: In the **Description** field, describe what the account is used for.
-5. Under **Set privileges**, select one or more predefined or custom roles that grant the privileges the account needs. To [create a role](kibana-role-management.md), click **Create new role**.
+5. Under **Set privileges**, select one or more predefined or custom roles that grant the privileges the account needs. To create a role, click **Create new role**.
+
+    For details on predefined roles and how to create custom roles, refer to:
+
+    - {{stack}} deployments: [Built-in roles](elasticsearch://reference/elasticsearch/roles.md) and [role management in {{kib}}](kibana-role-management.md).
+    - {{serverless-short}} projects: [Predefined roles](/deploy-manage/users-roles/cloud-organization/user-roles.md#general-assign-user-roles-table) and [custom roles](/deploy-manage/users-roles/serverless-custom-roles.md).
+
 6. Review the selected roles, and click **Create account**.
+7. Confirm that the account appears in the **Service accounts** table with the roles you selected. On {{stack}} deployments, the account uses the principal `kibana/<name>`.
+
+Your service account is now ready to use in {{kib}} applications such as [Workflows](/explore-analyze/workflows.md). {{kib}} manages the credential for you. You don't need to copy a secret, and no token is displayed.
+
+{applies_to}`serverless: unavailable` To use the account from an external API client, [create a separate named service token](authenticate-kibana-api-with-service-account.md#create-service-account-api-token).
+
+### Roles and privileges in {{serverless-short}} [service-account-serverless-roles]
+```{applies_to}
+serverless: ga
+```
 
-The service account uses the principal `kibana/<name>`. For workloads such as workflows, rules, and scheduled tasks, {{kib}} creates and securely stores the credential for you. You don't need to copy a secret, and no token is displayed. To use the account from an external API client, [create a separate named service token](authenticate-kibana-api-with-service-account.md#create-service-account-api-token).
+A service account can have up to 50 roles. Its privileges come from its assigned roles and cannot exceed the access its creator had when the account was created.
 
-{{es}} resolves the assigned roles by name whenever the account authenticates. Editing a role changes the privileges it grants to the account. Deleting a role stops that role from granting privileges.
+Roles reserved for internal use by [{{alerting-v2-system}}](/explore-analyze/alerting/esql/system-overview.md) aren't available in the role picker.
+
+When a workload uses [cross-project search](/explore-analyze/cross-project-search.md), its service account's predefined roles apply across linked projects. For a custom role to grant access to a linked project, that project must define a role with the same name. Custom roles aren't copied between projects.
+
+% Pending confirmation from Larry: determine whether role assignment is restricted when linked projects have different project types. No restriction was found in the code reviewed.
 
 ## Review service accounts [review-service-accounts-kibana]
 
@@ -48,17 +76,22 @@ The **Service accounts** table shows each account's name, description, roles, cr
 
 When an account has bound workloads, click **View** in the **Workloads** column to review them.
 
-Accounts created directly through the [{{es}} API]({{es-apis}}operation/operation-security-put-user-managed-service-account) also appear in the table.
+{applies_to}`serverless: unavailable` Accounts created directly through the [{{es}} API]({{es-apis}}operation/operation-security-put-user-managed-service-account) also appear in the table, but don't have associated {{kib}} workloads.
 
-:::{important}
-Don't create service accounts directly through the {{es}} API if you plan to use them with {{kib}} applications such as Workflows. Create them in {{kib}} so it can generate and securely store the credential needed to run workloads as the account.
-:::
+## Update a service account [update-service-account-kibana]
+
+You can't update service accounts in the {{kib}} UI. On {{serverless-short}}, to change an account's assigned roles or description, [delete the account](#delete-service-account-kibana) and [create a new one](#create-service-account-kibana). On {{stack}} deployments, you can update accounts through the {{es}} API.
 
-You can't edit an account on this page. To change its roles or description, [update the account through the {{es}} API](#disable-service-account), or delete the account and create another one.
+:::{tip}
+To change a service account's privileges, you can edit a role already assigned to it without changing the account's role assignments. Changes to a role also affect other users and service accounts assigned that role.
+:::
 
-## Update or deactivate a service account [disable-service-account]
+### Update or deactivate an account through the {{es}} API [disable-service-account]
+```{applies_to}
+serverless: unavailable
+```
 
-Use the [create or replace user-managed service account API]({{es-apis}}operation/operation-security-put-user-managed-service-account) to update an account's roles or description, or to deactivate it by setting `enabled` to `false`. These actions aren't available in the {{kib}} UI.
+Use the [create or replace user-managed service account API]({{es-apis}}operation/operation-security-put-user-managed-service-account) to update an account's roles or description, or to deactivate it by setting `enabled` to `false`.
 
 The PUT request replaces the complete account definition. Send the full definition, including every role, the description, and the `enabled` value you want to preserve. A role left out of the `roles` list is no longer assigned, and an omitted `description` is cleared. If you omit `enabled`, it defaults to `true`. The `roles` field itself is required.
 
@@ -81,7 +114,7 @@ To reactivate the account, send the complete definition again with `enabled` set
 
 ## Delete a service account [delete-service-account-kibana]
 
-Deleting a service account is permanent. If you only need to temporarily prevent the account from authenticating, [deactivate it](#disable-service-account) instead.
+Deleting a service account is permanent. On {{stack}} deployments, if you only need to temporarily prevent the account from authenticating, [deactivate it](#disable-service-account) instead.
 
 To delete a service account:
 
@@ -93,6 +126,18 @@ To delete a service account:
 
 If you force delete an account, workloads assigned to it fail on their next run. To restore access, assign each affected workload a valid service account. This reassignment is required even if you recreate the deleted account with the same name. For Workflows, [assign a service account to each affected workflow](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md#assign-workflow-service-account).
 
+### Credentials after deletion in {{serverless-short}} [delete-service-account-serverless-credentials]
+```{applies_to}
+serverless: ga
+```
+
+Deleting an account stops new tokens from being issued immediately. Tokens already issued remain valid until they expire, which takes a few minutes at most.
+
+### Credentials after deletion in {{stack}} deployments [delete-service-account-stack-credentials]
+```{applies_to}
+serverless: unavailable
+```
+
 Deleting an account through {{kib}} attempts to remove every service token, including the credential it stores for workloads and tokens created outside {{kib}}. It also attempts to invalidate any short-lived access tokens used to run workloads as the account. If any credential cleanup fails, {{kib}} completes the deletion and reports a warning.
 
 A service token left behind after deletion can't authenticate, but it prevents you from creating another account with the same name until you delete the token. If you delete an account directly through the {{es}} API, short-lived access tokens already issued to the account remain valid until they expire, 20 minutes after issuance by default.
@@ -106,5 +151,5 @@ API keys owned by the account aren't invalidated when you delete the account. {{
 Use these guides to work with service accounts and learn more about their credentials:
 
 - [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
-- [Authenticate to the {{kib}} API with a service account](authenticate-kibana-api-with-service-account.md).
+- {applies_to}`{serverless: unavailable}` [Authenticate to the {{kib}} API with a service account](authenticate-kibana-api-with-service-account.md).
 - Learn more about [service account types and credentials](service-accounts.md).
diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md b/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
index 02cbb043dc0..1badb5102c8 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
@@ -3,30 +3,29 @@ mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/service-accounts.html
 applies_to:
   stack: all
-  serverless: unavailable
+  serverless: ga
 description: Learn how built-in and user-managed service accounts provide non-human identities for Elastic services and workloads.
 products:
   - id: elasticsearch
   - id: kibana
+  - id: cloud-serverless
 ---
 
 # Service accounts [service-accounts]
 
 A service account is a non-human identity for a service or workload. Unlike a user, a service account isn't associated with a person and can't log in to the {{kib}} UI.
 
-Service accounts authenticate with service tokens. The account defines the identity and privileges, while the token is a credential for that identity. For example, {{fleet}} server uses a service token to authenticate with {{es}} and manage its own API keys.
-
-You can create multiple service tokens for the same service account. This lets multiple instances of a service use the same identity without sharing credentials.
+Service accounts authenticate with tokens. The account defines the identity and privileges, while the token is a credential for that identity.
 
 ::::{important}
-Don't use service accounts to authenticate individual users. Service tokens are credentials for software and workloads, not people.
+Don't use service accounts to authenticate individual users. Service account credentials are for software and workloads, not people.
 ::::
 
 $$$service-accounts-explanation$$$
 
-Each service account has a unique identifier, called a principal, in the form `<namespace>/<service>`. The `namespace` groups related accounts, and the `service` name must be unique within that namespace.
+Each service account has a unique identifier, called a principal. In {{stack}}, the principal has the form `<namespace>/<service>`. The `namespace` groups related accounts, and the `service` name must be unique within that namespace.
 
-Service accounts are not included in the response of the [get users API]({{es-apis}}operation/operation-security-get-user). To retrieve a service account, use the [get service accounts API]({{es-apis}}operation/operation-security-get-service-accounts). Use the [get service account credentials API]({{es-apis}}operation/operation-security-get-service-credentials) to retrieve all service credentials for a service account.
+On {{stack}}, service accounts are not included in the response of the [get users API]({{es-apis}}operation/operation-security-get-user). To retrieve a service account, use the [get service accounts API]({{es-apis}}operation/operation-security-get-service-accounts). Use the [get service account credentials API]({{es-apis}}operation/operation-security-get-service-credentials) to retrieve all service credentials for a service account.
 
 ## Service account types [service-account-types]
 
@@ -48,39 +47,55 @@ The following built-in accounts are available:
 
 The `elastic` namespace is reserved for built-in accounts.
 
-You can create and delete service tokens for these accounts, but you can't change their predefined privileges.
+In {{stack}}, you can create and delete service tokens for these accounts, but you can't change their predefined privileges.
 
 ### User-managed service accounts [user-managed-service-accounts]
 ```{applies_to}
 stack: ga 9.6+
+serverless: ga
 ```
 
-You create these accounts and assign roles to control their privileges. Accounts created in {{kib}} use the `kibana` namespace, and their principals have the form `kibana/<name>`.
+You create these accounts and assign roles to control their privileges. The accounts belong to the deployment on {{stack}} or to the Cloud organization on {{serverless-short}}, rather than to the user who created them. In {{stack}}, accounts created in {{kib}} use the `kibana` namespace, and their principals have the form `kibana/<name>`.
 
-Use a user-managed service account when your application needs its own identity to access {{es}} or {{kib}} APIs. Assign the roles required by the application, and authenticate its requests with a [service account token](#service-accounts-tokens).
+Use a user-managed service account when your workload needs its own identity to access {{es}} or {{kib}} APIs. Assign the roles required by the workload.
 
-In {{stack}} 9.6, [Workflows](/explore-analyze/workflows.md) is the only {{kib}} application that supports directly assigning a service account as the execution identity of a workload. {{kib}} manages the credential used for this integration.
+[Workflows](/explore-analyze/workflows.md) is the only {{kib}} application that supports directly assigning a service account as the execution identity of a workload. {{kib}} manages the credential used for this integration.
 
-To manage service accounts and use them in your own applications:
+To manage service accounts and use them in your workloads:
 
 - [Create and manage service accounts in {{kib}}](manage-service-accounts-in-kibana.md).
-- [Authenticate to the {{kib}} API with a service account](authenticate-kibana-api-with-service-account.md).
+- {applies_to}`{stack: ga 9.6+, serverless: unavailable}` [Authenticate to the {{kib}} API with a service account](authenticate-kibana-api-with-service-account.md).
 
 To use service accounts with {{kib}} Workflows, refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
 
-The {{es}} API reference also documents these operations:
+On {{stack}}, the {{es}} API reference also documents these operations:
 
 - [Create or replace an account]({{es-apis}}operation/operation-security-put-user-managed-service-account).
 - [Delete an account]({{es-apis}}operation/operation-security-delete-user-managed-service-account).
 
-% TBD: Add the query service accounts API link when elasticsearch-specification includes the endpoint from elastic/elasticsearch#159406.
-% Serverless follow-up: publish only after availability is confirmed. Reuse these pages with deployment-specific sections for the 50-role limit, creator privilege ceiling, user-only management, and cross-project role resolution.
-% Serverless follow-up: omit the encryption-key prerequisite and direct service-token API instructions. Document deletion and token expiry instead of disabling an account. Confirm mixed-project-type restrictions before documenting them.
+### Service accounts in {{serverless-short}} [service-accounts-serverless]
+```{applies_to}
+serverless: ga
+```
+
+{{serverless-short}} uses the same [built-in service accounts](#built-in-service-accounts), with credentials managed by Elastic.
+
+User-managed accounts have a generated identifier that is independent of the name you enter in {{kib}}. Their identifiers don't use the `<namespace>/<service>` principal format of {{stack}} accounts.
+
+You can assign a user-managed account to a workflow, and {{kib}} manages the short-lived credentials used to run it. You can't obtain a token for an external application or manage these accounts through the {{es}} service account APIs. The service token instructions on this page apply to {{stack}}.
+
+The account's privileges are limited to those allowed by both its assigned roles and its creator's access at creation time. For details about role limits, cross-project search, and deleting accounts, refer to [Create and manage service accounts in {{kib}}](manage-service-accounts-in-kibana.md).
 
 ## Service account tokens [service-accounts-tokens]
+```{applies_to}
+stack: all
+serverless: unavailable
+```
 
 A service account token, or service token, is a unique string that a service uses to authenticate with {{es}}. For a given service account, each token must have a unique name. Because tokens include access credentials, they should always be kept secret by whichever client is using them.
 
+For example, {{fleet}} server uses a service token to authenticate with {{es}} and manage its own API keys. You can create multiple service tokens for the same service account. This lets multiple instances of a service use the same identity without sharing credentials.
+
 :::{note}
 :applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
 When you create a user-managed service account in {{kib}}, {{kib}} creates and stores a service token so applications such as Workflows can run on behalf of the account. This token isn't displayed. To authenticate requests from your own application, create an additional service token with the API.
@@ -198,11 +213,14 @@ In both responses:
 ## Audit user-managed service account activity [audit-service-account-activity]
 ```{applies_to}
 stack: ga 9.6+
-serverless: unavailable
+serverless: ga
 ```
 
 {{kib}} [audit events](kibana://reference/kibana-audit-events.md) record account creation and deletion, changes to workload assignments, and attempts to run a workload as an account. The `service_account_assume` event identifies the account and workload execution. Events caused by that workload identify the service account as the acting principal.
 
-{{es}} [audit events](elasticsearch://reference/elasticsearch/elasticsearch-audit-events.md) also attribute requests that use a service account credential to the account.
+In {{stack}}, {{es}} [audit events](elasticsearch://reference/elasticsearch/elasticsearch-audit-events.md) also attribute requests that use a service account credential to the account.
+
+On {{serverless-short}}, configure [audit trail log delivery](/deploy-manage/monitor/log-delivery/audit-trail.md) to collect audit logs from your project.
 
-% Follow-up in elastic/kibana: change the service account audit event lifecycle labels from preview to GA for 9.6. The service_account_assume event is already documented after #295817 merged.
+% Follow-up in elastic/kibana: Update all five service account audit events from preview to GA for 9.6 and document their Serverless availability.
+% Serverless verification: Confirm Elasticsearch audit attribution for UIAM-backed service accounts.
diff --git a/explore-analyze/workflows/authoring-techniques.md b/explore-analyze/workflows/authoring-techniques.md
index 5bd99c6534b..f6e64a58284 100644
--- a/explore-analyze/workflows/authoring-techniques.md
+++ b/explore-analyze/workflows/authoring-techniques.md
@@ -21,7 +21,7 @@ Techniques that apply across workflow types, regardless of which outcome you're
 - [Use the YAML editor](/explore-analyze/workflows/authoring-techniques/use-yaml-editor.md): Author and run workflows in the YAML editor in {{kib}}.
 - [Anatomy of a workflow](/explore-analyze/workflows/authoring-techniques/anatomy.md): Every top-level field in a workflow definition and the execution lifecycle.
 - [Workflow settings](/explore-analyze/workflows/authoring-techniques/settings.md): Workflow-wide settings reference, including timeout, timezone, concurrency, max step size, and global on-failure.
-- {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md): Give every run a stable, least-privilege identity.
+- {applies_to}`stack: ga 9.6+` [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md): Give every run a stable, least-privilege identity.
 - [Choose the right step](/explore-analyze/workflows/authoring-techniques/choose-the-right-step.md): Decision aid for picking the right step type. Keyed by intent.
 - [Pass data and handle errors](/explore-analyze/workflows/authoring-techniques/pass-data-handle-errors.md): Move data between steps, use dynamic templating, and make workflows resilient with `on-failure`.
 - [Compose workflows from reusable parts](/explore-analyze/workflows/authoring-techniques/compose-workflows.md): Decompose long workflows into reusable child workflows, design the input and output contract, and fan out with asynchronous composition.
diff --git a/explore-analyze/workflows/authoring-techniques/anatomy.md b/explore-analyze/workflows/authoring-techniques/anatomy.md
index d60605cb43c..8908864c76a 100644
--- a/explore-analyze/workflows/authoring-techniques/anatomy.md
+++ b/explore-analyze/workflows/authoring-techniques/anatomy.md
@@ -278,7 +278,7 @@ A workflow that doesn't declare outputs can still complete successfully. `output
 
 ```yaml
 settings:
-  run_as: kibana/workflow-runner <1>
+  run_as: "<service-account-id>" <1>
   timeout: "10m"
   timezone: "America/Los_Angeles"
   max-step-size: "10mb"
@@ -291,7 +291,7 @@ settings:
       max-attempts: 2
       delay: "10s"
 ```
-1. {applies_to}`{stack: ga 9.6+, serverless: unavailable}` Runs every execution with the specified user-managed service account. Refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
+1. {applies_to}`stack: ga 9.6+` Runs every execution with the specified user-managed service account. Replace `<service-account-id>` with the account's ID. Refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
 
 Every field in `settings` is optional. The full reference with per-field semantics is available in [](/explore-analyze/workflows/authoring-techniques/settings.md).
 
@@ -338,7 +338,7 @@ Five states are terminal: `completed`, `failed`, `cancelled`, `timed_out`, and `
 ## Related [workflows-anatomy-related]
 
 - [Workflow settings](/explore-analyze/workflows/authoring-techniques/settings.md): The full `settings` reference.
-- {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md): Assign a stable, least-privilege execution identity.
+- {applies_to}`stack: ga 9.6+` [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md): Assign a stable, least-privilege execution identity.
 - [Choose the right step](/explore-analyze/workflows/authoring-techniques/choose-the-right-step.md): Decision aid for picking step types.
 - [Steps overview](/explore-analyze/workflows/steps.md): The step catalog.
 - [Triggers overview](/explore-analyze/workflows/triggers.md): The trigger catalog.
diff --git a/explore-analyze/workflows/authoring-techniques/manage-workflows.md b/explore-analyze/workflows/authoring-techniques/manage-workflows.md
index 5b2479dd2be..1affc298eb5 100644
--- a/explore-analyze/workflows/authoring-techniques/manage-workflows.md
+++ b/explore-analyze/workflows/authoring-techniques/manage-workflows.md
@@ -20,7 +20,7 @@ The **Workflows** page allows you to view and manage all your workflows. From th
 ::::{admonition} Requirements
 To use workflows, you must turn on the feature and ensure your role has the appropriate privileges. Refer to [](/explore-analyze/workflows/get-started/setup.md) for more information.
 
-{applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` Updating or deleting a workflow [assigned to a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md) also requires the `manage_security` cluster privilege.
+{applies_to}`stack: ga 9.6+` Updating or deleting a workflow [assigned to a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md) also requires the `manage_security` cluster privilege.
 
 You must also have the appropriate subscription. Refer to the subscription page for [Elastic Cloud](https://www.elastic.co/subscriptions/cloud) and [Elastic Stack/self-managed](https://www.elastic.co/subscriptions) for the breakdown of available features and their associated subscription tiers.
 ::::
diff --git a/explore-analyze/workflows/authoring-techniques/monitor-workflows.md b/explore-analyze/workflows/authoring-techniques/monitor-workflows.md
index f372f49d6f9..67ef08ed1ac 100644
--- a/explore-analyze/workflows/authoring-techniques/monitor-workflows.md
+++ b/explore-analyze/workflows/authoring-techniques/monitor-workflows.md
@@ -57,7 +57,7 @@ serverless: ga
 
 Every execution begins with a trigger entry that shows how the run started, such as a manual run, a schedule, an alert, or an event. Expand this entry to see the input the workflow received, including the full event payload for [event-driven](/explore-analyze/workflows/triggers/event-driven-triggers.md) runs. This lets you trace an execution back to the event or action that started it, which is especially useful when workflows react to one another through event-driven triggers.
 
-{applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` For workflows assigned to a service account, **Triggered by** shows the identity associated with the start of the run, which can be a user or a service account. **Run as** shows the assigned service account used for authorization. For details, refer to [](/explore-analyze/workflows/authorization.md#workflows-authorization-audit).
+{applies_to}`stack: ga 9.6+` For workflows assigned to a service account, **Triggered by** shows the identity associated with the start of the run, which can be a user or a service account. **Run as** shows the assigned service account used for authorization. For details, refer to [](/explore-analyze/workflows/authorization.md#workflows-authorization-audit).
 
 ## View execution history [workflows-execution-history]
 
diff --git a/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md b/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
index 203f6dc8926..d4ddde04613 100644
--- a/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
+++ b/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
@@ -2,10 +2,11 @@
 navigation_title: Run as a service account
 applies_to:
   stack: ga 9.6+
-  serverless: unavailable
+  serverless: ga
 description: Assign a user-managed service account to a workflow, verify its execution identity, and troubleshoot permission errors.
 products:
   - id: kibana
+  - id: cloud-serverless
   - id: cloud-hosted
   - id: cloud-enterprise
   - id: cloud-kubernetes
@@ -16,7 +17,7 @@ products:
 
 By default, workflows run with a user's privileges. As an alternative, you can run a workflow as a [user-managed service account](/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md#user-managed-service-accounts).
 
-The workflow then uses the account's roles for every run, regardless of who starts or last edits it. This gives shared workflows a stable identity, even if their creator leaves your organization. You can also give the account only the privileges the workflow needs, even if the people who manage it have broader access.
+The workflow then uses the account's privileges for every run, regardless of who starts or last edits it. This gives shared workflows a stable identity, even if their creator leaves your organization. You can also give the account only the privileges the workflow needs, even if the people who manage it have broader access.
 
 This guide shows you how to assign a service account to a workflow and verify its execution identity.
 
@@ -29,23 +30,27 @@ Before you assign a service account to a workflow, make sure you meet these requ
 
 ## Assign a service account [assign-workflow-service-account]
 
-The `settings.run_as` field specifies the account that runs the workflow. Set it to the account's full principal, such as `kibana/incident-response`.
+The `settings.run_as` field specifies the ID of the account that runs the workflow. On {{stack}} deployments, this is the account's principal, such as `kibana/incident-response`. On {{serverless-short}}, it is a generated identifier independent of the account's name.
 
-You can assign an existing account or create one without leaving the workflow editor. In both cases, the account must be [created in {{kib}}](/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md) and have the roles required by the workflow steps. Accounts created directly through the {{es}} API can't be used for workflow execution, even if they use the `kibana` namespace.
+You can assign an existing account or create one without leaving the workflow editor. In both cases, the account must be [created in {{kib}}](/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md) and have the privileges required by the workflow steps.
+
+{applies_to}`serverless: unavailable` Accounts created directly through the {{es}} API can't be used for workflow execution, even if they use the `kibana` namespace.
 
 1. Open the workflow in the {{kib}} workflow editor.
 2. In the `settings` block, add `run_as`:
 
-    - To use an existing account, select it from the picker or enter its principal.
+    - To use an existing account, select it from the picker or enter its ID.
     - To create and assign an account, select **Create account** and configure its roles.
 
     For example:
 
     ```yaml
     settings:
-      run_as: kibana/incident-response
+      run_as: "<service-account-id>"
     ```
 
+    Replace `<service-account-id>` with the account's ID.
+
 3. Save the workflow.
 
 The saved assignment applies to manual, scheduled, alert, and event-driven runs. Users who have permission to run the workflow don't need `manage_security` to start it.
@@ -69,9 +74,9 @@ A workflow assigned to a service account never falls back to the triggering user
 
 - If the account is deactivated or deleted, the next run fails.
 - If the account lacks a privilege required by a step, that step fails with a privileges error.
-- If the account was deleted and recreated with the same principal, the old assignment no longer matches it. Remove the assignment, save the workflow, then assign the recreated account.
+- If the account was deleted and recreated with the same name, the old assignment no longer matches it. Remove the assignment, save the workflow, then assign the recreated account.
 
-[Update the account or its roles](/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md#disable-service-account), or assign a different account, then run the workflow again.
+[Update the account or its roles](/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md#update-service-account-kibana), or assign a different account, then run the workflow again.
 
 ## Remove the assignment [remove-workflow-service-account]
 
diff --git a/explore-analyze/workflows/authoring-techniques/settings.md b/explore-analyze/workflows/authoring-techniques/settings.md
index 7c4be33cdc8..cf9c84daf29 100644
--- a/explore-analyze/workflows/authoring-techniques/settings.md
+++ b/explore-analyze/workflows/authoring-techniques/settings.md
@@ -26,7 +26,7 @@ The top-level `settings` block configures workflow-wide behavior. Every field is
 | `concurrency` | object | Controls what happens when a new execution would exceed the concurrency limit for its group. Refer to [Concurrency control](#workflows-settings-concurrency). |
 | `max-step-size` | byte size | Cap on per-step output size (for example `10mb`). |
 | `on-failure` | object | Global failure handling applied to every step. Same shape as per-step `on-failure`. Refer to [Pass data and handle errors](/explore-analyze/workflows/authoring-techniques/pass-data-handle-errors.md). |
-| `run_as` {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` | string | User-managed service account ID that authorizes every workflow run. Refer to [](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md). |
+| `run_as` {applies_to}`stack: ga 9.6+` | string | User-managed service account ID that authorizes every workflow run. Refer to [](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md). |
 
 Fields not set take the engine defaults.
 
@@ -39,7 +39,7 @@ Fields not set take the engine defaults.
 | Prevent overlapping runs from colliding on shared state | `concurrency` |
 | Keep a single step from producing 100 MB of output that bogs down the UI | `max-step-size` |
 | Apply a default retry policy to every step | `on-failure` |
-| Run with a stable, least-privilege identity {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` | `run_as` |
+| Run with a stable, least-privilege identity {applies_to}`stack: ga 9.6+` | `run_as` |
 
 ## `timeout` [workflows-settings-timeout]
 
@@ -84,16 +84,17 @@ Steps that produce outputs exceeding this limit fail with a clear error. Useful
 ## `run_as` [workflows-settings-run-as]
 ```{applies_to}
 stack: ga 9.6+
-serverless: unavailable
 ```
 
-Assigns a user-managed service account to the workflow. Every trigger type runs the workflow with the account's current roles:
+Assigns a user-managed service account to the workflow. Every trigger type runs the workflow with the account's privileges:
 
 ```yaml
 settings:
-  run_as: kibana/incident-response
+  run_as: "<service-account-id>"
 ```
 
+Replace `<service-account-id>` with the ID of the service account you want to assign.
+
 Setting, changing, or removing `run_as` requires the `manage_security` cluster privilege. Refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md) for setup instructions, permissions, and testing restrictions.
 
 ## Concurrency control [workflows-settings-concurrency]
diff --git a/explore-analyze/workflows/authorization.md b/explore-analyze/workflows/authorization.md
index 9ef6cb4a49d..3b3c2750e4d 100644
--- a/explore-analyze/workflows/authorization.md
+++ b/explore-analyze/workflows/authorization.md
@@ -18,7 +18,7 @@ products:
 The privileges used to authorize a workflow run depend on whether the workflow has an assigned service account:
 
 * **No service account assigned (default):** The run uses a user's privileges, determined by how the workflow starts.
-* {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` **Service account assigned:** The run uses the privileges of that account.
+* {applies_to}`stack: ga 9.6+` **Service account assigned:** The run uses the privileges of that account.
 
 Use this page to configure who runs your workflows, diagnose privileges errors, and keep your workflows' access current.
 
@@ -37,20 +37,21 @@ When a workflow doesn't run as a service account, the trigger type determines wh
 ### Workflows that run as a service account [workflows-authorization-service-account]
 ```{applies_to}
 stack: ga 9.6+
-serverless: unavailable
 ```
 
-When you [assign a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md) with `settings.run_as`, every run uses that account's roles. The trigger type and the user who last saved or started the workflow don't change its privileges.
+When you [assign a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md) with `settings.run_as`, every run uses that account's privileges. The trigger type and the user who last saved or started the workflow don't change its privileges.
 
-The workflow stores a reference to the account. When a run starts, {{kib}} obtains a short-lived credential and renews it as needed. {{es}} resolves the account's roles whenever it authenticates, so changes to an assigned role apply to later credential requests without saving the workflow again.
+The workflow stores a reference to the account. When a run starts, {{kib}} obtains a short-lived credential and renews it as needed. Changes to an assigned role affect the account's privileges without saving the workflow again.
 
-If the account is deleted, turned off, or lacks a required privilege, the run fails without falling back to a user.
+On {{serverless-short}}, the account's privileges are also limited by its creator's access when the account was created. Refer to [Roles and privileges in {{serverless-short}}](/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md#service-account-serverless-roles).
+
+If the account is deleted or lacks a required privilege, the run fails without falling back to a user.
 
 ## How {{kib}} records execution identity [workflows-authorization-audit]
 
 When a workflow run starts, {{kib}} records the execution identity so you can audit which privileges it used. Refer to [](/explore-analyze/workflows/reference/context-variables.md#workflows-ctx-execution) for execution context variables.
 
-{applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` For workflows assigned to service accounts, **Triggered by** shows the identity associated with the start of the run. This can be a user or a service account. **Run as** shows the assigned service account whose privileges authorize the workflow's actions.
+{applies_to}`stack: ga 9.6+` For workflows assigned to service accounts, **Triggered by** shows the identity associated with the start of the run. This can be a user or a service account. **Run as** shows the assigned service account whose privileges authorize the workflow's actions.
 
 The **Created By** filter on the **Workflows** page reflects who last saved the workflow, not necessarily who originally created it.
 
@@ -58,7 +59,7 @@ The **Created By** filter on the **Workflows** page reflects who last saved the
 
 A workflow can call a child workflow with [`workflow.execute`](/explore-analyze/workflows/steps/composition.md#workflow-execute). When neither workflow is assigned a service account, the child runs with the same execution identity as the parent.
 
-{applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` When service accounts are involved, each workflow uses its own assignment by default. A child doesn't automatically inherit its parent's service account. If only the parent is assigned a service account, the child uses the identity associated with the [parent run's trigger](#workflows-authorization-user). For example, if a user manually starts the parent, the child uses that user's privileges even when the parent runs as a service account.
+{applies_to}`stack: ga 9.6+` When service accounts are involved, each workflow uses its own assignment by default. A child doesn't automatically inherit its parent's service account. If only the parent is assigned a service account, the child uses the identity associated with the [parent run's trigger](#workflows-authorization-user). For example, if a user manually starts the parent, the child uses that user's privileges even when the parent runs as a service account.
 
 ## How steps use the execution identity [workflows-authorization-scope]
 
@@ -87,6 +88,6 @@ The following authorization errors can cause a workflow step to fail:
 |---|---|---|---|
 | Step-level privileges error | The execution identity lacks a required privilege for the step. | On the failing step in the run's **Executions** tab. | For a user identity, update the user's role and save the workflow again. For a service account, update one of its assigned roles. |
 | Stale or not-valid API key | The stored key is no longer valid, for example because an administrator deleted a role it depended on. There's no dedicated status or list-level indicator for this condition. | As an API key error on the individual `elasticsearch` or `kibana` step in the run's **Executions** tab. | Refresh the API key by saving the workflow again or toggling **Enabled** off and back on. |
-| Service account identity error {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` | The assigned account has `enabled: false`, is deleted, or no longer matches the saved assignment. | In the run's execution details. | Set `enabled: true` or assign an available account, then start a new run. |
+| Service account identity error {applies_to}`stack: ga 9.6+` | The assigned account is deleted, deactivated, or no longer matches the saved assignment. | In the run's execution details. | Assign an available account or, on {{stack}} deployments, [reactivate the account](/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md#disable-service-account). Then start a new run. |
 
 <!-- TODO: Workflows currently uses {{es}} API keys on both {{stack}} and {{serverless-short}} with no deployment-specific key type. When {{serverless-short}} enables UIAM API keys, Task Manager will use UIAM-issued keys for Serverless workflow runs. Add a "How the API key differs by deployment type" section when that ships. -->
diff --git a/explore-analyze/workflows/get-started/setup.md b/explore-analyze/workflows/get-started/setup.md
index bb58c08329b..95f5aa211c8 100644
--- a/explore-analyze/workflows/get-started/setup.md
+++ b/explore-analyze/workflows/get-started/setup.md
@@ -51,8 +51,8 @@ Access to workflows is controlled by [{{kib}} privileges](/deploy-manage/users-r
 | Access the **Workflows** page | `All` or `Read` for **Analytics → Workflows** |
 | Fully manage workflows | `All` for **Analytics → Workflows** |
 | Grant access to specific workflow actions | [Set sub-feature privileges](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md#kibana-privileges-workflows-subfeatures) for **Analytics → Workflows** |
-| Add, change, or remove a [service account assignment](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md#assign-workflow-service-account) {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` | The **Update** Workflows privilege and the `manage_security` cluster privilege |
-| Edit or delete a workflow assigned to a service account {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` | The corresponding Workflows privilege and the `manage_security` cluster privilege |
+| Add, change, or remove a [service account assignment](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md#assign-workflow-service-account) {applies_to}`stack: ga 9.6+` | The **Update** Workflows privilege and the `manage_security` cluster privilege |
+| Edit or delete a workflow assigned to a service account {applies_to}`stack: ga 9.6+` | The corresponding Workflows privilege and the `manage_security` cluster privilege |
 
 ## Show managed workflows [workflows-managed-visibility]
 
diff --git a/explore-analyze/workflows/reference/context-variables.md b/explore-analyze/workflows/reference/context-variables.md
index d00562c34a8..25152c920c7 100644
--- a/explore-analyze/workflows/reference/context-variables.md
+++ b/explore-analyze/workflows/reference/context-variables.md
@@ -125,8 +125,8 @@ Metadata about the current workflow execution.
 | `execution.startedAt` | ISO timestamp of start. |
 | `execution.isTestRun` | `true` if run from the editor's **Test** button. |
 | `execution.executedBy` | Identifier of the user or service account associated with the run. |
-| `execution.effectiveIdentity.type` {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` | Identity type. Set to `service_account` when the workflow runs as a user-managed service account. |
-| `execution.effectiveIdentity.id` {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` | ID of the user-managed service account that authorizes the workflow. |
+| `execution.effectiveIdentity.type` {applies_to}`stack: ga 9.6+` | Identity type. Set to `service_account` when the workflow runs as a user-managed service account. |
+| `execution.effectiveIdentity.id` {applies_to}`stack: ga 9.6+` | ID of the user-managed service account that authorizes the workflow. |
 | `execution.triggeredBy` | Which trigger initiated this execution (`manual`, `scheduled`, `alert`, `workflows.failed`). |
 | `execution.url` | Deep link to the execution view in {{kib}}. |
 | `execution.compositionDepth` | 0 for a top-level invocation. Increments by 1 for each [`workflow.execute`](/explore-analyze/workflows/steps/composition.md#workflow-execute) level. |
diff --git a/explore-analyze/workflows/triggers/alert-triggers.md b/explore-analyze/workflows/triggers/alert-triggers.md
index 50a876d0c4a..01573c848b8 100644
--- a/explore-analyze/workflows/triggers/alert-triggers.md
+++ b/explore-analyze/workflows/triggers/alert-triggers.md
@@ -29,7 +29,7 @@ Declaring `type: alert` on a workflow isn't enough to run the workflow when aler
 The privileges used for each alert-triggered run depend on whether the workflow has an assigned service account:
 
 * **No service account assigned (default):** The run uses the privileges of the user who last saved the rule.
-* {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` **Service account assigned:** The run uses the privileges of that account.
+* {applies_to}`stack: ga 9.6+` **Service account assigned:** The run uses the privileges of that account.
 
 For details, refer to [](/explore-analyze/workflows/authorization.md).
 
diff --git a/explore-analyze/workflows/triggers/event-driven-triggers.md b/explore-analyze/workflows/triggers/event-driven-triggers.md
index dc8f8c04e98..b28a8bb9c4c 100644
--- a/explore-analyze/workflows/triggers/event-driven-triggers.md
+++ b/explore-analyze/workflows/triggers/event-driven-triggers.md
@@ -28,7 +28,7 @@ Event-driven triggers let workflows react to events elsewhere in {{kib}}. The fo
 The privileges used for each event-driven run depend on whether the workflow has an assigned service account:
 
 * **No service account assigned (default):** The run uses the privileges of the user whose action produced the event. For `workflows.failed`, it uses the same privileges as the failed workflow.
-* {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` **Service account assigned:** The run uses the privileges of that account.
+* {applies_to}`stack: ga 9.6+` **Service account assigned:** The run uses the privileges of that account.
 
 For details, refer to [](/explore-analyze/workflows/authorization.md).
 
diff --git a/explore-analyze/workflows/triggers/manual-triggers.md b/explore-analyze/workflows/triggers/manual-triggers.md
index 2f538f3dcf7..0eddccb59f5 100644
--- a/explore-analyze/workflows/triggers/manual-triggers.md
+++ b/explore-analyze/workflows/triggers/manual-triggers.md
@@ -33,7 +33,7 @@ This allows you to run a workflow manually by:
 The privileges used for each manual run depend on whether the workflow has an assigned service account:
 
 * **No service account assigned (default):** The run uses the privileges of the user who starts it.
-* {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` **Service account assigned:** The run uses the privileges of that account.
+* {applies_to}`stack: ga 9.6+` **Service account assigned:** The run uses the privileges of that account.
 
 For details, refer to [](/explore-analyze/workflows/authorization.md).
 
diff --git a/explore-analyze/workflows/triggers/scheduled-triggers.md b/explore-analyze/workflows/triggers/scheduled-triggers.md
index 695e5d88e2d..b67c8a571fe 100644
--- a/explore-analyze/workflows/triggers/scheduled-triggers.md
+++ b/explore-analyze/workflows/triggers/scheduled-triggers.md
@@ -26,7 +26,7 @@ You can configure scheduled triggers using:
 The privileges used for each scheduled run depend on whether the workflow has an assigned service account:
 
 * **No service account assigned (default):** The run uses the privileges of the user who last saved the workflow.
-* {applies_to}`stack: ga 9.6+` {applies_to}`serverless: unavailable` **Service account assigned:** The run uses the privileges of that account.
+* {applies_to}`stack: ga 9.6+` **Service account assigned:** The run uses the privileges of that account.
 
 For details, refer to [](/explore-analyze/workflows/authorization.md).
 

From 96a51b9584b931d7ed34111786371dd9e914a291 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Thu, 5 Nov 2026 17:57:56 +0100
Subject: [PATCH 34/45] Clarify service account deployment differences and
 navigation

AI-Assisted: Codex
---
 .../deploy/elastic-cloud/serverless-faq.md        |  2 +-
 .../service-accounts.md                           | 15 ++++++++++++---
 2 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/deploy-manage/deploy/elastic-cloud/serverless-faq.md b/deploy-manage/deploy/elastic-cloud/serverless-faq.md
index e38e221a743..9ce3bf33fca 100644
--- a/deploy-manage/deploy/elastic-cloud/serverless-faq.md
+++ b/deploy-manage/deploy/elastic-cloud/serverless-faq.md
@@ -33,7 +33,7 @@ User-initiated data recovery is anticipated in a future release. You can follow
 ## Security, compliance, and access
 
 **Q: How can I create {{serverless-full}} service accounts?**<br>
-A: You can [create user-managed service accounts in {{kib}}](/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md#create-service-account-kibana) for use within {{kib}} applications, such as [Workflows](/explore-analyze/workflows.md). For programmatic access from external applications, use [API keys](/deploy-manage/api-keys.md).
+A: You can [create user-managed service accounts in {{kib}}](/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md) for use within {{kib}} applications, such as [Workflows](/explore-analyze/workflows.md). For programmatic access from external applications, use [API keys](/deploy-manage/api-keys.md).
 
 **Q: Can I configure {{es}} authentication realms (for example, native realm) in {{serverless-short}} projects?**  
 A: No. {{serverless-short}} uses a different authentication model and does not support [{{es}} authentication realms](/deploy-manage/users-roles/cluster-or-deployment-auth/authentication-realms.md). Project-level access is handled through [Serverless project API keys](/deploy-manage/api-keys/serverless-project-api-keys.md), and user authentication is managed at the [{{ecloud}} organization level](/deploy-manage/users-roles/cloud-organization.md) (including SAML SSO).
diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md b/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
index 1badb5102c8..1d5c1d72163 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
@@ -21,11 +21,11 @@ Service accounts authenticate with tokens. The account defines the identity and
 Don't use service accounts to authenticate individual users. Service account credentials are for software and workloads, not people.
 ::::
 
-$$$service-accounts-explanation$$$
+This page refers to {{ech}}, {{ece}}, {{eck}}, and self-managed deployments as {{stack}} deployments. In these environments, {{es}} stores and manages user-managed service accounts. In {{serverless-full}} projects, {{ecloud}} manages these accounts at the organization level. These differences affect account identifiers, credentials, and the available management APIs.
 
-Each service account has a unique identifier, called a principal. In {{stack}}, the principal has the form `<namespace>/<service>`. The `namespace` groups related accounts, and the `service` name must be unique within that namespace.
+$$$service-accounts-explanation$$$
 
-On {{stack}}, service accounts are not included in the response of the [get users API]({{es-apis}}operation/operation-security-get-user). To retrieve a service account, use the [get service accounts API]({{es-apis}}operation/operation-security-get-service-accounts). Use the [get service account credentials API]({{es-apis}}operation/operation-security-get-service-credentials) to retrieve all service credentials for a service account.
+Each service account has a unique identifier, called a principal. In {{stack}} deployments, the principal has the form `<namespace>/<service>`. The `namespace` groups related accounts, and the `service` name must be unique within that namespace.
 
 ## Service account types [service-account-types]
 
@@ -61,6 +61,11 @@ Use a user-managed service account when your workload needs its own identity to
 
 [Workflows](/explore-analyze/workflows.md) is the only {{kib}} application that supports directly assigning a service account as the execution identity of a workload. {{kib}} manages the credential used for this integration.
 
+:::{note}
+:applies_to: serverless: ga
+On {{serverless-short}}, user-managed service accounts can only be used within {{kib}} applications. For programmatic access from external applications, use [API keys](/deploy-manage/api-keys.md).
+:::
+
 To manage service accounts and use them in your workloads:
 
 - [Create and manage service accounts in {{kib}}](manage-service-accounts-in-kibana.md).
@@ -208,6 +213,10 @@ In both responses:
 - `token` describes the credential used for the request. Its `name` is the service token's name, and its `type` identifies the storage backend: `_service_account_index` for tokens stored in the `.security` index, or `_service_account_file` for file-backed tokens used by built-in accounts.
 - `metadata` identifies the account type: `_elastic_service_account` for built-in accounts or `_user_managed_service_account` for user-managed accounts.
 
+:::{note}
+Service accounts are not included in the response of the [get users API]({{es-apis}}operation/operation-security-get-user). To retrieve a service account, use the [get service accounts API]({{es-apis}}operation/operation-security-get-service-accounts). Use the [get service account credentials API]({{es-apis}}operation/operation-security-get-service-credentials) to retrieve all service credentials for a service account.
+:::
+
 {applies_to}`stack: ga 9.6+` To authenticate calls to {{kib}} with a user-managed service account, refer to [Authenticate to the {{kib}} API with a service account](authenticate-kibana-api-with-service-account.md).
 
 ## Audit user-managed service account activity [audit-service-account-activity]

From 58c3ef4c07190742c3b79e06a2e549097f7e1061 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Thu, 5 Nov 2026 18:07:03 +0100
Subject: [PATCH 35/45] Inherit Serverless scope for the service token note

AI-Assisted: Codex
---
 .../users-roles/cluster-or-deployment-auth/service-accounts.md  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md b/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
index 1d5c1d72163..eeca35c1f4a 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
@@ -102,7 +102,7 @@ A service account token, or service token, is a unique string that a service use
 For example, {{fleet}} server uses a service token to authenticate with {{es}} and manage its own API keys. You can create multiple service tokens for the same service account. This lets multiple instances of a service use the same identity without sharing credentials.
 
 :::{note}
-:applies_to: {"stack": "ga 9.6+", "serverless": "unavailable"}
+:applies_to: stack: ga 9.6+
 When you create a user-managed service account in {{kib}}, {{kib}} creates and stores a service token so applications such as Workflows can run on behalf of the account. This token isn't displayed. To authenticate requests from your own application, create an additional service token with the API.
 :::
 

From 1f69b55d3bb1d248b8e8f7f653a1062265b7bb5e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Thu, 5 Nov 2026 18:08:05 +0100
Subject: [PATCH 36/45] Inherit Stack version scope for the service account API
 link

AI-Assisted: Codex
---
 .../users-roles/cluster-or-deployment-auth/service-accounts.md  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md b/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
index eeca35c1f4a..a22af53d37f 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
@@ -69,7 +69,7 @@ On {{serverless-short}}, user-managed service accounts can only be used within {
 To manage service accounts and use them in your workloads:
 
 - [Create and manage service accounts in {{kib}}](manage-service-accounts-in-kibana.md).
-- {applies_to}`{stack: ga 9.6+, serverless: unavailable}` [Authenticate to the {{kib}} API with a service account](authenticate-kibana-api-with-service-account.md).
+- {applies_to}`serverless: unavailable` [Authenticate to the {{kib}} API with a service account](authenticate-kibana-api-with-service-account.md).
 
 To use service accounts with {{kib}} Workflows, refer to [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
 

From 376e51fcf6da4c44fa8a4e347227a15de25ae92e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Thu, 5 Nov 2026 18:12:27 +0100
Subject: [PATCH 37/45] Clarify service tokens and Serverless API
 authentication

AI-Assisted: Codex
---
 .../authenticate-kibana-api-with-service-account.md           | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md b/deploy-manage/users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md
index e1a290413a6..9014460242d 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md
@@ -15,7 +15,9 @@ products:
 
 # Authenticate to the {{kib}} API with a service account [authenticate-kibana-api-service-account]
 
-Use a user-managed service account to authenticate programmatic requests to {{kib}}. The account provides a non-human identity whose privileges come from its assigned roles.
+Use a service token to authenticate programmatic requests to {{kib}} as a user-managed service account. The account provides a non-human identity whose privileges come from its assigned roles.
+
+On {{serverless-full}}, use [API keys](/deploy-manage/api-keys.md) for programmatic access from external applications, because service account tokens aren't available for this use.
 
 ## Before you begin [authenticate-kibana-api-service-account-prerequisites]
 

From 2417918eb1bc3545d99f60b393647fb983140843 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Thu, 5 Nov 2026 18:15:36 +0100
Subject: [PATCH 38/45] Remove redundant API caveat from the workflow service
 account guide

AI-Assisted: Codex
---
 .../authoring-techniques/run-workflow-as-service-account.md     | 2 --
 1 file changed, 2 deletions(-)

diff --git a/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md b/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
index d4ddde04613..2da433c417f 100644
--- a/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
+++ b/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md
@@ -34,8 +34,6 @@ The `settings.run_as` field specifies the ID of the account that runs the workfl
 
 You can assign an existing account or create one without leaving the workflow editor. In both cases, the account must be [created in {{kib}}](/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md) and have the privileges required by the workflow steps.
 
-{applies_to}`serverless: unavailable` Accounts created directly through the {{es}} API can't be used for workflow execution, even if they use the `kibana` namespace.
-
 1. Open the workflow in the {{kib}} workflow editor.
 2. In the `settings` block, add `run_as`:
 

From 1a5dba7ed77136fd027f4a56e72afb58b42bac46 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Fri, 6 Nov 2026 12:03:11 +0100
Subject: [PATCH 39/45] Link Serverless service account FAQ to project API keys

AI-Assisted: Codex
---
 deploy-manage/deploy/elastic-cloud/serverless-faq.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/deploy-manage/deploy/elastic-cloud/serverless-faq.md b/deploy-manage/deploy/elastic-cloud/serverless-faq.md
index 9ce3bf33fca..642e73e2447 100644
--- a/deploy-manage/deploy/elastic-cloud/serverless-faq.md
+++ b/deploy-manage/deploy/elastic-cloud/serverless-faq.md
@@ -33,7 +33,7 @@ User-initiated data recovery is anticipated in a future release. You can follow
 ## Security, compliance, and access
 
 **Q: How can I create {{serverless-full}} service accounts?**<br>
-A: You can [create user-managed service accounts in {{kib}}](/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md) for use within {{kib}} applications, such as [Workflows](/explore-analyze/workflows.md). For programmatic access from external applications, use [API keys](/deploy-manage/api-keys.md).
+A: You can [create user-managed service accounts in {{kib}}](/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md) for use within {{kib}} applications, such as [Workflows](/explore-analyze/workflows.md). For programmatic access from external applications, use [API keys](/deploy-manage/api-keys/serverless-project-api-keys.md).
 
 **Q: Can I configure {{es}} authentication realms (for example, native realm) in {{serverless-short}} projects?**  
 A: No. {{serverless-short}} uses a different authentication model and does not support [{{es}} authentication realms](/deploy-manage/users-roles/cluster-or-deployment-auth/authentication-realms.md). Project-level access is handled through [Serverless project API keys](/deploy-manage/api-keys/serverless-project-api-keys.md), and user authentication is managed at the [{{ecloud}} organization level](/deploy-manage/users-roles/cloud-organization.md) (including SAML SSO).

From 71ec621b8ff3896496f1e1f596818e94d4b62691 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Mon, 9 Nov 2026 15:13:28 +0100
Subject: [PATCH 40/45] Apply suggestions from code review

Co-authored-by: shainaraskas <58563081+shainaraskas@users.noreply.github.com>
Co-authored-by: Larry Gregory <lgregorydev@gmail.com>
---
 ...nticate-kibana-api-with-service-account.md |  5 +----
 .../manage-service-accounts-in-kibana.md      | 21 +++++--------------
 .../service-accounts.md                       |  4 ++--
 3 files changed, 8 insertions(+), 22 deletions(-)

diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md b/deploy-manage/users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md
index 9014460242d..6b78e1084c5 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/authenticate-kibana-api-with-service-account.md
@@ -17,7 +17,7 @@ products:
 
 Use a service token to authenticate programmatic requests to {{kib}} as a user-managed service account. The account provides a non-human identity whose privileges come from its assigned roles.
 
-On {{serverless-full}}, use [API keys](/deploy-manage/api-keys.md) for programmatic access from external applications, because service account tokens aren't available for this use.
+Service accounts can't be used with external applications on {{serverless-full}}. For programmatic access from external applications, use [API keys](/deploy-manage/api-keys.md).
 
 ## Before you begin [authenticate-kibana-api-service-account-prerequisites]
 
@@ -47,9 +47,6 @@ curl --request GET "$KIBANA_URL/api/spaces/space" \
   --header "Authorization: Bearer $SERVICE_ACCOUNT_TOKEN"
 ```
 
-Ensure that your [HTTP authentication configuration](kibana-authentication.md#http-authentication) accepts the `Bearer` scheme.
-
-The response depends on the account's roles. A `403` response means the account authenticated but doesn't have the required privilege. Add privileges by editing the assigned role rather than assigning broad administrative roles to the account.
 
 For requests that change data, also include the headers required by that API, such as `kbn-xsrf`.
 
diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md b/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
index c4b1639b9db..955fbe4abed 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
@@ -16,7 +16,7 @@ products:
 
 # Create and manage service accounts in {{kib}} [manage-service-accounts-kibana]
 
-Create user-managed service accounts and assign roles to control programmatic access to {{es}} and {{kib}} APIs. Accounts created in {{kib}} are ready to use with applications such as [Workflows](/explore-analyze/workflows.md), and {{kib}} automatically manages the credentials needed to run workloads as those accounts.
+Create user-managed service accounts and assign roles to control programmatic access to {{es}} and {{kib}} APIs. Accounts created in {{kib}} are ready to use with {{kib}} applications such as [Workflows](/explore-analyze/workflows.md). On {{stack}} deployments, you can also use them with your own applications by [creating a service token](authenticate-kibana-api-with-service-account.md#create-service-account-api-token).
 
 Some service account capabilities differ between [{{serverless-full}}](/deploy-manage/deploy/elastic-cloud/serverless.md) and other [deployment types](/deploy-manage/deploy.md#choosing-your-deployment-type). This guide uses {{stack}} deployments to refer to {{ech}}, {{ece}}, {{eck}}, and self-managed deployments.
 
@@ -33,7 +33,7 @@ Before you create or manage service accounts, check these requirements:
 
 - Sign in to {{kib}} as a user with the `manage_security` cluster privilege. Without it, the **Service accounts** page isn't available.
 - {applies_to}`self: ga` Set [`xpack.encryptedSavedObjects.encryptionKey`](kibana://reference/configuration-reference/security-settings.md#xpack-encryptedsavedobjects-encryptionkey) in `kibana.yml`. {{kib}} uses this key to encrypt the stored credential.
-- On {{stack}} deployments, make sure service accounts are enabled in {{kib}}. They're enabled by default. If they've been turned off, set [`xpack.security.serviceAccounts.enabled`](kibana://reference/configuration-reference/security-settings.md#service-account-settings) to `true` before continuing.
+- On {{stack}} deployments, service accounts must be enabled in {{kib}}. This is the default. If your deployment turns them off, set [`xpack.security.serviceAccounts.enabled`](kibana://reference/configuration-reference/security-settings.md#service-account-settings) to `true` to re-enable them.
 
 ## Create a service account [create-service-account-kibana]
 
@@ -48,7 +48,7 @@ Create a service account with the roles your workloads need:
     For details on predefined roles and how to create custom roles, refer to:
 
     - {{stack}} deployments: [Built-in roles](elasticsearch://reference/elasticsearch/roles.md) and [role management in {{kib}}](kibana-role-management.md).
-    - {{serverless-short}} projects: [Predefined roles](/deploy-manage/users-roles/cloud-organization/user-roles.md#general-assign-user-roles-table) and [custom roles](/deploy-manage/users-roles/serverless-custom-roles.md).
+    - {{serverless-short}} projects: [Predefined roles](/deploy-manage/users-roles/cloud-organization/user-roles.md#general-assign-user-roles-table) and [custom roles](/deploy-manage/users-roles/serverless-custom-roles.md). Before you assign roles, review the [role limits in {{serverless-short}}](#service-account-serverless-roles).
 
 6. Review the selected roles, and click **Create account**.
 7. Confirm that the account appears in the **Service accounts** table with the roles you selected. On {{stack}} deployments, the account uses the principal `kibana/<name>`.
@@ -64,11 +64,8 @@ serverless: ga
 
 A service account can have up to 50 roles. Its privileges come from its assigned roles and cannot exceed the access its creator had when the account was created.
 
-Roles reserved for internal use by [{{alerting-v2-system}}](/explore-analyze/alerting/esql/system-overview.md) aren't available in the role picker.
-
 When a workload uses [cross-project search](/explore-analyze/cross-project-search.md), its service account's predefined roles apply across linked projects. For a custom role to grant access to a linked project, that project must define a role with the same name. Custom roles aren't copied between projects.
 
-% Pending confirmation from Larry: determine whether role assignment is restricted when linked projects have different project types. No restriction was found in the code reviewed.
 
 ## Review service accounts [review-service-accounts-kibana]
 
@@ -76,8 +73,6 @@ The **Service accounts** table shows each account's name, description, roles, cr
 
 When an account has bound workloads, click **View** in the **Workloads** column to review them.
 
-{applies_to}`serverless: unavailable` Accounts created directly through the [{{es}} API]({{es-apis}}operation/operation-security-put-user-managed-service-account) also appear in the table, but don't have associated {{kib}} workloads.
-
 ## Update a service account [update-service-account-kibana]
 
 You can't update service accounts in the {{kib}} UI. On {{serverless-short}}, to change an account's assigned roles or description, [delete the account](#delete-service-account-kibana) and [create a new one](#create-service-account-kibana). On {{stack}} deployments, you can update accounts through the {{es}} API.
@@ -126,19 +121,13 @@ To delete a service account:
 
 If you force delete an account, workloads assigned to it fail on their next run. To restore access, assign each affected workload a valid service account. This reassignment is required even if you recreate the deleted account with the same name. For Workflows, [assign a service account to each affected workflow](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md#assign-workflow-service-account).
 
-### Credentials after deletion in {{serverless-short}} [delete-service-account-serverless-credentials]
-```{applies_to}
-serverless: ga
-```
-
-Deleting an account stops new tokens from being issued immediately. Tokens already issued remain valid until they expire, which takes a few minutes at most.
 
 ### Credentials after deletion in {{stack}} deployments [delete-service-account-stack-credentials]
 ```{applies_to}
 serverless: unavailable
 ```
 
-Deleting an account through {{kib}} attempts to remove every service token, including the credential it stores for workloads and tokens created outside {{kib}}. It also attempts to invalidate any short-lived access tokens used to run workloads as the account. If any credential cleanup fails, {{kib}} completes the deletion and reports a warning.
+Deleting an account through {{kib}} attempts to remove every service token, including the credential it stores for workloads and tokens created outside {{kib}}. If any credential cleanup fails, {{kib}} completes the deletion and reports a warning.
 
 A service token left behind after deletion can't authenticate, but it prevents you from creating another account with the same name until you delete the token. If you delete an account directly through the {{es}} API, short-lived access tokens already issued to the account remain valid until they expire, 20 minutes after issuance by default.
 
@@ -151,5 +140,5 @@ API keys owned by the account aren't invalidated when you delete the account. {{
 Use these guides to work with service accounts and learn more about their credentials:
 
 - [Run a workflow as a service account](/explore-analyze/workflows/authoring-techniques/run-workflow-as-service-account.md).
-- {applies_to}`{serverless: unavailable}` [Authenticate to the {{kib}} API with a service account](authenticate-kibana-api-with-service-account.md).
+- {applies_to}`serverless: unavailable` [Authenticate to the {{kib}} API with a service account](authenticate-kibana-api-with-service-account.md).
 - Learn more about [service account types and credentials](service-accounts.md).
diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md b/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
index a22af53d37f..b19ff9763b2 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
@@ -55,7 +55,7 @@ stack: ga 9.6+
 serverless: ga
 ```
 
-You create these accounts and assign roles to control their privileges. The accounts belong to the deployment on {{stack}} or to the Cloud organization on {{serverless-short}}, rather than to the user who created them. In {{stack}}, accounts created in {{kib}} use the `kibana` namespace, and their principals have the form `kibana/<name>`.
+You create user-managed service accounts and assign roles to control their privileges. These accounts belong to the deployment on {{stack}} or to the Cloud organization on {{serverless-short}}, rather than to the user who created them. In {{stack}}, accounts created in {{kib}} use the `kibana` namespace, and their principals have the form `kibana/<name>`.
 
 Use a user-managed service account when your workload needs its own identity to access {{es}} or {{kib}} APIs. Assign the roles required by the workload.
 
@@ -103,7 +103,7 @@ For example, {{fleet}} server uses a service token to authenticate with {{es}} a
 
 :::{note}
 :applies_to: stack: ga 9.6+
-When you create a user-managed service account in {{kib}}, {{kib}} creates and stores a service token so applications such as Workflows can run on behalf of the account. This token isn't displayed. To authenticate requests from your own application, create an additional service token with the API.
+When you create a user-managed service account in {{kib}}, {{kib}} creates and stores a service token named `kibana-managed` so applications such as Workflows can run on behalf of the account. This token isn't displayed. To authenticate requests from your own application, create an additional service token with the API.
 :::
 
 You can create a service token using either:

From 3177cfc9de4f448fd2ebe7c9bc8de7fb341a03e4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Mon, 9 Nov 2026 18:00:12 +0100
Subject: [PATCH 41/45] reviewing progress

---
 deploy-manage/users-roles/cloud-organization.md             | 2 ++
 .../manage-service-accounts-in-kibana.md                    | 6 ++----
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/deploy-manage/users-roles/cloud-organization.md b/deploy-manage/users-roles/cloud-organization.md
index b440c0f4e1f..1100b8f1e06 100644
--- a/deploy-manage/users-roles/cloud-organization.md
+++ b/deploy-manage/users-roles/cloud-organization.md
@@ -24,6 +24,8 @@ You can perform the following tasks to control access to your Cloud organization
 
 You can also control programmatic access to {{ecloud}}, your deployments, and your projects using [API keys](/deploy-manage/api-keys.md).
 
+For workloads that run within {{kib}} applications in {{serverless-short}} projects, you can also use [user-managed service accounts](/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md).
+
 :::{tip}
 If you're using {{ech}}, then you can also manage users and control access [at the deployment level](/deploy-manage/users-roles/cluster-or-deployment-auth.md).
 :::
diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md b/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
index 955fbe4abed..9de01a8dc2f 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/manage-service-accounts-in-kibana.md
@@ -18,8 +18,6 @@ products:
 
 Create user-managed service accounts and assign roles to control programmatic access to {{es}} and {{kib}} APIs. Accounts created in {{kib}} are ready to use with {{kib}} applications such as [Workflows](/explore-analyze/workflows.md). On {{stack}} deployments, you can also use them with your own applications by [creating a service token](authenticate-kibana-api-with-service-account.md#create-service-account-api-token).
 
-Some service account capabilities differ between [{{serverless-full}}](/deploy-manage/deploy/elastic-cloud/serverless.md) and other [deployment types](/deploy-manage/deploy.md#choosing-your-deployment-type). This guide uses {{stack}} deployments to refer to {{ech}}, {{ece}}, {{eck}}, and self-managed deployments.
-
 :::{note}
 :applies_to: serverless: ga
 On {{serverless-short}}, user-managed service accounts can only be used within {{kib}} applications. For programmatic access from external applications, use [API keys](/deploy-manage/api-keys.md).
@@ -127,9 +125,9 @@ If you force delete an account, workloads assigned to it fail on their next run.
 serverless: unavailable
 ```
 
-Deleting an account through {{kib}} attempts to remove every service token, including the credential it stores for workloads and tokens created outside {{kib}}. If any credential cleanup fails, {{kib}} completes the deletion and reports a warning.
+Deleting an account through {{kib}} attempts to remove every service token, including the credential it stores for workloads and tokens created outside {{kib}}. It also attempts to invalidate any short-lived access tokens used to run workloads as the account. If any credential cleanup fails, {{kib}} completes the deletion and reports a warning.
 
-A service token left behind after deletion can't authenticate, but it prevents you from creating another account with the same name until you delete the token. If you delete an account directly through the {{es}} API, short-lived access tokens already issued to the account remain valid until they expire, 20 minutes after issuance by default.
+A service token left behind after deletion can't authenticate, but it prevents you from creating another account with the same name until you delete the token.
 
 :::{important}
 API keys owned by the account aren't invalidated when you delete the account. {{rules-ui}} and tasks that obtained an API key while authenticated as the account can continue to run with that key. To revoke this access, [invalidate the API keys]({{es-apis}}operation/operation-security-invalidate-api-key) explicitly.

From 37039bc8651da5f392552af40d1bf3b426f8f1bf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Mon, 9 Nov 2026 18:06:21 +0100
Subject: [PATCH 42/45] Consolidate Serverless service account guidance

AI-Assisted: Codex
---
 .../service-accounts.md                       | 21 +++++--------------
 1 file changed, 5 insertions(+), 16 deletions(-)

diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md b/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
index b19ff9763b2..8b3e0221550 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
@@ -47,7 +47,7 @@ The following built-in accounts are available:
 
 The `elastic` namespace is reserved for built-in accounts.
 
-In {{stack}}, you can create and delete service tokens for these accounts, but you can't change their predefined privileges.
+In {{stack}}, you can create and delete service tokens for these accounts, but you can't change their predefined privileges. On {{serverless-short}}, Elastic manages their credentials.
 
 ### User-managed service accounts [user-managed-service-accounts]
 ```{applies_to}
@@ -55,7 +55,9 @@ stack: ga 9.6+
 serverless: ga
 ```
 
-You create user-managed service accounts and assign roles to control their privileges. These accounts belong to the deployment on {{stack}} or to the Cloud organization on {{serverless-short}}, rather than to the user who created them. In {{stack}}, accounts created in {{kib}} use the `kibana` namespace, and their principals have the form `kibana/<name>`.
+You create user-managed service accounts and assign roles to control their privileges. These accounts belong to the deployment on {{stack}} or to the Cloud organization on {{serverless-short}}, rather than to the user who created them.
+
+In {{stack}}, accounts created in {{kib}} use the `kibana` namespace, and their principals have the form `kibana/<name>`. On {{serverless-short}}, accounts have a generated identifier that is independent of the name you enter in {{kib}}.
 
 Use a user-managed service account when your workload needs its own identity to access {{es}} or {{kib}} APIs. Assign the roles required by the workload.
 
@@ -63,7 +65,7 @@ Use a user-managed service account when your workload needs its own identity to
 
 :::{note}
 :applies_to: serverless: ga
-On {{serverless-short}}, user-managed service accounts can only be used within {{kib}} applications. For programmatic access from external applications, use [API keys](/deploy-manage/api-keys.md).
+On {{serverless-short}}, user-managed service accounts can only be used within {{kib}} applications. The {{es}} service account APIs aren't available for these accounts. For programmatic access from external applications, use [API keys](/deploy-manage/api-keys.md).
 :::
 
 To manage service accounts and use them in your workloads:
@@ -78,19 +80,6 @@ On {{stack}}, the {{es}} API reference also documents these operations:
 - [Create or replace an account]({{es-apis}}operation/operation-security-put-user-managed-service-account).
 - [Delete an account]({{es-apis}}operation/operation-security-delete-user-managed-service-account).
 
-### Service accounts in {{serverless-short}} [service-accounts-serverless]
-```{applies_to}
-serverless: ga
-```
-
-{{serverless-short}} uses the same [built-in service accounts](#built-in-service-accounts), with credentials managed by Elastic.
-
-User-managed accounts have a generated identifier that is independent of the name you enter in {{kib}}. Their identifiers don't use the `<namespace>/<service>` principal format of {{stack}} accounts.
-
-You can assign a user-managed account to a workflow, and {{kib}} manages the short-lived credentials used to run it. You can't obtain a token for an external application or manage these accounts through the {{es}} service account APIs. The service token instructions on this page apply to {{stack}}.
-
-The account's privileges are limited to those allowed by both its assigned roles and its creator's access at creation time. For details about role limits, cross-project search, and deleting accounts, refer to [Create and manage service accounts in {{kib}}](manage-service-accounts-in-kibana.md).
-
 ## Service account tokens [service-accounts-tokens]
 ```{applies_to}
 stack: all

From 613d0b383b448f1814769d435856bc300572fdaa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Mon, 9 Nov 2026 18:09:10 +0100
Subject: [PATCH 43/45] Clarify service account token credentials and
 authentication

AI-Assisted: Codex
---
 .../users-roles/cluster-or-deployment-auth/service-accounts.md  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md b/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
index 8b3e0221550..38d57fda5f8 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
@@ -86,7 +86,7 @@ stack: all
 serverless: unavailable
 ```
 
-A service account token, or service token, is a unique string that a service uses to authenticate with {{es}}. For a given service account, each token must have a unique name. Because tokens include access credentials, they should always be kept secret by whichever client is using them.
+A service account token, or service token, is a credential that a service or workload uses to authenticate with {{es}}. User-managed service accounts can also use service tokens to authenticate with {{kib}}. Keep service tokens secret.
 
 For example, {{fleet}} server uses a service token to authenticate with {{es}} and manage its own API keys. You can create multiple service tokens for the same service account. This lets multiple instances of a service use the same identity without sharing credentials.
 

From 2e6baeca9d12a4c4b7a846b648400b55cd093504 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Mon, 9 Nov 2026 18:14:34 +0100
Subject: [PATCH 44/45] Refine service token API authentication and secrecy
 guidance

AI-Assisted: Codex
---
 .../users-roles/cluster-or-deployment-auth/service-accounts.md  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md b/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
index 38d57fda5f8..af9f618cd0d 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
@@ -86,7 +86,7 @@ stack: all
 serverless: unavailable
 ```
 
-A service account token, or service token, is a credential that a service or workload uses to authenticate with {{es}}. User-managed service accounts can also use service tokens to authenticate with {{kib}}. Keep service tokens secret.
+A service account token, or service token, is a credential that a service or workload uses to authenticate requests to {{es}} or {{kib}} APIs. Treat service tokens as secrets: anyone who has a valid token can authenticate as the service account.
 
 For example, {{fleet}} server uses a service token to authenticate with {{es}} and manage its own API keys. You can create multiple service tokens for the same service account. This lets multiple instances of a service use the same identity without sharing credentials.
 

From 679a6b6dacb51e4e53babd8eea90beabc957c23f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Edu=20Gonz=C3=A1lez=20de=20la=20Herr=C3=A1n?=
 <25320357+eedugon@users.noreply.github.com>
Date: Mon, 9 Nov 2026 18:26:28 +0100
Subject: [PATCH 45/45] Clarify Kibana account creation and Fleet service token
 generation

AI-Assisted: Codex
---
 .../cluster-or-deployment-auth/service-accounts.md         | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md b/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
index af9f618cd0d..64a66da9db7 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md
@@ -61,7 +61,7 @@ In {{stack}}, accounts created in {{kib}} use the `kibana` namespace, and their
 
 Use a user-managed service account when your workload needs its own identity to access {{es}} or {{kib}} APIs. Assign the roles required by the workload.
 
-[Workflows](/explore-analyze/workflows.md) is the only {{kib}} application that supports directly assigning a service account as the execution identity of a workload. {{kib}} manages the credential used for this integration.
+[Workflows](/explore-analyze/workflows.md) is the only {{kib}} application that supports directly assigning a service account as the execution identity of a workload. To use this integration, create the service account in {{kib}}, which manages the credential for you.
 
 :::{note}
 :applies_to: serverless: ga
@@ -92,13 +92,14 @@ For example, {{fleet}} server uses a service token to authenticate with {{es}} a
 
 :::{note}
 :applies_to: stack: ga 9.6+
-When you create a user-managed service account in {{kib}}, {{kib}} creates and stores a service token named `kibana-managed` so applications such as Workflows can run on behalf of the account. This token isn't displayed. To authenticate requests from your own application, create an additional service token with the API.
+When you [create a user-managed service account in {{kib}}](manage-service-accounts-in-kibana.md), {{kib}} creates and stores a service token named `kibana-managed` so applications such as Workflows can run on behalf of the account. This token isn't displayed. To authenticate requests from your own application, create an additional service token with the API.
 :::
 
-You can create a service token using either:
+You can create a service token using the following methods:
 
 * The [create service account token API]({{es-apis}}operation/operation-security-create-service-token) (recommended). The API stores the token in the `.security` index and returns the bearer token in the HTTP response. Tokens are available for authentication on all nodes and are included in cluster snapshots.
 * The [elasticsearch-service-tokens](elasticsearch://reference/elasticsearch/command-line-tools/service-tokens-command.md) CLI tool, for built-in accounts on self-managed and {{eck}} deployments. The tool stores the token in the [`$ES_HOME/config/service_tokens` file](elasticsearch://reference/elasticsearch/command-line-tools/service-tokens-command.md) and outputs the bearer token to your terminal. This method is intended for environments where an external orchestration process, such as [{{ece}}](/deploy-manage/deploy/cloud-enterprise.md) or [{{eck}}](/deploy-manage/deploy/cloud-on-k8s.md), manages and distributes the file.
+* The {{fleet}} UI in {{kib}}, for the built-in `elastic/fleet-server` account. Click **Generate service token** when [adding a {{fleet-server}}](/reference/fleet/add-fleet-server-on-prem.md#add-fleet-server-on-prem-add-server).
 
 Both the API and CLI generate service tokens with a 22-character secret. {{es}} requires a secret of at least 10 characters and rejects shorter secrets without checking their value.