How TrustBroker Brings Context-Aware Authentication to SAP Environments

Strong authentication, including multi-factor authentication (MFA), is now a common requirement for SAP environments. Compliance directives, audit expectations, and breach-prevention strategies push teams to strengthen how users prove their identity.

The challenge is when MFA is enforced. MFA can sit on top of a single sign-on architecture, so users may be challenged when they access the first SAP system after logging on to a workstation or device. But SAP authentication risk does not always appear at login. It can emerge later, when a user moves into a critical SAP system, accesses confidential data, approves a bank payment, or performs an administrative action.

SecurityBridge is addressing that gap with TrustBroker, the SAP-focused authentication product it added when it acquired CyberSafe. Tim Alsop, Product Architect and Managing Director at SecurityBridge UK, said, “TrustBroker helps SAP customers enforce stronger authentication when users enter higher-risk systems or perform sensitive actions after logon. It uses the customer’s existing identity provider for MFA, but in an SAP-specific context shaped by system, role, action, or data sensitivity.”

TrustBroker Extends Existing Authentication Into SAP Context

Alsop, who served as Technical and Managing Director of CyberSafe before its acquisition, said, “TrustBroker has been sold for over 20 years to SAP customers on a global basis.”

SecurityBridge saw the product as a natural extension of its platform because it added SAP-specific authentication capabilities that could help improve security and block cyberattacks in real time. “Since breaches are mostly caused by credential misuse and theft, authentication is clearly a priority topic to improve SAP security,” Alsop said.

As a standalone product, TrustBroker offers SSO and MFA for users logging on to SAP business applications and performing actions after logon. It can base those authentication requirements on SAP role assignments or the action performed by the user.

The SecurityBridge Platform adds another layer. When TrustBroker is combined with the platform, the decision about whether to require MFA becomes more context-aware and risk-based. That allows authentication checks to account for SAP activity and broader risk indicators before a user proceeds with a sensitive action.

Context-Aware MFA Moves Authentication Closer to Risk

Alsop described TrustBroker’s standout capability as “targeted, context-aware and risk-based MFA.” Other SAP MFA tools and protocols, he said, often enforce MFA only at logon and usually only for the first SAP system accessed after workstation login.

As an example, Alsop described a user who logs on to a workstation, enters a less important SAP system, and then hours later accesses a company’s most critical SAP system containing confidential data or “crown jewels.” MFA based on an SSO architecture would not require another challenge at that point, he said. TrustBroker is designed to enforce MFA when required, not just at initial access.

That determination can come from the SAP system being accessed, the role assigned to the user, the user’s behavior, the business process action, or the data involved. When TrustBroker is integrated with the SecurityBridge Platform, those decisions can also draw on indicators such as anomalous logon behavior, suspicious devices, and past user activity.

Step-Up Authentication Connects Security to SAP Actions

This approach is known as Step-Up Authentication. Rather than treating authentication as complete at login, TrustBroker can require another MFA challenge when a user attempts a sensitive action inside an SAP application.

Alsop pointed to bank payment approval as an example. A user may already be inside SAP, but the action itself carries a higher level of risk. TrustBroker can require stronger authentication at that moment, helping SAP teams protect the process without adding unnecessary friction to routine activity.

Step-Up Authentication can also apply to other sensitive SAP actions, such as opening payroll records, making administrative changes, or accessing confidential data.

SecurityBridge’s TrustBroker materials describe coverage across SAP GUI and related client software, browser access to ABAP ICF services such as SAP Fiori launchpad and SAP Web GUI, SAP NetWeaver AS Java applications such as SAP Enterprise Portal and SAP PI, and SAP BusinessObjects Business Intelligence platform. That coverage matters because SAP users reach sensitive actions through different interfaces and applications.

What This Means for SAPinsiders

• SAP risk should shape authentication decisions. Authentication requirements should reflect the system, role, action, and data involved in each SAP workflow. That approach helps SAP teams move beyond login-level assurance and apply stronger verification when business risk increases.
• MFA policies need business-relevant triggers. Step-up authentication is strongest when tied to actions such as bank payment approval, payroll access, administrative changes, and confidential data access. SAP teams should define which actions require stronger verification before deciding how broadly to enforce MFA.
• Risk indicators can refine MFA decisions. Context-aware authentication becomes more precise when it accounts for anomalous logon behavior, suspicious devices, and past user activity. SAP teams can use those indicators to make MFA challenges more selective, timely, and aligned with actual risk.