Custom code carryover risk

Expanded Definition

Custom code carryover risk is the possibility that migrated or rewritten code preserves old trust assumptions, hidden privilege paths, or embedded approval logic that no longer matches the target platform. In SAP and adjacent enterprise systems, the risk is not limited to syntax or compatibility. It also includes governance drift, where a function that once made sense in a legacy landscape now bypasses a control that the new environment expects. That is why this term sits close to identity, authorisation, and change management rather than pure development hygiene. NHI Management Group treats it as a security issue whenever code continues to act like an unreviewed credential broker, policy exception, or implicit entitlement source. The concept aligns well with the control intent in the NIST Cybersecurity Framework 2.0, especially where access control and secure change management must remain consistent across system transitions. The most common misapplication is treating carryover code as a functional migration artifact only, which occurs when teams validate outputs but do not reassess embedded authorisation behavior.

Examples and Use Cases

Implementing migration controls rigorously often introduces release friction, requiring organisations to weigh speed of cutover against the cost of code-by-code review and entitlement revalidation.

• A batch job still calls a legacy function module that assumes broad background-user access, even though the target system expects explicit role checks.
• An adapter carries over hardcoded approval exceptions from the source environment, creating an indirect authorisation path that bypasses modern workflow controls.
• A custom report reads sensitive master data through a technical account that was never scoped for the new target landscape, increasing NHI exposure.
• A migrated integration stores credentials in code or configuration, compounding the issues described in the Ultimate Guide to NHIs — Key Challenges and Risks and making secret handling part of the code review itself.
• Security teams use guidance from the Top 10 NHI Issues alongside NIST Cybersecurity Framework 2.0 to check whether migrated code still reflects least-privilege assumptions.

In practice, the safest use case is a pre-go-live review that traces each custom object to its original security purpose and asks whether that purpose still exists in the target state. Where the answer is no, the code should be refactored, retired, or wrapped with explicit controls.

Why It Matters in NHI Security

Custom code carryover risk matters because migrated logic often becomes an invisible control plane for NHIs. If service accounts, API keys, or technical users are embedded in code paths that were never redesigned, the organisation can unknowingly preserve excessive privilege, weak segregation of duties, or undocumented access routes. That is exactly the kind of issue highlighted in the Ultimate Guide to NHIs — Why NHI Security Matters Now, where NHI sprawl and weak governance create broad attack surface. NHI Management Group research shows that 97% of NHIs carry excessive privileges, and 30.9% of organisations store long-term credentials directly in code. Those conditions make carryover logic especially dangerous during migration because code can reintroduce risk even when infrastructure has been modernised. The governance lesson is simple: if code still assumes the authority model of the old system, the new system has not really been secured. Organisations typically encounter the impact only after a failed access review, an unauthorised transaction, or a post-cutover incident forces them to trace which migrated custom program preserved the old rule.

Related resources from NHI Mgmt Group

• Low-Code Integration
• When do AI-generated code and assistants increase secret exposure risk?
• What is the difference between code integrity risk and identity exposure risk in CI/CD?
• Why do AI code assistants create more risk than ordinary development plugins?