Two Recovery Checks. One Retired Phone Number. A PayPal Account Takeover.

How one retired phone number became the key to a financial account, and what the incident taught me about identity, recovery design, and what account-takeover response should really look like.

My wife did not click a phishing link.

She did not share her password.

She did not approve an unexpected login or read an MFA code to a stranger.

In fact, she never interacted with the attacker at all.

Her PayPal account was still taken over.

The opening was a phone number she had stopped using years earlier.

According to multiple PayPal fraud representatives, the attacker reset her password using two recovery checks: an SMS message and a WhatsApp message.

Both were tied to the same retired phone number.

Two checks. One underlying factor.

That is the part of this story that should matter to anyone who has ever changed a phone number, retired an email address, replaced a credit card, or simply forgotten about an old online account.

It should also matter to the people designing authentication, fraud, and recovery systems.

I have spent much of my career in CIO and cybersecurity leadership roles. When this happened at home, the incident responder in me took over. I wanted to know four things: What happened? How did the attacker get in? What persistence had they established? And what had to change so it could not happen again?

What followed became a useful reminder that security failures are rarely about one bad password. They are often about old identity data, weak recovery logic, and the gap between restoring a user’s access and actually removing an adversary from an account.

The forgotten number

A few years ago, my wife changed her Google Voice number. She no longer used it, and like most people, she did not maintain a master inventory showing every online account that still referenced it.

That matters because the modern household has an identity inventory problem.

Most of us have accumulated hundreds of online accounts over many years. As our lives progress, we change phone numbers, change jobs, move homes, replace cards, retire email addresses, and forget about services we rarely use. But those old identifiers do not always disappear from the accounts that once depended on them.

In this case, the retired number remained associated with an old PayPal account that my wife had not logged into for years.

My wife had done many of the things security professionals tell people to do. She uses unique passwords, a password manager, MFA, and passkeys where available. None of those controls helped with an account-recovery path tied to a phone number she no longer controlled.

The first warning arrived quietly: an email saying her PayPal password had been reset.

It went unnoticed and unread in her inbox.

That is not unusual. Personal inboxes are noisy. And anyone who works in security knows the irony: PayPal-themed phishing is so common that legitimate PayPal security messages can resemble the very messages people have been trained not to trust.

About a week later, while catching up on unread emails, my wife noticed the earlier PayPal password-reset notification along with a newer PayPal email for a payment she did not recognize. She asked whether I knew anything about it.

My first thought was phishing.

It was not.

We opened PayPal directly rather than clicking anything in the email. The transaction was real. The account had been compromised.

At that point, the payment stopped being the problem.

It was evidence.

The account was the incident.

The incident responder in me took over

Having led organizations through cybersecurity incidents, I immediately shifted into crisis-response mode. My wife could still get into the account using a legitimate passkey that the attacker had not removed. That was fortunate, because it gave us visibility into the state of the account before speaking with PayPal’s fraud team.

Once inside, I approached it the way I would approach a compromised enterprise identity: establish the timeline, assume persistence, review every trust relationship, remove anything that could allow re-entry, and only then rebuild trusted access.

We found exactly what I would expect an attacker to establish after gaining control:

• A passkey we did not recognize.
• Multiple OneTouch auto-login authorizations that were not hers.
• Multiple unfamiliar Android device sessions.
• Changes to authentication and trusted-access relationships that could allow the attacker to return.

The attacker had done more than change the password. These screenshots show the additional persistence we found inside the account: registered passkeys, OneTouch auto-login authorizations, and approved device sessions. Most of the entries shown were unfamiliar and did not belong to my wife, reinforcing why a password reset alone is not enough to contain an account takeover.

That is the part of account takeover many consumers never see. Once inside, an attacker may establish persistence through trusted devices, sessions, passkeys, or other authentication methods that survive a password reset.

Account recovery and incident containment are not the same thing.

Recovery gives the legitimate owner access again.

Containment removes the adversary.

We reset the password, reviewed authentication methods, removed the unauthorized passkey, cleared unfamiliar sessions and devices, removed OneTouch authorizations we did not recognize, re-established trusted authentication, and reviewed the account for other unauthorized changes.

As far as we could determine, there were no additional unauthorized transactions beyond those already identified. PayPal reversed the unauthorized payment quickly, and there was no financial loss. That part of the response was fast and effective.

But I still did not know how the attacker got in.

And until you know that, you do not know what else you should consider compromised.

How did they get in?

This became the investigative part of the incident.

I called PayPal’s fraud department repeatedly because the answer mattered. If the attacker had compromised my wife’s email account, I needed to respond to that. If they had used an old credit card, I wanted to understand that exposure. If they had answered security questions, that suggested a different problem again.

The first explanation we received was vague and initially pointed us in the wrong direction. A representative referred to my wife’s email address and the forgot-password process, which left open the possibility that the email account itself had been compromised.

So I kept asking.

On a later call, a PayPal fraud representative confirmed the recovery methods used in the actual takeover.

The attacker had initiated PayPal’s “Forgot password” process using my wife’s email address as the account identifier.

Then, according to the representative, the attacker used “Get a Text” as one recovery check and “Get a WhatsApp Text” as the other.

Both went to the same retired number.

I did not rely on that one conversation. We subsequently confirmed the same recovery sequence with additional PayPal fraud representatives, including a supervisor. One representative also confirmed that no email code, credit card number, or security-question response was used. This narrowed the reset path to the SMS and WhatsApp checks tied to the retired number.

That changed the entire understanding of the incident.

Two recovery prompts. One phone number.

At the time of the incident, the PayPal recovery screen we observed presented several options, including SMS, WhatsApp, security questions, and confirmation of a credit card number.

The problem was allowing SMS and WhatsApp associated with the same telephone number to satisfy successive recovery checks.

From a security-design standpoint, those are not independent factors. Two interfaces are not two independent controls when compromising the same underlying asset defeats both.

Based on what PayPal’s representatives told us, that was the path used to reset my wife’s password. Had the recovery process required genuinely independent evidence, this specific takeover path would not have worked.

Large-scale breaches involving companies such as Equifax, Marriott, Meta, Ticketmaster, and Change Healthcare have exposed enormous volumes of personal information, including names, email addresses, phone numbers, physical addresses, dates of birth, payment information, and other identity data.

I do not know how the attacker connected my wife’s retired phone number to her PayPal login, and I do not want to speculate about a specific source or technique. But pieces of our identity now exist across an enormous number of systems, and once that data is exposed, scraped, brokered, or stolen, attackers can potentially connect relationships we may have forgotten ourselves.

An old phone number that seems meaningless to you may still be an authentication signal somewhere else.

What I reported to PayPal and what appears to have changed

Once I understood the recovery path, I told PayPal’s fraud team that I believed the same-number recovery logic represented a serious security weakness and asked that it be escalated.

PayPal never provided me with a written technical explanation of what it changed or when.

But something changed.

When I tested the flow a few days after reporting the issue, I could not reproduce the SMS-then-WhatsApp sequence. After completing SMS verification, WhatsApp tied to that same number was no longer available as the next recovery check. I also tested the behavior using several other accounts available to me and could not reproduce the earlier sequence.

A PayPal fraud representative later told me the recovery concern had been escalated to its technical team and thanked me for bringing it to their attention, noting that it could affect other users as well. She also indicated that the earlier recovery flow was no longer available at that time and said the matter had been taken very seriously.

That deserves credit.

If the control was changed in response to this incident, PayPal moved quickly.

But quick remediation should not obscure the underlying lesson: the recovery design should not have allowed two channels dependent on the same telephone number to function as independent assurance in the first place.

For security and technology leaders, the lesson is simple: adding another verification step does not automatically add security. If the same underlying compromise defeats both, the system may look layered while still depending on a single point of failure.

The bigger problem I still think PayPal needs to solve

The specific recovery weakness we observed appears to have been addressed.

The customer account-takeover support experience is what still concerns me.

During our initial fraud-support calls, the focus was primarily on the unauthorized transaction, the password, and whether my wife could get back into the account.

No representative proactively initiated a comprehensive reset of the account’s trust relationships. We were not immediately guided through every active session, passkey, OneTouch authorization, trusted device, and authentication method. We discovered and removed the broader persistence mechanisms ourselves. It was only after I asked whether PayPal normally helps customers review those areas that a representative offered to walk us through some of the checks.

That may sound like a support-process issue. It is actually a security-control issue.

Imagine the account holder was not married to someone who has spent years dealing with cybersecurity incidents.

Imagine it was your mother.

Your grandfather.

Your aunt or uncle.

The fraudulent payment gets reversed. The password is changed. A fraud representative confirms that the user can log in again.

Would that person know to inspect registered passkeys?

Would they know what OneTouch is?

Would they know to terminate every unfamiliar session and trusted device?

Would they know which MFA methods should be removed and re-enrolled?

Should they have to?

They should not.

A confirmed account takeover should trigger a repeatable containment workflow that returns the account to a known-good state. Active sessions should be terminated, newly added authentication methods and trusted devices reviewed or revoked, recovery information verified, and the legitimate owner helped to rebuild trusted access.

PayPal did an excellent job of quickly reversing the unauthorized charges and recovering the funds, but fixing the transaction is not the same as securing the account.

The customer should leave the interaction knowing two things: the money is addressed, and the attacker is gone.

Security has to work for the least technical legitimate customer while still being difficult for the most capable attacker.

The bigger lesson: your digital identity has an inventory problem

The most important lesson I took from this incident is not actually about PayPal.

It is about how we manage digital identity over time.

Phone numbers, email addresses, postal addresses, payment cards, recovery emails, and authentication methods are no longer merely contact details.

They are identity infrastructure.

Online services use them to decide who we are, how we recover accounts, and sometimes whether we should be allowed to reset credentials.

But most households do not maintain an inventory of that infrastructure.

We should.

I am a strong advocate of password managers, but I think we need to use them for more than passwords. Treat your password manager as a lightweight inventory of the identity information attached to your important accounts.

For financial, medical, government, cloud-storage, primary email, and other sensitive accounts, record at least:

• The registered email address.
• The registered phone number.
• Any recovery email address or phone number.
• The postal address on file when relevant.
• The MFA method in use.
• Any important payment or identity information the service relies upon for recovery.

Then make one behavior routine:

Whenever you change a phone number, retire an email address, move homes, or replace an identity anchor, search the password manager for the old value and update every account that still depends on it.

That simple practice would have identified this old PayPal association before an attacker did.

The security basics still matter

This incident does not mean passwords, MFA, passkeys, or password managers failed. It demonstrates why security has to be managed as a lifecycle rather than a one-time setup.

Use strong authentication, keep recovery information current, review trusted devices and active sessions on sensitive accounts, and treat unexpected password-reset messages as incidents until proven otherwise.

Most importantly, when you retire a phone number or email address, do not assume the risk retires with it.

Security leadership starts at home

Executives and security leaders spend enormous amounts of time talking about identity governance, asset inventories, layered controls, incident response, root-cause analysis, and lessons learned.

Those principles do not stop at the office door.

Our households are small digital enterprises. They contain financial information, health records, identity documents, cloud accounts, personal communications, and the people we care most about.

This incident ended well. PayPal reversed the unauthorized transaction. We contained the account. The specific recovery sequence involved in the takeover appears to have been changed after I raised it. Those are meaningful positives.

But the incident should never have been possible through the recovery path PayPal’s representatives described to us.

And a customer who reports a confirmed takeover should not need cybersecurity expertise to make sure the attacker has truly been removed.

That is where I believe PayPal, and every company responsible for sensitive consumer identities, should keep improving.

If you do one thing after reading this, open your password manager today and search for every old phone number and email address you can remember.

The account you forgot about may be the one an attacker finds first.

---

Joshua Bellendir is a technology executive and advisor with global CIO and cybersecurity leadership experience across retail, technology, and consumer businesses.