Requirements
- SMS-based two-factor authentication is prohibited for any account of significance. It may be used only where no alternative exists and the account in question has negligible value.
- Every account of significance — email, financial, identity-linked, or professionally critical — must be protected by a second authentication factor. A password alone is not sufficient.
- The minimum acceptable second factor is a device-bound TOTP authenticator application. Cloud-synced authenticators are prohibited: if the cloud account is compromised, all stored codes are compromised with it. Recommended applications: Aegis (Android), Raivo (iOS).
- Hardware security keys — physical devices such as YubiKey or Google Titan — are required at Sentinel rank and above on all accounts of significance. These must be purchased directly from the manufacturer to ensure authenticity.
- Where a platform supports passkeys, passkeys must be used in preference to passwords. Passkeys are device-bound cryptographic credentials that eliminate the password entirely and are resistant to phishing by design.
- Backup codes must be stored exclusively in an encrypted entry within your password manager, alongside the account credentials. They must not be stored in a notes application, an email, a photograph, or on paper kept at a desk. Backup codes must be regenerated each time one is used.
- Account recovery options must be reviewed and hardened with the same scrutiny applied to the primary authentication method. SMS recovery must be removed from all significant accounts where the platform permits it. Recovery email addresses must themselves be secured to at least the same standard as the accounts they protect.
Why a Second Factor Exists
Passwords are inadequate as a sole authentication mechanism. They are reused across services, captured by phishing, leaked in breaches, and guessed through credential stuffing. The purpose of a second factor is to ensure that a compromised password alone is not sufficient to access an account — that an attacker who holds your credentials still cannot get in without something you physically possess or control.
This logic only holds if the second factor itself cannot be intercepted or transferred. SMS codes fail this test. A hardware key or device-bound TOTP application passes it. Understanding why requires understanding how SMS authentication is defeated.
A phone number is not a secure second factor. It is a second factor tied to your mobile carrier — an institution whose security practices you do not control and cannot verify.
Why SMS Fails
When an authentication code is sent via SMS, it is routed through your mobile carrier. Your carrier can be manipulated. A SIM-swap attack involves an attacker convincing — or bribing — a carrier support representative to transfer your phone number to a SIM card under their control. Once the transfer is complete, every SMS intended for you is received by them.
This is not a theoretical risk. SIM-swap attacks have been used to drain cryptocurrency wallets, take over social media accounts, and access banking systems. The technical sophistication required is minimal: the attack requires social engineering a carrier support agent, which is frequently achievable using personal information that is publicly available. For anyone with substantial assets or a prominent profile, the risk is real and the mitigation is straightforward.
The Authentication Hierarchy
From weakest to strongest — these are the only methods relevant to The Order's standard:
- SMS codes — Unacceptable for any account of significance. Vulnerable to SIM-swap. Retain only on accounts of negligible value where no better option exists.
- Email-based codes — Marginally better than SMS, but only as secure as your email account. Not recommended as a standalone second factor. Acceptable as a fallback only on low-value accounts.
- TOTP authenticator apps (device-bound) — Time-based one-time passwords generated locally on your device. Not transmitted over a network. Not vulnerable to SIM-swap. This is the acceptable minimum standard. Use Aegis (Android) or Raivo (iOS). Do not use Google Authenticator or Authy with cloud backup enabled.
- Hardware security keys — Physical devices that require possession to authenticate. Phishing-resistant: even a convincing fake login page cannot capture a response from a hardware key, as the key verifies the domain it is authenticating against. Required at Sentinel rank and above.
- Passkeys — Device-bound cryptographic key pairs that replace passwords entirely. Phishing-resistant by design. Where supported, this is the preferred authentication method regardless of rank.
Backup Codes and Recovery
Backup codes are one-time codes generated when you set up two-factor authentication. They exist to allow account recovery if your primary second factor is unavailable. They are also frequently the weakest point in an otherwise strong authentication setup: generated once, valid indefinitely, and often stored carelessly in a notes app, a screenshot, or a printed sheet on a desk.
The standard: backup codes are stored in a dedicated encrypted note in your password manager, immediately adjacent to the account credentials. They are not stored anywhere else. If a code is used, the full set is regenerated immediately and the old set discarded.
Recovery email addresses deserve the same scrutiny as the primary account. If your recovery email is secured only by a password, a compromised password on that email account defeats the second factor on everything it protects. The recovery path must be as strong as the path it exists to recover.
If your second factor is recoverable via SMS, a compromised password plus a SIM-swap achieves full account access. The second factor has been nullified. Review every account's recovery options, not just its primary authentication method.