diff --git a/docs/cspell.json b/docs/cspell.json
index 0ede027551757..ef1255318fac6 100644
--- a/docs/cspell.json
+++ b/docs/cspell.json
@@ -612,7 +612,7 @@
     "serviceaccounts",
     "serviceacct",
     "serviceid",
-    "sesssion",
+    "session",
     "setspn",
     "sharded",
     "signup",
diff --git a/docs/pages/access-controls/guides/hardware-key-support.mdx b/docs/pages/access-controls/guides/hardware-key-support.mdx
index c194e5c20fc1d..8adc155a72e43 100644
--- a/docs/pages/access-controls/guides/hardware-key-support.mdx
+++ b/docs/pages/access-controls/guides/hardware-key-support.mdx
@@ -166,7 +166,7 @@ For existing users of per-session MFA, upgrading to `hardware_key_touch` may be
 
 For users who want this mash-up of functionality, you can use the `require_session_mfa: hardware_key` option in both roles and cluster auth preference settings. This option will continue to use per-session MFA checks while also requiring hardware-based private keys for all Teleport requests.
 
-This prevents basic data exfiltration attacks for Teleport sesssion and non-session requests. However, it does not prevent hacking attacks with non-session Teleport requests, since gaining access to a user's computer would provide both their certificates on disk and a local connection to their YubiKey, assuming its connected.
+This prevents basic data exfiltration attacks for Teleport session and non-session requests. However, it does not prevent hacking attacks with non-session Teleport requests, since gaining access to a user's computer would provide both their certificates on disk and a local connection to their YubiKey, assuming its connected.
 
 ## Troubleshooting