Webinar Recap: The Four Pillars of SAP Autonomous Cyber Operations

SAP environments support critical business processes and sensitive data, making them a high-value target for cyber threats. Protecting them requires more than securing user access or addressing individual vulnerabilities, as risk can emerge across infrastructure, system configurations, applications, integrations, and identities.

A strong identity and access controls, for example, cannot compensate for an unpatched SAP kernel, insecure system configuration, or vulnerable application code.

In the fourth session of the Rise of SAP Autonomous Cyber Operations webinar series, IT-Conductor CEO and Co-Founder Linh Nguyen introduced four pillars for looking at SAP security as a connected discipline: Platform Security, Configuration Security, Application Security, and Identity & Access Management (IAM).

Figure 1: The Four Pillars of SAP Cyber Resilience

The framework addresses an important challenge for SAP teams. Attackers are not constrained by organizational boundaries between Basis, infrastructure, development, and security teams. They look for any weakness that can provide a path into the environment and may chain vulnerabilities across multiple areas. Because of this, strengthening one pillar cannot compensate for significant gaps in another.

Pillar 1: Platform security

Platform security covers the technology that SAP depends on to operate. This can include operating systems, databases, the SAP kernel, virtualization, networking, SAP Host Agent, cloud infrastructure, and platforms such as SAP BTP.

Figure 2: Platform Security

Within the framework presented during the webinar, platform security represents approximately 30% of the overall SAP cyber risk picture. One reason for its significance is the number of components beneath the application layer that must remain secure and current. Vulnerabilities affecting the SAP kernel, SAProuter, Host Agent, operating systems, databases, or related infrastructure can expose an SAP environment even when application-level security controls are strong.

The webinar highlighted the challenge organizations face when critical vulnerabilities are identified but remediation depends on maintenance windows, approvals, resource availability, or coordination with service providers. Simply knowing that a vulnerability exists does not reduce the risk. The organization must be able to remediate it quickly enough to meaningfully reduce its exposure.

Cloud and managed SAP environments do not eliminate that responsibility either.

For organizations running SAP through RISE with SAP or a managed service provider (MSP), platform security often operates under a shared responsibility model. SAP or MSP may maintain parts of the infrastructure, but customers still need processes for reviewing vulnerabilities, approving patches, coordinating downtime, and confirming that remediation has occurred.

Organizations also need to know whether vulnerabilities are being identified, prioritized, and remediated at a pace appropriate to their business risk.

Pillar 2: Configuration security

A secure configuration at go-live does not guarantee a secure configuration six months or several years later.

Configuration security accounted for approximately 25% of the framework discussed during the webinar, with configuration drift identified as one of the primary challenges.

Figure 3: Configuration Security

SAP landscapes contain a large number of security-relevant settings. These extend beyond SAP profile parameters to database configurations, TLS settings, certificates and trust stores, RFC connections, access control lists, gateway configurations, integration settings, and system-to-system communication.

Many organizations establish secure configuration baselines during implementations, upgrades, migrations, or dedicated security initiatives. Over time, however, routine operational changes can cause those configurations to drift. Parameter adjustments, integration requirements, new system connections, and changes made to address performance or availability needs can gradually move the environment away from its approved security baseline.

Maintaining a secure configuration baseline requires continuous visibility into how settings change over time. Rather than relying on periodic assessments, organizations need to identify configuration changes as they occur and determine whether they introduce new security exposure.

The webinar also highlighted a common gap between identifying configuration issues and resolving them. Findings may be documented in reports, spreadsheets, meeting notes, or separate tools, but without clear ownership and follow-through, remediation can remain outstanding long after the issue is discovered. A more resilient approach connects configuration findings with prioritization, ownership, remediation workflows, testing, approvals, and verification to help ensure identified risks are addressed in a timely and controlled manner.

Pillar 3: Application security

Application security in SAP extends across SAP-delivered code, custom ABAP development, third-party add-ons, interfaces, APIs, transports, and other extensions connected to the core environment. It represents approximately 20% of the SAP cyber risk model presented during the session. Because most SAP landscapes include custom code and external applications to support business-specific requirements, organizations need consistent security controls throughout the development and transport lifecycle. This includes validating authorization checks, scanning for vulnerabilities, reviewing third-party code, and ensuring that faster development approaches, including AI-assisted development, do not bypass established security practices.

Figure 4: Application Security

SAP BTP also expands the application security scope as organizations move extensions, integrations, APIs, and business logic outside SAP S/4HANA to support clean core strategies. While this reduces modifications within the ERP core, it also creates additional connections that can exchange data, credentials, and events with critical SAP systems. The webinar emphasized the importance of maintaining visibility into these interactions through appropriate logging, auditing, and governance so that applications running outside the core are secured with the same level of oversight as the systems they connect to.

Pillar 4: Identity and access management

Identity and access management has traditionally been a major focus of SAP security, covering areas such as roles and authorizations, segregation of duties, privileged access, firefighter accounts, single sign-on, Active Directory integration, audits, and SAP GRC-related controls.

Figure 5: Identity & Access Management

Within the framework introduced in the webinar, identity and access represented approximately 25% of the overall SAP cyber risk picture. While these controls remain important, they address only part of the broader risk landscape. Phishing, social engineering, exposed privileged credentials, weak password practices, compromised service accounts, and insecure system-to-system connections can still provide attackers with legitimate access to SAP environments.

Effective identity and access management also requires continuous visibility into how accounts are being used. SAP systems can generate large volumes of security audit events, making manual review difficult at scale. The webinar highlighted how machine learning, behavioral baselines, pattern recognition, and agentic approaches can help correlate activity and surface anomalous behavior that may indicate compromise. When suspicious activity is detected, organizations need processes to assess its significance and respond quickly before the impact expands. In this context, cyber resilience extends beyond controlling access to include the ability to detect, respond to, contain, and recover from threats when preventive controls are bypassed.

Bringing the four pillars together for SAP cyber resilience

The most important takeaway from the webinar is that these four pillars cannot operate independently. SAP cyber risk is distributed across platform, configuration, application, and identity layers, which means strength in one area cannot compensate for significant weaknesses in another. Unlike many enterprise applications where identity can represent 40–50% of cyber risk, SAP requires organizations to account for a broader range of technical and operational exposures across the entire environment.

Therefore, a more resilient approach depends on connecting these risks rather than managing them through separate teams, tools, and processes. The discussion outlined a progression from detection to assessment, prioritization, and remediation, with findings evaluated in the context of system criticality, business impact, and related weaknesses across the landscape. Then, governed automation and predefined playbooks can help accelerate response while maintaining the approvals, testing, and controls required in SAP environments.

End-to-end coordination across the four pillars is central to SAP Autonomous Cyber Operations. The objective is not to perfect one security domain, but to continuously understand the health of all four pillars and reduce the time between identifying a risk and resolving it. For organizations building a SAP cybersecurity Center of Excellence, this creates a stronger foundation for replacing fragmented security activities with a connected operating model focused on visibility, prioritization, remediation, and cyber resilience.