Windows DLL trust checks show how code integrity is enforced

At a glance

What this is: This is a technical analysis of how Windows enforces trusted DLL loading, with the key finding that signature policy is checked in the kernel during image mapping.

Why it matters: It matters because security-sensitive applications that depend on process integrity must treat loaded modules as identity-bearing components, not just files, or they risk undermining higher-level controls.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes - and as quickly as 9 minutes in some cases.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Island's analysis of trusted DLL verification in Windows

Context

Trusted DLL loading is an identity assurance problem for running code. If a browser or other sensitive process accepts an untrusted module, the module inherits the process context and can act with the same effective privileges as the host application, which makes module trust part of the identity perimeter.

The article focuses on how Windows validates that loaded DLLs meet a required signing policy and how that validation is anchored in the kernel, not in user-mode loader logic. For practitioners, the relevant question is whether the trust chain behind loaded code is pinned, bounded, and resistant to local store manipulation.

That distinction matters in environments where the process handles credentials, tokens, or other sensitive data. Once module loading is treated as an access decision, not a file integrity detail, the governance conversation becomes familiar to IAM and NHI teams: who or what is trusted, under what anchor, and for how long.

Key questions

Q: How should security teams control DLL trust in sensitive Windows processes?

A: Security teams should treat DLL loading as an execution-admission decision. For sensitive processes, define explicit allowlists for approved signer identities, validate that the trust chain reaches an approved root, and confirm enforcement happens before the image is mapped into memory. That approach is stronger than relying on local certificate validity alone.

Q: Why is signature verification alone not enough to trust loaded code?

A: A signature proves that some certificate signed the binary, but it does not by itself prove that the signer is the one you intended to trust. If local trust stores can be modified, an attacker can create a believable chain that still fails your real governance requirement. Pinned trust anchors close that gap.

Q: What breaks when an application trusts the local certificate store for module loading?

A: The application inherits the weaknesses of any privileged local change to that store. In a sensitive process, that can turn a valid-looking signature into a false assurance signal, because the trust decision depends on mutable machine state rather than an explicit policy boundary.

Q: How do you know DLL trust enforcement is actually working?

A: Test it by attempting to load a non-allowlisted module and confirming the failure occurs at image section creation, before the module is mapped and executed. If the block happens only after user-mode execution begins, the control is too late for high-risk processes.

Technical breakdown

How Windows enforces DLL trust at image load time

Windows does not merely inspect a DLL after it is loaded. When a process requests a module, the loader transitions into kernel-managed image section creation, where Code Integrity evaluates the file against the active signing policy before the image is mapped into memory. That makes trust enforcement synchronous and boundary-defining. In the case described here, a Microsoft-signed-only policy caused the load to fail because the module did not satisfy the required signing level. For security architecture, the important point is that trust is enforced at the moment of execution admission, not as a post-load audit.

Practical implication: Treat DLL admission as a gate control and validate whether your own process policies are enforced before execution, not after.

Why local certificate stores are not a reliable trust anchor

The article shows why simple signature checks are not enough. On Windows, an attacker with sufficient privilege can add a self-signed certificate or self-signed CA to the local store, which means a validity chain that depends on local trust state can be subverted. A stronger model pins trust to known certificate material, such as thumbprints, public keys, or approved root identities, so the decision no longer depends on mutable local configuration. This is the same design principle used in broader identity systems: trust should be anchored to explicit, controlled identities rather than ambient machine state.

Practical implication: Pin trust anchors for high-risk code paths and do not rely on the local machine certificate store as the sole source of truth.

What ci.dll proves about signing-level verification

The reverse-engineering path shows that ci.dll compares the validated image against a required signing level using root-key and certificate-chain logic embedded in the code integrity stack. The key mechanism is not a superficial subject-name match. The system checks whether the certificate chain terminates at an approved root and whether the image satisfies the policy’s signing threshold. That is a useful model for identity teams because it mirrors least privilege: trust is not binary at the brand level, it is bound to a specific allowed class of signer and a specific execution policy.

Practical implication: Use signer class, trust anchor, and policy threshold together when designing allowlists for sensitive binaries.

NHI Mgmt Group analysis

Module trust is a privileged identity decision, not a file property. Once a DLL is loaded, it becomes part of the process’s effective identity surface and can inherit the host’s capabilities. That means browser hardening, token protection, and code integrity are joined problems, not separate controls. Practitioners should treat module admission as an access-control decision with identity consequences.

Local trust stores are too mutable to serve as the only trust root for sensitive execution paths. The article illustrates a classic control gap: a local certificate store can be influenced by privileged changes, which weakens any trust model that depends on it alone. The stronger pattern is to pin trust to approved signer identities and root material so the execution boundary is not delegated to ambient machine state.

Trusted-root validation is the named concept that matters here. The real boundary is not whether a DLL carries a signature, but whether that signature chains to an approved root and satisfies the policy applied to the process. That distinction is central to secure application design because it separates decorative trust from enforceable trust. Identity teams should map this to how they think about federation, anchors, and revocation.

Process signature policy shows how software supply-chain trust becomes runtime governance. The article demonstrates that code signing is only useful when policy consumes it at load time. In practice, that shifts the conversation from static provenance to runtime admission control, which is where higher-value workloads need to be defended. Security teams should align software trust decisions with runtime enforcement points, not package metadata alone.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes - and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• From our research: The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• From our research: 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to The State of Secrets in AppSec.

What this signals

The governance lesson is broader than Windows. Any control that relies on mutable local trust state creates an identity boundary that can be changed underneath the policy, which is why pinned trust anchors and explicit signer classes matter across code, workloads, and delegated access. Security teams should align runtime admission controls with the same rigor they already expect from identity federation.

Trusted-root validation: when a runtime control depends on the trust chain behind code, the practical implication is that identity assurance must be tied to immutable anchors rather than convenience-based trust decisions. That same pattern appears in workload identity and secrets governance, where the real question is whether the trust decision survives local administrative drift.

The next programme step is to connect this model to broader zero trust thinking. If the process boundary can be weakened by a single untrusted module, then the control plane for code execution belongs alongside identity, device, and session assurance in the same architecture review.

For practitioners

• Map process trust boundaries to loaded-module risk Inventory sensitive processes that handle credentials, tokens, or secrets, then document which DLLs they may load and which trust anchors those modules depend on. Focus on the process contexts where one untrusted module can break the entire assurance model.
• Pin approved signer identities for high-risk binaries Use certificate thumbprints, public keys, or approved root identities for allowlisted modules instead of relying only on the local certificate store. Keep the allowlist small and review it whenever signer material changes.
• Test enforcement at the kernel boundary Validate that your policies stop untrusted image loads before mapping, not after execution starts. Build a reproducible test that attempts to load a disallowed DLL and confirms the failure occurs at image admission.
• Separate Microsoft-signed trust from third-party trust Treat platform-signed modules and business-approved third-party modules as different trust classes with different governance rules. That avoids overgeneralising a single signature policy across binaries with different risk profiles.

Key takeaways

• Trusted DLL loading is an identity control because the loaded module enters the process’s effective authority boundary.
• Kernel-enforced image admission is stronger than a post-load integrity check because it blocks untrusted code before execution.
• Pinned trust anchors and explicit signer classes are the practical way to avoid relying on mutable local certificate state.

Key terms

• Code Integrity: 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.
• Hardware Root Of Trust: A hardware root of trust is a device-level trust anchor, often backed by a TPM or similar mechanism, that proves a system is what it claims to be. It helps infrastructure enroll without relying on static bootstrap secrets and gives identity systems a more durable basis for issuance and attestation.
• Process Signature Policy: Process Signature Policy is a Windows mitigation that restricts which images a process may load based on signing rules. For security teams, it is a runtime admission control mechanism, not a decorative label, and it only helps when the policy is matched to the exact trust classes you intend to permit.

What's in the full article

Island's full blog post covers the reverse-engineering detail this analysis intentionally leaves for the source:

• The Windows internals path from LdrLoadDll through section creation to Code Integrity enforcement, with the debugger evidence.
• The ci.dll analysis showing how trusted-root validation, EKU checks, and signing-level comparison are implemented.
• The certificate remap and renewal handling for Microsoft issuing CAs, including the maintainability logic behind the allowlist.
• The AI-assisted reverse-engineering workflow used with PDB dumps, WinDbg, and IDA Pro MCP.

👉 Island's full post covers the kernel enforcement path, ci.dll validation logic, and the signed-root allowlist behind the check.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM, PAM, or identity security programme, it is worth exploring.