Risk-based authentication
Risk-based authentication (RBA) is a feature of AuthControl Sentry® that is designed to deliver intelligent authentication by optimising security based on the user, the device and the application.
Book a demo
Risk-based authentication
Risk-based authentication (RBA) is a dynamic feature of AuthControl Sentry®, designed to automatically request the appropriate level of authentication to access applications, whether the user is connecting through a VPN, cloud, or on-premise. Based on parameters set in the policy engine, RBA will request the appropriate level of authentication to access applications based on the user, their device and the application.
Ultimate flexibility & control
RBA enables you to set the appropriate risk required for an individual or group to access particular applications. Using a predefined set of parameters, it works for you and decides what level of authentication is required, based on criteria including but not limited to:
– What applications they are trying to access
– What group membership they do have
– Where they are accessing the applications from
– What device they are using
The policy engine
Based on a points system, the adaptive authentication policy engine enables administrators to set parameters per user, per application.
Parameters include:
– Group membership
– Application being accessed
– IP address
– Last authentication
– X509 Cert
– Device
– Physical location (GeoIP)
– Time / date / day
The Policy engine allows you to create new rules and combine existing rules, as well as provide a mechanism to support a range of scenarios with increasing complexity.
Maximum adoption
Everyone is different and with a range of authentication factors to authenticate access to applications, administrators can select the factors that are suitable for their organisation. Authentication factors include:
– Mobile app
– SMS
– Fingerprint
– Image authenticators: TURing & PINpad®
– Hardware token
Risk-based authentication: Example 1
The Purchasing Assistant has flown to South East Asia to visit a supplier with the Purchasing Manager. She has just finished a meal in a restaurant and realises she forgot to check the stock of some components for a meeting the following day. While waiting for the taxi, she thought she’d quickly log in to the ERP system, using her company-issued mobile device.
ERP system | |
---|---|
Requires 120 points | |
LAN | 0 |
Known IP | 0 |
Managed Device | 50 |
IP Range (Asia) | -100 |
Authentication required | |
U&P | 10 |
Mobile App | 60 |
Fingerprint | 20 |
Result – unsuccessful
Although she is trying to use a company-issued device to access the ERP, the IP range sets her back -100 points because of her location. She will not be granted access to the ERP this time, independently of her willingness to use multi-factor authentication.
Risk-based authentication: Example 2
The Sales Manager is working in the office today and wants to access the CRM to create an opportunity following a meeting. He is using his company-issued laptop and is accessing the application which is located on-premise.
CRM system | |
---|---|
Requires 120 points | |
LAN | 50 |
Known IP | 50 |
Managed Device | 50 |
IP Range (US) | 50 |
Authentication required | |
U&P | 10 |
Mobile App | 60 |
Fingerprint | 20 |
Result – successful
The Sales Manager clearly exceeds to points he needs to access the CRM. Once he is authenticated, he can use single sign-on (SSO) to access other applications. He receives a call from the Purchasing Assistant and is able to access the ERP system, and provides the quantity with the part number he is given.
Single sign-on
Once authentication utilising risk-based authentication is successful, users can access all of their applications using single sign-on (SSO), without having to authenticate access to each individually. Tailored to each user or group, users only see the applications they have access to, minimising navigation time.
Find out more