This unit has a peculiarity: the signal arrives on its own. You do not have to look for it — it is a notification appearing on your phone.
The problem is therefore not noticing it. It is twofold, and subtler: working out whether the alert is real, because fake security alerts are among the most widespread deceptive messages; and working out what it actually says, because a real alert contains information almost nobody reads all the way through.
It expands on the recommendation account login alerts.
First question: is the alert real?
Fake security alerts work because they arrive at a moment when critical attention is low: there is alarm, and alarm pushes people to act quickly.
What marks out a fake alert
| Element | A real alert | A fake alert |
|---|---|---|
| What it asks | It informs, and suggests you check | It asks you to click now |
| Tone | Neutral, descriptive | Urgent, threatening |
| Deadline | None | “Within 24 hours or the account will be closed” |
| Data requested | None | Password, verification code, payment details |
| Personalisation | It uses your name and your account’s details | Generic: “Dear user” |
| Where it leads | To the service’s security section | To a page imitating the service’s |
The most reliable row is “Data requested”: a service never asks for your password or a verification code inside a security message. If it asks, it is not that service.
The rule that makes any analysis unnecessary
There is a way never to have to decide whether an alert is real: do not decide.
Ignore the message, open the service’s app or type the address into your browser, go to the security section. If there is something, you see it there. If there is nothing, the message was fake.
That rule has an advantage worth noting: it works even if the fake alert is beautifully made. It does not require recognising the deception — it goes around it.
The variant that exploits a real alert
There is a more insidious case: you receive a real alert about a failed sign-in, and a few minutes later a call or a message presenting itself as the service’s support, referring to that alert.
The coincidence is credible because it is true: whoever tried to sign in knows they generated the alert. The rule stays the same — no legitimate support asks for verification codes, and if in doubt you end the call and dial the service’s official number yourself.
Second question: what does the alert say?
A real alert typically contains four pieces of information. Each says something, and none is conclusive on its own.
The device
“Windows”, “iPhone”, “Chrome on Mac”. It is the most useful piece of data: if you do not own that kind of device, the sign-in is not yours.
Careful, though: a different browser on the same computer can present itself as a new device, and the same goes after a system update or after clearing browser data.
The location
A city, usually. It is the least reliable of the four, and it is worth explaining why: the location is inferred from the network address, and that indicates where your operator’s node is, not where you are.
On a mobile connection it can show a city tens of kilometres away. With a VPN on, it shows the server’s country. An unusual location on its own is not a signal; a plausible location is not reassurance.
The time
It is the most underrated piece of data. A sign-in at 4 in the morning while you were asleep is a strong signal, even if the device and location look plausible.
Always compare the time with what you were doing: it is the quickest check and often the most conclusive.
The outcome
“Successful sign-in” or “failed attempt”. The difference is substantial:
- Successful and not yours: somebody is in. Act at once.
- Failed and not yours: somebody has your password but not the second factor, or is trying. The password should be changed anyway.
The second case often gets filed as “nothing happened”. In fact it is the news that a credential of yours is in circulation.
The patterns that count more than a single alert
An isolated alert says little. A sequence says a great deal.
Repeated attempts close together. Five failed sign-in alerts in ten minutes indicate a systematic attempt, not a typo.
Attempts across several different services. If alerts arrive from different services in the same period, the common factor is probably a reused password or a provider’s breach.
A successful sign-in alert after a run of failures. It is the most serious signal possible: it means somebody kept trying until they got in.
A change alert after a sign-in. A successful sign-in, and immediately after an alert about a password change or a recovery method being added: the typical sequence of a takeover. Here minutes count.
Silence where you expected an alert. If you signed in from a new device and nothing arrived, the configuration is not working. That is a signal about the detection system, not about the account.
What is NOT a signal
To stop the noise making the system useless.
| What | Why it is not a signal |
|---|---|
| A sign-in from a nearby city | Network geolocation is approximate |
| “New device” after clearing cookies | The service no longer recognises you |
| A sign-in from a different browser | It counts as a different device |
| A sign-in after a system update | The device identifier changes |
| A sign-in “from another country” with a VPN on | It is the VPN’s server |
| An isolated failed attempt | It can be a typing error of your own |
The general rule: a single anomaly almost always has an explanation; two consistent anomalies in the same time window do not.
The signals that come from outside
Not every clue in this unit arrives as a service alert. Some arrive from other directions, and they are often the first to appear when alerts are not configured.
A contact reports an odd message. “Did you write me this?” is, in practice, the most frequent way people discover a sign-in. It is a strong signal and should be taken seriously even when the message looks harmless.
A service asks you to confirm a change you did not request. An address change, a device added, a password reset request. Do not click the link: go to the service and look.
You receive verification codes you did not request. It means somebody is trying to sign in and is getting as far as the second factor — that is, they already have the password. It is a serious signal, and should be treated as such even if the attempt did not succeed.
A service stops working for no reason. A password not accepted, a session that closes, an app asking you to sign in again. It can be a technical problem, but it is also the effect of a password changed by somebody else.
An invoice or a charge you do not recognise. It arrives late relative to the event, but it arrives.
These signals share a characteristic: they appear once something has already been done. They are later than alerts, and they are exactly what is left to anybody who has not configured them.
What to do, in order
If the alert is real and the sign-in is not yours:
- Go to the service from the app, not from the message.
- Revoke every active session, not only the one reported.
- Check the recovery methods and remove entries that are not yours.
- Check the forwarding rules and the connected apps.
- Change the password, now and not before.
- Turn on the second factor if there was none.
- Check the other accounts using that same password.
If the alert reports a failed attempt: change the password anyway and check the second factor is on. The failed attempt is telling you somebody has the credential.
Building a reference point in three weeks
The most effective way to read alerts well is not to study the rules: it is knowing what your own normal sign-ins look like. With that reference point, the anomaly stands out with no analysis needed.
Building it takes little.
Week 1. Every time an alert arrives, open it and look at the four pieces of information. Do nothing, just look. You are learning how your devices appear in the service’s language: you will discover your phone shows up under a different name from the one you expect, and that your computer can appear to be in a nearby city.
Week 2. Open one account’s sign-in log and scroll through the last month. Note the regularities: which devices appear, in which time bands, from which locations.
Week 3. Deliberately sign in from a different device — the home computer, a family member’s phone with your account, a different network — and look at how the service describes it. Now you know what a “new but yours” sign-in looks like.
At the end you have something no guide can give you: a personal yardstick. It is why false alarms decrease over time — not because fewer alerts arrive, but because telling them apart becomes immediate.
How this connects to the Cyber Welfare Framework
| Pillar | What this content contributes |
|---|---|
| Awareness | Knowing that alerts are also phishing’s favourite template |
| Skills | Reading an alert’s four pieces of information and weighing them correctly |
| Secure Behaviour | Always checking from the app, never from the link |
Reference level: FL3 — Autonomous.
Summary
- Checking does not require recognising the fake: going to the service yourself is enough.
- Location is the least reliable piece of data; time is the most underrated.
- A failed attempt is not good news: it means the password is in circulation.
- What counts are the sequences, not the individual alerts.
One thing to do today. Take the last security alert you received and reread it looking for the four pieces of information: device, location, time, outcome. If you cannot find all four, you already know that alert needed checking from the app.
Related content
- Account login alerts — the recommendation this expands on
- How to turn on login alerts — the configuration that makes them arrive where they help
- How login detection works — why a service considers a sign-in unusual
- Attacks that rely on delayed detection — what happens when the alert goes unread
Related resources
Short reads from the Resources section, for anyone who wants to stop on a single aspect:
Start with the first step: the Cyber Welfare Programme guides you free of charge, one recommendation at a time.
