Critical systems are a tricky problem in most organizations. They're not just critical because bad things will happen if they go down—they're also critical because they're central to the operation of the business day-to-day.
This puts them at the center of a knotty security paradox, in which they are called to have two seemingly incompatible characteristics:
-
Access to them is difficult. That is to say, the most stringent criteria need to be met to access them, with everyone else excluded—otherwise, these most important systems are left open to attack.
-
Access to them is guaranteed. That is to say, if at any given time they need attention someone must, without fail, be able to rapidly log in and provide it. Without this prompt attention whenever needed, the consequences to the business can be catastrophic.
Of course the problem is that these two requirements don't go together.
A critical system is critical precisely because if it doesn't get prompt attention whenever needed, bad things will happen, yet that same importance means that it would be madness to grant access without stringent requirements, even if someone is frantically trying to log in. Particularly if someone is frantically trying to log in.
In the real world, this leads to a variety of actual states of affairs:
-
Improper protection. Since critical systems are often also those for which it's hardest to practically deploy things like multi-factor authentication, it's not all that uncommon to see strong access control measures simply omitted. For example, company email may be protected by MFA and accessed via SSO, while often far more sensitive secure shell (SSH) servers retain legacy login workflows.
-
Account sharing. Maybe it's to reduce the number of login-capable accounts. Maybe it's to provide access to a critical worker on an emergency basis. However it happens, it's not uncommon to find a small circle of several individuals using a single set of key credentials, even if this means passing one-time password (OTP) codes or various types of issued keys back and forth in real time.
-
Key work that can't get done. On the other hand, some teams and organizations are so careful to limit access to such a small group of individuals that needed work simply can't get done and is instead bottlenecked by a particular individual. Key systems that need regular attention instead never get touched, even when they ought to be.
None of these "solutions" is particularly satisfying, for obvious reasons.
Beyond Authentication and SSO
What's needed is a way to check identity seamlessly, so that rigorous authentication steps can be put into place, yet access to key systems is neither slowed nor hampered unless the user requesting access shouldn't have access—and the certainty levels about these things should be high.
At Plurilock™, we're increasingly hearing that clients want to do this without mid-session spot checks:
-
No username and password re-entry
-
No mobile push
-
No fingerprint or face scans
In other words, just let the right people in, and keep the wrong people out!
We're also hearing that for the most critical systems, SSO may not be secure enough to keep those who have to worry about risk comfortable. After all, those tokens aren't really saying anything about identity now, they're saying something about identity a while ago, at the time of the last token refresh.
Identity as a Signal
To enable this kind of protection—protection that requires the provision of very stringent identity confirmation data, yet also ensures rapid access for the people that should have it, we're increasingly being asked for identity-as-a-signal solutions.
These solutions rely on Plurilock DEFEND, which:
-
Runs silently in the background of user work sessions
-
Verifies their identity biometrically every 3-5 seconds
-
Without any extra work, steps, or hardware on the user's part
-
Makes this identity confirmation signal available via API
When deployed, these kinds of solutions enable a kind of multi-factor authentication that can be loginless, passwordless, and OTP-less. It goes something like this:
-
User opens a new connection to a key system
-
The destination system figures out who's making this request
-
It then queries DEFEND via API to see the status of this user's identity at the origin
-
If their identity is currently already biometrically confirmed, they're logged in
-
If not, they can either be denied or some other identity check can occur
How is this better than other forms of login handshake or authentication on the market? It's better because:
-
It relies on a real-time identity that is constantly being verified
-
It's biometric without privacy concerns or "scan" steps
-
It can enable seamless logins without even a username or password step
-
But if the identity signal is bad, there is still room for other steps or gatekeeping
For example, command-line sessions via SSH are often difficult to protect with traditional forms of multi-factor authentication, yet even if traditional multi-factor authentication solutions can be deployed, they add significant friction to SSH logins and to their management.
By enabling SSH to query Plurilock DEFEND for a user's identity status—the user either judged biometrically either to be "the right person" or "not the right person"—stringent identity checks can happen during SSH login without added steps.
And because DEFEND confirms identity continuously, throughout entire work sessions, as users work, this invisible identity signal is a much stronger proof of identity at any given moment than usernames, passwords, or OTP codes.
Talk to Us About Solutions
If you think that your organization has a use case for a real-time, biometric identity signal for working users—one that can be queried via API to confirm a user's "currently known to be themselves" or "currently likely an intruder" identity status at any time, contact us.
We're actively helping organizations to deploy next-generation authentication solutions using identity-as-a-signal today. ■
