Sentinel calls the user before it locks the account
The cheapest way to know whether a login is legitimate is to ask the person whose login it is, and almost no security process is built to do that in the moment it would matter.
What actually happens
Every automated response to an anomalous login is a bet. Calling the account owner is the only step that settles it rather than improving the odds.
An anomalous login is detected. The available responses in most estates are to block, to queue for an analyst, or to send an email or push notification and hope for a response.
Blocking is fast and frequently wrong, and every wrong block costs you a colleague being unable to work plus a small amount of the organisation willingness to cooperate with security controls.
Queueing is safe and slow, and the safety is illusory: while the alert sits in a queue, a real compromise is progressing.
Emailing or pushing to the user is the worst of the three in the specific case that matters. If the account is compromised, the attacker may well control the channel you are sending to, and if it is not compromised, the legitimate user is asleep and their phone is on silent.
A phone call is different in one important respect. It is out of band relative to the compromised credential, it interrupts rather than queues, and the answer arrives in seconds rather than at the convenience of the recipient.
Block, queue, or email. Each is a way of avoiding the one action that would settle it, which is talking to the person.
The same detection, two ways
This is not a comparison of detection quality. Both columns detect the same event at the same moment.
Illustrative, not measured. The times below model a scenario built from the patterns we see in production estates. They are not timings recorded at a named customer. The point is the shape of the clock, not the totals: check it against your own last ten incidents.
Today, block or queue
- 22:41Anomalous login detected. Policy is to block first and confirm afterwards.
- 22:41Account locked automatically. Session terminated.
- 22:41 ↓ 23:20WaitingLegitimate user, travelling, cannot work. Raises a service desk ticket.
- 23:20 ↓ 00:05WaitingTicket triaged, identity confirmed through the service desk process.
- 00:05Account unlocked. Incident closed as a false positive.
- OngoingThe user, and their team, now route around the control where they can.
~85 minutes of lost access · and a lasting trust cost
With Sentinel calling first
- 22:41Anomalous login detected. Sentinel assembles context before choosing a response.
- 22:42Device posture, travel records, session behaviour and comparable recent patterns correlated.
- 22:43Sentinel places a voice call to the account owner on a number held in the identity system, not one supplied by the session.
- 22:43Owner answers and confirms. Session annotated. Geography added to the expected set with an expiry.
- 22:44No lockout, no ticket, no analyst engaged, and a full evidence bundle retained.
- If no answerIsolation MOP staged with blast radius mapped, escalated to the duty manager for approval.
Resolved in the moment · and the same path if the answer had been no
The comparison that matters is not the eighty-five minutes. It is the false positive rate multiplied by your login anomaly volume, because that product is the amount of legitimate work your security control destroys per month.
Most estates handle that by loosening the detection until the false positives are tolerable, which is exactly the wrong adjustment: it reduces the visible cost by increasing the invisible one.
Out-of-band voice contact changes the economics of the detection threshold. If confirming a suspicious login costs seconds and interrupts nobody except the account owner for the length of one question, you can afford to investigate far more anomalies than you can afford to block.
The out-of-band property is the part to scrutinise. The number is taken from the identity system rather than from anything the session supplied, which is what makes it resistant to a compromised account redirecting the confirmation to itself.
Why the number is what it is
The comparison that matters is not the eighty-five minutes. It is the false positive rate multiplied by your login anomaly volume, because that product is the amount of legitimate work your security control destroys per month.
Most estates handle that by loosening the detection until the false positives are tolerable, which is exactly the wrong adjustment: it reduces the visible cost by increasing the invisible one.
Out-of-band voice contact changes the economics of the detection threshold. If confirming a suspicious login costs seconds and interrupts nobody except the account owner for the length of one question, you can afford to investigate far more anomalies than you can afford to block.
The out-of-band property is the part to scrutinise. The number is taken from the identity system rather than from anything the session supplied, which is what makes it resistant to a compromised account redirecting the confirmation to itself.
Out-of-band voice contact changes the economics of the detection threshold.
Who decides to press go
The voice call is the reversible action. Everything after it is not, and is gated accordingly.
Placing the call, assembling evidence, retaining session recording and staging the isolation MOP all run under policy. None of them locks anything.
The isolation MOP is raised and held with the evidence bundle, the affected systems and the rollback path attached. A named human approves before any account is touched.
If the owner does not answer, that is escalated rather than treated as consent. The absence of a confirmation never becomes a justification for automatic action.
Anomalous login detected. Response options are block, queue, or contact. Context not yet assembled.
Device posture, travel records, session behaviour and comparable recent patterns correlated before any response is chosen.
Voice call placed to a number held in the identity system. Isolation MOP staged but not executed. Session recording retained regardless of outcome.
Confirmed geography added to the expected set with an expiry. Detection threshold reviewed against the confirmed outcome so investigation volume can rise without lockout volume rising.
This is a platform capability, not a published customer deployment. The mechanism, which is correlated investigation followed by out-of-band contact and governed action with approval gating, is running in production today; see governed day-2 operations across 2,000+ nodes and closed-loop network automation. The voice scenario above applies that same mechanism to an identity and access context. The timings shown are modelled, not measured.
If the action carries no service impact
Placing the call, assembling evidence, retaining session recording and staging the isolation MOP all run under policy. None of them locks anything.
If the account is locked or the session terminated
The isolation MOP is raised and held with the evidence bundle, the affected systems and the rollback path attached. A named human approves before any account is touched.
What Sentinel did, step by step
- ObserveAnomalous login detected. Response options are block, queue, or contact. Context not yet assembled.
- InvestigateDevice posture, travel records, session behaviour and comparable recent patterns correlated before any response is chosen.
- ActVoice call placed to a number held in the identity system. Isolation MOP staged but not executed. Session recording retained regardless of outcome.
- OptimizeConfirmed geography added to the expected set with an expiry. Detection threshold reviewed against the confirmed outcome so investigation volume can rise without lockout volume rising.
Bring us your false positive rate
We will show what it costs you in blocked colleagues per month.