One-time logon codes over SMS and email feel secure. They are not a secret — they are a message, carried by relays, carriers and inboxes that were never built to protect it.
An emailed or texted code leaves your server and crosses the open internet to reach the user.
Carriers, SMS gateways, mail providers and spam filters each hold a readable copy in transit.
The code sits in plain text on a lock screen, in an inbox and in cloud backups — long after use.
SIM swaps, ported numbers and compromised inboxes redirect the code before it ever reaches you.
SMS and email one-time passwords (OTPs) were never designed as a security channel. They were a convenient channel that got reused for security. The gap between those two things is where attacks live.
The SS7 telephony network and the global email system are open infrastructure. Every hop is a third party with its own security posture — and you control none of them.
An attacker convinces a carrier to move the victim's number to a new SIM. Every SMS code — bank, email, work logon — then arrives on the attacker's phone instead.
A fake login page asks for the code the moment it arrives and replays it to the real site within seconds. The code being "one-time" does not help — the attacker uses it first.
If a logon code is emailed, anyone who can read that inbox can authenticate. Email accounts are breached constantly — reused passwords, old sessions, forwarding rules.
Codes preview on a locked phone, sync to a tablet and a laptop, and land in cloud message backups. The "one-time" code persists in plain text in many places at once.
Carrier delays, filtering and roaming mean the code may arrive late or never. Users then disable the protection, or support staff bypass it — the security becomes optional.
The difference is not the six digits on the screen. It is where the secret lives and how many hands the proof passes through.
| Property | SMS / Email OTP — Open | TOTP — Crypto |
|---|---|---|
| Where the secret lives | On the server, and recreated for every login | Set once at enrolment, then only on your device |
| Is the code transmitted? | Yes — to you, over networks you don't control | No — computed locally, never sent to you |
| Third parties who see it | Carriers, SMS gateways, mail providers, filters | None in the path of the code |
| SIM swap exposure | Vulnerable — codes follow the number | Not affected — no phone number involved |
| Compromised inbox exposure | Vulnerable — inbox access = code access | Not affected — no inbox involved |
| Works offline / no signal | No — needs delivery to succeed | Yes — only needs a correct clock |
| Real-time phishing relay | Vulnerable — the code is still phishable | Still phishable*, but no delivery channel to attack |
| Cost & reliability | Per-message fees; carrier delays and failures | Free — no messaging, no delivery dependency |
| Standard | No single standard; provider-dependent | Open standard — RFC 6238 |
* TOTP removes the delivery channel but a user can still be tricked into typing a code into a fake site. Phishing-resistant authentication (passkeys / FIDO2, or certificate-based identity) closes that last gap — see below.
TOTP — Time-based One-Time Password — is just a small piece of shared maths. No magic, no messaging.
At enrolment, the server and your authenticator agree on a random secret key — usually shown as a QR code you scan. This is the only time the secret moves.
Every 30 seconds, both sides take the current time and the secret and run them through a one-way hash: HMAC-SHA1(secret, time). Same inputs, same output.
Your device shows its computed 6 digits. The server computes its own and checks they match. No code ever travelled to you — only your answer travels back.
The key insight: because both sides can independently calculate the same code from a secret they already share, there is nothing to transmit. Remove the transmission and you remove SIM swaps, inbox breaches, carrier interception and delivery failures in a single move.
entityOS treats the open internet as hostile by default. Proving identity is not something we hand off to a carrier or an inbox — it stays inside infrastructure we control and verify.
TOTP, passkeys and certificate-based identity all keep the secret on the user's device. Nothing sensitive crosses systems we cannot account for.
mTLS and X.509 client certificates prove a device or person cryptographically. A certificate cannot be SIM-swapped, ported or read off a lock screen.
IP allowlisting and a closed-internet architecture mean the authentication exchange happens only between endpoints that already know each other.
KERI / ACDC credentials let an entity hold and present its own verifiable identity — no shared secret to leak, no central code-sender to compromise.
TOTP is a large improvement over SMS and email OTP because it removes the delivery channel — but it is not the end of the road. A user can still be tricked into typing a valid code into a convincing fake site. Defences that bind the login to the real site — passkeys / FIDO2 and certificate-based identity — close that remaining gap. The principle holds throughout: the less a secret travels, and the fewer parties it passes, the safer it is.
SMS and email OTPs cross open systems — carriers, gateways, inboxes — that you neither own nor verify.
TOTP keeps the secret on the device and calculates the code locally. Nothing is delivered, so nothing can be intercepted.
Certificates, allowlisting and self-sovereign identity remove the shared secret and the open channel entirely.
The safest secret is the one that never travels. entityOS is built so that proving who you are happens inside a path you control — not across an internet you don't.