Apex Authenticator
Live
Good security that people will actually use every morning is a design problem, and this is the answer we settled on.
See itInfrastructure
View it here, in the page
Functional scope
Identity first, then a second factor. The pattern is the one large institutions use, because people already know it.
Time based codes with a number match screen, so approving a sign in is a deliberate act rather than a reflex tap.
A per device trust window the person opts into, so the second factor is asked for when the window has lapsed rather than every single time.
An approve sign in request screen carried into the admin console, with the input layer hardened against injection and the common probing attempts.
Users and roles
Everyone who signs in. Administrators get the same flow with no grace period.
Workflow in practice
People sign in. When a device passes its window, the second factor is asked for once and the window resets.
In production
- Number match replaces a blind approval tap
- A trusted device is not asked again inside its window
- The console requires identity plus a second factor with no exception
Build status
Running in production today with people using it.
Included in every system we build
This is foundation, not a product. It ships inside the systems it belongs to, and its cost is already in their figures.
If a system you are commissioning does not already carry this piece, adding it is a line in your quote, not a second purchase.
It is here so you can see what you are getting rather than take our word for it.
Rails used
Stack
- Next.js
- Postgres
- TOTP
- Signed session cookies
Handover includes
- Source for the sign in, enrolment, and approval screens
- The device trust schema and policies
- The hardening test set
- Console integration notes
Ask about Apex Authenticator
Tell us how your business runs today and we will show you which systems carry this piece and what they would cost you.