diff --git a/site/content/docs/background/architecture.md b/site/content/docs/background/architecture.md
index bf258bac..ec481a5a 100644
--- a/site/content/docs/background/architecture.md
+++ b/site/content/docs/background/architecture.md
@@ -91,7 +91,7 @@ cleanly enable this integration.
 
 Pinniped supports the following cluster integration strategies.
 
-* Kube Cluster Signing Certificate: Pinniped hosts a credential exchange API endpoint via a Kubernetes aggregated API server.
+* Token Credential Request API: Pinniped hosts a credential exchange API endpoint via a Kubernetes aggregated API server.
 This API returns a new cluster-specific credential using the cluster's signing keypair to
 issue short-lived cluster certificates. (In the future, when the Kubernetes CSR API
 provides a way to issue short-lived certificates, then the Pinniped credential exchange API
diff --git a/site/content/docs/reference/supported-clusters.md b/site/content/docs/reference/supported-clusters.md
index 278e51d4..28ba554b 100644
--- a/site/content/docs/reference/supported-clusters.md
+++ b/site/content/docs/reference/supported-clusters.md
@@ -23,12 +23,15 @@ menu:
 
 The Pinniped Concierge has two strategies available to support clusters, under the following conditions:
 
-1. Kube Cluster Signing Certificate: Can be run on any Kubernetes cluster where a custom pod can be executed on the same node running `kube-controller-manager`.
+1. Token Credential Request API: Can be run on any Kubernetes cluster where a custom pod can be executed on the same node running `kube-controller-manager`.
 This type of cluster is typically called "self-hosted" because the cluster's control plane is running on nodes that are part of the cluster itself.
 Most managed Kubernetes services do not support this.
 
 2. Impersonation Proxy: Can be run on any Kubernetes cluster where a `LoadBalancer` service can be created. Most cloud-hosted Kubernetes environments have this
 capability. The Impersonation Proxy automatically provisions a `LoadBalancer` for ingress to the impersonation endpoint.
 
-If a cluster is capable of supporting both strategies, the Pinniped Concierge will use the
-kube cluster signing certificate strategy.
+If a cluster is capable of supporting both strategies, the Pinniped CLI will use the
+token credential request API strategy by default.
+
+To choose the strategy to use with the concierge, use the `--concierge-mode` flag with `pinniped get kubeconfig`.
+Possible values are `ImpersonationProxy` and `TokenCredentialRequestAPI`.