Should organisations prioritise application control or code signing for DLL sideloading risk?

Application control should come first because it decides what can execute, while code signing only helps establish origin. A signed application can still become a delivery path for untrusted code if runtime-loaded libraries are not checked. The practical priority is to govern the full load chain and then use signing as one input to that decision.

Why application control outranks code signing for DLL sideloading

DLL sideloading is a trust-boundary problem, not just a provenance problem. The core issue is that an application may load a library from a location or path that the operator did not intend, which means a legitimate executable can become a carrier for untrusted code. Application control is the control that decides what is allowed to execute and load in the first place, while code signing only says something about where a file came from and whether it was altered after signing. For that reason, signing is useful evidence, but it is not a complete decision rule on its own. See the NIST SP 800-53 Rev 5 Security and Privacy Controls for the broader control context around system and software integrity.

Teams often overfocus on whether the application binary is signed and underfocus on whether the load path is constrained. In practice, a signed parent executable can still load an unsigned, malicious, or simply wrong library if the runtime trust decision is weak. That means the control gap sits at execution time, not just at distribution time. In practice, many security teams encounter DLL sideloading only after a trusted application has already been used as the launch point for untrusted code, rather than through intentional loading policy.

How the two controls work together during the load chain

Application control governs whether a process, script, module, or library is permitted to run on the endpoint. For DLL sideloading risk, that matters because the abuse path usually depends on the operating system resolving a library in a way that the operator did not plan. If the control only checks that the executable is signed, it can miss the fact that the executable is loading code from an unsafe directory, an attacker-writable path, or a location that is merely adjacent to the intended binary.

Code signing helps answer a narrower question: who published this file, and has it been modified since signing? That is valuable for supply-chain trust, tamper detection, and software provenance. It does not, by itself, guarantee that the library is the correct one for the intended context, or that it is safe to load in this execution path. A signed but vulnerable library can still be abused, and a properly signed application can still be used as an execution proxy for an unintended module.

Application control is strongest when it governs the full load chain, including dependent libraries and runtime-loading behavior.
Code signing is strongest as a trust signal, not as the only allow-or-block criterion.
Path control matters because sideloading frequently succeeds through search-order and writable-location abuse.
Verification should cover where the library comes from, where it is loaded from, and whether that combination is expected.

In practice, the most reliable approach is to treat signing as one input to a broader allow decision and to use application control to block unexpected execution contexts. Where organisations rely on signing alone, they often discover that provenance was intact but the runtime selection was not. The guidance breaks down when the environment cannot accurately inventory dependent loads or when legitimate software frequently self-loads plugins from variable paths.

When the answer changes: managed software, plugins, and partially trusted paths

Tighter application control often increases operational overhead, requiring organisations to balance blocking unexpected loads against supportability for complex software estates. That tradeoff becomes sharper in environments that use plugins, optional modules, updater components, or vendor software that loads libraries dynamically. In those cases, a pure allowlist approach can generate friction, while a loose signing-only model can leave the load chain too permissive.

There is no universal consensus that signing should be ignored, because some organisations use it as a meaningful secondary trust signal for packaged software and internally distributed components. The important distinction is that signing helps rank trust, while application control decides whether that trust is sufficient in this execution context. If a library is expected to change frequently, is loaded from a writable directory, or is selected at runtime, the control decision should be stricter than a simple signed-versus-unsigned check.

The edge case to watch is software that is both legitimate and dynamic. Security teams can overcorrect by blocking all dynamic loading, which breaks business workflows, or undercorrect by allowing any signed component, which leaves a sideloading path open. The practical middle ground is to validate the expected publisher, the expected path, and the expected process relationship together, rather than treating any one of them as decisive.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST CSF 2.0, MITRE-ATTACK and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	2	DLL sideloading hinges on controlling what software and modules can run.
Recommendation: Use allowlisting and software control to stop unexpected libraries from executing.
NIST CSF 2.0	PR.DS	The issue is integrity of software and loaded code, not just publisher provenance.
Recommendation: Protect software integrity by constraining untrusted code paths and load behavior.
MITRE-ATTACK	T1574.001	DLL sideloading is a recognised attack technique involving abused library loading paths.
Recommendation: Map and disrupt search-order abuse that lets attackers execute code through trusted apps.
CIS Controls v8	10	Sideloading is a common malware delivery and execution path on endpoints.
Recommendation: Use endpoint malware defenses to detect and restrict malicious library execution.

Practitioner Guidance

What to prioritise: Start with the execution decision, not the file origin. If a control cannot tell you which binaries and libraries are allowed to load in a given context, signing will not close the sideloading gap on its own.

What to verify: Confirm that the approved application path also covers dependent libraries, updater folders, plugin directories, and any location that the application may search implicitly. The common failure is assuming the parent executable is enough evidence.

Decision rule: If a library can be loaded from a writable or semi-trusted location, treat that as a higher-risk condition even when the parent application is signed. If the load path is fixed and controlled, signing becomes a stronger supporting signal rather than the primary safeguard.

Practitioner takeaway: DLL sideloading is usually defeated by governing what may load, where it may load from, and under which process context, with code signing serving as supporting evidence rather than the decision-maker.