Code Integrity is the Windows enforcement layer that validates whether executable code can be loaded or run under a given policy. In practice, it turns signature and trust decisions into runtime gates, so untrusted binaries are blocked before they can join a process context.
Expanded Definition
Code Integrity is a runtime trust control that decides whether a binary, library, script host, or other executable component may load under a defined policy. In Windows environments, it sits between code provenance and process execution, so trust is not merely recorded in a catalog but enforced at the point of use. That matters for NHI security because agents, service wrappers, build runners, and automation tooling often execute with non-human credentials and can inherit broad privilege if untrusted code is allowed into their process space.
In NHI governance, code integrity is closely related to software supply chain assurance, but it is not the same thing. Supply chain controls verify how code was built and delivered, while code integrity answers whether the runtime environment will actually permit it to execute. Definitions vary across vendors when policy extends beyond Windows-native signing to include catalog files, enterprise trust stores, and managed application control. For operational guidance, the NIST Cybersecurity Framework 2.0 is useful for mapping how protection, detection, and recovery expectations intersect with code execution control. The most common misapplication is treating a signed binary as inherently safe, which occurs when organisations confuse signature validation with full policy-based runtime enforcement.
Examples and Use Cases
Implementing code integrity rigorously often introduces deployment friction, requiring organisations to weigh tighter execution control against the cost of maintaining trusted signer lists, policy updates, and exception handling.
- A service account used by a CI runner is limited to launching only approved build agents, preventing an attacker from replacing the runner binary with a trojanised version.
- An automation host blocks unsigned PowerShell modules so an attacker cannot drop a malicious helper into a scheduled task path and inherit the task’s privileges.
- A Windows server enforces allow-listed application control for a privileged backup agent, reducing the chance that a rogue DLL can be loaded during backup operations.
- After a review of long-lived credentials embedded in code, a team pairs code integrity with secret hygiene controls described in the Ultimate Guide to NHIs to stop both tampered binaries and exposed credentials from reaching production.
- A platform team aligns runtime enforcement with signing and trust workflows referenced by NIST Cybersecurity Framework 2.0 so that only approved code reaches privileged automation paths.
In practice, code integrity is most valuable where NHIs execute unattended: CI/CD nodes, endpoint management tools, backup agents, and orchestration layers. It prevents a simple file-drop attack from becoming a privileged execution event.
Why It Matters in NHI Security
NHIs frequently run with elevated or persistent access, which means a single unauthorized executable can become a lateral movement path, a credential theft mechanism, or a persistence anchor. NHI Mgmt Group research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, and 30.9% store long-term credentials directly in code. When code integrity is weak, those embedded secrets can be harvested by malicious code that would otherwise never have been allowed to load.
This control also supports governance after compromise. If an attacker tampers with an automation host, the question is no longer just who authenticated, but what code was permitted to execute under that NHI’s authority. The Ultimate Guide to NHIs helps frame this as a lifecycle issue, not a one-time configuration task, while broader resilience objectives in NIST Cybersecurity Framework 2.0 emphasise containment and recovery when trust boundaries fail. Organisations typically encounter the need for code integrity only after a trusted automation path has been abused, at which point runtime execution control becomes operationally unavoidable to address.
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, CSA MAESTRO and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-08 | Runtime code trust protects non-human execution paths from malicious binary injection. |
| NIST CSF 2.0 | PR.DS | Code integrity preserves software and code integrity as a protective function. |
| NIST Zero Trust (SP 800-207) | SC-23 | Zero trust assumes code cannot be trusted without explicit runtime enforcement. |
| CSA MAESTRO | Agentic systems need guardrails preventing unapproved code from entering execution. | |
| OWASP Agentic AI Top 10 | Agentic workflows are exposed when injected or replaced code gains tool access. |
Enforce approved-code execution so NHIs cannot load untrusted binaries or scripts.
Related resources from NHI Mgmt Group
- What is the difference between code integrity risk and identity exposure risk in CI/CD?
- Why is hardcoding credentials into source code so dangerous?
- What is the difference between code scanning and runtime identity monitoring?
- What is the difference between scanning AI-generated code and governing AI agent identity?
