How should security teams approach a Greenfield SAP S/4HANA implementation when they want a clean core without carrying legacy risk forward?

Why This Matters for Security Teams

A Greenfield SAP S/4HANA programme is a security reset opportunity, but only if the team treats it as a design exercise rather than a technical migration. clean core decisions affect identity boundaries, privileged access, interfaces, logging, segregation of duties, and how much legacy process debt is allowed back in through “temporary” exceptions. That is why governance has to start before configuration, not after testing is already underway.

Security teams often inherit pressure to preserve familiar workflows, yet familiar does not mean safe. A disciplined Greenfield approach lets the organisation define what must be retained, what can be retired, and where compensating controls are required for integrations, custom code, and master data. The most durable patterns align cleanly with the NIST Cybersecurity Framework 2.0 and with NHIMG guidance on common identity and access failures in Top 10 NHI Issues.

In practice, many security teams discover that “clean core” is undermined not by the SAP platform itself, but by last-minute integration shortcuts and access exceptions that reintroduce old risk through the back door.

How It Works in Practice

The practical starting point is to define security architecture alongside business process design. That means mapping target-state processes, data classifications, system-to-system trust boundaries, and privileged roles before any build begins. A Greenfield S/4HANA implementation should use this stage to decide which business functions are genuinely needed, which controls must be embedded in configuration, and which legacy authorisations should be discarded rather than migrated.

From there, teams should harden the clean core with controls that support future maintainability:

• Design least-privilege access around business roles, not around old job titles or inherited profile dumps.
• Separate development, test, and production access, and require approvals for any emergency or elevated access path.
• Validate master data quality early, because poor data creates hidden access, reporting, and process-control failures later.
• Treat interfaces as security boundaries, especially where middleware, APIs, batch jobs, or third-party services connect to SAP.
• Build security testing into every phase, including role testing, segregation-of-duties checks, and interface validation.

For implementation detail, teams can anchor their control model in NIST SP 800-53 Rev. 5 Security and Privacy Controls and use NHIMG research on Ultimate Guide to NHIs — Key Challenges and Risks to pressure-test service accounts, automation identities, and hidden machine-to-machine dependencies that often expand during ERP transformations. If the organisation needs a recent benchmark for why governance discipline matters, NHIMG’s 2024 ESG Report: Managing Non-Human Identities shows that 72% of organisations have experienced or suspect a breach of non-human identities, which is a warning sign for any transformation that increases automation and integration count.

These controls tend to break down when the programme compresses design time and allows “temporary” access, custom code, or interface exceptions to survive into production because no one owns their removal.

Common Variations and Edge Cases

Tighter clean-core control often increases design effort and can slow early delivery, so organisations have to balance speed against the cost of carrying hidden technical debt into a business-critical ERP platform. The best practice is evolving, but current guidance suggests that exceptions should be explicit, time-bound, and approved with a removal plan rather than treated as normal architecture.

One common edge case is the need to retain a few legacy integrations or bespoke reports. Those can be acceptable if they are wrapped in narrow contracts, monitored closely, and reviewed for retirement as the platform stabilises. Another is regulatory or audit-driven retention of historical data, which should be separated from operational access so the clean core remains uncluttered. Security teams should also watch for “shadow migration” patterns where business owners ask for the old process to be rebuilt one-for-one, which recreates legacy risk under a modern interface.

NHIMG’s SAP Breach research reinforces a simple lesson: ERP compromise is often enabled by weak identity discipline and overextended trust, not by the application layer alone. For broader risk treatment, Ultimate Guide to NHIs — Why NHI Security Matters Now is useful when the implementation relies heavily on service accounts, automation, and third-party connectors.

In short, Greenfield succeeds when security teams preserve only what is necessary, make every exception visible, and remove inherited access patterns before they become the new standard.

Related resources from NHI Mgmt Group

• How should security teams approach GRC migration without carrying forward old risk?
• How should security teams plan an SAP ECC to S/4HANA migration without disrupting business operations?
• How can security teams reduce risk without redesigning legacy shared workflows?
• How should security teams govern ABAP customisation in large SAP environments without creating upgrade risk?