ACSC Essential Eight

Application control is implemented on workstations. Application control is applied to user profiles and temporary folders used by operating systems, web browsers and email clients. Application control restricts the execution of executables, software libraries, scripts, installers, compiled HTML, HTML applications and control panel applets to an organisation-approved set.

• Application control product configuration export (Microsoft AppLocker XML, Windows Defender Application Control policy XML, Carbon Black or AirLock ruleset)
• List of workstations in scope, cross-referenced to asset inventory and CMDB to evidence full coverage
• GPO or MDM policy showing application control is in Enforce mode (not Audit Only) on workstations
• Sample of allowed and blocked events from workstation Event Viewer (Microsoft-Windows-AppLocker/EXE and DLL, MSI and Script channels)
• Documented approved application list with owner, last review date and approval workflow
• Screenshot or export showing rules covering user profiles (C:\Users, AppData) and temporary folders (Temp, Downloads)
• Evidence that rule scope covers all required file types: .exe, .dll, .ps1, .vbs, .js, .msi, .chm, .hta, .cpl
• Exception register listing approved exceptions, owner, business justification, expiry and compensating control

• Application control deployed in Audit Only mode rather than Enforce
• Coverage missing scripts (.ps1, .vbs, .js), MSI installers, HTA or CPL files
• User profile and temporary folder paths not enforced, allowing LOLBins from AppData
• No formal approved application list, rules built ad hoc by IT
• Exceptions granted without expiry or compensating control
• Allowed and blocked events not collected centrally, only available on the endpoint

All ML1 requirements plus: Application control is implemented on internet-facing servers. Application control is applied to all locations other than user profiles and temporary folders used by operating systems, web browsers and email clients. Microsoft's recommended application blocklist is implemented. Application control rulesets are validated on an annual or more frequent basis. Allowed and blocked application control events are centrally logged. Event logs are protected from unauthorised modification and deletion. Event logs from internet-facing servers are analysed in a timely manner to detect cyber security events. Cyber security events are analysed in a timely manner to identify cyber security incidents. Cyber security incidents are reported to the CISO and to ASD as soon as possible after they occur or are discovered. Following identification of a cyber security incident, the cy

• Application control policy export covering internet-facing servers (web, mail, VPN, RDS gateway) with mode set to Enforce
• Inventory of internet-facing servers cross-referenced to enforcement coverage
• Evidence that Microsoft's recommended block rules (https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/applications-that-can-bypass-appcontrol) are imported into the ruleset
• Annual ruleset review record: date, reviewer, list of changes, sign-off
• SIEM dashboard or query showing AppLocker / WDAC events ingested from workstations and internet-facing servers
• Log retention configuration showing logs are write-once or otherwise protected from modification and deletion
• Incident response plan with a defined Essential Eight trigger and last-tested date
• Sample tickets showing an application control event was triaged from SIEM to incident closure with ASD report (if reportable)

• Internet-facing servers not in scope or in Audit Only mode
• Microsoft recommended blocklist not implemented or out of date
• Annual ruleset review not performed, rules drift uncontrolled
• Logs collected centrally but not protected from deletion by administrators
• Incidents reported to internal CISO but ASD notification step omitted
• Internet-facing server logs sent but not actively analysed (no use cases, no alerts)

All ML2 requirements plus: Application control is implemented on non-internet-facing servers. Application control restricts the execution of drivers to an organisation-approved set. Microsoft's vulnerable driver blocklist is implemented. Event logs from non-internet-facing servers and from workstations are analysed in a timely manner to detect cyber security events.

• Application control enforcement evidence for non-internet-facing servers (file, print, AD, database) with mode set to Enforce
• Windows Defender Application Control policy or equivalent showing driver control restrictions to an approved driver set
• Microsoft vulnerable driver blocklist policy imported and active (HVCI / Smart App Control or WDAC driver blocklist)
• SIEM evidence showing event analysis use cases against non-internet-facing server logs and workstation logs
• Driver inventory with vendor, signature status and approval status
• Documented Secure Admin Workstation or jump path used to deploy and update WDAC policies
• Last validation of driver allowlist and Microsoft vulnerable driver blocklist against current Microsoft published version
• End-to-end incident sample: workstation AppLocker block to SIEM to triage to IR plan to ASD report

• Non-internet-facing servers excluded as too disruptive to enforce
• Driver allowlist not implemented, BYOVD attack path remains
• Microsoft vulnerable driver blocklist not enabled or version out of date
• Workstation events ingested into SIEM but no detection use cases configured
• WDAC policies signed but signing keys not rotated or held in HSM
• Annual ruleset validation performed but no record of driver rules being reviewed

Microsoft Office macros are disabled for users that do not have a demonstrated business requirement. Microsoft Office macros in files originating from the internet are blocked. Microsoft Office macro antivirus scanning is enabled. Microsoft Office macro security settings cannot be changed by users.

• Group Policy or Intune ADMX export showing 'Disable all macros without notification' for users not in the business-requirement group
• Evidence of demonstrated business requirement approval workflow with current approved user list
• GPO showing 'Block macros from running in Office files from the internet' set to Enabled
• AMSI macro scanning evidence (Defender or third-party AV) and version sufficient to scan Office macros
• Office Trust Center settings export showing user lockdown (HKCU policy keys overridden by HKLM)
• Sample test: open a macro-enabled file from the internet zone, confirm execution is blocked
• Office version inventory showing supported builds that honour the policy
• Audit of users in the macro-enabled group reviewed at least annually

• Macros disabled by default but no audit of who is in the exception group
• Mark of the Web policy enabled but a downstream tool strips MOTW (file shares, email gateways)
• AMSI scanning not enabled or AV does not support macro AMSI
• Users still able to click 'Enable Content' due to HKCU writeable settings
• Policy applied to Word and Excel but not PowerPoint, Outlook or Visio
• Macro signing not used so legitimate macros require global enablement

All ML1 requirements plus: Microsoft Office macros are blocked from making Win32 API calls.

• Microsoft Defender Attack Surface Reduction rule '92E97FA1-2EDF-4476-BDD6-9DD0B4DDDC7B' (Block Win32 API calls from Office macros) set to Block mode
• Intune or GPO export showing ASR rule enforcement across all in-scope endpoints
• ASR event log evidence (Defender Operational log Event ID 1121 / 1122) showing blocks and audit entries
• List of any approved exceptions with business justification, scope and review date
• Coverage report cross-referencing endpoint inventory to ASR enforcement state
• Test artefact: a macro that calls a Win32 API is blocked and logged
• Quarterly review record of ASR rule status across the fleet
• Evidence that ASR data is forwarded to SIEM for analysis

• ASR rule deployed in Audit mode only
• Exception applied org-wide instead of scoped to specific users or hosts
• Coverage gaps on devices not enrolled in Intune or domain-joined
• Defender disabled or replaced by third-party EDR that does not implement equivalent rule
• ASR logs not forwarded to SIEM for analysis
• Macros relying on Win32 calls migrated to legitimate alternatives without documentation

All ML2 requirements plus: Only Microsoft Office macros running from within a sandboxed environment, a Trusted Location or that are digitally signed by a trusted publisher are allowed to execute. Microsoft Office macros are checked to ensure they are free of malicious code before being digitally signed or placed within Trusted Locations. Only privileged users responsible for checking that Microsoft Office macros are free of malicious code can write to and modify content within Trusted Locations. Microsoft Office macros digitally signed by an untrusted publisher cannot be enabled via the Message Bar or Backstage View. Microsoft Office macros digitally signed by signatures other than V3 signatures cannot be enabled via the Message Bar or Backstage View. Microsoft Office's list of trusted publishers is validated on an annual or more frequent basis.

• Macro signing certificate inventory with issuance, expiry, owner and HSM storage evidence
• GPO 'Disable Trust Bar Notification for unsigned application add-ins' and trusted publisher policy export
• Policy enforcing V3 (SHA-2) signatures only with downlevel signatures blocked
• Trusted Locations list with NTFS ACLs showing only macro reviewers have write access
• Macro code review checklist and sample reviewed macros with reviewer sign-off
• Annual review record of trusted publisher list with additions, removals and approver
• Documented sandboxed macro environment (Application Guard, Windows Sandbox, virtualised execution) for any non-signed legitimate use
• User awareness evidence: how end users request a new macro signed

• Macro reviewers and developers are the same people, no separation of duties
• Trusted Locations have inherited write permissions from Domain Users
• V3 signature enforcement bypassed because legacy add-ins still in use
• Trusted publisher list not reviewed annually, includes retired vendors
• Macro code review is informal, no signed evidence of review
• Sandbox option not implemented, leading to mass-signing of operational macros

MFA on internet-facing services, third-party services that process org data, and customer-facing services.

• MFA configuration
• Service inventory
• Login logs showing MFA
• Customer MFA opt-in evidence

• SMS-only MFA
• No MFA on legacy SaaS

MFA on privileged users and important data repositories; phishing-resistant where possible.

• Privileged MFA enforcement
• FIDO2/WebAuthn rollout evidence
• MFA logs

• Admin bypass groups
• Push fatigue exploitable

Phishing-resistant MFA for all users; verifier impersonation resistant; central authentication event logs.

• FIDO2/CBA rollout
• Number matching enforced
• SIEM MFA event logs
• Number of legacy auth blocks

• Legacy basic auth still allowed
• Not all users on FIDO2

An automated method of asset discovery is used at least fortnightly to support detection of assets for subsequent vulnerability scanning. A vulnerability scanner with an up-to-date vulnerability database is used. The scanner runs at least daily for online services and at least weekly for office productivity suites, web browsers and their extensions, email clients, PDF software and security products. Patches or vendor mitigations for online services are applied within 48 hours when critical or working exploits exist, otherwise within two weeks. Patches for office productivity suites, web browsers and their extensions, email clients, PDF software and security products are applied within two weeks of release. Online services that are no longer supported by vendors are removed. Office productivity suites, web browsers and their extensions, email clients, PDF software, Adobe Flash Player, and

• Asset discovery tool configuration (Tenable Nessus, Qualys, Rapid7 InsightVM, Microsoft Defender for Endpoint) showing fortnightly scheduled discovery scans
• Vulnerability scanner plugin/feed last-updated timestamp evidence
• Daily scan schedule and result history for online services (web apps, externally exposed APIs, internet-facing portals)
• Weekly scan schedule and result history for the in-scope application classes
• Patch deployment evidence: tickets, change records or SCCM / Intune / Jamf reports correlating CVE publication date to patch deployment date for each in-scope class
• List of online services with EOL/EOS status and decommissioning evidence
• Endpoint software inventory showing no Adobe Flash, no unsupported browser versions, no out-of-support PDF readers
• Vendor support lifecycle policy with explicit deadlines for replacement

• Asset discovery cadence longer than fortnightly or run only when changes are requested
• Scanner credentialed scanning not configured, only unauthenticated scans, missing internal patch state
• Patching SLA met for Microsoft updates but missed for third-party apps (Chrome, Firefox, Adobe, Java, Zoom)
• Adobe Flash Player still installed on legacy systems
• Online services classed differently to ACSC definition, missing daily scan obligation
• Critical CVE patched but evidence of decision (critical vs non-critical) not retained

All ML1 requirements plus: A vulnerability scanner is used at least fortnightly to identify missing patches in applications other than office productivity suites, web browsers and their extensions, email clients, PDF software and security products. Patches for those other applications are applied within one month of release.

• Fortnightly authenticated scan schedule covering all in-scope applications outside the ML1 priority classes
• Scan results history with CVE coverage and last patched dates per host
• Patch deployment evidence showing CVE publication to deployment under 30 days for non-priority apps
• Patch management policy listing the in-scope application classes and SLAs
• Risk acceptance register for any patch deferred beyond SLA with executive sign-off and compensating control
• Monthly patch compliance report by application class to CISO or risk forum
• Cross-reference between vulnerability scan output and patching system ticket queue
• Evidence that line-of-business and bespoke apps are in the scanner inventory

• Fortnightly scan runs but only covers Microsoft updates
• Bespoke or in-house developed apps excluded from scanning
• One-month SLA tracked but missed for line-of-business apps where vendor delivery is slow
• Risk acceptance approved verbally with no register
• Scan output not reconciled to patch deployment evidence (cannot prove every CVE was actioned)
• Vendor mitigations (configuration changes) used in lieu of patches but not documented

All ML2 requirements plus: Patches or vendor mitigations for office productivity suites, web browsers and their extensions, email clients, PDF software and security products are applied within 48 hours of release when vulnerabilities are critical or working exploits exist. Applications other than the priority classes that are no longer supported by vendors are also removed.

• Threat intelligence feed configuration (CISA KEV, MSRC, vendor advisories) integrated with patching workflow
• Sample emergency patch tickets showing CVE publication, criticality decision, deployment to fleet within 48 hours
• Vendor mitigation register where a patch was not available but mitigation was applied (registry change, configuration change, firewall rule)
• Asset inventory showing no unsupported applications across the entire application estate
• Decommissioning evidence (change tickets, audit logs) for removed legacy applications
• Out-of-cycle change board records authorising emergency deployments
• Coverage report showing every workstation, server and mobile device received the patch within SLA
• Quarterly executive report showing 48-hour SLA compliance percentage

• 48-hour SLA tracked but not met for remote or roaming workstations
• Browser extension patches missed because of dependency on user-driven updates
• Vendor mitigation applied but no record kept of when patch supersedes it
• Unsupported in-house apps tolerated indefinitely under risk acceptance
• Threat intelligence not linked to patch prioritisation
• Coverage report incomplete because mobile devices use separate patching tool

An automated method of asset discovery is used at least fortnightly. A vulnerability scanner with an up-to-date vulnerability database is used. The scanner runs at least daily for operating systems of internet-facing servers and internet-facing network devices, and at least fortnightly for operating systems of workstations, non-internet-facing servers and non-internet-facing network devices. Patches for internet-facing OS and network device vulnerabilities are applied within 48 hours when critical or working exploits exist, otherwise within two weeks. Patches for workstation, non-internet-facing server and network device OS are applied within one month of release. Operating systems that are no longer supported by vendors are replaced.

• Asset discovery configuration and reports showing fortnightly cadence covering servers, workstations and network devices
• Authenticated OS vulnerability scan results (Nessus, Qualys, Defender for Endpoint TVM) with last-update timestamp
• Daily scan schedule and report for internet-facing servers and network devices (perimeter firewalls, load balancers, VPN concentrators)
• Fortnightly scan schedule and report for workstations and non-internet-facing infrastructure
• Patch deployment evidence (WSUS, SCCM, Intune, Jamf, vendor portals for network devices) with CVE-to-patch timestamps
• Network device firmware management evidence (Cisco PSIRT subscription, deployment tickets)
• Asset register showing no out-of-support OS (e.g. no Windows 7, no Server 2012 R2 past EOL)
• EOL replacement plan for any in-progress migrations with compensating controls

• Network devices not in vulnerability scan scope
• Internet-facing servers patched in 48 hours but cloud-managed appliances (load balancer firmware) miss SLA
• Workstations patched via WSUS but roaming or remote machines miss the one-month window
• Non-internet-facing servers patched on quarterly cycle, breaching one-month SLA
• Out-of-support OS retained for legacy app without compensating control documented
• Asset discovery misses cloud VMs spun up outside the central inventory

The same set of requirements as ML1, applied consistently across the in-scope estate. ACSC defines ML2 for Patch Operating Systems primarily through tightened evidence quality and breadth of coverage rather than additional new clauses, with the next material change introduced at ML3.

• Reconciliation between asset inventory, vulnerability scanner inventory and patch tool inventory (three-way match)
• Monthly SLA compliance report by OS class to risk committee
• Risk acceptance register for any host outside SLA with executive owner, compensating control and expiry
• Cloud workload coverage evidence (Defender for Cloud, AWS Inspector, GCP Security Health) with patch states
• Remote endpoint coverage evidence (Intune compliance, last-seen, last-patch-applied)
• Network device coverage including HA pairs and legacy devices
• Quarterly governance committee minutes covering patching KPIs
• Out-of-cycle patch deployment evidence for emergency CVE response

• Three-way reconciliation drifts because asset discovery, scanner and patch tool use different identifiers
• Risk acceptance register exists but with no expiry, accumulating perpetual exemptions
• Cloud workloads patched by an automation that is not audited
• Remote endpoints excluded from one-month SLA because of unreliable VPN
• Network device HA pair patched on different schedules
• SLA reported as a percentage but not by criticality

All ML2 requirements plus: A vulnerability scanner is used at least fortnightly to identify missing patches in drivers and in firmware. Patches for drivers and firmware are applied within 48 hours of release when critical or working exploits exist, otherwise within one month. Patches for workstations, non-internet-facing servers and non-internet-facing network device operating systems are applied within 48 hours when critical or working exploits exist (rather than one month). The latest release, or the previous release, of operating systems are used. Operating systems that are no longer supported by vendors are replaced.

• Fortnightly driver and firmware scan results from vendor tools (Dell Command Update, HP Image Assistant, Lenovo Vantage, server iLO/iDRAC, network device vendor advisories)
• Driver and firmware patch deployment evidence with CVE-to-deployment timestamps within SLA
• Emergency patching evidence for non-internet-facing servers and workstations within 48 hours for critical CVEs
• OS version inventory confirming all hosts are on the latest or N-1 OS release
• Replacement evidence (decommissioning tickets, migration plans) for any out-of-support OS
• Threat intelligence to patch workflow link (CISA KEV subscription, vendor PSIRT, ASD alerts)
• Coverage report for drivers across all hardware models and firmware across UEFI, BIOS, BMC, network device OS
• Quarterly executive report showing N or N-1 OS adherence percentage

• Driver and firmware patching done opportunistically at hardware refresh only
• 48-hour SLA met for internet-facing but not internal critical workloads
• OS version drift (e.g. Windows 10 22H2 retained alongside Windows 11) with no clear N-1 boundary
• Network device firmware lagging due to maintenance window scarcity
• Driver vulnerability scanning depends on vendor agent not installed across fleet
• EOL OS replacement plan slipped without re-baselining

Backups of data, applications and settings are performed and retained in accordance with business criticality and business continuity requirements. Backups of data, applications and settings are synchronised to enable restoration to a common point in time. Backups of data, applications and settings are retained in a secure and resilient manner. Restoration of data, applications and settings from backups to a common point in time is tested as part of disaster recovery exercises. Unprivileged user accounts cannot access backups belonging to other user accounts. Unprivileged user accounts are prevented from modifying and deleting backups.

• Backup policy with RTO, RPO and retention by data classification
• Backup tool configuration (Veeam, Commvault, Rubrik, Azure Backup, AWS Backup) showing scope covers data, applications and OS settings/system state
• Synchronisation evidence: backup job schedules showing common-point-in-time consistency or application-consistent quiesce
• Off-site or offline backup evidence (immutable storage, air-gapped tape, separate cloud tenant)
• DR test plan and most recent test report with restoration evidence (file, application, settings) to a common PIT
• Access control matrix showing unprivileged users cannot read other users' backups (NTFS / IAM)
• Backup repository ACLs showing unprivileged users have no modify or delete rights
• Sample restore tickets to demonstrate restorability

• Backups exist but DR exercises only test infrastructure, not data restoration
• Backups stored on the same hypervisor or cloud account as production (not resilient)
• Application settings not backed up, only data
• Last DR test more than 12 months old
• User home drives backed up to a share where users can delete their own backups
• Common point-in-time restoration untested because each system uses different schedules

All ML1 requirements plus: Privileged user accounts (excluding backup administrator accounts) cannot access backups belonging to other user accounts. Privileged user accounts (excluding backup administrator accounts) are prevented from modifying and deleting backups.

• Backup platform RBAC export showing only Backup Operators / Backup Admins have read and modify rights
• AD or IAM group membership evidence: Domain Admins are NOT a member of Backup Admins by default
• Separation of duties documentation between backup administrator role and other privileged roles
• Audit log evidence of any privileged non-backup-admin access attempts to backups (none, or alerted)
• Backup repository ACLs showing inheritance is blocked from broader admin groups
• Quarterly review of who holds backup admin entitlements
• Sample alert from SIEM if a non-backup-admin attempts to read or modify backup data
• Documented break-glass process for backup admin loss with seal evidence

• Domain Admins implicitly hold backup admin rights via inheritance
• Backup admin role not separated; the same identity holds Tier 0 and backup admin
• Backup vault on the same identity plane (same AD forest) as production with admin reachability
• No alert when a non-backup-admin reads the backup repository
• Backup admin role granted permanently rather than via JIT
• Audit logs of backup access not retained or not monitored

All ML2 requirements plus: Unprivileged user accounts cannot access their own backups. Privileged user accounts (excluding backup administrator accounts) cannot access their own backups. Backup administrator accounts are prevented from modifying and deleting backups during their retention period.

• Backup platform configuration showing immutable retention (Veeam Hardened Repository, Rubrik SLA, Azure Immutable Vault, AWS S3 Object Lock Compliance mode)
• Evidence that backup administrators cannot delete or modify backups within retention period even with full admin rights
• Policy and technical control showing unprivileged users cannot restore or read their own backups directly (must go through service desk)
• Privileged user backup self-access prevention configuration
• Cryptographic verification (hashing, chain of custody) of backup integrity
• Audit log showing attempted modification or deletion of in-retention backups is rejected
• Annual immutability test report
• Backup retention configuration export with periods aligned to BCP requirements

• Backup admin has implicit override (Compliance mode set to Governance mode, allowing override)
• User self-restore portal allows users to access their own backups
• Immutability implemented but retention period shorter than RPO+investigation window
• Cloud backup vault deletable by tenant root account (account-level controls missing)
• No annual test of immutability (no attempted delete from authoritative admin)
• Tamper-evident logging not enabled on the backup platform itself

Requests for privileged access to systems, applications and data repositories are validated when first requested. Privileged users are assigned a dedicated privileged user account to be used solely for duties requiring privileged access. Privileged user accounts (excluding those explicitly authorised to access online services) are prevented from accessing the internet, email and web services. Privileged user accounts explicitly authorised to access online services are strictly limited to only what is required for users and services to undertake their duties. Privileged users use separate privileged and unprivileged operating environments. Unprivileged user accounts cannot logon to privileged operating environments. Privileged user accounts (excluding local administrator accounts) cannot logon to unprivileged operating environments.

• Access request workflow records (ServiceNow, Jira) showing privileged access requests with approvers and validation
• Privileged account naming convention and AD/Entra ID inventory mapping privileged users to dedicated accounts
• Firewall, proxy or conditional access policy blocking privileged accounts from internet, email and web browsing
• Conditional access or named locations evidence restricting privileged accounts to administrative interfaces
• Tiered admin model documentation (Tier 0 / Tier 1 / Tier 2) with environment boundaries
• Group Policy Deny Logon rights: 'Deny logon locally', 'Deny logon through RDS' for cross-tier accounts
• Sample admin workstation showing it cannot send email or browse the internet
• Annual review of who holds privileged accounts vs whose role still requires them

• Privileged users use a single account for both daily and admin work
• Email blocked but web browsing still possible because no egress proxy enforced on admin VLAN
• No tiering, all admins log into Tier 0 from regular workstations
• Privileged accounts allowed to log into unprivileged environments (and vice versa) because Deny Logon GPOs missing
• Access request workflow exists but approvers rubber-stamp without validation
• Online-services authorisation applied broadly (e.g. all admins can use Microsoft 365 admin portal)

All ML1 requirements plus: Privileged access to systems, applications and data repositories is disabled after 12 months unless revalidated. Privileged access to systems and applications is disabled after 45 days of inactivity. Privileged operating environments are not virtualised within unprivileged operating environments. Administrative activities are conducted through jump servers. Credentials for break glass accounts, local administrator accounts and service accounts are long, unique, unpredictable and managed. Privileged access events are centrally logged. Privileged user account and security group management events are centrally logged. Event logs are protected from unauthorised modification and deletion. Event logs from internet-facing servers are analysed in a timely manner to detect cyber security events. Cyber security events are analysed in a timely manner to identify cyber sec

• Identity governance workflow (SailPoint, Saviynt, Entra ID PIM) showing 12-month revalidation and 45-day inactivity disablement
• Sample audit log of disabled accounts with reason (inactivity vs revocation)
• Jump server architecture diagram and access policy: admins cannot RDP directly to managed servers, must go via bastion
• Privileged Access Workstation policy showing it is not a VM inside a regular workstation
• Credential vault (CyberArk, BeyondTrust, HashiCorp Vault, Entra ID password rotation) configuration evidence
• Break-glass account procedure with seal logs and last access date
• SIEM use case for privileged logon, group membership change, AdminSDHolder modification, golden ticket markers
• Log integrity evidence (Azure Monitor immutable, WORM, separation of duties)

• Revalidation done annually but no automated disablement, manual list maintained
• Inactivity threshold tracked but service accounts excluded entirely
• Jump servers exist but bypass paths allowed (direct RDP for break-glass scenarios uncontrolled)
• Local admin passwords managed by LAPS on workstations but not on servers
• Service account passwords static for years, no rotation
• Privileged events logged but log management is itself controlled by the same admins

All ML2 requirements plus: Privileged access to systems, applications and data repositories is limited to only what is required for users and services to undertake their duties. Secure Admin Workstations are used in the performance of administrative activities. Just-in-time administration is used for administering systems and applications. Memory integrity functionality is enabled. Local Security Authority protection functionality is enabled. Credential Guard functionality is enabled. Remote Credential Guard functionality is enabled. Event logs from non-internet-facing servers and workstations are analysed in a timely manner to detect cyber security events.

• Privileged role definition matrix showing each role has a specific scope and entitlement set
• SAW build documentation (clean OS, App Control, no productivity software) and inventory of deployed SAWs
• Just-in-time access tool (Entra ID PIM, CyberArk JIT, Saviynt JIT) configuration with activation reason and approver
• Group Policy or MDM showing HVCI Memory Integrity enabled, LSA Protection RunAsPPL enabled, Credential Guard enabled, Remote Credential Guard enforced
• Endpoint compliance scan output confirming all of the above on every admin endpoint
• SIEM detection use cases against workstation and non-internet-facing server logs (lateral movement, credential dumping, AdminSDHolder)
• JIT activation logs sampled and reconciled with change tickets
• Decommissioning or quarantine evidence for any admin endpoint that failed compliance

• Least privilege expressed but enforced via broad AD groups (e.g. Domain Admins) for convenience
• SAWs deployed but used by admins for non-admin work (browsing, email)
• JIT in place for some platforms (Azure) but not for on-prem AD or Linux
• Credential Guard incompatible with legacy software so disabled on subset of fleet
• Memory Integrity disabled due to driver compatibility
• Workstation logs forwarded but only Security 4624/4625 collected, missing process and PowerShell context

Web browsers do not process Java or web ads from Internet; IE11 disabled or removed; users cannot change settings.

• Browser GPO/policy
• IE11 removal evidence
• Ad/Java block proof

• Java still enabled
• IE11 present

Browsers, Office, PDF readers hardened per ASD guides; logged; users cannot disable.

• ASD hardening guide compliance
• Office/PDF policy export
• Endpoint hardening logs

• PDF reader not hardened
• Logs not collected

Add PowerShell logging (module, script block, transcription), .NET Framework 3.5 disabled; logs centrally collected.

• PowerShell logging policy
• Script block log SIEM ingestion
• Disabled .NET 3.5 evidence

• Script block logging off
• Transcription not central