In digital security the signals are almost always ambiguous. A sign-in from a different city might be your phone on a mobile network. A “new” device might be an updated browser.
There is one exception, though, and it is the most useful of all: a verification request you did not start is not ambiguous. It has no innocent explanation. It means one thing only: somebody typed your correct password and stopped at the second step.
This post collects the indicators of compromise connected to multi-factor authentication. It expands on the recommendation protecting accounts with a second factor.
Why these signals are worth more than the others
Three reasons, and they are worth keeping in mind.
They are unambiguous. The second factor is requested only after the password has been entered correctly. There are no meaningful false positives.
They arrive in time. The attempt has stopped: you still control the account and can change the password before anything happens.
They tell you what to do. The implicit message is precise: this password is known to somebody else, replace it.
It is the only case where an indicator of compromise arrives before the damage and with clear instructions. Wasting it — by filing the notification or approving it to stop the nuisance — is the mistake this post is trying to prevent.
Technical indicators
| Indicator | What it means | Why it matters | Where you see it | What to do |
|---|---|---|---|---|
| Verification request you did not start | Somebody entered your correct password | The most direct signal there is: the password is known | Push notification, text, email, authenticator app | Do not approve. Change the password from a safe device |
| Repeated requests close together | Insistent attempts, often at odd hours | Prompted-approval technique: it counts on tiredness | Multiple notifications on the phone | Approve none; change the password at once; silence notifications only afterwards |
| A new authentication method registered | Somebody added a second factor of their own | It is there to keep access even after a password change | Account security settings | Remove it, change the password, regenerate the recovery codes |
| Recovery codes regenerated or used | The previous codes are no longer valid, or one has been consumed | May indicate a recovery started by somebody else | Service notifications, security section | Check whether it was you; otherwise recover the account and regenerate everything |
| MFA disabled without your action | Somebody managed to remove the second factor | It is the step that precedes a takeover | Confirmation emails, account settings | Act immediately: re-enable it, change the password, contact support |
| Successful sign-in from an unknown device despite MFA | The second factor was beaten somehow | Deserves attention: may indicate phishing or a hijacked session | Sign-in history, device list | Revoke every session, change the password, check the registered methods |
| Recovery phone number changed | Text codes would arrive elsewhere | It compromises access and recovery together | Change notifications, settings | Restore the correct number, change the password, move to an authenticator app |
Signs you can observe yourself
| Signal | What it means | Why it matters | How you notice | What to do |
|---|---|---|---|---|
| You receive a code you did not ask for | Somebody is attempting to sign in | As above: the password is known | A text or notification arrives with a code | Do not use it, do not pass it to anyone; change the password |
| Somebody asks you to read out a code | An attempt to be handed the second factor | No legitimate service ever asks this, in any circumstance | A call or message from “support” | End the conversation; check through an official channel |
| Notifications arriving at night | A moment chosen to obtain a distracted approval | It is a technique, not a coincidence | The phone lights up at odd hours | Do not approve; change the password in the morning |
| The verification stops reaching you | The method may have been changed by somebody else | It often precedes losing the account | You try to sign in and the code never arrives | Check the registered methods from the official site |
| A service asks for MFA where you never enabled it | It may be a page imitating the service | Phishing often asks for the second factor too | An unexpected screen after clicking a link | Enter nothing; go in through the app or usual address |
| Sign-ins that no longer ask for the second factor | The device was marked as trusted by somebody else | MFA shows as enabled but is not being applied | You get in without being asked anything | Remove trusted devices you do not recognise |
A concrete example
Sarah receives three notifications in two hours: “Confirm sign-in to your account”.
She ignores the first. The second annoys her. At the third, as she is about to approve just to make the phone stop, she pauses.
She does not approve. She opens the account from her computer, looks at the security section and finds eight sign-in attempts in the last twenty-four hours, all stopped at the second factor.
She changes the password. Then she wonders where it leaked from: it was the same one she used on a forum she had joined years earlier. She changes it there too.
The point: MFA held eight times. The ninth, the one where Sarah was about to approve out of tiredness, would have been enough.
Why “approving to make it stop” is the trap
This deserves a paragraph, because it is how this protection actually gets bypassed.
Repeated requests are not a malfunction: they are a technique. The reasoning behind them is simple — sooner or later an approval will be given out of distraction, out of haste, or simply to make the notifications stop.
It works best in three situations: at night, when people are half asleep; during a meeting, when the phone is disruptive; and when a phone call also arrives presenting itself as support and asking you to “confirm so we can close the report”.
Three rules that settle the matter:
- Never approve a request you did not start, for any reason.
- No legitimate service ever asks you to approve a request or read out a code. None. If somebody does, they are not support.
- If the notifications will not stop, the answer is not to approve: it is to change the password. The requests stop on their own, because without the correct password they can no longer be sent.
The signals that come before the attempt
Some clues arrive before the verification request, and recognising them brings your reaction forward further still.
An alert that a password appeared in a breach. If your vault or browser flags that one of your credentials is circulating publicly, it is reasonable to expect it will be tried. Changing it beforehand means never receiving the request at all.
An incident notice from a service you use. The same reasoning applies, with an added complication: in the days that follow, fraudulent messages imitating the official notice also increase.
An increase in targeted messages. Emails or texts that concern you closely — your name, a service you genuinely use, an order you are waiting for — indicate somebody has information about you. They often precede an attempt to obtain credentials.
A phone call asking for confirmations. Anyone presenting themselves as support and asking questions about accounts or sign-ins is gathering material, even if they ask for nothing explicit.
None of these is an indicator of compromise in the strict sense. They are signals of exposure: they say you are within range of something, not that it has already happened. The appropriate response is the same — change the password and check MFA — but without urgency.
What to check, and how often
| Frequency | What to check |
|---|---|
| As soon as an unexpected request arrives | Do not approve, and change the password within the day |
| Every 2–3 months | Authentication methods registered on your main accounts |
| Every 2–3 months | Devices marked as trusted, which skip the verification step |
| Every 6 months | Validity of recovery codes and associated contact details |
| When you change phone or number | That the registered methods are updated before decommissioning |
What is not an indicator
| Situation | Why it is usually not a signal |
|---|---|
| The service asks for MFA after a trip | The context changed: that is the protection working |
| A code arrives while you are signing in | That is the normal flow |
| MFA is asked more often than usual | Some services shorten how long trusted devices last |
| A code arrives a few seconds after your sign-in | Delivery delay, typical of text messages |
| A “new” device after an update | Updated browsers and systems are often registered as new |
The key difference remains a single one: were you signing in to something at that moment? If yes, it is normal. If no, it is a signal.
If you find an indicator
- Do not approve, and do not pass any received code to anyone.
- Change the account’s password, from a device you trust.
- Check the registered authentication methods and remove any that are not yours.
- Review the trusted devices and remove those you do not recognise.
- Regenerate the recovery codes.
- Change that same password everywhere you had used it: the request you received proves it is in circulation.
The full sequence is in how to turn on a second factor.
Two warnings
MFA reduces risk, it does not remove it. Techniques exist that can work around it in particular circumstances: they are described, without operational detail, in the post on attacks that bypass the second factor. They remain far less frequent than sign-ins with a password alone.
Beware of messages imitating these notifications. Precisely because these are alerts people pay attention to, they get replicated. No legitimate alert asks you to enter your password in order to “verify your security”. Always go in through the app or the usual address, never through a link you received.
How this connects to the Cyber Welfare Framework
| Pillar | What this content contributes |
|---|---|
| Skills | Telling a legitimate request apart from one you did not start |
| Awareness | Understanding that an unexpected request is valuable information, not a nuisance |
| Secure Behaviour | Never approving out of habit, not even to stop the notifications |
Reference level: FL3 — Autonomous.
Conclusion
In digital security it is rare to receive a clear warning, in good time, with implicit instructions on what to do. A verification request you did not start is exactly that.
It is worth treating it as such: not a nuisance to dismiss, but the most useful thing that will happen to you that day.
What to do right now. Open your email’s security settings and look at the list of registered authentication methods. If there is one you do not recognise, you have just found something important.
Related content
- Protecting accounts with a second factor — the recommendation this belongs to
- Attacks that bypass the second factor — what generates these signals
- How to turn on a second factor — what to do when you find one
- Accounts with only a password — why without a second factor these signals would never arrive at all
Start with the first step: the Cyber Welfare Programme guides you free of charge, one recommendation at a time.
