What is the difference between Greenfield and Brownfield SAP S/4HANA implementation from a controls perspective?

Why This Matters for Security Teams

From a controls perspective, the implementation path changes the amount of identity, access, and process redesign required before go-live. Greenfield SAP S/4HANA programs can define target-state controls up front, which makes it easier to remove legacy exceptions, rebuild segregation of duties, and standardise privileged access. Brownfield programs inherit existing authorisations, technical debt, and control gaps, so the work shifts toward mapping, rationalising, and validating what already exists against the new platform.

This distinction matters because migration decisions affect how much confidence can be placed in the control baseline on day one. The control challenge is not limited to application roles. It also includes privileged accounts, service accounts, integration credentials, and downstream dependencies that often survive a technical conversion. NHI Mgmt Group notes that 97% of NHIs carry excessive privileges, which becomes especially relevant when a brownfield conversion carries forward old access patterns into a new environment. See Ultimate Guide to NHIs — Standards and NIST Cybersecurity Framework 2.0 for the broader governance lens.

In practice, many security teams discover control weaknesses only after custom transactions, interface users, and emergency access paths have already been carried into production.

How It Works in Practice

Greenfield and brownfield implementation differ most in how control design is executed, not in whether controls are needed. In a greenfield build, teams typically define a new control model around business process design, then configure authorisations, logging, workflow approvals, and emergency access to match the target operating model. That creates an opportunity to align SAP roles with least privilege, clean segregation of duties, and stronger joiner-mover-leaver processes from the start.

In a brownfield conversion, the practical task is control remapping. Existing roles, Z roles, firefighter access, batch jobs, RFC users, and interface credentials must be reviewed for compatibility with the target SAP S/4HANA architecture. Security teams should inventory which controls are preserved, which must be revalidated, and which now behave differently because of changed business process paths or simplified data structures. The question is often not “can this role be migrated?” but “does this role still make sense in the new environment?”

• Map legacy roles to target-state business processes before technical cutover.
• Review privileged and non-human access separately from human user access.
• Re-test segregation of duties after role redesign, not just after transport moves.
• Validate interface accounts, API keys, and service credentials as part of migration scope.

This is where NHI governance becomes operationally important. The NHIMG guidance in Ultimate Guide to NHIs helps teams separate human entitlements from machine access, while SAP-specific exposure examples such as SAP Breach show why inherited credentials and weak lifecycle controls remain a real risk in enterprise platforms. These controls tend to break down when brownfield cutovers preserve old emergency access, custom code, and interface trust relationships because the old exceptions are still needed to keep business operations running.

Common Variations and Edge Cases

Tighter control redesign often increases migration effort, testing time, and business disruption, so organisations must balance target-state security against the need to preserve operational continuity. The main tradeoff is between speed and assurance: greenfield offers stronger control clarity, while brownfield offers lower change impact but higher validation burden.

There is no universal standard for exactly how much control redesign is required in brownfield SAP programs. Current guidance suggests treating the migration as a control re-assessment exercise, not only a technical conversion. That means verifying whether inherited roles still align with current business ownership, whether privileged access is still justified, and whether emergency access is governed consistently across environments. For organisations with extensive third-party integrations or outsourced operations, the scope expands further because external access paths often carry hidden dependencies.

One useful way to think about it is lifecycle risk. Greenfield lets teams establish governance for NHIs, approvals, and monitoring at the outset. Brownfield forces teams to discover which access paths are already embedded in operations and decide which ones can be remediated later versus blocked before go-live. For broader identity governance context, the Ultimate Guide to NHIs — What are Non-Human Identities is useful because SAP controls increasingly depend on how machine identities are inventoried and rotated, not just how end users are provisioned.

Related resources from NHI Mgmt Group

• What is the difference between greenfield, brownfield, and hybrid SAP S/4HANA migration approaches?
• How should security teams approach a Greenfield SAP S/4HANA implementation when they want a clean core without carrying legacy risk forward?
• When does a Greenfield SAP S/4HANA approach create more security work than a Brownfield conversion?
• What is the difference between privilege reduction and secret rotation?