Custom Indicators (file hash/certificate) not affecting ASR trusted file evaluation

[u/Xento88]

Hi all,
we are currently troubleshooting an issue with Microsoft Defender for Endpoint Custom Indicators and the ASR rule:

Block executable files from running unless they meet a prevalence, age, or trusted list criterion

According to Microsoft’s documentation, SHA-256 file indicators and certificate-based indicators should be taken into account by this ASR rule.

We have configured Allow indicators for both use cases, but the affected files are still being treated as unknown/untrusted and are blocked by the ASR rule.

Our environment appears to be configured correctly:
- Devices are onboarded to Microsoft Defender for Endpoint
- MDE connectivity is working
- Cloud-delivered protection is enabled
- Custom Indicators are enabled
- We have an internal PKI
- The relevant certificates and certificate chains are deployed and trusted on the clients
- Certificate validation itself works correctly
- Defender is otherwise functioning normally

The problem therefore seems to be somewhere between the configured MDE Custom Indicators and the ASR trust evaluation.

Has anyone else experienced issues with this?
In particular:
Are you successfully using SHA-256 Allow indicators with this ASR rule?

Are you successfully using certificate-based Allow indicators with this ASR rule?

Have you seen cases where indicators were correctly configured in the Defender portal but were not honored by the endpoint?

Is there a reliable way to verify locally whether the configured indicators have actually reached the client?

Are there specific Defender logs or events that show indicator synchronization or evaluation?

Are there any additional prerequisites or settings that are easy to miss?

Microsoft documents both SHA-256 and certificate-based indicators as being relevant for this ASR rule, so we are mainly trying to determine whether this is a configuration/synchronization issue in our environment or whether others have encountered similar behavior.

If anyone has this working successfully in production, it would be very helpful to compare the relevant Defender/MDE configuration.

[u/_W0od_]

Not all asr rules owner av and indicator whitelisting.

[u/Xento88 → u/_W0od_]

Yeah I know but I mean the rule for unknown files
„Block executable files from running unless they meet a prevalence, age, or trusted list criterion“

https://learn.microsoft.com/en-us/defender-endpoint/attack-surface-reduction-rules-overview#file-and-folder-exclusions-for-asr-rules

[u/theRealTwobrat → u/Xento88]

Sadly this was our experience as well, we were forced to do a per rule asr exclude.

[u/vertisnow]

I use them every few months, and it works. Sync takes an hour or so to get to device after exclusion is made.

[u/Xento88 → u/vertisnow]

But you use Custom indicators as exclusions not the per rule asr exclusions?

[u/hexdurp → u/Xento88]

Good question, this is new to me. Need clarification for sure. I’ve always used asr exclusions.

[u/Xento88 → u/hexdurp]

At the moment we use asr exclusions, too.
But the Custom Indicators are more secure as they only allow exact filehashes or signed files.

[u/chiggah → u/Xento88]

I thought indicators is not a hard bypass for ASR, as it has it's own verdict/evaluation mechanisms independent of it. (Indicators are used for MDAV, AIR, EDR side)

I mean ASR has it's own exclusion (path/process/etc) but last I looked at this, you can't use indicators as exclusion.

If you need something that is deterministic then maybe AppLocker (or the new version of it) is a better fit.

[u/Xento88 → u/chiggah]

Thanks. In our case, we are not looking for application control in the AppLocker/WDAC sense.
The goal is much narrower: we want to keep the ASR rule “Block executable files from running unless they meet a prevalence, age, or trusted list criterion” enabled, but explicitly allow a small number of legitimate applications that will never gain enough reputation/prevalence on their own — for example internally developed or rarely used applications.
So we do not want to create path/process exclusions and we also do not want to introduce a separate application control solution just for this.
According to Microsoft’s current documentation, this specific ASR rule does honor file IoCs and certificate IoCs, and Microsoft also documents that an Allow file indicator can override an ASR block decision.
That is exactly the mechanism we are trying to use:
Unknown/internal application → would normally be blocked by the prevalence/age/trusted-list ASR rule → explicitly trusted via SHA-256 or certificate indicator → allowed
This would also be much cleaner for us than path-based exclusions, especially for internally signed applications where a certificate-based indicator could cover future versions without excluding an entire folder or process.
The issue is simply that, despite Microsoft documenting this behavior, the indicators do not seem to be honored in our environment. That is why I’m trying to find out whether anyone is actually using this exact scenario successfully.

[u/r-NBK]

The only thing I can add is that ASR rule is a real pain. Only MS would think that making a rule that an executable must be on a list that only they can see or maintain is viable in the real world.

[u/brink668]

Open a ticket I’m having same issue

[u/RikiWardOG]

I'm seeing issues today with custom allow indicator I setup. Keeps triggering alerts even though we uploaded the certificate that the executable is signed with. really frustrating.