Security · 2026-08-10
Account Recovery Is the Front Door: Carrier-State Checks in Credit Union and Community Bank Recovery Flows
By J. W. Bouckaert
Recovery is authentication with the strong factors removed
Every authentication stack has a second, weaker copy of itself that nobody demos: the recovery flow. It exists precisely because the strong factors failed. The member lost the phone, forgot the password, replaced the device, or got a new number. By construction, recovery must work when the credentials do not, which means it authenticates on whatever is left: knowledge questions, a mailed code, a call-center conversation, or a one-time passcode sent to the number on file.
That last one is the problem this post is about. When the strong path fails, most financial institutions fall back to the phone number. And the phone number is a pointer into a carrier's database rather than a fact about the member: the thing it points at can be moved by an attacker without the member's participation.
Attackers understood this asymmetry years before most control frameworks did. Why phish a passkey that cannot be phished when the recovery flow will mint you a fresh credential after one SMS round-trip to a line you hijacked last night? The strongest authentication deployment in the world inherits the security of its weakest reset path. We made a version of this argument for authentication generally in Why SIM-Swap Detection Alone Is Not a Control; recovery is the place where it stops being an argument and starts being a loss report.
The three recovery flows a credit union runs
Credit unions and community banks are not weaker at this than large banks, only differently shaped, and the shape matters for where the control has to sit.
Digital self-service reset. Online or mobile banking, "forgot password / forgot username," typically gated by an OTP to the number on file plus one or two identity attributes. This is the highest-volume flow and the one attackers automate against. It is also where a carrier-state check is easiest to insert, because the flow is already an API pipeline.
Call center. A member (or someone claiming to be one) reaches a human. The agent authenticates from account attributes, sometimes with an OTP callback as the tiebreaker. Voice channels cannot use a passkey, which makes the phone line's own state, SIM tenure, recent port, forwarding status, the strongest signal available in the channel. It is also the flow where social engineering pressure works on a person instead of a rate limiter.
Branch and shared branching. In-person recovery against physical ID. Strong against remote attackers, but shared branching means a member of one institution can be serviced at another's counter, which widens who is performing identity verification on your member during an account-changing event.
The composite risk is that all three flows converge on the same account, and the attacker chooses the weakest one available that day.
The SIM stays in the loop after passkeys
A common objection from identity teams: "we are rolling out passkeys, SMS is on the way out." The rollout is real; the exposure remains. Three reasons.
First, recovery is the SMS retirement's last mile. Institutions remove SMS from login years before they remove it from reset, because reset needs a channel that survives device loss, and the phone number is the only universal one on file.
Second, the number is used for more than OTP. Call-center callbacks, out-of-band confirmations for wire and ACH release, and fraud-alert outreach all route to the number on file. A hijacked line converts every one of those from a control into an attacker notification service.
Third, the SIM behind the number changes silently. A swap executed at a carrier store, an eSIM profile transfer, or a port to another carrier produces no event your core banking platform sees. The number on file is unchanged; everything behind it moved. The signal variance across carriers makes this worse: the same attack is loud on one network and nearly silent on another, and recycled numbers reproduce the effect with no fraud at all.
The regulatory context has been converging on the same conclusion. The FCC's rules adopted in late 2023 require wireless carriers to use secure authentication before executing SIM changes and ports and to notify customers when one occurs, which tells you what the FCC concluded about how these attacks begin. The FFIEC's 2021 authentication guidance applies well beyond the login ceremony, covering identity verification at enrollment, layered security, and the weakness of single-factor authentication across customer and call-center access, and it is the document your examiners work from. And NIST SP 800-63B classifies out-of-band authentication over the PSTN, which includes SMS, as a restricted authenticator type for exactly the reasons above.
The attack, on a clock
Here is the composite attack as it actually runs against a credit union member, with the timing that makes it work.
Time Event Visible to the institution?
──────────────────────────────────────────────────────────────────────────────
T-14 days Credential stuffing / phish yields No
member email + partial attributes
T-1, 21:40 SIM swap executed at carrier No (nothing on file changed)
T-1, 21:41 Member's handset drops to no-service No
T+0, 08:05 "Forgot password" on digital banking Yes, as a routine reset
T+0, 08:05 OTP sent to number on file → Yes, as a successful OTP
attacker's device receives it
T+0, 08:07 New password + new device enrolled Yes, as a routine enrollment
T+0, 08:15 External transfer initiated; Yes, as an authenticated
out-of-band confirmation goes to member action confirming
the hijacked line its own fraud
T+0, ~09:00 Member reaches call center about Yes, first real signal,
dead phone; agent sees "recent after the money moved
successful authentication"
──────────────────────────────────────────────────────────────────────────────Every row the institution sees looks like a member helping themselves. The only fact that was abnormal, the SIM behind the number changed hours before the reset, was never queried. The window between swap and drain is measured in hours, which is why detection latency is the whole game: a nightly batch file of carrier events answers yesterday's question.
A carrier-state check inside the flow
The control is one additional question, asked at the moment it matters: in this recovery request, before sending the OTP or honoring the callback, what is the live state of the line we are about to trust?
Concretely, the check returns facts of this shape: how long the current SIM has been associated with the number (tenure), whether a port-out or swap occurred inside a defined window, and whether the number was recently recycled to a new subscriber. Sourced live via carrier-grade providers over GSMA Open Gateway interfaces rather than from a batch file, the answer arrives inside the request, fast enough to sit inline in a reset flow or on an agent's screen before the callback is dialed.
The decision logic worth copying is deliberately unclever:
- Fresh swap or port inside the risk window + recovery request → hard deny on the SMS path. Route to a channel the attacker does not hold: branch visit, video verification, or a passkey ceremony on a previously enrolled device. This is a binary rule with no score to tune, which is what lets it wire directly into an existing rules engine.
- Stable tenure → proceed, and record the signed attestation alongside the reset event so the decision is auditable later.
- Signal unavailable (carrier gap, MVNO opacity, provider degradation) → degrade honestly: step up to another channel rather than silently reverting to trust. Freshness matters more than existence here: a stale signal is a no-answer, not a weak yes.
Two properties make this deployable at a credit union's scale rather than a money-center bank's. Integration is a REST call from the reset pipeline or the agent desktop, well short of a platform migration. And the check runs zero-PII: the number is hashed with keyed HMAC-SHA-256 before it touches storage on our side, so adding the control does not add a member-data store to your vendor-management inventory.
Ownership when the check denies a recovery
The uncomfortable organizational truth: when a carrier-state check denies a recovery, the event lands in a gap. Fraud teams own losses and see the chargeback after the fact. IAM owns the reset flow and sees a support ticket. The call center owns the angry caller. Nobody, by default, owns "a hard identity signal fired mid-recovery and someone must now decide what the member experiences."
The fix is a written playbook, agreed before the first deny, that answers four questions: who is paged, what the member-facing script says, which alternate channel completes the recovery, and who clears the hold once identity is re-established. We published the template we use with financial institutions in Building an Identity Threat Playbook; the recovery-flow section is the part most institutions adopt first, because it turns a deny from a support escalation into a procedure.
Examiners increasingly ask a version of the same question. Layered security that stops at login does not satisfy guidance that explicitly names the lifecycle; a documented, evidenced control inside recovery, with an audit trail of signed attestations for each decision, does.
Limits of the control
A control you deploy on the strength of a vendor's silence about its limits is a control you will mis-trust. The failure modes, plainly:
- Coverage is uneven. Carrier signal quality varies by network, and some MVNOs expose little or nothing. The mitigation is the degrade-honestly rule above. Pretending the check is universal is the failure mode.
- Recycled numbers are only detectable when the carrier exposes the event. A quietly reassigned number can look tenured. Treat long-dormant contact numbers on high-balance accounts as their own review class.
- The insider-shaped attack bypasses it. A fraudulent recovery executed with a genuine, unswapped line, coached social engineering of the member themselves, carries a clean carrier state. Carrier signals price one attack class; they do not replace behavioral controls for the others.
- It is one signal among several. The deny rule is deliberately binary for the swap-plus-recovery composite because that composite is overwhelmingly hostile. Most other combinations belong in your existing risk engine as a weighted input, alongside device and behavioral signals.
Placement in the PasskeyBridge architecture
For readers mapping this to PasskeyBridge specifically: the recovery-flow check is the same in-request verification primitive we run everywhere else, consumed at a different call site. The fraud prevention API returns the signed attestation your rules engine consumes; the account takeover prevention lander covers the login-side counterpart; and the live playground runs real probes against production if you want latency numbers you measured yourself rather than read in a vendor's post.
The summary that fits on an index card: recovery flows trust the phone number at exactly the moment the phone number is least trustworthy. Ask the carrier what happened to the line before you trust it. Deny the composite that is almost never legitimate. Write down who owns the deny. And be honest, internally and with your examiner, about what the signal can and cannot see.