D3-EAL Executable Allowlisting: Signature-Based Execution Control and How to Verify It

Malware, renamed tools and dropped payloads all need a process to start, and a host that refuses to start code it cannot authenticate removes that step for most of them. MITRE D3FEND names this countermeasure Executable Allowlisting (D3-EAL) and defines it narrowly as "Using a digital signature to authenticate a file before opening", with the synonym File Signature Authentication. It sits under the Isolate tactic as a child of Execution Isolation (D3-EI), and D3FEND models it as blocking Executable File and filtering Create Process. This card explains what that signature-centred definition means in practice, which ATT&CK techniques D3FEND relates to it, where it is implemented on Windows, macOS and Linux, how to prove enforcement works, and where it is bypassed. It is written for endpoint engineers and detection teams; the wider rollout programme is in the Application Allowlisting Guide.

Key takeaways

• D3FEND defines it by signatures. The D3FEND article describes hashing a file, verifying the signer's hash with the public key from a certificate, and invoking file quarantine, deletion or Executable Denylisting on a mismatch, at the moment a file is loaded or executed.
• Signer rules beat path rules. Microsoft documents that FilePath rules depend on mutable access permissions and do not give the guarantees of signer rules; publisher and hash rules authenticate the file itself.
• The mapping is wide but inferred. D3FEND links D3-EAL through Create Process and Executable File to persistence, privilege escalation, stealth and execution techniques, from Registry Run Keys to Mshta and Rundll32. These are artefact relations, not tested coverage.
• Trusted signers are the bypass. Signed system binaries that proxy execution, and code signed with stolen certificates, pass a signature check by design, so allowlisting needs blocklists for abused signed binaries and fast revocation.
• Audit mode first, always. Every major implementation has a log-only mode (App Control option 3 Enabled:Audit Mode, fapolicyd permissive = 1); enforcement follows only after the audit log is quiet.

D3-EAL at a glance

How it works

D3FEND's knowledge base article describes the generic mechanism. A certificate authority issues a certificate for a key pair; the publisher encrypts a hash of the file with the private key. When the file arrives, the receiving system decrypts the stored hash with the public key, computes a new hash of the file, and compares the two. A mismatch means the file is not what the signer produced, and further techniques such as file deletion, file quarantine or Executable Denylisting may be invoked. D3FEND notes the technique "may be invoked when deciding whether to load or execute a file."

Production allowlisting products wrap that signature check in a policy that answers a second question: not only "is this file intact and signed?" but "is this signer, or this exact hash, one we allow?" In practice the decision draws on these attributes:

• Signer: the certificate chain or publisher name. Broad and low-maintenance, because updates from the same publisher keep passing.
• Signer plus file: publisher, file name and minimum version. Narrower; allows one product, not everything the publisher ships.
• Hash: the exact file. Most specific, but every update changes the hash.
• Path: a location. Simple, but only as strong as the write permissions on that folder.
• Provenance: how the file arrived, such as a managed software distribution tool or the package manager database.

D3FEND's own consideration is operational: organisations that download or create high volumes of software, in particular engineering or scientific organisations, find management complex. That is the cost to plan for. NIST SP 800-167, the Guide to Application Whitelisting, covers the same planning ground for the whole deployment lifecycle.

Where identity fits

A signer rule makes a code signing key into a high-value machine credential: whoever holds it can produce files your fleet will run. Signing keys and the build pipelines that use them need the same custody as any privileged non-human identity, with hardware-backed storage, narrow access and a revocation plan. See the Code Signing Security Guide and, for the bad day, the Compromised Code Signing Certificate Playbook.

ATT&CK techniques D3FEND relates to D3-EAL

Relationship type: inferred only. D3FEND does not hand-map D3-EAL to ATT&CK. It derives these relationships through shared digital artefacts: D3-EAL filters Create Process and blocks Executable File, so ATT&CK techniques that invoke Create Process or create, execute or obfuscate an Executable File are related to it (D3FEND 1.6.0, checked November 2026). Every ID was checked against ATT&CK v20. The table lists the techniques with a direct artefact relation in the D3FEND ontology, grouped by ATT&CK tactic.

The D3FEND website shows a longer inferred list for D3-EAL, adding further persistence techniques (for example T1547.001 Registry Run Keys / Startup Folder, T1546.015 Component Object Model Hijacking, T1037.001 Logon Script (Windows), T1505.003 Web Shell, T1137.001 Office Template Macros), T1036.001 Invalid Code Signature, T1036.003 Rename Legitimate Utilities and eight Discovery techniques such as T1057 Process Discovery and T1082 System Information Discovery. For discovery the relation is weak: attackers usually run signed, built-in tools. The site also lists Impair Command History Logging under an ID that ATT&CK v20 has revoked; its v20 successor is T1690 Prevent Command History Logging. Treat the whole list as a placement guide, not a coverage claim. The mitigation view of the same ground is in M1038 Execution Prevention, and the proxy problem in the T1218 System Binary Proxy Execution Defensive Guide.

Where it is implemented

Platforms are listed alphabetically. Each implements signature or trust-based execution control with its own terms.

Availability: Microsoft documents App Control for Business on Windows Pro, Enterprise, Education and SE editions; fapolicyd ships with Red Hat Enterprise Linux; Gatekeeper is part of macOS. Platform depth is in App Control for Business (WDAC) and the fapolicyd and Linux Application Allowlisting Guide. Endpoint protection suites and third-party allowlisting agents implement the same idea with their own policy models.

Choosing rule levels

Implementation steps

1. Inventory what runs. Collect process creation and code integrity audit data from a representative set of devices for at least a full business cycle (month-end jobs and quarterly tools included).
2. Build a base policy from signers. Start from the platform's default or example policy, add publisher rules for vendors you use, and sign in-house tools rather than allowing their folders.
3. Deploy in audit mode to a pilot ring. Use App Control option 3 or fapolicyd permissive mode. Review every 3076 event or fanotify denial and decide: add a rule, fix the software, or accept the block.
4. Add explicit blocks for abused signed binaries. Signed proxies such as Mshta and Rundll32 pass signer rules; deny those your users do not need, which is where Executable Denylisting complements this technique.
5. Enforce in rings. Remove the audit option on the pilot ring, watch 3077 events and help desk tickets for two weeks, then widen. Keep servers with stable software early; developer workstations last.
6. Define the exception path. A time-bound request process with an owner and expiry, so local admin rights do not become the workaround.
7. Plan rollback. Keep the previous signed policy version ready to redeploy and document how to return a ring to audit mode without disabling the control entirely.

How to verify it works

• Unsigned test binary: on an enforced test host, copy a harmless unsigned executable (for example, one compiled in-house for the purpose) to a user-writable folder and run it. Expect a block and a 3077 event (Windows) or a fanotify denial (Linux) in the SIEM.
• Tampered file test: modify one byte of a copy of a signed, allowed test binary. The signature check should fail and the file should be blocked.
• Path rule test: confirm a standard user cannot write into any folder covered by a path rule.
• Policy drift check: compare the active policy version on each device with the approved version; on Linux, fapolicyd-cli --check-trustdb reports trust database mismatches.
• Adversary emulation: include execution of unapproved and proxy binaries in authorised purple team exercises and record which were blocked.

Limits and bypasses

• Signed proxies: System Binary Proxy Execution (T1218) and XSL Script Processing (T1220) run attacker content through binaries your signer rules trust. See the Living off the Land Guide.
• Stolen or misused signing keys: malware signed with a valid certificate passes a signer check until the certificate is revoked or the hash is denied.
• Interpreters and scripts: an allowed interpreter runs arbitrary script content unless script enforcement is on; App Control covers scripts and MSI files and places interactive PowerShell in Constrained Language Mode under enforcement.
• Writable trusted paths: path rules over folders users can write to let any file through. Microsoft's runtime FilePath rule protection checks this by default; option 18 Disabled:Runtime FilePath Rule Protection turns the check off and raises risk.
• In-memory techniques: process injection and doppelgänging abuse an already allowed process; pair with process monitoring.
• Not a replacement for anti-malware: Microsoft states App Control is not a replacement for antivirus and should run alongside it.

Common failure patterns

• Permanent audit mode: the policy logs for years and blocks nothing because nobody owns the move to enforcement.
• Allowing whole signers too broadly: trusting a large vendor's root or intermediate certificate allows every tool that vendor ever signed, including admin and debugging utilities.
• Local admin as the exception process: users who can change policy or install freely make allowlisting optional.
• Unprotected deployment channel: managed installer or package trust means a compromised software distribution account can push trusted malware; secure its credentials like any privileged account.
• No revocation drill: when a signing certificate is compromised, nobody knows how to deny it across the fleet quickly.

Framework mapping

Related countermeasures

• Executable Denylisting (D3-EDL): blocks known-bad or abused files; the article for D3-EAL names it as a follow-on action. See D3-EDL Executable Denylisting.
• Service Binary Verification (D3-SBV): integrity checking for service binaries. See D3-SBV Service Binary Verification.
• File Hashing (D3-FH): the hash computation that hash rules rely on. See D3-FH File Hashing.
• Execution Isolation (D3-EI): the parent family, which also covers process isolation techniques. Overview in the MITRE D3FEND Guide.

Practitioner checklist

• Base the policy on signer and signer-plus-file rules; keep hash rules for unsigned exceptions.
• Sign in-house tools with a protected internal certificate instead of allowing their folders.
• Never write path rules over folders that standard users can modify.
• Run audit mode on a pilot ring and triage every audit block before enforcing.
• Deny signed proxy binaries your users do not need and turn on script enforcement.
• Forward 3076, 3077, 3089, 8028 and 8029 events, or fanotify denials, to the SIEM.
• Protect code signing keys and deployment tool credentials as privileged machine identities.
• Rehearse denying a compromised signing certificate across the fleet.
• Test enforcement monthly with an unsigned and a tampered test binary.

Standards and references

• MITRE D3FEND: Executable Allowlisting (D3-EAL)
• NIST: SP 800-167 Guide to Application Whitelisting
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• Apple Platform Security: Gatekeeper and runtime protection in macOS
• Microsoft Learn: App Control for Business
• Microsoft Learn: Understand App Control policy rules and file rules
• Microsoft Learn: App Control event IDs
• Red Hat: Blocking and allowing applications by using fapolicyd

Related NHI Mgmt Group resources: Application Allowlisting Guide · App Control for Business (WDAC) · M1038 Execution Prevention · Code Signing Security Guide · MITRE D3FEND Guide