Multi-factor authentication (MFA) protects access by asking for two or more proofs of identity at sign-in.
InstaSafe gives administrators and high-risk users security keys and passkeys that a fake login page cannot fool, and extends the same MFA to every SaaS app, the Windows logon and the network device console under one access policy.
Multi-factor authentication
Multi-factor authentication is a sign-in method that requires two or more independent proofs of identity before granting access. The kinds are what matter: something you know, something you have, something you are. If one factor is stolen, the account stays protected.
Factors differ in two ways: how widely they work, and how hard they are to phish. InstaSafe supports both kinds, so field staff can use a factor that works without a smartphone while administrators use one that cannot be phished. Most organisations need one from each column.
Our plant runs out of a location where mobile signal drops for hours at a stretch. If the OTP is an SMS, my shift supervisors simply cannot log in.
The code is generated on the phone itself, not sent to it. The InstaSafe Authenticator produces a fresh time-based code every 30 seconds with no network of any kind: no SMS, no data, no Wi-Fi.
The phone and the server agree on the time, and that is the entire dependency.
new code every 30s · works fully offlineSix methods, and no requirement to pick one. Auth profiles are set globally and then overridden per user or per group, so the field team can be on SMS while treasury is on security keys, inside the same policy.
Backup codes sit alongside these six as a recovery path, not a sign-in factor. A pre-issued code is how someone gets back in when the phone is lost, broken or replaced, which is a different job from proving who they are at the login. It is counted as recovery in the specification sheet, never as a method.
They are not equivalent, and the distance between the strongest factor and the weakest one is wider than the distance between having MFA and not having it. Four tiers, strongest first.
The key is bound to the real sign-in domain and checks where the request came from before it answers. A convincing replica of your login page gets nothing, because it is not the origin the key was registered against.
The attacker has the password and still needs the handset in the user's pocket or the finger on the reader. What it does not stop on its own is a user who taps approve on a prompt they did not start.
The code is generated on the phone rather than sent to it, so there is no message to intercept and no network to depend on. It can still be read out to someone who asks for it convincingly.
A code in transit can be redirected: a SIM swap moves the number, a forwarded mailbox moves the message. Far better than a password alone, and the right answer for a user with no smartphone — not the right answer for an administrator.
Tiering follows the US Cybersecurity and Infrastructure Security Agency's guidance on phishing-resistant MFA. Read CISA's fact sheet
Most MFA deployments protect browser-based apps and stop there. InstaSafe applies the same factors to the Windows logon, to network devices, and to directory-integrated applications, so no sign-in path is left on the password alone.
Anything that talks SAML 2.0, OAuth 2.0 or OpenID Connect sits behind the same challenge: Microsoft 365, Salesforce, Workday, your own internal web apps, and the vendor portal nobody remembers buying.
The factor is not configured in the application. It is a property of the group the person is in, which is why adding an app never means configuring MFA again.
Microsoft 365SAML 2.0PushTOTP
SalesforceSAML 2.0Push
WorkdaySAML 2.0FIDOTOTP
SAPSAML 2.0FIDO
GitLabOpenID ConnectTOTP
ServiceNowSAML 2.0Push
SlackOAuth 2.0Push
ZoomSAML 2.0SMSThis is the OS logon itself, not a browser pretending to be a login screen. The InstaSafe agent brings the tunnel up before anyone has signed in, which is what lets a domain login complete on a laptop sitting in a hotel.
Then the machine asks for the second factor the same way the browser would: an SMS code, an authenticator code, or the fingerprint reader already in the palm rest. Windows is the OS logon we cover — macOS and Linux users get MFA at the applications and the directory behind them rather than at the desktop.
InstaSafe agent starting…before anyone has signed inRouters, switches, firewalls and VPN concentrators cannot run MFA on their own. They ask something else to do it. InstaSafe answers on RADIUS and TACACS+, which is the language that gear has spoken for thirty years.
So the engineer who opens a privileged CLI at 2am gets the same challenge as the person opening a SaaS app at 10am, and lands on the same line of the same log. On TACACS+ you can authorise individual commands as well as the session.
InstaSafeRADIUS · TACACS+Not everything speaks SAML. Applications wired straight into Active Directory or an LDAP server get the second factor at the directory, without being modified to understand what a factor is.
Learn moreEvery authentication attempt is recorded with the user, time, method, device, location and result. Export the log for your auditors in seven formats, among them CEF, LEEF and JSON. InstaSafe MFA supports the access-control requirements in:
A risk profile reads the request before the factor is chosen: who is asking, the device they are on, where it is connecting from, the time, the network. A sign-in that matches goes through on the group's normal factor. One that does not is sent for another factor, given a reduced session, or refused with the reason named.
Adaptive step-up runs on risk profiles, and only on the groups where you have configured them. With no profile set, MFA stays rule-based — the factor comes from the user's group, the application and the device, which is how most deployments start and often where they stay.
Continuous facial verification exists as well: we built it for a customer whose contact-centre floor needed the session re-checked rather than just the login. It is not a packaged part of the product, so if your environment calls for it, raise it and we will scope it with you.
Watch a Windows logon with a second factor, from boot to desktop. Choose a factor and follow each step. This is a simulation: it does not connect to a directory, and no account is needed.
Run the Windows login demo →Pick a method to see what your users would see: the code entry, the push request, the fingerprint prompt, and the access decision at the end. No account needed.
Choose a verification method.
Pick a method on the left to watch the second factor play out — live.
no real account neededTick what your evaluation actually needs and copy the shortlist straight into your ticket or RFP. Filtering hides rows; it never clears a tick.
15 specs · none selected
The same six factors reach the SaaS suite, the OS logon, the switch console and the directory-integrated legacy app. Each group gets the factor its risk actually justifies.
The phish succeeds and the login still fails: the attacker holds the secret and not the second kind of proof. Against a security key the fake page never gets a usable answer at all.
The Windows logon, the switch console and the directory-integrated legacy app get the same factor as the SaaS suite, from the same policy.
Push for everyday work, security keys for the people who can move money, and automatic step-up on the groups where a risk profile is set.
“InstaSafe helped us strengthen our access security without adding complexity for our users. The seamless integration with our existing infrastructure, combined with strong identity and device-based controls, enabled us to enhance security while meeting our compliance and business continuity objectives.”
The second factor moved in front of the desktop sign-in, not just the applications behind it.
Read the case studyTap a question, or open them all and read straight through.
Talk to us//Ready when you are//
Roll out alongside the setup you already run, starting with the applications and the devices that matter most. Nothing to rack, and no network to re-architect.
Regulated, air-gapped, or on-premise? See deployment options
Active Directory
OpenLDAP
Oracle
VMware
Teams
Azure
