diff --git a/website/docs/add-secure-apps/flows-stages/stages/authenticator_endpoint_gdtc/index.mdx b/website/docs/add-secure-apps/flows-stages/stages/authenticator_endpoint_gdtc/index.mdx
index b002743d9a9a..d8d3c6b642a5 100644
--- a/website/docs/add-secure-apps/flows-stages/stages/authenticator_endpoint_gdtc/index.mdx
+++ b/website/docs/add-secure-apps/flows-stages/stages/authenticator_endpoint_gdtc/index.mdx
@@ -21,7 +21,7 @@ Typical use cases included remote-work, contractor, and BYOD environments where
 
 ## Configuration options
 
-- **Credentials**: Google service-account JSON used to access the Chrome Verified Access API.
+- **Credentials**: a **JSON** [secret](../../../../sys-mgmt/secrets/index.mdx) containing the Google service account key used to access the Chrome Verified Access API.
 - **Authenticator type name**: optional friendly name shown to the user in self-service settings.
 - **Configuration flow**: optional authenticated flow that exposes the stage in user settings.
 
@@ -58,7 +58,7 @@ More concretely:
 3. In **IAM** > **Service Accounts**, create a service account.
 4. Generate a JSON key from the service account's **Keys** tab.
 5. In the Google admin side, configure a new provider under **Chrome browser > Connectors** and point it at your authentik URL, for example `https://authentik.company/endpoint/gdtc/chrome/`.
-6. Paste the exported JSON key into the stage's **Credentials** field in authentik.
+6. In the stage's **Credentials** field, create or select a **JSON** secret containing the exported JSON key.
 
 ### Why this stage is different
 
diff --git a/website/docs/add-secure-apps/outposts/integrations/kubernetes.mdx b/website/docs/add-secure-apps/outposts/integrations/kubernetes.mdx
index fbcac8d2fa81..70e422352184 100644
--- a/website/docs/add-secure-apps/outposts/integrations/kubernetes.mdx
+++ b/website/docs/add-secure-apps/outposts/integrations/kubernetes.mdx
@@ -70,4 +70,10 @@ The required permissions for this integration are documented in the Helm chart:
 
 To connect a remote cluster, install the [`authentik-remote-cluster` Helm chart](https://artifacthub.io/packages/helm/goauthentik/authentik-remote-cluster) in the target cluster and namespace.
 
-After installation, the chart outputs an example kubeconfig file. Add that kubeconfig to authentik to connect to the cluster.
+After installation, the chart outputs an example kubeconfig file. Store it as an authentik [secret](../../../sys-mgmt/secrets/index.mdx) and select that secret when you configure the remote connection:
+
+1. In the Admin interface, go to **System** > **Outpost Integrations**.
+2. Click **New Outpost Integration** and choose **Kubernetes**.
+3. Enter a name and disable **Local connection**.
+4. Beside the **Kubeconfig** field, click **Create secret**, select the **JSON** type, and paste the kubeconfig's YAML as the value.
+5. Select the new secret and save the integration.
diff --git a/website/docs/add-secure-apps/providers/gws/create-gws-provider.mdx b/website/docs/add-secure-apps/providers/gws/create-gws-provider.mdx
index faa340c892de..5d11acf8e59a 100644
--- a/website/docs/add-secure-apps/providers/gws/create-gws-provider.mdx
+++ b/website/docs/add-secure-apps/providers/gws/create-gws-provider.mdx
@@ -17,7 +17,7 @@ To create a Google Workspace provider in authentik, you must have already [confi
 4. On the **New Google Workspace Provider** page, set the following configurations:
     - **Name**: provide a descriptive name (e.g. `GWS provider`)
     - Under **Protocol settings**:
-        - **Credentials**: paste the contents of the JSON file that you downloaded when [configuring Google Workspace](./configure-gws.mdx)
+        - **Credentials**: create or select a **JSON** [secret](../../../sys-mgmt/secrets/index.mdx) containing the JSON key that you downloaded when [configuring Google Workspace](./configure-gws.mdx).
         - **Delegated Subject**: enter the email address of the Google Workspace user that all authentik actions will be delegated to
         - **Default group email domain**: enter a domain which will be used to generate the email address for groups synced from authentik to Google Workspace
         - **User deletion action**: controls what happens in Google Workspace when a user is deleted from authentik. Defaults to **Delete**. See [Deletion and offboarding](./index.mdx#deletion-and-offboarding) for the available actions and their effects
diff --git a/website/docs/add-secure-apps/providers/oauth2/create-oauth2-provider.mdx b/website/docs/add-secure-apps/providers/oauth2/create-oauth2-provider.mdx
index a3ffb3055381..a75fd9b18832 100644
--- a/website/docs/add-secure-apps/providers/oauth2/create-oauth2-provider.mdx
+++ b/website/docs/add-secure-apps/providers/oauth2/create-oauth2-provider.mdx
@@ -12,6 +12,8 @@ To create a provider along with the corresponding application that uses it for a
 5. On the **Configure Provider** page, provide the required configuration settings.
 6. Click **Create Application** to create both the application and the provider.
 
+A confidential client's client secret is stored as a [secret](../../../sys-mgmt/secrets/index.mdx). If you don't select one, authentik creates a secret with a generated value. To share a client secret between providers, select the same secret on each. When you [rotate the secret](../../../sys-mgmt/secrets/manage-secrets.mdx#rotate-a-secret), clients that still use the old value are rejected, and if the provider has no signing key, ID tokens signed with the old value no longer validate. Update every client after rotating.
+
 :::info
 Optionally, configure the provider with the `offline_access` scope mapping. By default, applications only receive an access token. To receive a refresh token, applications and authentik must be configured to request the `offline_access` scope. Do this in the Scope mapping area on the **Configure OAuth2/OpenID Provider** page.
 :::
diff --git a/website/docs/add-secure-apps/providers/radius/index.mdx b/website/docs/add-secure-apps/providers/radius/index.mdx
index 4083826a0b24..43a70436af9e 100644
--- a/website/docs/add-secure-apps/providers/radius/index.mdx
+++ b/website/docs/add-secure-apps/providers/radius/index.mdx
@@ -14,6 +14,10 @@ This provider requires the deployment of a [RADIUS outpost](../../outposts/index
 
 Currently, only authentication requests are supported.
 
+### Shared secret
+
+The shared secret is stored as a [secret](../../../sys-mgmt/secrets/index.mdx). If you don't select one when you create the provider, authentik creates a secret with a generated value. When you [rotate the secret](../../../sys-mgmt/secrets/manage-secrets.mdx#rotate-a-secret), the outpost receives the new value automatically, and RADIUS clients that still use the old value are rejected until you update them.
+
 ### Authentication flow
 
 Authentication requests against the Radius Server use a flow in the background. This allows you to use the same flows, stages, and policies as you do for web-based logins.
diff --git a/website/docs/customize/blueprints/v1/structure.mdx b/website/docs/customize/blueprints/v1/structure.mdx
index 38bebeb062c0..e200c218355e 100644
--- a/website/docs/customize/blueprints/v1/structure.mdx
+++ b/website/docs/customize/blueprints/v1/structure.mdx
@@ -78,7 +78,7 @@ entries:
       # as these values will override existing attributes.
       # Note: When creating objects, identifiers and attrs are merged together.
       # On updates (state: present), only fields specified in attrs are modified - other
-      # fields (like auto-generated client_id/client_secret) are left unchanged.
+      # fields (like auto-generated client_id/client_secret_ref) are left unchanged.
       attrs:
           denied_action: message_continue
           designation: stage_configuration
diff --git a/website/docs/endpoint-devices/device-compliance/connectors/google-chrome.mdx b/website/docs/endpoint-devices/device-compliance/connectors/google-chrome.mdx
index 3092054f2afa..b60a6556cf33 100644
--- a/website/docs/endpoint-devices/device-compliance/connectors/google-chrome.mdx
+++ b/website/docs/endpoint-devices/device-compliance/connectors/google-chrome.mdx
@@ -69,7 +69,7 @@ For detailed instructions, refer to Google documentation.
 3. Select **Google Device Trust Connector** as the connector type, click **Next**, and configure the following settings:
     - **Name**: define a descriptive name, such as "chrome-device-trust".
     - **Google Verified Access API**
-        - **Credentials**: paste the contents of the JSON file (the key) that you downloaded earlier.
+        - **Credentials**: create or select a **JSON** [secret](../../../sys-mgmt/secrets/index.mdx) containing the JSON key that you downloaded earlier.
 
 4. Click **Finish**.
 
diff --git a/website/docs/releases/2026/v2026.11.mdx b/website/docs/releases/2026/v2026.11.mdx
index 0de2b580b96b..8aa2c5b370b8 100644
--- a/website/docs/releases/2026/v2026.11.mdx
+++ b/website/docs/releases/2026/v2026.11.mdx
@@ -8,6 +8,32 @@ draft: true
 
 ## Breaking changes
 
+### Credentials are stored as secrets
+
+Credentials that were stored on providers, sources, stages, and connectors are now stored as [secrets](../../sys-mgmt/secrets/index.mdx), which those objects reference. This applies to credentials such as:
+
+- OAuth2/OpenID client secrets
+- Proxy provider cookie secrets
+- RADIUS shared secrets
+- LDAP and Kerberos source bind and sync passwords
+- OAuth, Plex, and Telegram source credentials
+- SCIM provider tokens and Basic authentication passwords
+- SMTP passwords
+- Duo, captcha, and SMS stage keys
+- Notification transport webhook URLs
+- Microsoft Entra and Fleet credentials
+- Google service account keys
+- Kubernetes kubeconfigs
+- Kerberos keytabs and credential caches
+
+During the upgrade, authentik creates a secret for each existing credential with its exact value, and copies existing role permissions to the new secrets. See [Permissions after upgrading](../../sys-mgmt/secrets/permissions.mdx#permissions-after-upgrading).
+
+The credential fields in the API and blueprints, such as `client_secret`, `shared_secret`, `bind_password`, and `token`, are replaced by reference fields named `<field>_ref`, such as `client_secret_ref`. Requests and blueprints that still set an old field fail with a validation error that names the new field. In blueprints, define the secret as its own entry and reference it with `!KeyOf` or `!Find`. Blueprint exports no longer include credential values, including OAuth2 client secrets and RADIUS shared secrets that earlier exports contained. See [API and blueprints](../../sys-mgmt/secrets/index.mdx#api-and-blueprints).
+
+:::info
+The previous credential database columns are kept until 2027.2 to support downgrades.
+:::
+
 ### RAC endpoints are now devices
 
 RAC providers now use [devices](../../endpoint-devices/index.mdx) instead of maintaining separate endpoints. This allows machines enrolled through connectors, such as the authentik agent, to be accessed directly through RAC without configuring them again.
@@ -66,6 +92,18 @@ The **Base URL** [system setting](../../sys-mgmt/settings.mdx#base-url), introdu
 
 - **Display names in `ak_send_email` recipients**: The `address`, `cc`, and `bcc` parameters of `ak_send_email` now accept `(name, email)` tuples and `"Name <email>"` strings, so emails sent from expressions can include a display name in the `To` and `CC` headers, matching the Email stage. See [`ak_send_email`](../../customize/policies/types/expression/reference.mdx).
 
+### Secrets
+
+Manage the credentials used by providers, sources, stages, and connectors under **System** > **Secrets**, or create them directly from the form that uses them.
+
+Each secret has its own permissions, so a role can edit an integration without being able to read its password. Viewing a value and replacing or rotating it require their own permissions, and authentik records an event each time someone does either.
+
+Several objects can reference the same secret, so you update a shared credential in one place. You can rotate text secrets from the Admin interface or the API. Rotation changes the value in authentik only, so update the clients that use it afterward.
+
+Secret values are stored unencrypted in the database, as these credentials were before.
+
+See [Secrets](../../sys-mgmt/secrets/index.mdx).
+
 ### Single sign-on into devices managed by the authentik agent
 
 A RAC provider signs into devices which are enrolled through the authentik agent as the user who launched the connection, with no credentials configured for the device. authentik issues a token for the device, the RAC outpost turns it into an SSH certificate, and the agent validates the token before accepting the login. See [the RAC provider documentation](../../add-secure-apps/providers/rac/index.mdx#signing-in-with-the-authentik-agent).
diff --git a/website/docs/sys-mgmt/events/event-actions.mdx b/website/docs/sys-mgmt/events/event-actions.mdx
index 051a9e5f645d..18246f8aa6b2 100644
--- a/website/docs/sys-mgmt/events/event-actions.mdx
+++ b/website/docs/sys-mgmt/events/event-actions.mdx
@@ -193,11 +193,11 @@ A user sets their password.
 
 ### `secret_view`
 
-A user views a token's/certificate's data.
+A user views the data of a token, certificate, or secret.
 
 ### `secret_rotate`
 
-A token was rotated automatically by authentik.
+A secret's value was replaced, either by [rotation](../secrets/manage-secrets.mdx#rotate-a-secret) or by entering a new value. authentik also records this event when it rotates a token automatically.
 
 ### `invitation_used`
 
diff --git a/website/docs/sys-mgmt/secrets/index.mdx b/website/docs/sys-mgmt/secrets/index.mdx
new file mode 100644
index 000000000000..bdf8b61c4b3a
--- /dev/null
+++ b/website/docs/sys-mgmt/secrets/index.mdx
@@ -0,0 +1,90 @@
+---
+title: Secrets
+description: "Store the credentials that providers, sources, stages, and connectors use."
+authentik_version: "2026.11"
+---
+
+A secret is a named credential, such as an OAuth2 client secret, an LDAP bind password, or an SMTP password. Providers, sources, stages, and connectors reference a secret instead of storing the credential themselves. Several objects can share one secret, each secret has its own [permissions](./permissions.mdx), and authentik records an event whenever someone views or replaces a value.
+
+Manage secrets in the Admin interface under **System** > **Secrets**. Every form that uses a credential has a secret picker, with buttons to create a secret, view its value, and, for text secrets, rotate it.
+
+- [Manage secrets](./manage-secrets.mdx): create, reuse, replace, rotate, and delete secrets.
+- [Secret permissions](./permissions.mdx): control who can see, use, and change a secret.
+
+## Secret types
+
+Choose a type when you create a secret. You can't change it afterward.
+
+- **Text**: any text value, which can span several lines, such as a password, token, or PEM-encoded private key. authentik can generate and [rotate](./manage-secrets.mdx#rotate-a-secret) text values.
+- **JSON**: a JSON or YAML object, such as a Google service account key or a kubeconfig. authentik validates the value when you save it, and rejects values that have no JSON equivalent, such as YAML dates.
+- **File**: an uploaded binary file, such as a Kerberos keytab or credential cache.
+
+Each credential field accepts only the types that fit it, and its secret picker lists only those secrets.
+
+## Storage
+
+:::warning
+authentik stores secret values unencrypted in its database, the same way it stored these credentials before secrets existed. File values are base64-encoded, which is not encryption. Secrets don't replace a dedicated secrets manager such as HashiCorp Vault. Restrict access to the database and its backups.
+:::
+
+## Objects that use secrets
+
+An object holds a reference to a secret, not a copy of its value. When you change a secret's value, every object that references it uses the new value.
+
+The following objects store their credentials as secrets:
+
+- OAuth2/OpenID providers (client secret)
+- Proxy providers (cookie secret)
+- RADIUS providers (shared secret)
+- SCIM providers (token and Basic authentication password)
+- Google Workspace providers and Microsoft Entra providers (credentials)
+- LDAP sources (bind password)
+- Kerberos sources (sync password, keytabs, and credential caches). A keytab or credential cache is either a **File** secret with its contents, or a **Text** secret with its location in the form `TYPE:residual`.
+- OAuth, Plex, and Telegram sources (consumer secret and tokens)
+- Duo, SMS, and email authenticator setup stages (API keys and SMTP passwords)
+- Captcha stages (private key) and email stages (SMTP password)
+- Google Chrome Device Trust authenticator stages, Google Chrome connectors, and Fleet connectors (credentials)
+- Notification transports (webhook URL)
+- Kubernetes service connections (kubeconfig)
+
+### Generated provider secrets
+
+When you create an OAuth2/OpenID, Proxy, or RADIUS provider without selecting a secret, the provider creates one with a generated value in its usual format:
+
+- OAuth2/OpenID client secrets: 128 characters
+- Proxy cookie secrets: 32 characters
+- RADIUS shared secrets: 40 characters
+
+After creation, these providers always reference a secret. On OAuth2/OpenID and RADIUS providers you can select a different secret, but you can't clear the field. Proxy providers manage their cookie secret themselves; rotate it under **System** > **Secrets**.
+
+## API and blueprints
+
+Manage secrets through the `/api/v3/secrets/secrets/` endpoint. The value is the write-only `value` field, so list and detail responses never include it. When you create a text secret without a value, the optional `length` field sets the length of the generated value. Use the `view_value` action to read a value and the `rotate` action to replace a text value with a generated one. See the [API reference](https://api.goauthentik.io/) for request details.
+
+Objects reference a secret by its UUID through fields named after the credential field they replace, with a `_ref` suffix. For example, `client_secret_ref` on OAuth2 providers, `shared_secret_ref` on RADIUS providers, `bind_password_ref` on LDAP sources, and `sync_keytab_ref` and `spnego_ccache_ref` on Kerberos sources. A request or blueprint that sets the old field, such as `client_secret`, fails with a validation error that names the `_ref` field to use instead.
+
+Attaching a secret to an object through the API requires the same permissions as in the Admin interface. See [Use a secret on another object](./permissions.mdx#use-a-secret-on-another-object).
+
+In a [blueprint](../../customize/blueprints/index.mdx), define the secret as its own entry and reference it with [`!KeyOf`](../../customize/blueprints/v1/tags.mdx#keyof). If you omit `value` from a text secret, authentik generates one.
+
+**Example**:
+
+```yaml
+- model: authentik_crypto_secrets.secret
+  id: my-app-client-secret
+  identifiers:
+      name: my-app client secret
+- model: authentik_providers_oauth2.oauth2provider
+  identifiers:
+      name: my-app
+  attrs:
+      client_secret_ref: !KeyOf my-app-client-secret
+```
+
+Blueprint exports include secrets without their values, because `value` is write-only, the same as certificate private keys. Add the values to an exported blueprint before you import it elsewhere. Otherwise authentik generates new values for text secrets and rejects JSON and file secrets.
+
+To reference a secret that already exists, use [`!Find`](../../customize/blueprints/v1/tags.mdx#find):
+
+```yaml
+client_secret_ref: !Find [authentik_crypto_secrets.secret, [name, my-app client secret]]
+```
diff --git a/website/docs/sys-mgmt/secrets/manage-secrets.mdx b/website/docs/sys-mgmt/secrets/manage-secrets.mdx
new file mode 100644
index 000000000000..777f9b4b0e5c
--- /dev/null
+++ b/website/docs/sys-mgmt/secrets/manage-secrets.mdx
@@ -0,0 +1,77 @@
+---
+title: Manage secrets
+description: "Create, reuse, replace, rotate, and delete secrets."
+authentik_version: "2026.11"
+sidebar_position: 1
+---
+
+Each task on this page requires specific secret permissions. Being able to edit a provider or source doesn't let you read or replace its credential. See [Secret permissions](./permissions.mdx).
+
+## Create a secret
+
+To create a secret before you configure the object that uses it:
+
+1. In the Admin interface, go to **System** > **Secrets** and click **New Secret**.
+2. Enter a **Name** that describes the credential's purpose, such as `Production LDAP bind password`. Anyone who can see the secret can see its name, so don't include the credential itself.
+3. Select a **Type**. See [Secret types](./index.mdx#secret-types).
+4. Enter or upload the value:
+    - For a **Text** secret, enter the value issued by the other system, or leave **Value** empty to have authentik generate one. A generated value uses ASCII letters and digits, and has the length in **Length**, or the **Default token length** [system setting](../settings.mdx#default-token-length) if you leave it empty.
+    - For a **JSON** secret, paste the JSON or YAML object.
+    - For a **File** secret, select the file under **File**.
+5. Click **Create Secret**.
+
+To create a secret while you configure an object, click **Create secret** beside the object's secret picker and follow the same steps. authentik saves the secret immediately, so it remains under **System** > **Secrets** even if you cancel the surrounding form.
+
+## Reuse a secret
+
+To use an existing secret, search for it by name in the object's secret picker, select it, and save the object. The object references the secret; it doesn't copy the value.
+
+For example, two email stages that log in to the same SMTP account can share one SMTP password secret. Replacing that secret's value changes the password for both stages.
+
+Use separate secrets when credentials need to change independently or need different permissions.
+
+If a secret is missing from the picker, check that its type fits the field and that you have permission to view it.
+
+## Replace a value
+
+When another system issues a new password, token, or credential file, enter it in authentik:
+
+1. Go to **System** > **Secrets** and click the edit icon on the secret's row.
+2. For a **Text** or **JSON** secret, click **Modify** and enter the **New value**. For a **File** secret, upload the **New file**. Leaving the field empty keeps the current value.
+3. Click **Save Changes**.
+
+Every object that uses the secret switches to the new value. To change the credential of only one object, create a separate secret and select it on that object instead.
+
+authentik records the replacement as a [`secret_rotate`](../events/event-actions.mdx#secret_rotate) event.
+
+## Rotate a secret
+
+Rotating replaces the value of a **Text** secret with a new value that authentik generates. The new value is at least as long as the current one and at least the **Default token length**, so a 128-character OAuth2 client secret stays 128 characters. Rotation is manual. authentik doesn't rotate secrets on a schedule.
+
+:::warning
+Rotation changes the value in authentik only. It doesn't update the clients or external systems that use the credential.
+
+Rotate only secrets that authentik issues, such as an OAuth2 client secret, a proxy cookie secret, or a RADIUS shared secret, and then update the clients that use them. If another system issued the credential, such as an LDAP bind password, a Duo API key, or an SMTP password, rotating it breaks the integration until that system accepts the new value. To change these credentials, [replace the value](#replace-a-value) instead.
+:::
+
+1. Go to **System** > **Secrets**, or open a form that uses the secret.
+2. Click **Rotate secret** on the secret's row or beside the secret picker.
+3. Click **Rotate** to confirm.
+
+The new value takes effect immediately, even if you then cancel the surrounding form. If you have the **View secret's value** permission, authentik shows the new value so that you can copy it to the clients that use it.
+
+Every object that uses the secret switches to the new value, and connected outposts receive it automatically. Some objects need extra care:
+
+- **OAuth2/OpenID providers**: clients that still send the old client secret are rejected. If the provider has no signing key, ID tokens signed with the old value no longer validate.
+- **Proxy providers**: rotating a cookie secret signs out every user of the providers that use it. The confirmation dialog warns about this when a proxy provider uses the secret. Cookie secrets must be at least 32 bytes long.
+- **RADIUS providers**: RADIUS clients that still use the old shared secret are rejected.
+
+authentik records each rotation as a [`secret_rotate`](../events/event-actions.mdx#secret_rotate) event.
+
+## Delete a secret
+
+authentik prevents you from deleting a secret that an object still references, and the delete confirmation lists the objects that use it. Deleting an object doesn't delete its secret, because other objects can reuse it.
+
+1. Change each object that uses the secret to another secret, clear the field if it is optional, or delete the object.
+2. Go to **System** > **Secrets**, select the secret, and click **Delete**.
+3. Confirm the deletion.
diff --git a/website/docs/sys-mgmt/secrets/permissions.mdx b/website/docs/sys-mgmt/secrets/permissions.mdx
new file mode 100644
index 000000000000..07eca242d29e
--- /dev/null
+++ b/website/docs/sys-mgmt/secrets/permissions.mdx
@@ -0,0 +1,66 @@
+---
+title: Secret permissions
+description: "Control who can see, use, replace, and rotate a secret."
+authentik_version: "2026.11"
+sidebar_position: 2
+---
+
+A [secret](./index.mdx) has its own permissions, separate from the providers, sources, stages, and connectors that use it. A role can maintain an integration without being able to read its password.
+
+Assign secret permissions to [roles](../../users-sources/roles/index.mdx), either on one secret or globally on all secrets. A global permission also covers unrelated secrets and secrets created later, so for a role that maintains one integration, assign permissions on that integration's secret.
+
+These permissions control access through authentik. They don't protect the values from anyone with direct access to the database. See [Storage](./index.mdx#storage).
+
+## Permissions for each task
+
+| Task                                                      | Required permissions                                                      |
+| --------------------------------------------------------- | ------------------------------------------------------------------------- |
+| Create a secret                                           | **Can add Secret**, assigned globally                                     |
+| See a secret's name and type                              | **Can view Secret**                                                       |
+| View, copy, or download its value                         | **Can view Secret** and **View secret's value**                           |
+| Rename it                                                 | **Can view Secret** and **Can change Secret**                             |
+| [Replace its value](./manage-secrets.mdx#replace-a-value) | **Can view Secret**, **Can change Secret**, and **Rotate secret's value** |
+| [Rotate it](./manage-secrets.mdx#rotate-a-secret)         | **Can view Secret** and **Rotate secret's value**                         |
+| [Attach it to an object](#use-a-secret-on-another-object) | **Can view Secret** and **View secret's value**                           |
+| Delete it                                                 | **Can view Secret** and **Can delete Secret**                             |
+
+**Can view Secret** shows a secret's name and type, not its value.
+
+Rotating doesn't reveal the new value. A role with **Rotate secret's value** but without **View secret's value** can rotate a secret without seeing the result. Assign both if the role must copy the new value to the clients that use it.
+
+## Use a secret on another object
+
+To select a secret on a provider, source, stage, or connector, you need permission to create or change that object, and **View secret's value** on the secret. The secret picker lists only secrets that you have **Can view Secret** on. An object can send its credential to an external system, so seeing a secret's name isn't enough to attach it.
+
+After an object references a secret, you can edit the object's other settings without permission to view the value. For example, you can rename an LDAP source without seeing its bind password. Users who log in through the object don't need any secret permissions.
+
+Replacing or rotating a secret changes it for every object that uses it, without requiring permission to change those objects. Before you assign **Rotate secret's value** on a shared secret, check which objects use it.
+
+Signing in with Plex while you edit a Plex source stores the new Plex token in the source's secret. Creating a Plex source this way needs **Can add Secret**, and updating an existing one needs **Can change Secret** and **Rotate secret's value** on its token secret.
+
+**Example**:
+
+A support role maintains an LDAP source but must not read its bind password. Assign the role **Can view LDAP Source** and **Can change LDAP Source** on the source, and **Can view Secret** on its bind password secret. The role can edit the source and keep its secret selected, but can't view, replace, or rotate the password.
+
+## Assign permissions on one secret
+
+1. In the Admin interface, go to **System** > **Secrets**.
+2. On the secret's row, click the permissions icon.
+3. Assign the permissions to the role.
+
+A global permission on the role still applies after you remove an object permission. For the general steps, see [Manage permissions](../../users-sources/access-control/manage_permissions.mdx). Users who work in the Admin interface also need the [**Can access admin interface**](../../users-sources/access-control/manage_permissions.mdx#assign-can-access-admin-interface-permissions) permission.
+
+## Access to new secrets
+
+**Can add Secret** doesn't grant any permission on the secrets a role creates, including secrets that a provider creates with a generated value. To let a role view, attach, or manage the secrets it creates, configure [initial permissions](../../users-sources/access-control/initial_permissions.mdx).
+
+## Permissions after upgrading
+
+The upgrade to authentik 2026.11 turns each existing credential into a secret with the same value, and copies role permissions from the object to its secrets as object permissions:
+
+- Roles that could view or change the object get **Can view Secret** on its secrets.
+- Roles that could previously read the credential through the API also get **View secret's value**. This applies to roles with change permission on OAuth2/OpenID providers, RADIUS providers, Plex sources, Kubernetes service connections, Google Workspace providers, Google Chrome connectors, and Google Chrome Device Trust authenticator stages, and to roles with view permission on notification transports.
+
+The upgrade doesn't grant **Can change Secret** or **Rotate secret's value** to any role. Assign them where needed.
+
+Initial permissions that included view or change permission on these object types are extended the same way, so roles that create these objects can still see the secrets created with them.
diff --git a/website/docs/users-sources/access-control/permissions.mdx b/website/docs/users-sources/access-control/permissions.mdx
index b4e6cc6344ba..4f57a78e729e 100644
--- a/website/docs/users-sources/access-control/permissions.mdx
+++ b/website/docs/users-sources/access-control/permissions.mdx
@@ -52,3 +52,7 @@ For example, the screenshot below shows the **Permissions** tab for the user nam
 You can see in the **Permissions on this object** table that the Admin role and one other role (Read-only) have permissions on Peter (that is, on the user object named Peter). The Admin role has all object permissions on this object, while the Read-only role has only the view permission.
 
 Hover over a checkmark to see whether that permission is granted by a global permission or an object permission.
+
+## Secret permissions
+
+[Secrets](../../sys-mgmt/secrets/index.mdx) have permissions separate from the objects that use them. A role can see a secret's name without being able to view its value, and rotating a value requires its own permission. See [Secret permissions](../../sys-mgmt/secrets/permissions.mdx).
diff --git a/website/docs/users-sources/sources/directory-sync/freeipa/index.mdx b/website/docs/users-sources/sources/directory-sync/freeipa/index.mdx
index eaf184a32acd..7745f5788d3a 100644
--- a/website/docs/users-sources/sources/directory-sync/freeipa/index.mdx
+++ b/website/docs/users-sources/sources/directory-sync/freeipa/index.mdx
@@ -121,6 +121,12 @@ metadata:
     labels:
         blueprints.goauthentik.io/description: "LDAP Source configuration for FreeIPA"
 entries:
+    - model: authentik_crypto_secrets.secret
+      id: freeipa-bind-password
+      identifiers:
+          name: FreeIPA bind password
+      attrs:
+          value: !Env FREEIPA_PASSWORD
     - model: authentik_sources_ldap.ldapsource
       identifiers:
           slug: ldap-source-freeipa
@@ -130,7 +136,7 @@ entries:
           additional_user_dn: cn=users,cn=accounts
           additional_group_dn: cn=groups,cn=accounts
           bind_cn: !Env FREEIPA_DN
-          bind_password: !Env FREEIPA_PASSWORD
+          bind_password_ref: !KeyOf freeipa-bind-password
           delete_not_found_objects: true
           group_membership_field: memberOf
           group_object_filter: (objectClass=groupofnames)
diff --git a/website/docs/users-sources/sources/protocols/kerberos/index.mdx b/website/docs/users-sources/sources/protocols/kerberos/index.mdx
index d84ef6ce8e1f..fe7f53c592c0 100644
--- a/website/docs/users-sources/sources/protocols/kerberos/index.mdx
+++ b/website/docs/users-sources/sources/protocols/kerberos/index.mdx
@@ -53,15 +53,13 @@ $ kadmin
 > add_principal authentik/admin@REALM.COMPANY
 > ktadd -k /tmp/authentik.keytab authentik/admin@REALM.COMPANY
 > exit
-$ cat /tmp/authentik.keytab | base64
-$ rm /tmp/authentik.keytab
 ```
 
 In authentik, configure these extra options:
 
 - Sync users: enable it
 - Sync principal: `authentik/admin@REALM.COMPANY`
-- Sync keytab: the base64-encoded keytab created above.
+- Sync keytab: create or select a **File** [secret](../../../../sys-mgmt/secrets/index.mdx), upload `/tmp/authentik.keytab` to it, and then delete the file.
 
 If you do not wish to use a keytab, you can also configure authentik to authenticate using a password or an existing credentials cache.
 
@@ -74,13 +72,11 @@ $ kadmin
 > add_principal HTTP/authentik.company@REALM.COMPANY
 > ktadd -k /tmp/authentik.keytab HTTP/authentik.company@REALM.COMPANY
 > exit
-$ cat /tmp/authentik.keytab | base64
-$ rm /tmp/authentik.keytab
 ```
 
 In authentik, configure these extra options:
 
-- SPNEGO keytab: the base64-encoded keytab created above.
+- SPNEGO keytab: create or select a **File** secret, upload `/tmp/authentik.keytab` to it, and then delete the file.
 
 If you do not wish to use a keytab, you can also configure authentik to use an existing credentials cache.