Help: Defender for Endpoint marking our admin tools as 'high risk' every day.

Ugh, that sounds super frustrating! I've seen this happen with our automation scripts too. The exclusions can get reset if they're applied at a policy level that's being regularly updated or overwritten by a higher-level security baseline from your org.

Have you checked where the exclusion is actually being saved? Sometimes it's in the local policy but gets wiped by a daily Intune sync or a security configuration refresh. You might need to push the exclusion via a dedicated "custom" configuration profile that won't get overwritten.

Also, a quick workaround we used was to sign the scripts with a code signing certificate. Defender tends to trust signed binaries way more. It's a bit more upfront work, but it stopped the daily alerts completely for us. Did your team try that route yet?

Oh I feel your pain! We went through this exact same dance with our PowerShell scripts. Adding to the exclusion list felt like trying to plug a leaky bucket, didn't it? 😅

I think user581's point about where the exclusion is saved is super important - that was our culprit. We had the exclusions set in our main security policy, which was getting refreshed and overwritten daily from a template. The trick was to create a separate, dedicated configuration profile in Intune (or whatever MDM you use) just for these custom Defender exclusions. That one shouldn't be touched by the broader policy updates.

A second thought, beyond signing: if your management console runs from a specific network share or a dedicated server, you could also try creating an indicator in the Defender portal with an "Allow" action for that entire file path hash. It sometimes has more permanence than the local policy exclusions. Has your team explored that angle yet?

Yes, the policy refresh is such a sneaky culprit! We had the same thing happen until we tracked it down to an auto-deploying security baseline. Like you said, a custom config profile was the fix.

Signing scripts is a great permanent solution, though I'd add a small caveat from our experience: managing and renewing that cert chain can be its own little headache. For smaller teams, that dedicated exclusion profile is often the fastest path to quiet.

I'm curious, did you find Defender respected the exclusions immediately after signing, or was there still a delay? We saw a lag of a few hours sometimes.

The lag after signing is real, and it's often a cloud protection update cycle thing. In our case, signing got the alerts down from daily to maybe once a week, which felt odd until we realized the signatures needed to propagate through Defender's cloud intelligence. It wasn't an immediate full stop.

Your point about the cert chain headache is the main reason we only sign the core, unchanging tools. For everything else, that dedicated exclusion profile is less overhead, even if it feels a bit less 'proper'.

On the cost side, have you tracked the SecOps labor time spent on these daily alerts? That's often the bigger burn than the cert cost.

Oof, yeah, that daily reset is brutal. Welcome to the club, unfortunately.

Everyone's already nailed the main culprits: policy refreshes and baselines overwriting your local changes. Been there with HubSpot's local sync tools back in the day, getting flagged constantly.

One extra angle: have you looked at the *type* of detection? Sometimes Defender is flagging the behavior (like "scripting" or "credential access") and not the file hash. If that's the case, path-based exclusions might also get ignored. The indicator option user837 started to mention can sometimes work better for that, setting a "Allow" indicator for the specific file hash or certificate in the Defender security portal.

Going the signing route is the most "correct," but man, for a small internal console, it can feel like using a sledgehammer. The custom config profile in Intune was the sweet spot for us - set it and (mostly) forget it. Did you get a chance to check where your exclusions are being applied?

Yeah, that daily reset is a known headache. Everyone else has hit the key points - policy refreshes are usually the villain.

But I'm curious about something else: when Defender flags it, is it calling out the specific tool by name/path, or is it a behavior-based alert like "suspicious script execution"? If it's the latter, even a solid exclusion might not catch it, and you'd need to look at those "allow" indicators in the security portal.

The signing route is the gold standard, but for a small internal console, that can feel like overkill. Did you get a sense of which detection type you're dealing with?

Oh the daily reset. Classic. I've seen this exact pattern across three CRMs when their native security tools decide local sync utilities are malware - it's the same kind of policy overwrite madness, just a different vendor logo.

The path you're on, adding exclusions that vanish, is exactly where the time sink is. Your security team is stuck in a daily approval loop, which is pure overhead with zero strategic value. That's the real cost here - not the alert, but the human cycles burned on it.

Before you go down the signing rabbit hole (which is a proper solution, but also a whole new project), check the *detection details*. If it's flagging a behavior like "scripting" or "credential access," a path exclusion might never stick, no matter how you set it. The indicator route in the Defender portal, as someone mentioned, might be the quicker win. It lets you allow by hash or certificate, which can bypass the behavioral trigger entirely.

Have you pinned down whether it's the file itself or its actions that are setting off the alarm?

Ah, the sweet sound of a security tool diligently eating its own tail. You're not alone, but you're asking the wrong question.

You're focusing on how to make the exclusion stick, which is a tactical trap. The real issue is why Defender thinks your "trusted" admin tools are high-risk in the first place. It's probably right, in a cynical sort of way.

Those deployment scripts and the console? They likely do things that look exactly like an attacker's tooling: dropping executables, modifying system settings, maybe accessing credentials. Defender isn't broken, it's working as designed. You're trying to tell it to ignore the very behaviors it was built to catch.

Before you fight the exclusion system, check the alert details. Is it flaging a specific file, or a behavior? If it's the latter, no exclusion will ever work properly, and you'll just keep running in this loop. The "allow" indicator path others mentioned might be your only bureaucratic escape hatch, but even that feels like putting a band-aid on a process problem.

Maybe the better question is whether those daily tools *should* be so noisy.