Feature/opsec/mfa (#452)

* Added MFA overview, and updated contributors file.

* Build fix and language updates.

* Refine MFA overview and recommendations

Revised language for clarity and emphasis on MFA importance. Updated recommendations for MFA methods and highlighted security considerations for passkeys.

* Further clarification about passkey storage.

---------

Co-authored-by: Matías Aereal Aeón <388605+mattaereal@users.noreply.github.com>

Author: shallem

docs/pages/config/contributors.json

@@ -665,5 +665,19 @@
       { "name": "New-Joiner", "lastActive": "2026-03-17" },
       { "name": "Active-Last-7d", "lastActive": "2026-03-23" }
     ]
+},
+"shallem": {
+    "slug": "shallem",
+    "name": "Seth Hallem",
+    "avatar": "",
+    "github": "https://github.com/shallem",
+    "twitter": "https://x.com/seth_certora",
+    "website": "https://www.certora.com/",
+    "company": "Certora",
+    "role": "steward",
+    "job_title": null,
+    "description": "Steward of Opsec framework",
+    "badges": [
+    ]
   }
 }

docs/pages/opsec/mfa/overview.mdx

@@ -3,6 +3,9 @@ title: "Multi-Factor Authentication | Security Alliance"
 tags:
   - Security Specialist
   - Operations & Strategy
+contributors:
+  - role: wrote
+    users: [shallem]
 ---
 
 import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components'
@@ -15,7 +18,31 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr
 <TagList tags={frontmatter.tags} />
 <AttributionList contributors={frontmatter.contributors} />
 
-Placeholder for Multi-Factor Authentication content
+MFA is necessary but not sufficient as an OpSec strategy. If you have not yet implemented MFA, we suggest making it your first priority as soon as you finish reading this page.
+
+Not all MFAs are created equally. A few recommendations:
+
+1. **Stay away from text and email as MFA methods.** There are innumerable reasons why neither of these methods
+   is a good idea. Suffice it to say, best practices have long since outlawed these MFA methods.
+
+2. **TOTP (e.g., Google Authenticator) is good but not great.** Why? It is easy enough to trick users into
+   entering TOTP codes into a phishing site. The methods cited below are more difficult to exploit. Also, any manual typing is susceptible to keyloggers.
+
+3. **Push-based MFA is better.** Why? Because initiating a push notification on iOS/Android requires that the
+   device itself be enrolled with the identity provider. Phishing sites cannot initiate a push notification to
+   the Gmail app, for example, without a major compromise of Google's infrastructure.
+
+4. **Passkeys are the best.** Biometrics are hard to fake, and in a world where attackers are looking for low
+   hanging fruit, passkeys protected by biometric factors are typically too hard for them to reach. However, passkey storage is critical to ensuring that this choice is secure - please read the note below.
+
+5. **Key admins (e.g., your G Suite admin) should be using Yubikeys.** They are inexpensive and easy. There is
+   no excuse here for not protecting the keys to the castle with the industry gold standard for MFA.
+
+Once you have MFA in place, you are ready to move on to the next step in your Opsec framework. However, before you declare your MFA journey a success, make sure you haven't forgotten any of your communication tools along the way. In this industry, we often use a combination of X, Signal, and Telegram, and each of them can and should be protected with an additional authentication factor. Also, note that the more you allow one-off sign-ins for each tool you use, the more you have to be concerned about the MFA features of each tool. Implementing single sign-on wherever possible is the best way to enforce MFA across all the tools you use.
+
+Take into consideration that, while using passkeys seems the most appropriate course of action, using them irresponsibly could lower your security posture. Passkeys only improve security when they remain tied to a strong device and recovery model; used carelessly, they can weaken it by shifting trust from a hard-to-phish login flow to softer cloud sync and account recovery paths. A common failure case is storing high-value passkeys in consumer sync ecosystems protected by weak recovery, reused credentials, SMS reset, or unmanaged devices, so an attacker who compromises the sync account can restore those passkeys on their own device and log in cleanly with what appears to be strong authentication. In that setup, the passkey itself is not broken, but the overall security posture is worse because the real attack surface becomes account recovery, device enrollment, and endpoint compromise rather than direct credential theft. A typical mistake would be to store a passkey in the Google password manager for your personal Google account, which may not be adequately protected with a strong password, MFA, and a secure account recovery method.
+
+To address the passkey storage issue, this section should be read in conjunction with the section (coming soon) about password handling and password management. Passkeys are the strongest form of MFA when stored in a secure password manager with biometric authentication (e.g., Bitwarden, 1Password). Passkeys stored in a personal account that uses phone or SMS as a recovery mechanism make overall security worse, not better. Before finalizing any decision to migrate to passkeys, please read the password management section and ensure that you are ready to store your passkeys securely.
 
 </TagProvider>
 <ContributeFooter />

utils/fetched-tags.json

@@ -486,6 +486,18 @@
     "/guides/account-management/vercel": [
       "DevOps Accounts"
     ],
+    "/guides/endpoint-security/hardware-security-keys": [
+      "Security Specialist"
+    ],
+    "/guides/endpoint-security/password-manager-endpoint-hardening": [
+      "Security Specialist",
+      "Operations & Strategy",
+      "Engineer/Developer"
+    ],
+    "/guides/endpoint-security/ssh-client-and-key-management-hardening": [
+      "Engineer/Developer",
+      "Security Specialist"
+    ],
     "/guides/endpoint-security/zoom-hardening": [
       "Security Specialist",
       "Operations & Strategy"
@@ -895,7 +907,8 @@
     ],
     "/opsec/endpoint/overview": [
       "Security Specialist",
-      "Operations & Strategy"
+      "Operations & Strategy",
+      "HR"
     ],
     "/opsec/google/overview": [
       "Community & Marketing",
@@ -1269,45 +1282,45 @@
     ]
   },
   "sectionMappings": {
-    "Community Management": "community-management",
+    "AI Security": "ai-security",
     "Awareness": "awareness",
-    "Operational Security": "opsec",
-    "OpSec Core Concepts": "opsec",
-    "While Traveling": "opsec",
-    "Wallet Security": "wallet-security",
-    "Signing & Verification": "wallet-security",
-    "Multisig for Protocols": "multisig-for-protocols",
-    "Multisig Administration": "multisig-for-protocols",
-    "Operational Runbooks": "multisig-for-protocols",
-    "For Signers": "multisig-for-protocols",
+    "Community Management": "community-management",
+    "DevSecOps": "devsecops",
+    "Isolation & Sandboxing": "devsecops",
+    "DPRK IT Workers": "dprk-it-workers",
+    "Encryption": "encryption",
+    "ENS": "ens",
     "External Security Reviews": "external-security-reviews",
     "Smart Contract Audits": "external-security-reviews",
-    "Vulnerability Disclosure": "vulnerability-disclosure",
-    "Infrastructure": "infrastructure",
-    "Domain & DNS Security": "infrastructure",
-    "Monitoring": "monitoring",
     "Front-End/Web Application": "front-end-web-app",
+    "Governance": "governance",
+    "Identity and Access Management IAM": "iam",
     "Incident Management": "incident-management",
     "Playbooks": "incident-management",
     "Incident Response Template": "incident-management",
     "Templates": "incident-management",
     "Runbooks": "incident-management",
-    "Threat Modeling": "threat-modeling",
-    "DPRK IT Workers": "dprk-it-workers",
-    "Governance": "governance",
-    "DevSecOps": "devsecops",
-    "Isolation & Sandboxing": "devsecops",
+    "Infrastructure": "infrastructure",
+    "Domain & DNS Security": "infrastructure",
+    "Monitoring": "monitoring",
+    "Multisig for Protocols": "multisig-for-protocols",
+    "Multisig Administration": "multisig-for-protocols",
+    "Operational Runbooks": "multisig-for-protocols",
+    "For Signers": "multisig-for-protocols",
+    "Operational Security": "opsec",
+    "OpSec Core Concepts": "opsec",
+    "While Traveling": "opsec",
     "Privacy": "privacy",
-    "Supply Chain": "supply-chain",
-    "Security Automation": "security-automation",
-    "Identity and Access Management IAM": "iam",
+    "Safe Harbor": "safe-harbor",
     "Secure Software Development": "secure-software-development",
+    "Security Automation": "security-automation",
     "Security Testing": "security-testing",
-    "AI Security": "ai-security",
-    "ENS": "ens",
-    "Safe Harbor": "safe-harbor",
-    "Encryption": "encryption",
+    "Supply Chain": "supply-chain",
+    "Threat Modeling": "threat-modeling",
     "Treasury Operations": "treasury-operations",
+    "Vulnerability Disclosure": "vulnerability-disclosure",
+    "Wallet Security": "wallet-security",
+    "Signing & Verification": "wallet-security",
     "Guides": "guides",
     "Account Management": "guides",
     "Endpoint Security": "guides",