WDAC(Application Control): How to correctly validate WDAC Disabled:Flight Signing with a flight-signed user-mode DLL

Hello @Gagan Kumar

Your general test approach is reasonable, but I would separate policy validation from validation of that particular FlightTest.dll.

Disabled:Flight Signing is an App Control policy option that prevents binaries signed by Windows flight/preview signing authorities from being trusted. Microsoft also notes that this option is intended for organizations that want to trust released binaries rather than flight/preview-signed builds.

A few points about your test:

1. Verify that the intended policy is actually active first.

Before interpreting the DLL result, confirm the deployed policy and options on the Windows 11 test system. On supported Windows 11 versions, you can use CiTool.exe to enumerate/manage active App Control policies. Also check:

Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational

Event 3099 indicates that an App Control policy was loaded and includes information about its policy options.

This matters after modifying, recompiling, signing, and refreshing the policy because you want to confirm that the policy containing Disabled:Flight Signing is the one evaluating the test.

2. LoadLibrary() is a reasonable way to cause a user-mode DLL to be evaluated, provided UMCI is enabled.

Your policy has Enabled:UMCI, which causes App Control to validate user-mode executables and scripts in addition to kernel-mode binaries. The test harness and all required dependencies must be allowed first; otherwise, as you observed, execution stops before FlightTest.dll becomes the binary under test.

I would therefore explicitly allow/sign the test loader and its required runtime dependencies through normal policy rules, while not adding any allow rule for FlightTest.dll or its flight signer. That isolates the DLL as the item being evaluated.

3. Event 3077 is the primary enforcement signal to look for.

3076 = file would have been blocked under an Audit policy

3077 = file failed the enforced policy and was blocked

3089 = signature information associated with an audit/block event

You can correlate event 3089 with the corresponding 3076/3077 event using the Correlation ActivityID.

So if App Control rejects the DLL under your enforced policy, I would expect the investigation to start with the applicable block event and then correlate the 3089 signature event. I would not use VerificationError=24 alone as proof that Disabled:Flight Signing has been validated; the complete correlated Code Integrity events and signer information are more reliable.

4. The existing Microsoft Flight signer in AllowedSigners is an important finding.

If your policy explicitly allows the signer that authorizes the test DLL, that can undermine the isolation you're trying to achieve. Removing that signer, while ensuring your test harness remains independently allowed, makes for a much cleaner test.

5. Do not use the UUP Dump image/binary as the basis for a definitive Microsoft-supported result.

UUP Dump isn't a Microsoft distribution/support channel. Even if the binary's certificate chain appears to contain Microsoft Development/Flight certificates, that doesn't establish that Microsoft considers that particular extracted binary a supported reference artifact for testing this policy option.

For a reproducible Microsoft-supported validation, I would repeat the test using an official Windows Insider Preview build obtained through Microsoft's Windows Insider channels, then use a flight-signed component from that environment whose signer can be verified independently.

I haven't found Microsoft documentation that publishes a dedicated Disabled:Flight Signing test DLL or an official step-by-step test procedure. Therefore, I wouldn't claim that FlightTest.dll from UUP Dump is Microsoft's supported test binary.

As an additional sanity check, you could initially perform the isolated test in Audit mode. Microsoft recommends Audit mode when validating new App Control policies: a binary that would be rejected should generate 3076 without actually being blocked. Once you confirm the expected signer evaluation, move the same policy/test to enforcement and verify the corresponding block behavior.

If an officially sourced flight-signed binary still loads after you've confirmed the active policy, removed the relevant Flight signer from the allow rules, and independently allowed the test harness, capture the 3099, 3076/3077, and correlated 3089 events and raise that evidence with Microsoft Support for App Control engineering review.

References:

Understand App Control policy rules and file rules

Understanding App Control event IDs

CiTool technical reference

Use audit events to create App Control policy rules

Help make this community better for everyone: if this answer resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution.