ASSURANCE LEVELS
Not every door needs the same lock.
A sign-in for a table booking and a sign-in for a payroll system are not the same job,
and pretending otherwise makes one of them annoying and the other one unsafe. Atom9 has
four postures. This page says plainly what each one proves, where it sits against the
public standard, and what it is honestly good for — so you can choose on purpose, and so
we can be held to the choice.
The standard we measure against
NIST SP 800-63B is the reference the rest of the industry uses for
authentication strength. It defines Authenticator Assurance Levels — AAL1, AAL2, AAL3 —
by what an attacker has to defeat, not by what a vendor calls it. Two of its rules matter
for the table below:
-
A link or code sent to an email inbox is not an approved
authenticator. The standard is explicit about it: a mailbox can be reached with a
password, read in transit, or taken over with the domain. It is a convenience, not a
proof.
-
Anything you type in — a code from an email, an SMS, an authenticator
app — is not phishing-resistant, because typing it somewhere does not bind it to the
site that asked. Only passkeys and hardware keys clear that bar.
The four postures
An emailed sign-in link, or a password. Whoever can open the inbox can get in. That is
the whole security model, and for a great many services it is exactly the right trade:
nobody wants to set up two-factor authentication to reserve a table.
Good for: restaurant and salon bookings, event sign-ups, newsletters
and preferences, class or court reservations, guest lists, loyalty cards, community
boards — anything where the worst case is an inconvenience.
Not for: anything holding money, health data, someone's identity
documents, or the ability to act on another person's behalf.
Sits below AAL1 when a link alone is accepted:
NIST does not permit email as an out-of-band authenticator at any level. We ship it
anyway, on purpose, labelled — because refusing it would push these services onto
something worse. It is single-use, short-lived, spent only by a deliberate click, and
it warns you when it is opened somewhere other than where it was asked for.
ELEVATED · PASSWORD
A real secret, checked properly.
AAL1
A password only the account holder knows, screened against known breach lists, stored
with a modern password hash, and rate-limited against guessing. A link alone will not
get you in at this posture.
Good for: customer portals, order history, support tickets,
memberships, internal tools that hold ordinary business data.
Not for: money movement or personal data you would have to report a
breach of.
Meets AAL1. One factor, but a real one.
HIGH SECURITY · PASSKEY
Phishing stops working here.
AAL2, phishing-resistant
A passkey on the person's own device. The key is bound to your domain by the browser,
so a convincing copy of your login page cannot use it — the credential simply refuses
to answer a site it was not created for. This is the first posture where a
well-executed phishing attack fails on its own.
Good for: accounts with payment details, HR and staff systems,
anything an employee signs into, customer data at scale.
Meets AAL2 and clears NIST's phishing-resistance
definition. Synced passkeys stop at AAL2 by design; only a device-bound key reaches
AAL3.
REGULATED · TWO FACTORS
Two independent proofs, every time.
AAL2 + second factor
Something known plus something held — a password and an authenticator code, or a
passkey plus a step-up. A password on its own cannot open the door, no matter how good
it is, and neither can a stolen phone.
Good for: financial services, healthcare, anything under DORA, admin
access to other people's data, and any account that can change where money goes.
Meets AAL2 with a second factor enforced at
every sign-in rather than offered.
How to choose, in one question
Ask what happens if the wrong person gets in. If the answer is somebody loses a
table booking, Standard is correct and anything heavier is friction you are charging
your customers for nothing. If the answer involves money, health, someone's legal
identity, or data you would have to report a breach of, start at High Security.
You set this per sign-in app, and you can raise it later — existing accounts are asked
for the stronger method the next time they sign in, rather than being locked out.
Why we publish this
A vendor that offers an emailed sign-in link and calls it "secure authentication" is
telling you something untrue. We would rather name the tier, name the standard, and let
you match the lock to the door. If you are picking a posture and are not sure which side
of the line you are on, write to us and a person will answer.
Measured against NIST SP 800-63B. Last reviewed 30 July 2026.