← Engineering journal

Project 01 · Endpoint protection

Engineering Microsoft Defender on a Small Budget

A deployment story about making existing tools useful, resolving conflicts, and checking the protection on the device.

  • Defender
  • Intune
  • PowerShell
  • Verification

The starting point

I needed more than an assigned policy.

I was building stronger endpoint protection in an environment with limited resources. Buying another product was not my starting point. I focused on the Microsoft capabilities already available and the work needed to turn them into functioning controls.

The work involved Defender for Endpoint onboarding, Intune configuration, attack surface reduction policies, Windows hardening, and PowerShell troubleshooting. Those pieces needed to work together while everyday applications remained usable.

01 · Establish the real state

Look at the device, then compare.

I checked endpoint onboarding and Defender’s operating state rather than treating device visibility as proof that every protection was enforcing. I compared what the management tools showed with what was happening locally.

PowerShell helped me inspect the antivirus state and configured preferences. Defender detections and endpoint telemetry provided additional evidence. Each answered a different question: was the device reporting, was antivirus active, and was the intended control in effect?

02 · Resolve the dependency

The existing antivirus was part of the problem.

I found that another installed security product was interfering with the intended Defender configuration. That made the migration and cleanup part of the engineering work, rather than a separate housekeeping task.

I worked through removal of the old product and its remaining components, then checked Defender again. The practical lesson was to verify the resulting protection state instead of assuming that an uninstall message meant the transition was complete.

Microsoft documents that Defender Antivirus can operate in different modes depending on the operating system and other security software. ASR rules require Defender Antivirus in active mode. This distinction matters when interpreting an onboarded device or a detection.

03 · Stage the controls

Use audit and block deliberately.

I built an ASR policy with a mixture of Audit and Block settings. The configuration included blocking selected credential-theft, ransomware-related, and script behaviors, while other rules remained in Audit for evaluation.

Audit mode records activity without blocking it. That gave me a way to investigate potential application impact before expanding enforcement. I also used pilot groups for Windows hardening so changes could be evaluated on a smaller set of devices.

Policy intent and effective enforcement are separate. An ASR rule configured for Block still needs its prerequisites and an effective deployment. I do not describe every endpoint or every ASR rule as fully enforced.

04 · Verify and keep working

Close the loop with evidence.

I checked reporting, endpoint state, policy settings, and available detections as I worked through the deployment. When a result did not match the intended configuration, I investigated the dependency or conflict instead of adding another policy and hoping it would win.

This became a repeated process: inspect, configure, pilot, verify, adjust. Some controls were implemented and checked; others needed more cleanup or evaluation. The work continues as the environment changes.

The budget

Small budget. Real engineering effort.

The approach was to use available licensing, Windows capabilities, Intune, Defender, and PowerShell before asking for another product. Automation and reusable policy configuration helped reduce repeated manual work.

How I approached the cost
ResourceHow it contributed
Existing Microsoft licensingA foundation to build on. Subscription costs and feature entitlements still matter.
Windows & PowerShellInspection, troubleshooting, and automation without purchasing a separate scripting product.
Intune policies & pilot groupsRepeatable configuration and a controlled way to evaluate changes within available licensing.
Time & engineering effortResearch, cleanup, testing, verification, and ongoing maintenance. These are real costs.
Additional spending & savingsNo itemized total or verified savings figure is published here.

The value of the work was in turning available capabilities into usable protection. A small purchasing budget did not remove the need to understand, test, and maintain what I built.

What I learned

The configuration is only part of the build.

  • Onboarding, antivirus mode, and control enforcement need separate checks.
  • Existing software can prevent a new control from working as intended.
  • Staged deployment makes application impact easier to investigate.
  • Audit findings and block enforcement describe different outcomes.
  • A limited budget makes good prioritization and verification especially valuable.

Technical references

Read the product guidance.

This article describes my engineering approach. Requirements vary by operating system, licensing, and product version.