Copilot, Application Control and Patch Management: Satisfying Essential Eight ML2 in Australia

Microsoft 365 Copilot introduces plugin and SaaS governance risks adjacent to the Essential Eight application control and patching strategies. The formal controls remain focused on their defined endpoint, application and online-service scope. This article provides an EDUC4TE defence-in-depth interpretation for Copilot alongside the controls that must still be assessed directly.

Why These Two Controls Matter Most for Copilot

The ACSC Essential Eight Maturity Model assigns each control a maturity level based on the effort required and the sophistication of the adversary the control defends against. At Maturity Level 2, application control and patch management are both assessed against a capable adversary using commodity and some targeted techniques.

Copilot changes the risk profile for both controls:

Application control: The Essential Eight application control mitigation is written for executables, libraries, scripts and installers running on endpoints, so Copilot plugins fall outside its literal scope. EDUC4TE's position is that the same principle should extend to them: every Copilot plugin runs code inside your Microsoft 365 environment, accessing your organisation's data through Microsoft Graph, calling external APIs, and processing information from employee interactions. Without governance, a malicious or compromised plugin represents a significant data exfiltration vector — one that traditional endpoint application control never sees, because it executes in the cloud.

Patch management: Copilot's attack surface extends to every third-party plugin in your environment. Each plugin is an independently maintained software product with its own vulnerability profile. Your SaaS-oriented patch management process must extend to cover these plugins.

Start with the free Copilot Essential Eight Alignment Assessment to establish your scored baseline across both controls before investing in remediation. The Essential Eight Copilot mapping pillar guide provides the strategic rationale for the controls covered here.

Part 1: Application Control for Copilot Plugins

Understanding the Scope

Essential Eight ML2 application control requires that only approved applications can execute on endpoints. Applying the same principle to Copilot, the plugins and apps worth governing include:

• Microsoft first-party Copilot extensions (approved by default as part of your Microsoft 365 licence agreement)
• Third-party plugins from Microsoft AppSource
• Line-of-business Copilot plugins developed internally or by vendors
• Microsoft Teams apps that have Copilot integration capabilities

Step 1: Audit Your Current Plugin State

Before configuring controls, establish what is currently deployed.

1. Sign in to the Microsoft 365 admin centre at admin.microsoft.com with Global Administrator credentials.
2. Navigate to Settings > Integrated apps.
3. Select Deployed apps and export the list. This is your current application state.
4. Navigate to Available apps to see what users can self-install — this represents your uncontrolled scope.
5. Run the following Microsoft Graph PowerShell command to enumerate all apps with Copilot integration capabilities in your tenant:

Connect-MgGraph -Scopes "Application.Read.All"
# OData lambda operators are lowercase ('any'/'all'). There is no documented, reliable
# service principal tag that identifies Copilot plugins, so treat the filter below as
# illustrative: confirm the tag values present in your own tenant, or enumerate service
# principals and review them, before depending on it.
$apps = Get-MgServicePrincipal -Filter "tags/any(t: t eq 'CopilotPlugin')" -All
$apps | Select-Object DisplayName, AppId, PublisherName | Export-Csv -Path "copilot-plugins-audit.csv" -NoTypeInformation

This gives you a complete view of all Copilot-enabled applications, including those registered but not yet deployed.

Step 2: Configure Block-by-Default for User-Deployed Apps

1. In the Microsoft 365 admin centre, navigate to Settings > Org settings > Services.
2. Select User consent to apps (or navigate to Entra ID > Enterprise Applications > User settings).
3. Set Users can consent to apps accessing company data on their behalf to No.
4. Set Users can consent to apps accessing company data for the groups they own to No.
5. Return to Integrated apps and verify the default state for new app deployment is set to require admin approval.

This ensures no new Copilot plugins can be enabled by users without IT review and approval.

Step 3: Build Your Approved Plugin List

For each plugin you consider approving, conduct a security assessment covering:

Publisher assessment:

• Is the publisher a verified Microsoft partner?
• Does the publisher have an active security vulnerability disclosure programme?
• Is the publisher subject to Australian data residency obligations if they process your data?

Permission scope assessment:

• What Microsoft Graph permissions does the plugin request? Catalogue these explicitly.
• Does the plugin request delegated or application permissions? Application permissions are higher risk as they operate without a specific user context.
• Does the plugin require access to Mail.ReadWrite, Files.ReadWrite.All, or other high-privilege scopes? These warrant additional scrutiny.

Data flow assessment:

• Does the plugin send data to external endpoints? If yes, to which jurisdictions?
• Is the data processing covered by your existing supplier agreement or does a new data processing agreement need to be executed?
• Does the plugin's data handling comply with the Australian Privacy Principles if it processes personal information?

Document each assessment decision in your IT service management system. The decision record should include: plugin name, version assessed, assessment date, assessor, permissions reviewed, approval decision, and review-by date.

Step 4: Deploy Approved Plugins Centrally

Once a plugin is approved, deploy it through the admin centre rather than allowing users to install it themselves:

1. In Integrated apps, select Deploy app.
2. Choose the approved plugin from the catalogue.
3. Select Specific users/groups for the assignment scope — deploy only to users with a legitimate business need, not organisation-wide by default.
4. For plugins with elevated permissions, require an additional approval step in your ITSM system before deployment.

Step 5: Implement Ongoing Monitoring

Application control is not a one-time configuration — it requires ongoing monitoring to detect violations.

Configure Microsoft Purview alerts for Copilot plugin activity:

1. Navigate to the Microsoft Purview compliance portal.
2. Select Audit > Search and search for Copilot and connected-app activity. Confirm the exact record types and operation names available in your tenant, as these change over time.
3. Configure an alert policy to notify your security team when a plugin that is not in your approved list generates activity — this may indicate a policy bypass or an app registered in your tenant through an indirect pathway.
4. Review Copilot and integrated-app usage in the Microsoft 365 admin centre weekly (the exact report names vary and change over time). Any plugin generating interactions that is not in your approved list should be investigated and blocked immediately.

Part 2: Patch Management for Copilot

Understanding Your Shared Responsibility

Under Essential Eight ML2, internet-facing services should generally be patched within two weeks of a vulnerability being identified, shortened to 48 hours when a working exploit exists. Microsoft handles platform-level patching for Microsoft 365 Copilot. Your obligation covers:

• Tracking and responding to Microsoft security advisories that require customer configuration action
• Patching third-party Copilot plugins where vendor updates are available
• Ensuring the endpoint devices used to access Copilot meet your OS and application patch requirements

Step 1: Configure Your Advisory Subscription

1. In the Microsoft 365 admin centre, navigate to Health > Message Centre.
2. Configure email preferences to send all security-related messages to your security team's shared inbox immediately (not as a weekly digest).
3. Subscribe to the Microsoft Security Response Centre (MSRC) security advisory RSS feed at msrc.microsoft.com — filter for Microsoft 365 and add "Copilot" as a keyword alert.
4. Subscribe to ACSC ASD alerts at cyber.gov.au/alerts-advisories to capture any ACSC-specific advisories related to Microsoft 365 or AI platform vulnerabilities.
5. For each third-party plugin in your approved list, subscribe to the vendor's security advisory channel.

Step 2: Document Your Advisory Response Process

The process must be documented before you need to use it — an undocumented process is not auditable.

Your Copilot patch management process document should define:

• Advisory identification: Who monitors which advisory sources, and at what frequency?
• Triage: Within 24 hours of receiving an advisory (EDUC4TE's recommended service standard, not an ACSC timeframe), who assesses whether it affects your Copilot deployment and at what severity?
• Response: ACSC's window for internet-facing services is generally two weeks, shortened to 48 hours when a working exploit exists. Who is accountable for initiating the response within the applicable window?
• Configuration change management: Advisory-driven configuration changes must be logged in your ITSM system as emergency or expedited changes with the advisory reference included.
• Escalation: If the applicable patch window cannot be met, what compensating controls are implemented, and who approves the exception?

A documented process is a compliance artefact. Store it in your security policy repository and reference it in your Essential Eight evidence pack.

Step 3: Third-Party Plugin Patch Management

Third-party plugins require a different process from platform-level patches because plugin updates are managed through the Integrated Apps catalogue rather than automatically applied.

1. Configure a monthly review task in your ITSM system to check for available updates for all approved Copilot plugins in the Integrated Apps catalogue.
2. When a plugin update is available, assess the update's changelog and permission changes before deploying — a plugin update that requests additional permissions requires a re-assessment before deployment.
3. When a plugin vendor publishes a security advisory, classify it using the CVSS score and apply your standard patch timelines. The tiers below are EDUC4TE's recommended service standard rather than ACSC timeframes: critical (CVSS 9.0 or above) within 48 hours, high (CVSS 7.0-8.9) within two weeks, medium within 30 days.
4. If a critical plugin vulnerability cannot be patched within 48 hours, disable the plugin immediately via the Integrated Apps admin centre and document the disable action.

The following PowerShell command disables a specific plugin quickly during an incident response scenario:

Connect-MgGraph -Scopes "Application.ReadWrite.All"
# Retrieve the service principal for the plugin by display name
$plugin = Get-MgServicePrincipal -Filter "displayName eq 'PluginNameHere'"
# Disable the service principal to block all access
Update-MgServicePrincipal -ServicePrincipalId $plugin.Id -AccountEnabled:$false

Replace "PluginNameHere" with the exact display name from your approved plugin list. Document the command execution time in your incident record.

Step 4: Device Compliance as a Patch Enforcement Gate

The most operationally efficient way to enforce OS and application patching as a condition of Copilot access is through Entra ID Conditional Access:

1. In Entra ID admin centre, navigate to Protection > Conditional Access.
2. Create a policy named "Require compliant device for Copilot access".
3. Assign to: All users (or your Copilot licence security group).
4. Target resource: Microsoft Copilot (search for the Copilot cloud application in your tenant).
5. Access controls > Grant: Require device to be marked as compliant.
6. Ensure your Intune compliance policies for Windows, macOS, iOS, and Android all include an OS patch currency requirement (for example, requiring the device to be within 30 days of the latest OS release).

This configuration means any device that falls out of patch compliance automatically loses Copilot access through the Conditional Access enforcement, without requiring manual intervention.

Building the Evidence Pack for These Two Controls

The following evidence helps demonstrate Copilot governance, but it is not a prescribed Essential Eight ML2 evidence list because the model does not define a Copilot-specific control. Prepare it alongside the formal endpoint and application evidence for your assessment:

Application control evidence:

• Exported approved plugin list with assessment records (date, assessor, permissions reviewed, decision)
• Screenshot of Integrated Apps admin settings showing user consent blocked
• Purview audit report showing no unapproved plugin activity in the review period
• Block action records for any plugins identified as unapproved and subsequently disabled

Patch management evidence:

• Advisory subscription confirmation (Message Centre, MSRC, ACSC)
• Advisory response log for the past 12 months — every advisory reviewed, with assessment date and response action
• Change records for any configuration changes made in response to security advisories, with timestamps demonstrating compliance with the applicable patch window
• Third-party plugin update records from monthly review tasks

The free Copilot Essential Eight Alignment Assessment generates a structured gap report with specific questions that map directly to the evidence categories above. Run it before your next audit preparation cycle to identify which evidence categories have gaps.

What Maturity Level 3 Adds

If your organisation is targeting ML3 or has elevated security obligations, strengthen the Copilot governance layer alongside the formal ML3 endpoint controls:

• Application control applied to all endpoints without exception (no legacy device carve-outs)
• Apply the formal Essential Eight patching timeframes to the systems and applications that fall within their defined scope; do not assume a Copilot plugin is an ACSC "online service"
• Plugin allowlisting enforced through a technically enforced control, not just an administrative policy

These Copilot configurations are defence-in-depth. ML3 still requires the formal endpoint application-control and patching controls to be assessed on their own terms; plugin governance can complement that implementation.