How SAP Cybersecurity Has Changed in 2026

AI was everywhere at Secure Together on the Road in Frankfurt on September 10, 2026. SecurityBridge and Accenture brought the community together, supported by NextLabs, Bowbridge, and Saviynt. From identity governance to security operations, the agenda showed how deeply AI is entering the SAP security conversation. But the thought I took away was not that we need to forget everything we know about security. It was that we need to become much better at putting it into practice. Microsoft’s Martin Pankraz captured that urgency. To paraphrase his message: before a breach, make your organization as expensive a target as possible. After a breach, every second counts. That distinction brings us back to the purpose of our work: making attacks harder to succeed – and being ready when prevention is not enough. In my March 2024 article, How Will AI Change the SAP Cybersecurity Threat Landscape?, I explored both sides of this development: AI can support defenders, but it can also strengthen attackers. I also questioned how much trust we should place in systems whose conclusions are not always easy to verify. That tension has not disappeared. The UK’s National Cyber Security Centre assesses that AI is already being used for activities including vulnerability research and exploit development. In its assessment of the cyber threat through 2027, it notes that the interval between vulnerability disclosure and exploitation has already shrunk to days, and expects AI to reduce it further. The practical consequence is a shrinking window for defenders to assess exposure, prioritize remediation, and put protection in place. The exact interval varies by vulnerability and attacker. But the direction should concern every SAP team: we have less time to turn knowledge into action.

From signal to justified action

Does this mean every SAP customer should simply buy more AI? I do not think so. The useful question is where AI can help a team understand a threat sooner, make a better decision, or execute an appropriate response faster. The Microsoft and SecurityBridge session in Frankfurt made this practical by focusing on cooperation between security operations analysts, AI agents, and SAP security teams. Microsoft’s documented partner integrations allow SAP security signals, including those from SecurityBridge, to be correlated with information from the wider IT environment. For me, the value is not that an AI agent participates. The value is whether the team can move from a signal to a justified action with less delay and better context.

Agentic AI is more than an efficiency gain

There must still be boundaries. In my May 2026 article, SAP’s New AI Strategy: Will ERP Become the Autonomous Control Center of the Enterprise?, I argued that autonomous actions require clear permissions, traceability, and human control where business risk demands it. Automating a decision does not remove the need for someone to own its consequences. An AI agent acting in SAP needs the same control objectives as a human identity: a named owner, a unique and traceable identity, least-privilege access, segregation of duties, appropriate approvals, access reviews, and a way to revoke permissions. These principles need to be implemented for machine identities, not copied mechanically from a human login process. Microsoft’s least-privilege guidance for AI agents makes that distinction operational. A prompt is not an authorization boundary. Permissions must also be enforced by the systems and tools an agent can call. OWASP’s guidance on excessive agency explains why excessive permissions and autonomy become dangerous when an agent is misled or produces an unexpected result. Faster execution is valuable only within a controlled scope.

Why does awareness still fail to become action?

Jochen Fischer of NO MONKEY raised a concern that resonated with me: the attack surface is expanding, while some SAP customers remain insufficiently aware of their exposure – or struggle to turn that awareness into action. I recognize that gap from many conversations over the years. I do not believe the answer is to lecture SAP teams. Nor should we assume that hesitation means people do not care. The more useful questions are whether the risk is understood, whether someone owns it, and whether that person has the authority and resources to act. We also need to stop discussing cybersecurity as though its consequences belong only to IT. In September 2025, Jaguar Land Rover reported that a cyber incident had severely disrupted its retail and production activities. Later that month, it announced a further extension of the production pause. These were operational consequences, not simply findings on a security dashboard. That is why I see protecting business-critical applications as a responsibility to employees, customers, suppliers, and everyone else who depends on the organization.

What needs to be done? Much of it should sound familiar.

In December 2024, I wrote Maximizing SAP Security: How AI and Human Intervention Work. Its central argument was straightforward: AI-driven detection does not replace the human work of patching, hardening, and securing custom code. Those tasks remain essential. The Frankfurt discussions did not overturn that argument. They made it more urgent.

Harden the application – and keep it hardened.

Reducing exposure means addressing vulnerabilities, reviewing security-relevant settings, restricting unnecessary access, protecting interfaces, and securing custom developments. SAP protection also needs to sit within the broader security architecture, rather than being treated as an isolated application concern. My emphasis is on the word keep. A hardening project should not end with a report that gradually becomes a historical document. Security checks need to accompany changes to business processes, integrations, authorizations, and code. Where a weakness cannot be corrected immediately, I would expect a named owner, an explicit decision about the risk, appropriate interim protection, and a date for review. A finding should not disappear from attention simply because it cannot disappear from the system today. Andreas Kirchebner made a related point in his Frankfurt session on SAP governance and accountability. To paraphrase the contrast I took from his talk: Germany may be described as a world champion in regulation, yet an audit result can be green while vulnerabilities inside SAP remain red. I took that as a warning not against audits, but against confusing a completed compliance exercise with a secured application. Accepting a risk on paper does not remove the technical exposure.

Know your weak spots – and connect monitoring to action.

Collecting SAP logs is a starting point. The next step is to make them useful to the people responsible for responding. Microsoft’s SAP security guidance describes correlating application-specific signals, such as user logons and access to sensitive transactions, with other security information. That context helps connect SAP activity to the wider incident. For every important detection, I would ask: who receives it, who can investigate it, and who can authorize a response? Evidence that a control exists and confidence that a team can act under pressure are different things. We should expect both.

Rehearse the response before you need it.

A response plan must be more than a document that people know exists. CISA recommends maintaining and regularly exercising incident response and communications plans, alongside testing the availability and integrity of backups. Preparation includes recovery, not just stopping the immediate threat. For an SAP environment, I would bring the SAP team, security operations, relevant service providers, and business decision-makers into the same exercise. Who can restrict a compromised account? Who decides whether to interrupt a critical interface? How is evidence preserved? How will the business operate during containment, and how will a safe restart be validated? Those are questions to work through before an incident, not during the first urgent conference call. The handovers should work like clockwork, even when the incident itself requires judgment. The goal is not to eliminate human decisions. It is to prevent avoidable confusion from consuming the time needed to make them.

Define the action plan before you delegate the action.

Only once an organization has a clear, tested action plan should it consider delegating those response actions to an AI agent – whether through supervised automation or within a carefully defined autonomous scope. An agent cannot make an unresolved question of business authority disappear. Who owns the decision, what is allowed, and when a human must intervene need to be explicit first. With today’s technology, companies still need to build that operational capability themselves. That does not mean writing their own AI models or working without partners. It means translating templates, tools, and external expertise into their own SAP landscape, business dependencies, approval paths, and recovery procedures – and then testing whether the result works. I would start with assistance: enrich an alert, assemble the evidence, and recommend a response. The next step can be a narrow, repeatable action with clear limits. High-impact actions should retain appropriate human approval. An agent’s identity and permissions, the conditions for escalation, the audit trail, and the ability to stop or reverse an action belong in the design, not in an afterthought. Least privilege must come before expanded autonomy. For example, allowing an agent to prepare an investigation summary is not the same decision as allowing it to disable a technical account used by a critical interface. Both may save time. Only one might immediately interrupt the business. The response plan needs to distinguish them. I expect AI to incorporate more operational best practices over the next few years. That is my expectation, not a reason to postpone the work. Even better models will still need to operate within the organization’s responsibilities and risk boundaries. Waiting is not an option. By the time that future arrives, an incident may already have forced the decision.

Secure together must mean working together.

For me, this is the purpose behind SecurityBridge and our partners: helping organizations running SAP prevent attacks, detect suspicious activity, and respond effectively. Our responsibility as vendors and advisers is to make that work easier – not add another layer of complexity. We should judge progress by whether customers understand their exposure better, whether teams can cooperate, and whether a response works when tested. I would encourage every SAP customer to take one question back to the organization:

How long would it take us to move from the first credible SAP security alert to an authorized response – and when did we last test that?

An honest answer is worth more than another confident assumption. So, has the art of SAP security changed? The tools have changed. The threat is evolving. AI creates opportunities we should use and risks we must control. But we still need to harden the application, maintain its security through continuous change, understand our weaknesses, and prepare our people to respond.

This article reflects my personal observations as a long-standing SAP security practitioner and evangelist, informed by conversations and experience. It is not a comprehensive market assessment or a representative study of SAP customer behavior