diff --git a/content/en/docs/concepts/architecture/master-node-communication.md b/content/en/docs/concepts/architecture/master-node-communication.md
index cdec599b1f2..013674f210b 100644
--- a/content/en/docs/concepts/architecture/master-node-communication.md
+++ b/content/en/docs/concepts/architecture/master-node-communication.md
@@ -28,10 +28,10 @@ All communication paths from the cluster to the master terminate at the
 apiserver (none of the other master components are designed to expose remote
 services). In a typical deployment, the apiserver is configured to listen for
 remote connections on a secure HTTPS port (443) with one or more forms of
-client [authentication](/docs/admin/authentication/) enabled. One or more forms
+client [authentication](/docs/reference/access-authn-authz/authentication/) enabled. One or more forms
 of [authorization](/docs/admin/authorization/) should be enabled, especially
-if [anonymous requests](/docs/admin/authentication/#anonymous-requests) or
-[service account tokens](/docs/admin/authentication/#service-account-tokens)
+if [anonymous requests](/docs/reference/access-authn-authz/authentication/#anonymous-requests) or
+[service account tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens)
 are allowed.
 
 Nodes should be provisioned with the public root certificate for the cluster
diff --git a/content/en/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/en/docs/concepts/cluster-administration/cluster-administration-overview.md
index 348caf2a7fe..d244a3df575 100644
--- a/content/en/docs/concepts/cluster-administration/cluster-administration-overview.md
+++ b/content/en/docs/concepts/cluster-administration/cluster-administration-overview.md
@@ -50,7 +50,7 @@ If you are using a guide involving Salt, see [Configuring Kubernetes with Salt](
 
 * [Controlling Access to the Kubernetes API](/docs/admin/accessing-the-api/) describes how to set up permissions for users and service accounts.
 
-* [Authenticating](/docs/admin/authentication/) explains authentication in Kubernetes, including the various authentication options.
+* [Authenticating](/docs/reference/access-authn-authz/authentication/) explains authentication in Kubernetes, including the various authentication options.
 
 * [Authorization](/docs/admin/authorization/) is separate from authentication, and controls how HTTP calls are handled.
 
diff --git a/content/en/docs/concepts/extend-kubernetes/extend-cluster.md b/content/en/docs/concepts/extend-kubernetes/extend-cluster.md
index 740603d72ba..92963d24b6c 100644
--- a/content/en/docs/concepts/extend-kubernetes/extend-cluster.md
+++ b/content/en/docs/concepts/extend-kubernetes/extend-cluster.md
@@ -136,13 +136,13 @@ When a request reaches the Kubernetes API Server, it is first Authenticated, the
 
 Each of these steps offers extension points.
 
-Kubernetes has several built-in authentication methods that it supports. It can also sit behind an authenticating proxy, and it can send a token from an Authorization header to a remote service for verification (a webhook). All of these methods are covered in the [Authentication documentation](/docs/admin/authentication/).
+Kubernetes has several built-in authentication methods that it supports. It can also sit behind an authenticating proxy, and it can send a token from an Authorization header to a remote service for verification (a webhook). All of these methods are covered in the [Authentication documentation](/docs/reference/access-authn-authz/authentication/).
 
 ### Authentication
 
-[Authentication](/docs/admin/authentication) maps headers or certificates in all requests to a username for the client making the request.
+[Authentication](/docs/reference/access-authn-authz/authentication/) maps headers or certificates in all requests to a username for the client making the request.
 
-Kubernetes provides several built-in authentication methods, and an [Authentication webhook](/docs/admin/authentication/#webhook-token-authentication) method if those don't meet your needs.
+Kubernetes provides several built-in authentication methods, and an [Authentication webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) method if those don't meet your needs.
 
 
 ### Authorization
diff --git a/content/en/docs/imported/community/devel.md b/content/en/docs/imported/community/devel.md
index 533e286a690..6f4fe9c510d 100644
--- a/content/en/docs/imported/community/devel.md
+++ b/content/en/docs/imported/community/devel.md
@@ -65,7 +65,7 @@ Guide](http://kubernetes.io/docs/admin/).
 
 ## Writing plugins
 
-* **Authentication** ([Authentication](http://kubernetes.io/docs/admin/authentication/)):
+* **Authentication** ([Authentication](http://kubernetes.io/docs/reference/access-authn-authz/authentication/)):
   The current and planned states of authentication tokens.
 
 * **Authorization Plugins** ([Authorization](http://kubernetes.io/docs/admin/authorization/)):
diff --git a/content/en/docs/reference/access-authn-authz/controlling-access.md b/content/en/docs/reference/access-authn-authz/controlling-access.md
index 723a10463f3..cc78d081d80 100644
--- a/content/en/docs/reference/access-authn-authz/controlling-access.md
+++ b/content/en/docs/reference/access-authn-authz/controlling-access.md
@@ -39,7 +39,7 @@ Once TLS is established, the HTTP request moves to the Authentication step.
 This is shown as step **1** in the diagram.
 The cluster creation script or cluster admin configures the API server to run
 one or more Authenticator Modules.
-Authenticators are described in more detail [here](/docs/admin/authentication/).
+Authenticators are described in more detail [here](/docs/reference/access-authn-authz/authentication/).
 
 The input to the authentication step is the entire HTTP request, however, it typically
 just examines the headers and/or client certificate.
diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md b/content/en/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md
index b1b31ffed94..9056829f831 100644
--- a/content/en/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md
+++ b/content/en/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md
@@ -27,7 +27,7 @@ To enable X509 client certificate authentication to the kubelet's HTTPS endpoint
 
 * start the kubelet with the `--client-ca-file` flag, providing a CA bundle to verify client certificates with
 * start the apiserver with `--kubelet-client-certificate` and `--kubelet-client-key` flags
-* see the [apiserver authentication documentation](/docs/admin/authentication/#x509-client-certs) for more details
+* see the [apiserver authentication documentation](/docs/reference/access-authn-authz/authentication/#x509-client-certs) for more details
 
 To enable API bearer tokens (including service account tokens) to be used to authenticate to the kubelet's HTTPS endpoint:
 
diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md b/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md
index d51e26afb86..f77ebcefc40 100644
--- a/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md
+++ b/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md
@@ -16,7 +16,7 @@ and progress on the feature is being tracked as [feature #43](https://github.com
 
 ## kube-apiserver configuration
 
-The API server should be configured with an [authenticator](/docs/admin/authentication/) that can authenticate tokens as a user in the `system:bootstrappers` group.
+The API server should be configured with an [authenticator](/docs/reference/access-authn-authz/authentication/) that can authenticate tokens as a user in the `system:bootstrappers` group.
 
 This group will later be used in the controller-manager configuration to scope approvals in the default approval
 controller. As this feature matures, you should ensure tokens are bound to a Role-Based Access Control (RBAC) policy which limits requests
@@ -45,7 +45,7 @@ name should be as depicted:
 ```
 
 Add the `--token-auth-file=FILENAME` flag to the kube-apiserver command (in your systemd unit file perhaps) to enable the token file.
-See docs [here](/docs/admin/authentication/#static-token-file) for further details.
+See docs [here](/docs/reference/access-authn-authz/authentication/#static-token-file) for further details.
 
 ### Client certificate CA bundle
 
diff --git a/content/en/docs/setup/scratch.md b/content/en/docs/setup/scratch.md
index c354785c7f4..77871e8a751 100644
--- a/content/en/docs/setup/scratch.md
+++ b/content/en/docs/setup/scratch.md
@@ -236,7 +236,7 @@ You need to prepare several certs:
 Unless you plan to have a real CA generate your certs, you will need
 to generate a root cert and use that to sign the master, kubelet, and
 kubectl certs. How to do this is described in the [authentication
-documentation](/docs/admin/authentication/#creating-certificates/).
+documentation](/docs/concepts/cluster-administration/certificates/).
 
 You will end up with the following files (we will use these variables later on)
 
@@ -262,7 +262,7 @@ The admin user (and any users) need:
 
 Your tokens and passwords need to be stored in a file for the apiserver
 to read.  This guide uses `/var/lib/kube-apiserver/known_tokens.csv`.
-The format for this file is described in the [authentication documentation](/docs/admin/authentication/).
+The format for this file is described in the [authentication documentation](/docs/reference/access-authn-authz/authentication/#static-token-file).
 
 For distributing credentials to clients, the convention in Kubernetes is to put the credentials
 into a [kubeconfig file](/docs/concepts/cluster-administration/authenticate-across-clusters-kubeconfig/).
diff --git a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md
index f4643332814..0e851f85fd0 100644
--- a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md
+++ b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md
@@ -49,7 +49,7 @@ The UI can _only_ be accessed from the machine where the command is executed. Se
 You may access the UI directly via the Kubernetes master apiserver. Open a browser and navigate to ``https://<master-ip>:<apiserver-port>/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/``, where `<master-ip>` is IP address or domain name of the Kubernetes
 master.
 
-Please note, this works only if the apiserver is set up to allow authentication with username and password. This is not currently the case with some setup tools (e.g., `kubeadm`). Refer to the  [authentication admin documentation](/docs/admin/authentication/) for information on how to configure authentication manually.
+Please note, this works only if the apiserver is set up to allow authentication with username and password. This is not currently the case with some setup tools (e.g., `kubeadm`). Refer to the  [authentication admin documentation](/docs/reference/access-authn-authz/authentication/) for information on how to configure authentication manually.
 
 If the username and password are configured but unknown to you, then use `kubectl config view` to find it.
 
diff --git a/content/en/docs/tasks/administer-cluster/securing-a-cluster.md b/content/en/docs/tasks/administer-cluster/securing-a-cluster.md
index eb9ab0e7283..3b75ef68549 100644
--- a/content/en/docs/tasks/administer-cluster/securing-a-cluster.md
+++ b/content/en/docs/tasks/administer-cluster/securing-a-cluster.md
@@ -46,7 +46,7 @@ allow users to be subdivided into groups.
 All API clients must be authenticated, even those that are part of the infrastructure like nodes,
 proxies, the scheduler, and volume plugins. These clients are typically [service accounts](/docs/admin/service-accounts-admin/) or use x509 client certificates, and they are created automatically at cluster startup or are setup as part of the cluster installation.
 
-Consult the [authentication reference document](/docs/admin/authentication/) for more information.
+Consult the [authentication reference document](/docs/reference/access-authn-authz/authentication/) for more information.
 
 ### API Authorization
 
diff --git a/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md b/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md
index 14522919972..60ccf8e0b61 100644
--- a/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md
+++ b/content/en/docs/tasks/tls/managing-tls-in-a-cluster.md
@@ -207,7 +207,7 @@ includes who the Kubernetes API trusts. The ability to approve CSRs should
 not be granted broadly or lightly. The requirements of the challenge
 noted in the previous section and the repercussions of issuing a specific
 certificate should be fully understood before granting this permission. See
-[here](/docs/admin/authentication#x509-client-certs) for information on how
+[here](/docs/reference/access-authn-authz/authentication/#x509-client-certs) for information on how
 certificates interact with authentication.
 
 ## A Note to Cluster Administrators
diff --git a/content/en/docs/user-journeys/users/application-developer/intermediate.md b/content/en/docs/user-journeys/users/application-developer/intermediate.md
index 31ca5952415..f270b2e82b3 100644
--- a/content/en/docs/user-journeys/users/application-developer/intermediate.md
+++ b/content/en/docs/user-journeys/users/application-developer/intermediate.md
@@ -102,7 +102,7 @@ You (or your {{< glossary_tooltip text="cluster operator" term_id="cluster-opera
 
 For even more comprehensive reading about security best practices, consider checking out the following topics:
 
-* {{< link text="Authentication" url="/docs/admin/authentication/" >}} (Is the user who they say they are?)
+* {{< link text="Authentication" url="/docs/reference/access-authn-authz/authentication/" >}} (Is the user who they say they are?)
 * {{< link text="Authorization" url="/docs/admin/authorization/" >}} (Does the user actually have permissions to do what they're asking?)
 
 #### Resource isolation and management
diff --git a/content/en/docs/user-journeys/users/cluster-operator/intermediate.md b/content/en/docs/user-journeys/users/cluster-operator/intermediate.md
index 124e13dfbfd..8f5d113172a 100644
--- a/content/en/docs/user-journeys/users/cluster-operator/intermediate.md
+++ b/content/en/docs/user-journeys/users/cluster-operator/intermediate.md
@@ -60,7 +60,7 @@ Securing your cluster includes work beyond the scope of Kubernetes itself.
 In Kubernetes, you configure access control:
 
 * [Controlling Access to the Kubernetes API](/docs/admin/accessing-the-api/)
-* [Authenticating](/docs/admin/authentication/)
+* [Authenticating](/docs/reference/access-authn-authz/authentication/)
 * [Using Admission Controllers](/docs/admin/admission-controllers/)
 
 You also configure authorization. That is, you determine not just how users and services authenticate to the API server, or whether they have access, but also what resources they have access to. Role-based access control (RBAC) is the recommended mechanism for controlling authorization to Kubernetes resources. Other authorization modes are available for more specific use cases.