Your product still treats SMS and email as “out‑of‑band” control channels. That assumption just died. ChatGPT can now send texts via Apple Messages. Assistants already read notifications, scrape inboxes, and follow cross‑app instructions. If an agent can see and send the message, it’s not out‑of‑band — it’s automated in‑band with a new attack surface.
If you’ve been waiting for a big vendor move before deprecating SMS 2FA and email‑based approvals, this is it. In this post I’ll give you a concrete decision framework to inventory where you rely on “out‑of‑band,” assess your exposure now that assistants can text, and ship a safer authentication and authorization model within a quarter.
What Changed: SMS and Email Are Now Automatable by Default
Two relevant signals landed recently:
- ChatGPT gained Apple Messages integration. That’s mainstream OS‑level access to a channel most consumer apps still trust for OTPs and approvals.
- Assistants can be induced to exfiltrate data even when filters “should” block it — including via obfuscated or encrypted prompt injection. If a model follows malicious instructions, your supposedly out‑of‑band code is just another token to copy and paste.
Combine those with years of platform drift — lock‑screen OTP previews, notification summarizers, email “smart reply,” cross‑device sync — and the security boundary you thought existed around SMS and email never really held. Now it’s completely porous.
Threat Model Update: From Human Second Factor to Scriptable Pipe
Here’s how your current controls degrade in the presence of OS‑level assistants that can read and send messages:
- SMS OTPs: Agents can read notification previews, full messages, and in some cases respond without user intervention. A compromised assistant = harvested OTP.
- Email magic links: If an assistant manages your inbox, “click the link” becomes trivial automation. Click‑blocking heuristics won’t save you from first‑party automation.
- Phone/IVR callbacks: With text‑to‑speech and call APIs, agents can place and navigate calls. Caller ID is spoofable; “voice verification” is theater against cloned voices.
- Push approvals: If your push is a simple “Approve/Deny,” an agent with notification access can tap Approve faster than your user notices.
Security guidance already warned you here. NIST SP 800‑63B classifies SMS for OTP as restricted due to SIM swap, interception, and malware risk. That was before assistants could relay messages on your behalf. Today, SMS and email are just process transport — and anything that can drive that transport can drive your controls.
Decision Framework: Kill Out‑of‑Band Assumptions in 4 Steps
1) Inventory Where You Depend on “Out‑of‑Band”
Make a two‑column list with business owner and technical owner. You’re looking for every place an actor outside your authenticated session can trigger a security‑sensitive change:
- Authentication: SMS OTP, email OTP, email magic links, phone callbacks, authenticator app TOTP.
- Authorization: Payment approvals, beneficiary add, key rotation, role changes, device enrollment, data export confirmations.
- Support/Recovery: Password resets via email or SMS, account unlocks via phone ticket, KYC re‑verification via emailed link.
For each, record channel(s), fallback path(s), and artifact shown to the user (OTP, link, approval button, etc.). Expect to find 12–30 distinct flows in a typical B2C SaaS; fewer in B2B but with higher blast radius.
2) Classify Channel Control and Assistant Exposure
Score each flow on three dimensions (High/Medium/Low):
- Assistant visibility: Can a mainstream OS assistant read it by default? (Lock‑screen OTP, email preview, Messages integration, notification content.)
- Assistant actuation: Can an assistant send/approve/respond in that channel?
- User verification strength: Is the user proving possession of a private key in secure hardware, or just responding to a challenge any app can see?
If a flow has High visibility + Medium/High actuation + Low verification strength, treat it as compromised. Any “but it requires the user to tap” argument is obsolete once a model can tap.
3) Choose a Cryptographic Replacement, Not Another Channel
Replace channel‑trust with key‑trust. Your options:
- WebAuthn (FIDO2) with resident keys: Hardware‑backed, phishing‑resistant, works on desktop and mobile. Use credProtect and user verification (UV) required. Prefer device‑bound platform authenticators over roaming keys for consumer flows; allow roaming keys for admins.
- App‑bound attestation for approvals: On mobile, use Apple App Attest and Android Play Integrity to attest your app; inside the app, perform transaction signing with cleartext “what you sign” (amount, beneficiary, action) displayed and bound to a signature. Outside the browser, use OS‑provided secure elements (Secure Enclave/StrongBox) via platform APIs.
- Push with per‑transaction cryptographic challenge: If you must use push, never send a blind “Approve.” Send a signed challenge that includes the critical fields and require a hardware‑backed assertion in return. Store and audit the assertions.
Do not replace SMS with email or vice versa. You’re not fighting channel reliability. You’re eliminating channel trust entirely.
4) Phase Out Fallbacks That Re‑Introduce the Hole
Most compromises happen via the least‑resistant fallback: “Didn’t work? Use SMS.” Kill or gate them:
- Remove SMS as a fallback where you deploy WebAuthn. If you must keep it for a minority, isolate those users into a restricted risk tier with lower transaction limits.
- Retire email magic links for admin roles and high‑value accounts. Force WebAuthn or in‑app signing.
- Replace phone recovery with verified device recovery kits: pre‑generated one‑time recovery codes stored offline, or secondary FIDO credentials enrolled in advance.
Design Changes You Need This Quarter
Authentication
- Make WebAuthn the default first factor for new signups. Stop treating it as a “power user” setting. Store user‑verifying credentials only (UV = required). Test cross‑device synced passkeys and offer opt‑out for high‑assurance roles that require device‑bound only.
- Gate legacy OTP with device posture: If OTP shows up (existing users), require additional device signals (App Attest/Play Integrity) and session binding before accepting it.
- Block OTP in notifications: For mobile apps you control, suppress OTP content in notifications. It’s not a fix, but it reduces drive‑by harvesting.
Authorization (Approvals and Step‑Up)
- Transaction signing, not yes/no: Display the exact action (e.g., “Pay $4,200 to ACME LLC, US‑123456789, today”) and require a hardware‑backed signature over that payload. Store it. Make it visible in the audit trail.
- Role and permission changes require WebAuthn or in‑app signing. Never approve via emailed link.
- Data export requires cryptographic step‑up and a short‑lived, single‑use token bound to the session and device.
Support and Recovery
- Agent‑safe recovery kits: Provide 8–12 printed one‑time recovery codes at enrollment. Allow enrollment of 2–3 secondary FIDO credentials. Disable SMS reset fully after successful passkey setup.
- No approvals over email/phone: Support can only initiate an in‑app, attested recovery flow. If a user only has email, require a cool‑down period (24–72 hours) before re‑enabling access.
- High‑risk changes require two different keys (e.g., two admins, or admin + compliance), not two channels.
“But Regulators Require Out‑of‑Band” — Read the Fine Print
Many standards reference “out‑of‑band” as a mitigation. Few insist it must be SMS or email in 2026. What auditors want is independent verification and tamper‑evidence:
- PCI DSS, FFIEC, and SOX care that the approver is the approver and that you can prove it later. Hardware‑backed WebAuthn with UV, plus transaction‑specific signatures and immutable logs, satisfies the principle better than SMS ever did.
- NIST SP 800‑63B explicitly discourages SMS OTP as a high‑assurance factor. Use that to justify your migration plan.
If a specific regulator still equates “out‑of‑band” with “send an SMS,” document why that channel is now automatable and propose cryptographic out‑of‑band: a second, independently attested device with a distinct key, or a second administrator with a separate credential.
Detection and Response: Assume Assistants Are in the Loop
Even with cryptographic controls, you need to spot abuse patterns consistent with assistant mediation:
- Fingerprints consistent with assistant‑driven flows: Repeated near‑instant approvals after notification delivery; identical cursor velocity/gesture profiles; atypical 24/7 cadence.
- Agent egress signatures: Known assistant IP pools, TLS fingerprints, or referer patterns. Do not block wholesale, but score for risk and require step‑up.
- Encrypted payload lure: If a user’s assistant is instructed to decrypt or forward data, you’ll see bursts of copy‑paste behavior. Rate‑limit OTP attempts and detune lock‑screen previews.
Build tripwires in your auth and approval services: when suspicious signals fire, downgrade sessions and force a user‑verifying WebAuthn check before processing sensitive actions.
Governance: Your Audit Trail Must Record the “What” You Signed
Audits that say “User approved at 10:03” are worthless in disputes. Store:
- The exact canonical payload the user saw (normalized amount, currency, counterparty ID),
- The attested app/device that displayed it,
- The cryptographic signature over that payload and key handle/credential ID,
- Any delegations or dual‑approval context.
Put this behind a write‑once log (WORM or append‑only store) and make retrieval a first‑class product feature for your risk team. This turns post‑mortems from blame sessions into evidence‑based triage.
30‑60‑90 Day Plan
Days 0–30: Stop the Bleeding
- Disable lock‑screen OTP previews in your mobile apps; remove OTP content from notifications.
- Ship WebAuthn for all users as a visible, recommended option; make it mandatory for employees and admins.
- Remove email link approvals for admin actions. Require in‑app confirmation with WebAuthn.
- Instrument assistant‑like behavior in auth logs; add simple tripwires and manual review for high‑value events.
Days 31–60: Replace, Don’t Patch
- Make WebAuthn the default at signup and during re‑authentication events. Offer a brief SMS grace period only where unavoidable, with capped privileges.
- Implement transaction signing in mobile and web for payments, data export, key rotation, and role changes.
- Launch recovery kits and secondary credential enrollment. Remove phone‑based resets for staff/admins.
Days 61–90: Burn the Ropes
- Remove SMS OTP from high‑risk markets and roles. Where mandated, isolate to a separate policy domain with reduced limits and enhanced monitoring.
- Turn on UV‑required resident keys and block non‑UV credentials for consumer flows.
- Finalize audit storage for signed payloads with WORM properties and self‑serve retrieval for risk/compliance.
Trade‑Offs You Should Own
- Friction today for fewer incidents tomorrow. WebAuthn enrollment adds a minute to onboarding. That’s cheaper than one support‑enabled ATO.
- Device‑bound vs synced passkeys. Device‑bound is stronger but increases lock‑out risk. For consumers, allow synced passkeys with strong recovery; for admins, prefer device‑bound.
- Support cost shift. You’ll handle more recovery kit and secondary key workflows. Train support and expose self‑serve paths. Net fraud cost still drops.
- Legacy partners. Some fintech and identity vendors still push SMS flows. Escalate now or plan an exit. Your users shouldn’t inherit your vendor’s risk posture.
What About B2B? Your Admins Are the Crown Jewels
Even if your product isn’t consumer‑facing, your admins can approve SSO domain changes, SCIM roles, API token scopes, and export customer data. Treat all admin approvals as signing events, not clicks. Enforce WebAuthn with UV‑required keys, dual control for irreversible changes, and session binding to attested devices.
Brazil/LatAm Note: Don’t Wait on Carriers
If you serve Latin America, you already know SMS delivery and SIM security vary by market. That used to be an operational headache; now it’s a security liability. The good news: WebAuthn works across iOS and Android everywhere, and hardware‑backed keys are ubiquitous. Nearshore pods can help you refactor flows without timezone pain (6–8 hours overlap with US), but the architectural direction is the same: cryptography over channels.
The New Rule
If an assistant can see it or send it, it’s in‑band. That’s fine — as long as what drives your security isn’t the channel, it’s the key. Move your controls there, prove what was signed, and you won’t care who’s reading the inbox.
Key Takeaways
- OS assistants can read and send texts and emails. SMS/email are no longer out‑of‑band — treat them as automatable in‑band.
- Replace channel‑trust with key‑trust: WebAuthn with UV‑required resident keys and explicit transaction signing.
- Kill fallbacks that re‑introduce risk (SMS, email links, phone approvals), or isolate them with tight limits and monitoring.
- Store signed “what you approved” payloads with WORM properties for evidence‑grade audits.
- Detect assistant‑like behavior and require cryptographic step‑up on suspicious flows.
- Regulators want independence and assurance, not SMS specifically. Cryptographic approvals satisfy the intent better than legacy OOB.