Deploying Microsoft Defender for Endpoint: a 12-step rollout for an Australian mid-market tenant

Most Australian organisations that believe they have EDR have bought EDR. Those are different states. Microsoft Defender for Endpoint arrives with the licence, but nothing is watching anything until devices are onboarded, device groups exist, automation is set, and the protections that ship disabled have been turned on. The gap between entitlement and coverage is where the incident happens.

This is the sequence Frontrow uses for an Australian mid-market tenant, in the order the steps have to happen. Several of them are irreversible or expensive to reverse, and they are near the front deliberately. Work through it in order rather than starting with the part that feels most like security work.

Step 1 — Settle where the data will be stored, before provisioning

Microsoft stores and processes Defender for Endpoint data in data centres in the European Union, the United Kingdom, the United States, Australia, Switzerland, India or the United Arab Emirates. Which one applies is determined by the geolocation of the tenant as identified during provisioning, not by a setting an administrator picks later from a dropdown.

For an Australian organisation this is the step that answers the question a procurement questionnaire, an insurer or an APRA-regulated client will eventually ask in writing. It is far easier to establish the position at provisioning than to explain afterwards why endpoint telemetry from a Melbourne office is being processed offshore. Write the answer down at this step and keep the evidence with the tenant documentation.

Step 2 — Choose the onboarding method deliberately

There is more than one way to onboard a device and the choice determines how the next two years of the deployment feel. Pick on the basis of how the estate is managed today, not on which method is quickest to demonstrate.

• Microsoft Intune, where devices are already enrolled. This is the target state for most Australian mid-market estates and the only method that makes the endpoint security policies manageable at the same time.
• Microsoft Configuration Manager, for estates still running co-management or a traditional SOE. Workable, and it keeps the existing change process intact.
• Group Policy, for domain-joined devices with no modern management in place. It onboards devices fine; it leaves you configuring Defender through a second console forever.
• Local script, which Microsoft supports for up to 10 devices. This is a proof-of-concept tool, not a rollout method. Using it for a 200-device estate produces an estate nobody can offboard cleanly.
• VDI onboarding scripts for non-persistent virtual desktops, which need their own package so that recycled machines do not appear as hundreds of duplicate devices.

Step 3 — Resolve the incumbent antivirus before day one

Almost every tenant already runs something. Where a non-Microsoft antivirus is the active protection, Microsoft Defender Antivirus moves to passive mode. In passive mode Defender Antivirus is not the primary real-time protection, but the Defender for Endpoint sensor still reports, and EDR in block mode allows Defender to remediate malicious artefacts the incumbent product missed.

That gives you a legitimate coexistence period, and it is the right way to run a migration. What it is not is a destination. Two products both claiming real-time protection produce performance complaints, mutual exclusions, and an incident where each vendor's console holds half the story. Decide the end state at the start of the project and put a date on the removal of the incumbent, including who owns the licence cancellation.

1. 1Install and onboard Defender for Endpoint while the incumbent is still active; confirm Defender Antivirus reports passive mode rather than disabled.
2. 2Enable EDR in block mode so remediation is available during the overlap.
3. 3Run both for a defined window — two to four weeks is usually enough to satisfy the business — with the incumbent still the enforcing product.
4. 4Remove the incumbent, ring by ring, and confirm Defender Antivirus transitions to active mode on each ring before moving to the next.
5. 5Strip the exclusions inherited from the old product rather than porting them across. Inherited exclusion lists are the most common way an otherwise good deployment ends up with a blind spot nobody chose.

Step 4 — Build device groups before you onboard devices

Device groups are not a tidiness feature. They determine which automation level applies to a device, and which analysts can see and act on it under role-based access control. Devices onboarded before the groups exist land in the default group, and retro-fitting the structure across a live estate is considerably more work than defining it first.

• Group by how you would respond, not by how the org chart is drawn. Servers, executives and finance, general staff, kiosks and shared devices, and anything belonging to a third party are five genuinely different response postures.
• Device groups are evaluated in rank order and a device lands in the first group whose rule it matches, so the narrow groups have to sit above the broad ones. A catch-all sitting at rank 1 makes every group beneath it decorative.
• Set the role-based access scope at the same time. If a managed service provider or an offshore team has console access, the group structure is what limits what they can isolate.
• Keep the count small. A structure with forty groups is a structure nobody maintains, and the automation level on a group nobody maintains is the one that surprises you.

Step 5 — Onboard a pilot ring, not the estate

Between 10 and 50 devices, chosen to be representative rather than convenient. That means at least one machine from each meaningfully different build: the standard laptop, the finance workstation with the legacy line-of-business application, the design or engineering machine with heavy local tooling, and a device belonging to someone senior enough that a problem gets reported rather than tolerated.

The pilot is not there to prove Defender works. It is there to find the two or three applications in this specific business that will generate noise, and to find them while the population is small enough to fix quietly.

Step 6 — Verify that onboarding actually worked

A device appearing in the device inventory is not proof that the sensor is healthy. Two states matter and both are visible in the portal: a device that has stopped communicating, and a device that is communicating but misconfigured. The second is the dangerous one, because it looks like coverage on every report.

1. 1Confirm each pilot device shows an active sensor health state rather than inactive or misconfigured.
2. 2Run Microsoft's detection test on at least one device per build so you have seen an alert arrive end to end rather than assuming the pipeline works.
3. 3Check the onboarding status of devices that never appeared. Proxy configuration and missing connectivity to the Defender service URLs account for most of them, and Microsoft publishes a client analyser for exactly this.
4. 4Reconcile the onboarded count against the actual device count from Intune or Active Directory. The difference is your real coverage gap, and it is almost never zero.
5. 5Repeat the reconciliation monthly. Coverage decays as new devices are built, and an EDR rollout that is not reconciled becomes a partial rollout within a quarter.

Step 7 — Set the automation level on purpose

Automated investigation and response examines alerts, decides what the verdict is, and either remediates or waits for a human. The automation level is set per device group, which is the practical reason step 4 came first.

• Full automation remediates automatically. For general staff devices this is the right answer for most Australian mid-market organisations, because the alternative is a queue nobody reads at 9pm on a Friday.
• Semi-automatic levels hold remediation for approval, either for all folders or for core folders only. Reasonable for servers and for a small number of high-consequence devices where an automatic action would be disruptive.
• No automated response is a decision to do the work manually. It is defensible for a specialised device group; as a tenant-wide setting it means the product's best feature is switched off.
• Whatever you choose, someone has to review the action centre. Automated remediations are recorded there, they can be undone, and a tenant where nobody has opened it has automation without oversight.

Step 8 — Turn on the protections that do not turn themselves on

This is where most deployments stop early, because the console already looks busy. The onboarding gets the sensor reporting; the preventive controls are separate and several are not enabled by default.

• Attack surface reduction rules. The highest-leverage setting in the product and the one most consistently left unconfigured. Roll them out in audit mode first — we have ranked all of them for Australian mid-market tenants in a separate guide.
• Network protection, which blocks connections to malicious domains and IP addresses at the endpoint. Not enabled by default. Deploy in audit mode, review, then block.
• Web content filtering, which depends on network protection being enabled and gives you category-level blocking without a separate proxy.
• Device control, if removable media is a live risk in the environment. Australian organisations in professional services and healthcare tend to discover this one during an incident rather than before it.
• Tamper protection. Confirm it is on for the tenant rather than assuming, because it is what stops an attacker with local administrator rights from simply switching the sensor off.

Step 9 — Onboard the servers separately

Servers are a different onboarding path with a different licensing position, and they are where the consequential intrusions actually land. A tenant with 100% laptop coverage and no server coverage has instrumented the noise and left the crown jewels dark.

Work through the server estate explicitly: domain controllers, file servers, the application servers running the line-of-business systems, and anything still running an operating system past end of support. That last category is the one to raise with the business early, because the answer is usually a project rather than a checkbox.

Step 10 — Route the alerts to a human who is actually awake

The incident queue in the Defender portal groups related alerts into incidents, which is what makes triage tractable. It is also a screen that only helps if someone is looking at it.

1. 1Configure email notifications by device group and by severity, so that high-severity alerts on servers reach a different distribution than informational alerts on kiosks.
2. 2Send them to a monitored mailbox or a ticketing queue, never to an individual. The individual will be on leave during the incident.
3. 3Decide and write down the out-of-hours position. Either someone is on call, or a provider is, or the organisation has consciously accepted that a Saturday-morning ransomware alert waits until Monday. All three are decisions; only the unwritten version is negligence.
4. 4Agree the escalation threshold with the business before the first real alert, including who can authorise isolating a device that belongs to an executive.

Step 11 — Enable response actions before you need them

Device isolation, application restriction, antivirus scan on demand and live response are the actions that turn detection into containment. Live response in particular has to be enabled at the tenant level and permitted through role-based access control, and the roles have to be assigned to real people.

Test each of them once, on a test device, while nothing is happening. An organisation that first attempts device isolation during an incident discovers that the person with the console rights left, or that nobody knows whether isolation will also cut the tool they are using to investigate. Twenty minutes of rehearsal buys back hours at the worst possible time.

Step 12 — Baseline the score and set a review cadence

Record the Microsoft Secure Score for devices on the day the rollout completes, and the onboarded device count against the true device count. Those two numbers are the before picture, and without them the next twelve months of work is unevidenced.

Then set the cadence: monthly coverage reconciliation, quarterly review of exclusions and attack surface reduction exceptions, and an annual re-test of the response actions. Defender for Endpoint is not a deployment with an end date; it is a control with an operating rhythm, and organisations that treat it as a project are the ones whose coverage quietly falls to 70%.

The five traps that stall Australian rollouts

1. 1Porting the old antivirus exclusion list across wholesale. Every exclusion is a hole; inherited holes are ones nobody in the business chose or can justify. Rebuild the list from observed need during the pilot.
2. 2Onboarding laptops and declaring victory while servers, virtual desktops and the two machines in the warehouse remain uninstrumented. Coverage is measured against the real device count or it is not measured.
3. 3Leaving every rule and every rollout in audit mode indefinitely. Audit mode is a phase with an end date. Tenants that never leave it have an excellent record of the attacks that succeeded.
4. 4Building device groups after onboarding, so everything sits in the default group with a single automation level and no role-based scoping. Fixing it later means re-tagging a live estate.
5. 5Nobody owning the console. The single strongest predictor of whether an EDR deployment produces value is whether a named person opens the incident queue on a normal Tuesday.

How this lines up against the Essential Eight

Defender for Endpoint is not an Essential Eight control in itself — the eight mitigation strategies in ASD's model are about application control, patching, macro settings, application hardening, administrative privileges, multi-factor authentication and backups. What a properly deployed Defender for Endpoint gives you is the evidence and enforcement layer underneath several of them: application control and hardening through attack surface reduction rules, patch visibility through vulnerability management, and the telemetry that makes the maturity assessment something other than an assertion.

It also matters for the obligation most Australian organisations actually face. Under the Notifiable Data Breaches scheme, an entity that suspects an eligible data breach must carry out a reasonable and expeditious assessment. Endpoint telemetry is frequently the only thing that establishes what an attacker did and did not reach — which is the difference between a scoped notification and a precautionary one covering every individual in the database.