> ## Documentation Index
> Fetch the complete documentation index at: https://help.the-meridian.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Suspicious sign-ins
Meridian scores every sign-in for risk **after** your credentials are accepted. A correct password is not the end of the check: if the attempt looks anomalous enough, the account is locked and no session is issued until you approve it out of band.
That ordering is the point. It means a stolen password on its own does not get someone in.
## The signals
Each of these is worth one point, judged against your **last 50 successful sign-ins**. With [2FA](/2-fa) on, a sign-in only counts as successful once the code was accepted, so a device that got past your password but not the code never becomes a known one:
| Signal | Fires when |
| - | - |
| **New IP** | The address has never appeared in that history |
| **New device** | The browser and platform family has never appeared in it |
| **New country** | Meridian sees a different country than any it has recorded for you |
| **Unusual hour** | No past sign-in falls within two hours of the current hour, wrapping around midnight |
| **Failed-guess burst** | 5 or more failed attempts on your account in the last 15 minutes, counting wrong passwords and wrong [2FA](/2-fa) codes |
**Two points locks the account.** The new-country signal only counts once Meridian has a country recorded for you at all, and a first-ever sign-in never triggers any of this, because with no history there is nothing to look anomalous against.
### Passkeys are scored differently
A [passkey](/passkey) is bound to the device it lives on, so the new-device signal is not counted for it and the threshold rises to **three**. A phishing-resistant credential should not lock you out because your phone changed IP on the train.
## What a lock looks like
No session is created, and the attempt is recorded in your [login history](/login-history) as **Blocked: suspicious**. Every further attempt while the lock holds is recorded as **Blocked: locked**.
Meridian emails the account address with two ways to approve, both good for **15 minutes**:
* an **Approve** link, and
* a **6-digit code** to enter.
The link opens a page that shows the device, IP address and time of the blocked sign-in. Nothing is approved until you press **Approve this sign-in** there. Company mail filters open the links in incoming mail to scan them, so a link that approved on its own would let a scanner approve the very sign-in the email warns you about. If it was not you, choose **This was not me, reset my password** instead.
Five wrong codes ends that challenge immediately and you need a new one. New challenges are issued at most once a minute, so repeated attempts do not flood your inbox.
An approval is tied to the **IP address and device that triggered it**. Approving from your phone does not unlock a sign-in you are attempting on your laptop. Approve, then sign in again from the same place the lock came from.
## Getting back in
Approve the challenge and sign in again, or [reset your password](/password). A reset proves control of the same email the approval was sent to, so it clears the lock on its own, and it expires any unused challenge, so an old approval message cannot be used afterwards.
## What this is not
This is not protection against password guessing. Repeated wrong passwords are handled by rate limiting, and locking an account on failed attempts would let anyone lock you out on purpose. The lock here applies only once credentials have **succeeded** and the session still looks wrong, which is why a burst of failed guesses is one input to the score rather than a trigger of its own.
Turning on [2FA](/2-fa) is the stronger control: it stops a stolen password being enough in the first place, rather than catching it afterwards. The two work together: risk scoring runs whether or not 2FA is on.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.