ASVS V6.3.5 requires that users are notified of suspicious authentication attempts, whether successful or not. Examples include an unusual location or client, a partially successful attempt where only one factor passed, a sign in after a long idle period, and a success after many failures. It is a Level 3 requirement.
This is the first control in the chapter that depends on understanding normal behavior. To notice something unusual, you need a record of what usual looks like for each account.
Why it matters
The account owner is the best detector of account takeover. An alert gives them a chance to react before an attacker settles in.
Passwords leak and second factors get phished. Detection is the layer that catches what prevention missed. Account owners have context you lack: they know whether they were in another country yesterday or whether they own a new phone. A notification asks them a simple question, "was this you?", and turns a silent compromise into a visible event.
The quality of the signal matters. Too many alerts and users ignore them, too few and the control does nothing. Choose a few high value rules and tune them.
How to implement it
Compute simple risk signals at login and send a message through a channel the attacker does not control, with a link to review activity.
def risk_signals(user, ctx):
s = []
if ctx.device_id not in user.known_devices: s.append("new device")
if ctx.country != user.last_country: s.append("new country")
if (now() - user.last_login).days > 90: s.append("long inactivity")
if user.recent_failures >= 5: s.append("success after failures")
if ctx.mfa_partial: s.append("partial authentication")
return s
signals = risk_signals(user, ctx)
if signals:
notify(user, f"Sign in alert: {', '.join(signals)}. Not you? Secure your account.")
Do not include one time codes or session links in the message. Avoid alert fatigue by tuning thresholds.
Maintain a small profile per user: known devices, usual countries or networks, typical hours and the last successful sign in. Evaluate each attempt against it and score.
Good triggers are:
- A sign in from a new device or client.
- A new country or a network type associated with anonymizers.
- Partial authentication, where the password passed and the second factor failed. This often means the password is known.
- A success after a burst of failures.
- A sign in after a long period of inactivity.
Deliver the message through a channel the attacker does not control. Make it plain: what happened, when, from roughly where, and a clear action to secure the account, which signs out all sessions and starts a password change. Avoid links that log in automatically.
Store the event in an account activity page as well, so users can review history without relying on one email. Keep a counter of notices per user per day to prevent mail floods from becoming an attack of their own.
How to test it
Sign in from a new device, from a different country using a test proxy, after setting last login to 100 days ago, and after five failed attempts. Each must produce one notice with correct context.
Prepare scripted scenarios in staging: a fresh device, a header that claims another country, a user whose last login is 120 days old, five failures followed by a success, and a password correct but second factor wrong. Verify the notification count, wording and recipient for each case. Check that a normal sign in from a known device sends nothing, since false positives will teach users to ignore the messages.
Also verify that the alert still works when the attempt came through the API or SSO rather than the web form.
Common mistakes
-
Notifying only on success.
-
Sending alerts to an address the attacker just changed.
-
Including a magic sign in link in the alert.
-
Sending alerts that contain one time codes or sign in links.
-
Using IP geolocation as the only signal when many users share mobile carrier addresses.
-
Alerting only after a successful sign in, which hides targeted failed attempts.
-
Keeping no record of the notice, which makes it impossible to prove the control in an audit.
Quick check
Should failed attempts ever trigger a notice?
Yes, when they are partial successes or form a pattern, since they show active targeting.
