Client Copy is the process of duplicating a client within an SAP instance or across instances. It is commonly used to create test, development, or training environments that mirror configuration or data structures, while maintaining separate logical boundaries between clients.
Expanded Definition
Client Copy refers to duplicating a client within an SAP landscape, either inside the same instance or across instances, to create controlled environments for testing, development, or training. In NHI and IAM conversations, the term matters because copied clients can also replicate roles, technical users, integrations, and stored credentials if governance is weak.
Usage in the industry is still precise but context-dependent: SAP administrators may treat client copy as a functional operations task, while security teams treat it as a data, identity, and segregation event. The operational risk is not the copy itself, but the persistence of access artifacts, background jobs, RFC destinations, or secrets that should not survive into non-production. That is why client copy procedures should be aligned with least privilege and post-copy sanitisation expectations from the NIST Cybersecurity Framework 2.0. The most common misapplication is treating a client copy as a harmless clone, which occurs when teams assume test boundaries automatically remove production-level access and sensitive data.
Examples and Use Cases
Implementing client copy rigorously often introduces environment-reset overhead, requiring organisations to weigh faster test readiness against the cost of cleansing identities, data, and authorisations after each clone.
- A basis team copies production into a QA client to reproduce a transport issue, then removes active RFC trust and replaces production credentials with test-only secrets.
- A security team clones a training client so analysts can practice incident response without exposure to live customer data or privileged service accounts.
- An SAP operations group performs an instance-to-instance copy for a new region, then validates that background jobs, integration users, and certificate bindings were not carried forward.
- An audit team reviews copied clients to confirm masking, access restrictions, and change tracking, using the post-copy checklist as evidence of control execution.
For broader NHI hygiene, a copied client should be checked against the lifecycle and secret-handling concerns highlighted in the Ultimate Guide to NHIs, especially where service accounts or API keys may have been replicated. The same discipline is consistent with NIST Cybersecurity Framework 2.0 guidance on controlled access and recovery.
Why It Matters in NHI Security
Client copy becomes a security issue when copied environments preserve non-human identities that were meant to stay production-bound. A cloned client can unintentionally inherit service accounts, cached tokens, interface credentials, and broad permissions, making it easier for testers or attackers to pivot into systems that should have remained isolated. NHIMG research shows that 97% of NHIs carry excessive privileges, which makes any uncontrolled duplication especially risky because copied access often becomes inherited access rather than reviewed access. The governance problem is not limited to SAP configuration; it also includes secrets sprawl, offboarding gaps, and incomplete visibility into what was duplicated.
That is why client copy should be paired with identity review, secret rotation, and post-copy validation rather than treated as a pure application administration task. The security implications are easier to see when comparing to real-world NHI abuse patterns described in Gemini CLI Breach — Silent Code Execution, where hidden execution pathways and overbroad trust create durable exposure. Organisations typically encounter the impact only after an unexpected access event or data leak, at which point client copy becomes operationally unavoidable to review and remediate.
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 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207), NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Copied clients can replicate secrets and technical identities, a core NHI secret-management risk. |
| NIST CSF 2.0 | PR.AA-1 | Client copy affects identity verification and access control in cloned environments. |
| NIST Zero Trust (SP 800-207) | SC-7 | Copied clients must preserve segmentation boundaries and limit lateral movement. |
| NIST SP 800-63 | IAL2 | Non-human actors in copied clients need assurance aligned to identity proofing and binding strength. |
| NIST AI RMF | Model and AI-enabled workflows in copied environments need risk review after duplication. |
Ensure copied service identities are re-established with appropriate assurance, not inherited blindly.
