diff --git a/content/actions/how-tos/secure-your-work/security-harden-deployments/index.md b/content/actions/how-tos/secure-your-work/security-harden-deployments/index.md
index 77ef5ef2a711..3d072238b1e0 100644
--- a/content/actions/how-tos/secure-your-work/security-harden-deployments/index.md
+++ b/content/actions/how-tos/secure-your-work/security-harden-deployments/index.md
@@ -13,6 +13,7 @@ versions:
 children:
   - /oidc-in-aws
   - /oidc-in-azure
+  - /oidc-in-docker
   - /oidc-in-google-cloud-platform
   - /oidc-in-hashicorp-vault
   - /oidc-in-jfrog
diff --git a/content/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-docker.md b/content/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-docker.md
new file mode 100644
index 000000000000..c2609b765886
--- /dev/null
+++ b/content/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-docker.md
@@ -0,0 +1,109 @@
+---
+title: Configuring OpenID Connect in Docker
+shortTitle: OIDC in Docker
+intro: Use OpenID Connect within your workflows to authenticate with Docker without storing long-lived credentials.
+versions:
+  fpt: '*'
+  ghec: '*'
+contentType: how-tos
+category:
+  - Secure your workflows
+---
+
+## Overview
+
+OpenID Connect (OIDC) allows your {% data variables.product.prodname_actions %} workflows to authenticate with [Docker](https://www.docker.com/) to access Docker Hub and Docker Build Cloud without storing Docker passwords, {% data variables.product.pat_generic_plural %}, or organization access tokens (OATs) in {% data variables.product.company_short %}.
+
+Instead of managing long-lived credentials, you configure a trust relationship between your {% data variables.product.prodname_dotcom %} organization and your Docker organization. When a workflow runs, {% data variables.product.prodname_dotcom %} issues a short-lived OIDC token that Docker validates against your configured rulesets, then issues a scoped access token for the workflow.
+
+This guide gives an overview of how to configure Docker to trust {% data variables.product.prodname_dotcom %}'s OIDC as a federated identity, and demonstrates how to use this configuration in a {% data variables.product.prodname_actions %} workflow.
+
+For more information, see [OIDC connections](https://docs.docker.com/enterprise/security/oidc-connections/) in the Docker documentation.
+
+## Prerequisites
+
+{% data reusables.actions.oidc-link-to-intro %}
+
+{% data reusables.actions.oidc-security-notice %}
+
+{% data reusables.actions.oidc-on-ghecom %}
+
+* Your Docker organization must use Docker Business, Docker Team, or Docker Hardened Images, or be enrolled in the Docker Sponsored Open Source Program.
+* You must be an organization owner or editor in your Docker organization.
+* You must plan which repositories, branches, and workflows need access to Docker, and configure rulesets accordingly.
+
+## Adding the identity provider to Docker
+
+To use OIDC with Docker, establish a trust relationship between {% data variables.product.prodname_actions %} and Docker by creating an OIDC connection. For more information about this process, see [Create and manage OIDC connections](https://docs.docker.com/security/authentication/oidc-connections/create-manage/) in the Docker documentation.
+
+1. Sign in to [Docker Home](https://app.docker.com/) and navigate to your organization.
+1. Go to **Identity & auth** > **OIDC connections**.
+1. Select **Create OIDC connection**.
+1. Configure at least one ruleset to define which {% data variables.product.prodname_dotcom %} repositories, branches, or workflows can authenticate. Each ruleset specifies:
+   * **Rules**: Conditions matched against OIDC token claims (repository, branch, workflow path). Wildcard patterns like `repo:my-org/*` are supported.
+   * **Resources**: Docker Hub repositories or Docker Build Cloud projects the workflow can access.
+   * **Scopes**: Permission levels (`read`, `write`).
+1. Save the connection and copy the **connection ID** for use in your workflow.
+
+## Updating your {% data variables.product.prodname_actions %} workflow
+
+Once you have created an OIDC connection in Docker, update your workflow to authenticate using the [`docker/login-action`](https://github.com/docker/login-action) action.
+
+The following example uses the placeholder `YOUR-CONNECTION-ID` for the connection ID you copied from Docker, and `YOUR-DOCKER-ORG` for your Docker organization name.
+
+```yaml
+{% data reusables.actions.actions-not-certified-by-github-comment %}
+permissions:
+  id-token: write
+  contents: read
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Check out repository
+        uses: {% data reusables.actions.action-checkout %}
+
+      - name: Sign in to Docker Hub with OIDC
+        uses: docker/login-action@abd2ef45e78c5afb21d64d4ca52ee8550d9572c7 # v4.5.1
+        with:
+          username: YOUR-DOCKER-ORG
+        env:
+          DOCKERHUB_OIDC_CONNECTIONID: YOUR-CONNECTION-ID
+
+      - name: Build and push
+        uses: docker/build-push-action@10e90e3645eae34f1e60eeb005ba3a3d33f178e8 # v6
+        with:
+          push: true
+          tags: YOUR-DOCKER-ORG/my-image:latest
+```
+
+### Key workflow settings
+
+* **`permissions.id-token: write`** is required so that {% data variables.product.prodname_dotcom %} can issue an OIDC token for the workflow.
+* The `docker/login-action` handles the OIDC token exchange and Docker login in a single step when `DOCKERHUB_OIDC_CONNECTIONID` is set and `password` is omitted.
+* The `username` field should be your Docker organization name.
+
+### Subject claim matching
+
+Docker evaluates the `sub` claim from the {% data variables.product.prodname_dotcom %} OIDC token against the rulesets you configured. The default subject claim format is:
+
+```text
+repo:<owner>/<repo>:ref:refs/heads/<branch>
+```
+
+> [!NOTE]
+> Repositories created after July 15, 2026, and repository renames or transfers after that date, use an immutable default OIDC `sub` claim that includes owner and repository IDs. Existing repositories keep the previous format unless they opt in. For more information, see [AUTOTITLE](/actions/reference/security/oidc#immutable-subject-claims).
+
+Different workflow triggers produce different subject claims. For example:
+
+| Trigger | Subject claim format |
+|---------|---------------------|
+| Branch push | `repo:my-org/my-repo:ref:refs/heads/main` |
+| Pull request | `repo:my-org/my-repo:pull_request` |
+| Tag | `repo:my-org/my-repo:ref:refs/tags/v1.0` |
+| Environment | `repo:my-org/my-repo:environment:production` |
+
+You can use wildcard patterns in your rulesets to match multiple repositories or branches. For legacy subject claims, `repo:my-org/*` matches all repositories in the organization. For immutable subject claims, use `repo:my-org@OWNER-ID/*`; if the organization contains repositories using both formats, configure both patterns.
+
+For more information, see [Rulesets and subject claims](https://docs.docker.com/security/authentication/oidc-connections/rulesets-claims/) in the Docker documentation.
diff --git a/content/admin/managing-iam/respond-to-incidents/revoke-authorizations-or-tokens.md b/content/admin/managing-iam/respond-to-incidents/revoke-authorizations-or-tokens.md
index ee634ed1b72b..e6dbee7e103a 100644
--- a/content/admin/managing-iam/respond-to-incidents/revoke-authorizations-or-tokens.md
+++ b/content/admin/managing-iam/respond-to-incidents/revoke-authorizations-or-tokens.md
@@ -102,6 +102,9 @@ Deleting keys and tokens removes credentials that have access to your enterprise
 
 {% ifversion single_user_cred_revocation %}For example, you can delete all {% data variables.product.pat_generic_plural %} for an individual member without affecting that member's SSH keys.{% endif %} To restore programmatic access, users must create new credentials, authorize them with organizations if required, and update affected processes to use the new credentials.
 
+> [!WARNING]
+> The "Delete keys and tokens" action is not a point-in-time operation. Credential deletion runs asynchronously and processes enterprise members in batches. Credentials created after the action starts may also be deleted if processing is still underway. To avoid deleting replacement credentials, create them only after the operation has finished.
+
 ### Included credentials
 
 Both actions include the following credential types: