Overview

Cyber Essentials requires critical and high-risk security updates (CVSS v3 ≥ 7.0) to be applied within 14 days of release. Amazon WorkSpaces in AUTO_STOP mode are powered down 70-80% of the time, making them unreachable by patch management tools and invisible to compliance scanners.

This article shows how to use the Automate maintenance and updates on Amazon WorkSpaces Personal solution from AWS Builder Center article to build a patching pipeline that meets the 14-day requirement, generates audit-ready compliance reports, and runs without manual intervention.

What you'll learn:

• Why the built-in monthly maintenance window doesn't meet Cyber Essentials
• How to configure automated patching every 10 days
• How to create a Cyber Essentials-specific patch baseline
• How to generate compliance reports for auditors
• How to handle Microsoft Office updates alongside OS patching
• Cost considerations for a fleet of 150+ WorkSpaces

AWS services used: Amazon WorkSpaces, AWS Systems Manager (Patch Manager, Automation, Maintenance Windows, Run Command), Amazon SNS, AWS Lambda, Amazon S3, Amazon CloudWatch

---

What is Cyber Essentials?

Cyber Essentials is a UK Government-backed certification scheme operated by the National Cyber Security Centre (NCSC). It requires organisations to meet five technical controls - one of which is patch management: critical and high-risk security updates (CVSS v3 score ≥ 7.0) must be applied within 14 days of release. Cyber Essentials certification is mandatory for UK government contracts involving the handling of sensitive data, and is widely adopted across the private sector.

---

The Problem: AUTO_STOP WorkSpaces and the 14-Day Window

Most organisations configure WorkSpaces with AUTO_STOP running mode to control costs. A typical fleet of 150+ WorkSpaces might only have 10-20 machines running at any given time during business hours, and near zero outside of them.

This creates three compliance gaps:

1. The built-in maintenance window is monthly, not fortnightly. AutoStop WorkSpaces are started automatically once a month, beginning on the third Monday, for up to two weeks. A critical patch released on the first of the month might not be installed until the third Monday - potentially 20+ days later.

2. Patch management tools cannot reach stopped machines. AWS Systems Manager Patch Manager, WSUS, SCCM, and third-party vulnerability scanners all require the machine to be running and the agent to be online. When a WorkSpace is in STOPPED state, it is unreachable.

3. There is no fleet-wide compliance report for offline machines. Auditors need evidence that all machines in scope are patched within the required window. When 80% of your fleet is stopped at any given time, you cannot produce that evidence without manually starting every machine.

---

The Solution: Automated Maintenance with Systems Manager

Note: If your organisation already uses a patch management tool such as Microsoft Endpoint Configuration Manager (MECM/SCCM), Microsoft Intune, Canonical Landscape (for Ubuntu), or Ansible, that should remain your primary patching mechanism. These tools are purpose-built for endpoint management and are the recommended approach for WorkSpaces patch compliance.

This article is intended for organisations that do not have an existing endpoint management solution deployed to their WorkSpaces, or that are already using AWS Systems Manager for WorkSpaces management. The core concepts - scheduling the start/stop lifecycle of AUTO_STOP WorkSpaces to meet a patching window - apply regardless of which patching tool you use.

For recommended approaches:

• Windows with Intune: Native Entra ID and Intune support for Amazon WorkSpaces
• Ubuntu with Landscape: Get started with Ubuntu Amazon WorkSpaces and Landscape

The sample-automate-workspaces-maintenance solution provides a Systems Manager Automation runbook that orchestrates the full patching lifecycle. It handles both AlwaysOn and AutoStop running modes, supports Windows and Linux (including BYOL), and operates at directory level.

How It Works

Maintenance Window (every 10 days)
    │
    ▼
SSM Automation Runbook
    │
    ├─► 1. Discover eligible WorkSpaces (by directory, excluding Patch:No tagged)
    ├─► 2. Verify which WorkSpaces are SSM-managed (hybrid activations)
    ├─► 3. Start stopped WorkSpaces
    ├─► 4. Optionally reboot to ensure SSM Agent is running
    ├─► 5. Set WorkSpaces to ADMIN_MAINTENANCE (blocks user login)
    ├─► 6. Apply patches (AWS-RunPatchBaseline or AWS-InstallWindowsUpdates for BYOL)
    ├─► 7. Monitor patch status until completion
    ├─► 8. Optionally update AWS drivers (NVMe, ENA)
    ├─► 9. Disable maintenance mode
    ├─► 10. Stop AUTO_STOP WorkSpaces
    └─► 11. Send patch summary and compliance report via SNS

Components

Service	Role
SSM Automation	Primary orchestration logic
SSM Patch Manager	Manages patches through Patch Groups and Patch Baselines
SSM Maintenance Window	Schedules patching operations
SSM Run Command	Executes remote patching scripts
SSM Compliance	Generates patch compliance data
SNS	Delivers email notifications with compliance reports
Lambda	Generates ad-hoc CSV compliance exports
S3	Stores historical CSV compliance reports
CloudWatch	Provides logging

---

Configuring for Cyber Essentials Compliance

Step 1: Prerequisites - SSM Hybrid Activations

WorkSpaces run in AWS-managed service accounts, not in your account. To manage them with Systems Manager, each WorkSpace must be registered as a hybrid managed instance via SSM activation codes.

Follow the Automating AWS Systems Manager activation for Amazon WorkSpaces guide to set this up. The recommended approach for Windows WorkSpaces is a Group Policy startup script that calls an API Gateway endpoint backed by Lambda to generate activation codes automatically on each boot.

For AutoStop WorkSpaces, the SSM Agent may not start immediately when resuming from hibernation. Create a scheduled task that restarts the SSM Agent on resume:

If (!(Get-ScheduledTask -TaskName "RestartSSMAgent" -ErrorAction SilentlyContinue)) {
    schtasks /create `
        /tn "RestartSSMAgent" `
        /tr "powershell.exe -Command 'Restart-Service -Name AmazonSSMAgent'" `
        /sc ONEVENT `
        /ec System `
        /mo "*[System[Provider[@Name='Microsoft-Windows-Power-Troubleshooter'] and EventID=1]]" `
        /ru "SYSTEM" `
        /f
}

Step 2: Deploy the Solution

Download the CloudFormation template from the GitHub repository and deploy it:

aws cloudformation deploy \
  --stack-name WorkSpacesMaintenance-d-93-example-7f \
  --template-file workspaces-maintenance.yaml \
  --capabilities CAPABILITY_NAMED_IAM \
  --parameter-overrides \
    DirectoryId=d-93example7f \
    NotificationEmail=security-team@example.com \
    MaintenanceSchedule="cron(0 1 ? * 1/10 *)" \
    AllowReboot=RebootIfNeeded

Naming the stack with the directory ID is recommended if you manage multiple directories, as the solution is deployed per-directory.

Step 3: Configure the Maintenance Schedule for 14-Day Compliance

Recommended: every 10 days. This provides a 4-day buffer for failures, retries, or manual intervention before the 14-day deadline.

Schedule	Cron Expression	Notes
Every 10 days	cron(0 1 ? * 1/10 *)	Recommended for Cyber Essentials
Every Sunday at 1 AM	cron(0 1 ? * SUN *)	Weekly, provides maximum buffer
Every other Wednesday	cron(0 1 ? * WED#1 *)	Fortnightly, minimal buffer

Set the maintenance window duration to at least 3 hours. For fleets of 150+ WorkSpaces, 4 hours is safer.

Step 4: Create a Cyber Essentials Patch Baseline

Create a custom patch baseline targeting patches with CVSS ≥ 7.0 (Microsoft's Critical and Important classifications):

aws ssm create-patch-baseline \
  --name "CyberEssentials-Windows" \
  --operating-system WINDOWS \
  --description "Targets Critical and Important updates for Cyber Essentials 14-day compliance" \
  --approval-rules '{
    "PatchRules": [{
      "PatchFilterGroup": {
        "PatchFilters": [
          {"Key": "CLASSIFICATION", "Values": ["CriticalUpdates", "SecurityUpdates"]},
          {"Key": "MSRC_SEVERITY", "Values": ["Critical", "Important"]}
        ]
      },
      "ApproveAfterDays": 0,
      "ComplianceLevel": "CRITICAL",
      "EnableNonSecurity": false
    }]
  }' \
  --approved-patches-compliance-level CRITICAL

Key settings:

• ApproveAfterDays: 0 — Patches are approved immediately on release. The 14-day clock starts when Microsoft publishes the update, not when you approve it.
• MSRC_SEVERITY: Critical, Important — Maps to CVSS ≥ 7.0 as required by Cyber Essentials.
• EnableNonSecurity: false — Keeps the scope focused on security patches only.

Register this baseline with your Patch Group:

aws ssm register-patch-baseline-for-patch-group \
  --baseline-id pb-0a1b2c3d4example \
  --patch-group "WorkSpaces-d-93-example-7f"

Step 5: Tag Your WorkSpaces for Patch Group Management

PatchGroup tag (on SSM managed instances) — Associates WorkSpaces with your custom patch baseline:

# Run in CloudShell (switch to PowerShell with: pwsh)
$domain = "yourdomain.com"
$directoryId = "d-93-example-7f"

Get-SSMInstanceInformation |
  Where-Object { $_.InstanceId -like "mi-*" -and $_.ComputerName -like "*.$domain" } |
  ForEach-Object {
    Add-SSMResourceTag -ResourceType "ManagedInstance" `
      -ResourceId $_.InstanceId `
      -Tag @{Key="PatchGroup"; Value="WorkSpaces-$directoryId"}
  }

Patch tag (on WorkSpaces) - Tag a WorkSpace with Patch:No to exclude it from patching. Useful for shared/kiosk WorkSpaces, machines undergoing manual testing, or those with known compatibility issues.

Step 6: Disable the Built-In Maintenance Mode

Disable the built-in WorkSpaces maintenance mode to avoid unnecessary costs:

1. Open the WorkSpaces console → Directories
2. Select your directory → Actions → Update Details
3. Expand Maintenance Mode → Set to Disabled
4. Click Update and Exit

---

Compliance Reporting for Auditors

Automated Post-Patching Report

After each patching cycle, the Automation runbook sends an SNS email containing a patching summary and a presigned S3 URL to a detailed CSV compliance report with per-machine patch details.

Ad-Hoc Compliance Reports

Generate a compliance report at any time:

aws lambda invoke \
  --function-name workspacemaintenance-compliancereport-d-93-example-7f \
  --payload '{"DirectoryId": "d-93-example-7f", "PatchGroup": "WorkSpaces-d-93-example-7f"}' \
  response.json

What Auditors Need to See

Requirement	Evidence
Patches applied within 14 days	Maintenance window schedule (every 10 days) + historical execution logs
Critical/high-risk patches prioritised	Custom patch baseline targeting MSRC Critical and Important
All in-scope machines covered	Compliance report showing total fleet vs. patched count
Process is automated and repeatable	CloudFormation template + maintenance window configuration
Exceptions are documented	Patch:No tagged WorkSpaces with justification

---

Managing Microsoft Office Updates

OS patching is only half the compliance picture. Microsoft Office (Click-to-Run) has its own update mechanism that is separate from Windows Update. SSM Patch Manager's AWS-RunPatchBaseline does not cover Office updates, and Office's built-in updater rarely gets a chance to run on AUTO_STOP machines.

Solution: SSM Run Command During the Maintenance Window

Create an SSM Command document that forces the Click-to-Run update:

schemaVersion: '2.2'
description: Force Microsoft Office Click-to-Run update
mainSteps:
  - action: aws:runPowerShellScript
    name: UpdateOffice
    inputs:
      runCommand:
        - |
          $C2RClient = "C:\Program Files\Common Files\microsoft shared\ClickToRun\OfficeC2RClient.exe"

          if (-not (Test-Path $C2RClient)) {
              Write-Output "Office Click-to-Run not found — skipping"
              exit 0
          }

          Write-Output "Starting Office Click-to-Run update..."
          $process = Start-Process $C2RClient -ArgumentList "/update user displaylevel=false forceappshutdown=true" -Wait -PassThru
          Write-Output "Office update completed with exit code: $($process.ExitCode)"

          $officeVersion = (Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Office\ClickToRun\Configuration" -ErrorAction SilentlyContinue).VersionToReport
          Write-Output "Current Office version: $officeVersion"
      timeoutSeconds: '1800'

Add it as a maintenance window task with priority 2 (runs after OS patching at priority 1):

aws ssm register-task-with-maintenance-window \
  --window-id "mw-0a1b2c3d4-example" \
  --task-type RUN_COMMAND \
  --task-arn "Update-OfficeClickToRun" \
  --targets "Key=tag:PatchGroup,Values=WorkSpaces-d-93-example-7f" \
  --priority 2 \
  --max-concurrency "25" \
  --max-errors "20%"

---

Handling Edge Cases

WorkSpaces that fail to patch: The Automation runbook reports failures via SNS. Common causes: SSM Agent not responding (fix: deploy the scheduled task restart hook), insufficient disk space, or patches requiring manual intervention. The 10-day schedule gives you 4 days to remediate before the 14-day deadline.

New WorkSpaces added between cycles: Picked up on the next run, provided they are SSM-registered, tagged with the correct PatchGroup, and not tagged Patch:No.

BYOL WorkSpaces: Use AWS-InstallWindowsUpdates instead of AWS-RunPatchBaseline. The solution handles this automatically via a deployment parameter.

---

Cost Considerations

Incremental potential cost for a fleet of 150 AutoStop WorkSpaces:

Component	Cost per Cycle	Monthly (3 cycles)
WorkSpaces compute (3 hrs × 150 at ~$0.22/hr)	~$99	~$297
SSM Automation	Free tier	Free tier
SSM Hybrid Activations (Standard tier, up to 1,000 nodes)	Free	Free
Lambda, S3, SNS	< $0.01	< $0.10

SSM Instance Tier Note: The standard-instances tier supports up to 1,000 hybrid-activated nodes per account per region at no additional cost. This solution uses SSM Automation and Run Command for patching, which do not require the advanced-instances tier. The advanced tier ($5/instance/month) is only required if you need: (a) more than 1,000 hybrid nodes, (b) Session Manager shell access to WorkSpaces, or (c) patching of Microsoft-released applications via SSM Patch Manager (as opposed to the custom Run Command approach used for Office updates in this article). For most WorkSpaces patching deployments, the standard tier is sufficient.

The dominant cost is WorkSpaces hourly compute during patching. This is the cost of compliance - the alternative (manual patching or failing the assessment) is significantly more expensive.

---

Applicability to ISO 27001

This solution also supports ISO 27001:2022 compliance (Annex A, Control A.8.8 - Management of technical vulnerabilities). Unlike Cyber Essentials' specific 14-day requirement, ISO 27001 requires organisations to identify vulnerabilities in a timely manner, evaluate risk, and take appropriate measures with a documented, repeatable process.

ISO 27001 Control	Evidence Provided
A.8.8 — Technical vulnerability management	Automated patching with configurable schedule, documented via CloudFormation
A.5.33 — Protection of records	Compliance reports retained in S3 with configurable retention
A.5.9 — Inventory of information assets	Fleet inventory via WorkSpaces API (all machines regardless of state)
A.8.8 — Risk-based approach	Tag-based exclusions (Patch:No) with documented justification

If your organisation holds both certifications, the 10-day cadence satisfies both standards simultaneously.

---

Summary

The combination of the AWS Builder Center maintenance automation with a Cyber Essentials-specific configuration gives you:

• Automated patching every 10 days (4-day buffer within the 14-day requirement)
• A custom patch baseline targeting Critical and Important updates (CVSS ≥ 7.0)
• Microsoft Office Click-to-Run updates alongside OS patching
• Per-machine compliance reports stored in S3 for audit evidence
• Email notifications after each cycle with summary and presigned report URL
• Tag-based exclusion for machines needing manual handling
• Support for both standard and BYOL WorkSpaces

The solution runs as a single CloudFormation stack per directory, uses native AWS services, and requires no additional infrastructure.

---

Resources

• sample-automate-workspaces-maintenance (GitHub)
• Automate maintenance and updates on Amazon WorkSpaces Personal (AWS Builder Center)
• Automating SSM activation for WorkSpaces
• Maintenance in WorkSpaces Personal
• NCSC Cyber Essentials Requirements
• AWS Systems Manager Patch Manager
• Microsoft 365 Apps update history