diff --git a/docs/adrs/ca-cert-rotation.md b/docs/adrs/ca-cert-rotation.md
index 876a94c09e..27b2b9018b 100644
--- a/docs/adrs/ca-cert-rotation.md
+++ b/docs/adrs/ca-cert-rotation.md
@@ -70,14 +70,20 @@ clients using tokens signed by the old key have received new tokens.
 ## Decision
 
 * K3s will allow for use of CA certificates signed by an arbitrary set of external root/intermediate CAs.
-* K3s will allow for nondisruptive renewal or replacement of the CA certificates and keys, if the cluster was
+* K3s will allow for non-disruptive[^1] renewal or replacement of the CA certificates and keys, if the cluster was
   originally started using user-provided certificates signed by an external CA.
-* K3s will allow for disruptive renewal or replacement of cluster CA certificates and keys, if the cluster was
+* K3s will allow for disruptive[^2] renewal or replacement of cluster CA certificates and keys, if the cluster was
   originally started with autogenerated self-signed CAs.
 * K3s will provide example tooling to allow users to generate cluster CA certificates and keys prior to initial
   cluster startup, and provide tooling and process documentation to update the bootstrap data and prepare agents
   to trust the new certificates (if necessary)
 
+[^1]: Non-disruptive renewal requires no change to node configuration. The service only needs to be restarted.
+[^2]: Disruptive renewal requires changes to the K3s CLI flags, configuration file, or environment variables
+  prior to restarting the service.  Additionally, the cluster may experience a temporary outage while the
+  configuration change has been affected to all nodes, due to cluster nodes temporary not sharing a common
+  root of trust.
+
 ## Consequences
 
 This will require additional documentation, CLI subcommands, and QA work to validate the process steps.