You’ve spent much of your career at the intersection of SAP, security, and enterprise risk. What has changed most in how organisations approach business-critical application security, and where do you still see the biggest gaps?
SAP security used to be an authorization topic owned by the SAP Basis applications team. Then the systems got internet exposure, attackers noticed, and regulations made the business accountable. Today, the CISO and the board own it, proving that we’ve won the argument that SAP is business-critical application security.
Three gaps. First, confidence without evidence: most teams have a feeling about their posture, few have a number. Our benchmarks across thousands of production systems show that the customer-owned areas, Basis, authorizations, and data protection, score between 58% and 68%, while the same customers say they're doing fine.
Second, the cloud myth: RISE changes who runs the system, but not who carries the consequences of an incident.
Third, SAP is still a black box to the SOC, and the SAP team has no incident response practice. Attackers live in that gap.
As a cybersecurity company, SecurityBridge must bring a high level of security expertise in-house. Does that make internal security easier, or does it create higher expectations and more complex decisions around risk, controls, and investment?
We don't have to argue about whether security matters. Nobody in the company needs convincing that MFA, patching, or code review is worth the friction. The expertise is in the room, and we use our own platform on our own SAP systems, so we find out quickly when something doesn't work.
SecurityBridge is a market leader in providing visibility into and securing SAP applications, so customers rightfully have high expectations. We also help customers prioritise and guide their risk acceptance.
In-house expertise makes the decisions better informed, not easier. It replaces “should we?” with “how much, where, and what do we consciously leave open?” That's a harder conversation, and it's the right one.
As Co-Founder and Board Member, how do you balance pushing security initiatives forward with the product, operational, and commercial priorities competing for the same resources?
First, I have a brilliant successor as CTO in Holger Huegel, who has taken virtually all operational load off my plate. That let me go back to my product engineering roots, and when you're doing what you love, you simply become more productive.
On innovation, we've always had an exceptional team, and I see a bright future there.
Commercial isn't my primary turf, but it does matter: we are a commercial organisation on a strong growth trajectory, and everything we build has to serve that.
In SAP environments, fixing a vulnerability can involve custom code, dependencies, and business-critical processes. How do you weigh the urgency of remediation against the risk of disrupting operations?
First, exploitability over severity. A CVSS 9.8 in a component we don't use on a system with no external exposure is less urgent than a 7.0 on an internet-facing Fiori gateway that is already being exploited in the wild. It's the context that sets the timeline, not the score.
Second, mitigate before you patch. An SAP system isn't an iPhone; most vulnerabilities can't be patched within 24 hours. That's why SecurityBridge supports virtual patching: apply the workaround first. Restrict the ICF service, block the RFC destination, and tighten authorization. You can often close 80% of the risk in an hour without touching custom code or a transport, then do the proper fix with regression testing behind it.
Third, watch while you wait. Most SAP vulnerabilities leave traces when exploited: a function module called, a parameter changed, or a login pattern. With monitoring in place, you can schedule the fix into the next maintenance window and keep a close eye on it in the meantime. Without visibility, every unpatched day is a blind spot, and that shifts the math toward acting faster.
Security teams are under pressure to consolidate tools and prove measurable risk reduction. Internally, how do you decide when a new security capability is worth adding to an already mature security stack?
SecurityBridge is a platform solution; it helps organisations avoid a zoo of tools being required to secure SAP.
Consider that every tool addition costs more than its license: someone has to run it, integrate it, look at its alerts, and explain to an auditor why it exists. A mature stack dies of a thousand good ideas.
- Which risk does it reduce that nothing we own already covers?
- Can we measure it?
- Does it consolidate or fragment?
The discipline that makes this work is retiring legacy applications. Every year, we look at what we're running and ask which tool we’d not buy again today. If nothing ever leaves the stack, it’s not mature, it’s just old.
What I did learn: Perfection is the enemy of the good. Complexity is a major enemy that can make security programs fail in practice.
Security telemetry is one thing; acting on it within the affected system is another. What are the biggest organisational or technical bottlenecks that prevent teams from moving from detection to remediation?
The gap between detection and remediation in SAP is more of an ownership problem than it is a tech problem.
Often, remediation lives outside the system that raised the alert. Detection in the SIEM, ticket in ServiceNow, fix in SAP, three tools and three people to close one finding. And once your SAP is on RISE, you still must deal with the shared responsibility.
Having been both a security practitioner and a cybersecurity company leader, what distinguishes a vendor that truly understands an enterprise security problem from one that simply has compelling technology?
You can tell in the first 10 minutes, does a vendor walk its talk?
Compelling technology talks about features. A vendor that understands the problem talks about who gets the alert.
An honest vendor will talk about what technology can't fix: ownership, process, and board attention.
Looking at SecurityBridge objectively within the SAP security market, where do you see its approach genuinely standing apart, and where does the broader market still have room to evolve?
We run inside SAP. Detection, compliance, patching, code scanning, and remediation happen on one platform, in the system the SAP team already works in. Most of the market bolts security onto SAP from the outside and struggles to add a fix. We took the harder path early, and it pays off where customers hurt most: moving quickly from find to fix.
We also serve both audiences, the SOC in its SIEM and the SAP team with the remediation attached, which is the actual problem to solve. And we work on evidence: with thousands of production systems on the platform, we can tell a customer how they compare to peers, not how they feel.
Today, remediation is still too manual; the industry is good at telling you what's wrong and only starting to fix it safely for you. SAP is still a black box to the SOC. Cloud coverage for RISE, GROW, and BTP lags years behind on-premise.
And the market still sells fear, focusing on too much marketing with too few statistics to back it up.
