The main failure is governance continuity. If the replacement does not recreate role logic, approval routing, lifecycle triggers, and downstream connectors, access may still be created and removed, but it will no longer behave as a controlled, auditable programme. That creates drift between policy and actual entitlement state.
Where retirement breaks governance continuity
Retiring SAP identity management without a successor plan does not usually stop access operations outright. What breaks first is the control layer that makes those operations meaningful: the entitlement model, approval paths, lifecycle events, and exception handling that previously tied access decisions to policy. Without that replacement, the organisation can still grant and remove access, but the process becomes harder to explain, audit, and trust.
That matters because identity programmes are not just directories or provisioning tools. They encode how roles are interpreted, who can approve changes, when accounts should move or be removed, and which downstream systems must be updated together. If those behaviours are lost during a retirement programme, the result is often fragmented manual handling or partial automation that no longer matches the business rule set.
For a transition like this, the critical question is whether the successor reconstructs the same governed behaviours, not whether it merely authenticates users or syncs accounts. A new platform or workflow can look functional while silently dropping SoD logic, recertification cadence, or edge-case routing that was previously embedded in the SAP estate. That is how policy drift begins.
What entitlement drift looks like after cutover
The most visible symptom is mismatch between the approved state and the live state. Access may continue to be created from legacy role assumptions even though the new target system uses a different entitlement structure, or removed users may retain access because the revocation path no longer reaches every connected application. In practice, the organisation ends up with orphaned access, overprovisioned accounts, and approvals that no longer correspond to actual privilege.
That drift is especially dangerous when SAP was acting as the coordination point for multiple dependent systems. If role translation, downstream connectors, or event triggers are not recreated, each connected application can start behaving differently. Some removals will succeed, some will lag, and some will never happen, which means the estate becomes inconsistent even when administrators believe the migration is complete.
This is also where lifecycle governance becomes a hidden dependency. NHI Lifecycle Management Guide is useful here because the failure mode is not limited to provisioning itself, it is the loss of joined-up provisioning, rotation, visibility, and offboarding behaviour across a system boundary. The same governance pattern applies whether the identities are human or non-human: the lifecycle must remain controlled after the tool change.
Why the retirement decision is really a control-design decision
When SAP identity management is retired, the replacement choice determines whether access governance remains a programme or becomes a set of ad hoc workflows. If the successor only replicates account creation but not role engineering, approval routing, periodic review, and connector coverage, then the organisation has preserved a mechanism but lost the control model. That is a material change in governance, not a routine technology swap.
Practitioners should treat this as an entitlement architecture issue first and a tooling issue second. The main design question is whether the successor can represent the same business roles, enforce the same approval intent, and leave a reliable audit trail for every create, change, and revoke event. If not, the migration should be treated as a redesign exercise, not a lift-and-shift.
That is why a broad access-governance reference point helps. IAM and IGA Basics covers the core split between authentication, authorization, provisioning, and access review, which is exactly the split that tends to blur during retirement programmes. Identity Security Programme Guide is also relevant because the replacement must fit into an operating model with ownership, governance, and roadmap discipline rather than existing as a one-off implementation.
Risk and Threat Considerations
When successor planning is missing, the primary risk is control failure at scale: access may remain functional while governance evidence, approval integrity, and revocation reliability degrade. That creates exposure to privilege creep, lingering access after role changes, and inconsistent enforcement across connected systems, especially where SAP previously served as the source of truth.
Failure mechanism: Role logic, approval paths, lifecycle triggers, or downstream connectors are not recreated with equivalent fidelity, so the retired platform’s control decisions stop mapping cleanly to live entitlements.
Impact: The organisation accumulates unauthorized or unexplained access states, loses confidence in auditability, and may not be able to prove that joiner, mover, and leaver events were handled consistently.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Controls account lifecycle and revocation behavior affected by SAP retirement |
| AC-6 — Least Privilege | Retirement can leave excess access when role logic and approvals drift | |
| AU-2 — Event Logging | Governance continuity depends on auditability of access changes after replacement | |
| Recommendation — Map SAP access transitions to AC-2 and verify every joiner, mover, and leaver path still executes cleanly. Revalidate entitlements under AC-6 so the successor does not preserve stale privilege. Ensure AU-2 coverage captures successor access events, approvals, and revocations. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | SAP retirement changes how access rules are defined and enforced across systems |
| A.5.18 — Access rights | Successor planning must preserve granting, modifying, and removing rights | |
| Recommendation — Rebuild access control rules in the successor and confirm they remain enforceable end to end. Review access rights handling in the new process before decommissioning the old one. | ||
Practitioner Guidance
What to verify: Confirm that the successor reproduces every material control behaviour, not just the user-facing workflow. The minimum test is whether role mapping, approval lineage, recertification, and revocation all still work against real downstream systems, including the awkward edge cases that SAP handled implicitly.
Decision rule: If a control path cannot be demonstrated end to end in the new design, treat the retirement as incomplete and keep the legacy control in place until the gap is closed. A partial replacement is often worse than no change because it creates confidence without continuity.
What practitioners underestimate: Connector loss is usually more damaging than the directory migration itself. The most common failure is not account creation, it is silent divergence between the authoritative policy and the operational entitlement state across dependent applications.
Practitioner takeaway: A safe retirement plan preserves governance semantics, not just identity data, and that requires proving that the successor can express and enforce the same access decisions before SAP is turned off.
Related resources from NHI Mgmt Group
- What breaks when organisations migrate AWS access management without aligning identity provider maturity and workflow design?
- What breaks when teams rely on identity tokens alone without an access management layer for workloads?
- What breaks when agencies move identity management to SaaS without preserving legacy support?
- What breaks when a managed DNS provider is retired without a full migration plan?