What is out-of-band verification?
Out-of-band verification means confirming a request through a channel other than the one it arrived on, using contact details you already hold rather than any the request supplied. If an instruction arrives by email, you confirm it by calling a number from your own records. It is the control that does not depend on judging whether the request was genuine, which is why it survives impersonation that has become good enough to defeat judgment.
The two halves, and the one people drop
The first half is the different channel: an email confirmed by voice, a call confirmed in a system of record. Both halves being the same channel confirms nothing, because whoever controls the channel controls both messages.
The second half is where the contact details come from, and this is the half that gets dropped. Calling the number in the request reaches the person who wrote the request. The details have to come from somewhere the request could not touch: your own supplier records, your directory, the signed contract.
This is also why an out-of-band step that has never been tested tends to fail on first use. The number on file turns out to be wrong, or nobody knows where the file is.
What it should cover
Anything that moves money, and specifically any change to where money goes. A change of bank details is the highest-value single request in most organizations and often the least ceremonious.
Anything that grants or changes access: a new administrator, a password reset for somebody who has lost their phone, adding a collaborator, issuing a key. These are frequently treated as helpdesk work rather than as consequential, and the consequence is larger and slower to notice.
And anything that changes where something is delivered or who receives it, which is the same fraud with a different object.
Where it fails
It fails when there is an exception for urgency, because urgency is manufactured. It fails when there is an exception for seniority, because seniority is what is being impersonated. Both exceptions exist in most organizations that have the control.
It fails quietly when the person doing the verification is junior to the person apparently making the request, and the organization has never made it clear that refusing is supported.
And it fails when it is a step in a document rather than a habit. The test is not whether it is written but whether somebody has done it recently, and whether anything happened to the person who slowed a payment down.
Common questions
- Is two-factor authentication out-of-band verification?
- They share the idea and answer different questions. Two-factor confirms that somebody is who they say when signing in. This confirms that a request somebody made is one they actually made, which matters even when the account is genuinely theirs and they are genuinely signed in.
- Does it have to be a phone call?
- No, but it has to be a channel the attacker does not control and a set of contact details they did not supply. A message in a system that requires separate authentication can work. Replying to the email cannot.
- How do you keep it from slowing everything down?
- Scope it to a small number of consequential actions, and set a threshold everybody knows. A callback rule that applies to everything is a rule that gets suspended when it is inconvenient, which is the moment it needed to hold.
Find out where you stand
The assessment on this site asks up to 24 questions about what the AI in use here exposes you to, and returns a score, a verdict and, where a control is short, the one thing to fix first. It never asks whether you have a list of the tools. It takes about ten minutes, and questions your organization has no surface for are dropped rather than scored against you.
It is a self-assessment of what has been arranged and practiced, not of whether it would hold against somebody actually trying. Not a penetration test, not an audit, not a certification.
Run the assessment