Your Okta Is Only As Strong As Your SIM Card

Most security teams sleep well knowing MFA is enforced in Okta,
Azure AD, or Duo. Then someone ports an employee's phone number to
a burner SIM in under 10 minutes and the identity perimeter
unravels silently.

This is the SIM swap blind spot in enterprise identity. Almost
nobody is talking about it.

The attack chain

1. Attacker identifies target via LinkedIn
2. Calls carrier, provides scraped personal data (DOB, address, last 4 SSN — all available from prior breaches)
3. Carrier ports the number. Target loses mobile service.
4. Attacker hits the Okta portal, triggers SMS OTP or recovery
5. Code arrives on attacker's device. Session established.

Total time: under 30 minutes. No malware. No zero-day.

Where Okta and SMS intersect

SMS OTP as primary factor — Many Okta deployments enable SMS
because app-based authenticators create support tickets. If SMS is
an allowed factor, a SIM-swapped number gives the attacker a live
OTP delivery channel. Your policy is satisfied. Access granted.

Account recovery fallback — Even if primary MFA uses Okta
Verify or TOTP, recovery often falls back to SMS. That single
fallback path is all an attacker needs.

Downstream email compromise — Gmail and Outlook offer SMS
account recovery. SIM swap the employee → reset their Google
account → own the email Okta is registered to. Game over.

The carrier layer is outside Okta's scope

Okta, Microsoft, and Duo will tell you to use phishing-resistant
MFA. They're right. But the carrier layer is invisible to every
identity platform — always has been.

Detecting it with code

SIM swap detection requires querying carrier data directly. Here's
how to check whether a number has been ported before triggering
account recovery or a high-risk action:

REST API (Python)

python
import requests

def check_sim_swap(phone: str) -> dict:
    """
    Returns swapped (bool), swap timestamp, and current carrier.
    Call before any high-risk action gated by SMS-based auth.
    """
    response = requests.post(
        "https://xhh3tfrhng.execute-api.us-east-1.amazonaws.com/prod/v1/sim-swap",
        headers={"x-api-key": "YOUR_RAPIDAPI_KEY"},
        json={"phone": phone}
    )
    return response.json()

result = check_sim_swap("[phone]")

if result.get("swapped"):
    print(f"⚠️  SIM swap detected at {result['swap_timestamp']}")
    print(f"   Current carrier: {result['carrier']}")
    # Block account recovery, alert security team
else:
    print("✓ No SIM swap detected — safe to proceed")

**MCP Server (for AI agents)**
If you're building agents that handle user identity or account
actions, add SIM swap detection as a pre-flight check:

pip install relayshield_mcp

from plugins.relayshield.relayshield_game_plugin import relayshield_functions
# Drop into any GAME agent worker — check_sim_swap is ready to call

**Where to gate it in your stack**
def okta_account_recovery_hook(user_phone: str) -> bool:
    """
    Pre-recovery hook — block if SIM swap detected in last 24hrs.
    Wire this into your Okta inline hook or recovery flow.
    """
    result = check_sim_swap(user_phone)

    if result.get("swapped"):
        # Log security event, require in-person verification
        security_alert(user_phone, result)
        return False  # Block recovery

    return True  # Safe to proceed

**What to fix right now**
**Audit factor enrollment** — find every Okta user with SMS
enabled
**Disable SMS as primary factor** — enforce Okta Verify or TOTP
**Harden recovery flows** — no SMS fallback for privileged
accounts
**Add detection** — query carrier data before account recovery
or high-risk actions
**Brief your help desk** — social engineering is the human
version of the same attack

**The bottom line**
Enterprise MFA is only as strong as its weakest factor. For most
organizations, that weakest factor is a phone number on a carrier
database that can be socially engineered in minutes.

The carrier layer is invisible to every identity platform. That's
the gap. Now you know where it is — and how to close it.

*SIM swap detection API: [RelayShield on RapidAPI](https://rapidapi.com/relayshielduser/api/relayshield-security-intelligence) — free tier available.*