SAP S/4HANA is the enterprise resource planning system that runs core business processes, while SAP BTP is the platform used to integrate, extend, and build applications around that core. In practice, S/4HANA is the system of record, and BTP is the service layer that helps connect data, workflows, and cloud-native capabilities across the wider SAP landscape.
Why This Matters for Security Teams
In a cloud migration, the S/4HANA versus BTP distinction is not just an architecture question. It defines where core business data lives, where integrations are allowed to execute, and where NHI controls must be enforced. Security teams often misread BTP as a simple add-on, then under-scope the identities, secrets, and service accounts that connect it to the ERP core. That creates a hidden trust boundary across workloads, APIs, and automation.
This matters because the migration path usually expands machine-to-machine access before it improves governance. NHIMG’s 2024 Non-Human Identity Security Report shows that 88.5% of organisations say their non-human IAM lags human IAM, which is exactly the kind of gap that appears when core ERP and platform services are treated as the same control plane. The same pattern shows up in incidents like the SAP Breach, where identity and access controls matter as much as application hardening. In practice, many security teams discover the real exposure only after integrations, service principals, and background jobs are already live in production.
How It Works in Practice
SAP S/4HANA is the system of record for finance, supply chain, procurement, and other core processes. SAP BTP is the platform layer used to extend those processes, integrate data, run workflows, expose APIs, and build adjacent cloud services. In a migration strategy, that means S/4HANA should stay tightly governed as the transactional core, while BTP becomes the orchestration and extension layer that connects users, applications, and external systems.
For security and identity planning, the distinction changes what gets privileged. S/4HANA typically needs tightly bounded application roles, administrative separation, and strong controls around business-critical transactions. BTP usually introduces more NHIs: integration runtimes, service instances, destination objects, API consumers, CI/CD automation, and event-driven workflows. Those components often rely on secrets and service bindings, which makes lifecycle management a control problem, not just an infrastructure task. NIST’s Cybersecurity Framework 2.0 is useful here because it pushes teams to define governance, asset visibility, and access control across the full stack rather than only at the ERP boundary.
A practical migration model usually separates responsibilities like this:
- S/4HANA owns master data, posting logic, and process integrity.
- BTP owns integration, eventing, extension apps, and workflow automation.
- Machine identities are issued per workload or per integration path, not shared across environments.
- Secrets are rotated and scoped to the minimum service, destination, or API needed for the task.
That operating model is also why legacy SAP patterns such as hardcoded credentials are risky; NHIMG has documented this problem in SAP SQL Anywhere Monitor Hardcoded Credentials. These controls tend to break down when BTP is used as a rapid extension layer across multiple landscapes because identity sprawl appears faster than governance can be standardized.
Common Variations and Edge Cases
Tighter separation between S/4HANA and BTP often increases migration overhead, requiring organisations to balance speed of delivery against control of the integration surface. That tradeoff becomes sharper when teams use BTP to bridge hybrid estates, connect third-party SaaS, or support phased carve-outs and selective modernization. There is no universal standard for this yet, but current guidance suggests treating each BTP service instance, destination, and technical user as a distinct trust boundary.
One common edge case is when business teams assume BTP can absorb application logic that should remain in S/4HANA. That can be appropriate for lightweight extensions, but it creates governance drift if transactional decisions, approvals, or sensitive data transformations move outside the core without updated controls. Another edge case is shared authentication between SAP and non-SAP systems, where identity federation improves user experience but can obscure which workload actually has permission to act.
Security teams should also watch for migration phases where temporary access becomes permanent. That is where NHI risk grows fastest, especially if service accounts, API keys, and automation tokens are copied between sandboxes, test tenants, and production. The Ultimate Guide to NHIs — What are Non-Human Identities is useful for keeping that distinction clear. In practice, the hardest failures show up when teams treat BTP as “just middleware” and do not assign separate identity governance to the automation that now controls business-critical paths.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers lifecycle control for service identities and secrets used by BTP integrations. |
| OWASP Agentic AI Top 10 | A-03 | Relevant where BTP automation and workflow agents execute actions across systems. |
| CSA MAESTRO | ID-1 | Addresses workload identity and trust boundaries across cloud platform extensions. |
| NIST AI RMF | Useful for governance of autonomous automation and changing access context. | |
| NIST CSF 2.0 | PR.AC-4 | Access control guidance maps to separation between ERP core and platform services. |
Inventory each BTP workload identity and enforce rotation, revocation, and least privilege.
Related resources from NHI Mgmt Group
- What is the difference between greenfield, brownfield, and hybrid SAP S/4HANA migration approaches?
- What is the difference between cloud migration and identity modernization?
- What is the difference between SAP access governance in core ERP and access governance across cloud business apps?
- What is the difference between a cloud identity platform approach and a legacy identity system in an M&A migration?
