No more blind trust: How risk-based authentication strengthens identity security
Traditional digital authentication methods have allowed users to enter and IT infrastructure if they hold the right key. Username and password alone provided limited context around the authenticity of the access attempt. But today, the person with the credentials may not claim who they are.
Beyond traditional mediums, risk-based authentication cultivates an overt rationale for reasoning, recognizing, analyzing, and deciding that a login attempt irrespective of titles or privileges should be allowed only based on context and behavior verification.
Recent FBI and CISA advisories identify the abuse and access of valid accounts as a successful initial login technique, highlighting that this goes beyond credential verification alone.
The concern is real. As an example, someone knocks on your door at an unusual hour. You weren't expecting any guests, nor were any invited. Before opening the door to let them in, wouldn't you take a moment to recognize them, reassess by looking through the peephole, and then decide whether to open the door? This correlates to the real-world authentication challenges in IT today.
Why is traditional authentication no longer enough?
Illegitimate attempts to bypass traditional authentication methods have grown and gained attention over the years. It's safe to say, that appropriate user education and additional security/verification layers better identify obstacles. However, the current momentum of threats across the system demands a sentinel strong enough to detect unusual activity and wisely trigger step-up authentication factors.
Some traditions are hard to carry forward, like relying on a static username and password to access an account. Beyond convenience and old habits, compromised credentials create a more complex problem: Why break a door when you hold the key to enter? We've moved past a time when security is about holding the door too tight. Security efforts today further question who is behind the door, their associated, trust, and more.
How does risk-based authentication work?
Authenticating sits a step higher than claiming an identity–it has to be proven before access is granted. Passwords, PINs, biometrics, 2FA, and MFA are details that a user would possess and could be exchanged or handed over. When authentication had to question the reason for a login, risk-based authentication emerged to verify the request, not just the credentials.
Risk-based authentication (RBA) does not treat every login equally. It is built and operates on the principle of adaptive authentication, allowing logins based entirely on contextual and behavioral signals. It assesses the risk associated with unusual access attempts. So, the success of a login depends upon the risk and sensitivity metrics of a request.
Based on risk signals from contextual factors, failed login attempts, and others, the adaptive engine triggers supplementary authentication factors, if necessary, to ensure the user behind the login is free of fraudulent intent. With ManageEngine AD360, proper access control mechanisms can be implemented: for instance, conditional access policies can treat a user who logs in during undefined business hours, outside of work. They will be evaluated for risk, prompting the use of an additional authentication factor or denying access outright.
Authentication requirements change based on the risk levels. For instance, a high-risk attempt might require MFA in org A, while instantly denying access in org B. The risk scores are categorized as low, medium, and high, with corresponding dynamic step-up authentication methods that may fit the category. Apart from risk scoring, trust could also be established through rule-based policies and machine learning models.
How have authentication requirements changed based on risk?
A classic example is of Arup's financial loss, involving $25.6 million in 2024, that remains unsolved to this day. The attack combined identity and authority impersonation: the attacker assumed a decision-maker's identity and claimed the authority to force a financial transaction. The idea behind impersonating key decision-makers in the organization, convincing through video calls, and successfully concluding the attempt raises the very question: "If seeing is not enough proof, how else do you verify?"
This incident highlights that relying entirely on identity alone is a limitation. Ideally, no internal systems were broken down, nor were accounts breached. With this, it's evident that only an employee's trust was manipulated. Arguing that the RBA would have dodged a bullet would be inappropriate in this context. However, its value lies in adding contextual checks to allow access, predominantly by counter-checking for unusual identity behavior.
When an authority with significant privileges attempts an access, the risk is assessed beforehand to ensure that the identity behind the request is genuine and would not exploit the trust—an organization cannot operate in a trust deficit. ManageEngine Identity360 ensures this by enforcing stricter entry requirements and heightened scrutiny, with zero discrimination.
Final thoughts
Circling back to what we've emphasized throughout, valid credentials alone doesn't make an access request legitimate anymore. The context of the variables belonging to every such attempt becomes a key deciding factor. To authenticate was once to prove an identity, but now it is to prove that the request fits the identity it claims.
As technology and security reach new heights, the need to impose stringent security measures to protect an organization's integrity also intensifies. The loss, either financial or reputational, is fairly proportional to the time the borrowed identity spends in the environment. Restricting access by permitting only risk-validated accounts could reduce the attacker's window of opportunity to exploit.