National ministries and agencies are the preferred targets of state espionage, yet most run on decades of legacy systems, shared services and suppliers that no single department controls. A central government cyber programme has to protect sensitive policy, diplomatic and citizen data, keep critical public services running, and do it under a cross-government assurance regime rather than as a stand-alone organisation. This guide covers how national departments structure such a programme: governance and accountability, the main assurance regimes in the UK, US and EU, priority technical controls, shared services and suppliers, and how to measure progress. It complements the Cybersecurity for Local Government Guide and is written for departmental CISOs, chief digital officers, senior information risk owners and programme leads.
Key takeaways
- Assume a state-level adversary. Espionage campaigns against ministries have repeatedly targeted identity systems, cloud email and remote access suppliers rather than exploiting obscure flaws.
- Assurance is cross-government. UK departments are assessed through GovAssure against the NCSC Cyber Assessment Framework, US agencies under FISMA and OMB memoranda, and EU institutions under Regulation (EU, Euratom) 2023/2841.
- Identity is the programme's centre. OMB M-22-09 requires phishing-resistant MFA for staff, contractors and partners, and enterprise-managed, centralised identity systems.
- Shared services spread risk. A weakness in a shared platform, a cloud tenant or a remote support supplier can reach many departments at once.
- Measure outcomes, not documents. Track critical systems assessed, MFA coverage, log coverage and time to remediate known exploited vulnerabilities, and report them to the board and the centre.
Why central government is different
- Adversary intent: foreign intelligence services seek policy positions, negotiating briefs, diplomatic communications and data on officials, and are patient and well resourced.
- Classification tiers: systems span public, official and higher classifications, each with its own networks, vetting and accreditation.
- Ministerial accountability: risk is owned by senior officials who answer to ministers and parliament, so cyber risk must be expressed in mission and service terms.
- Machinery of government changes: departments merge, split and move functions, leaving orphaned systems, tenants and accounts. The UK GovAssure page itself notes that the Government Cyber Unit moved from DSIT to DCMS following such changes.
- Legacy and scale: large estates with mainframes, bespoke case management systems and long procurement cycles.
- Centre and departments: a central body sets standards and offers shared services, while departments keep accountability for their own risk.
Threats to national departments
The threat picture for ministries is dominated by espionage, with disruption and crime alongside. The table links each common pattern to its usual entry point and the first control to check.
| Threat | Usual entry point | First control to check |
|---|---|---|
| State espionage against officials' email and documents | Password spraying, phishing, token theft, forged or stolen signing material in cloud identity | Phishing-resistant MFA, conditional access, cloud audit logging with alerting |
| Exploitation of edge devices | VPN gateways, firewalls and file transfer appliances with known exploited vulnerabilities | Edge device inventory, KEV-driven patching, log forwarding from appliances |
| Supplier and supply chain compromise | Remote support tools, managed service providers, software updates | Tier-zero supplier controls, scoped credentials, update integrity checks |
| Ransomware and extortion | Valid accounts, unpatched services, arm's length bodies with weaker controls | Immutable backups, segmentation, MFA on remote access |
| Hacktivist denial of service and defacement | Public websites and citizen services | DDoS protection, content integrity monitoring |
| Insider misuse | Privileged staff and contractors with broad data access | Least privilege, access reviews, data access monitoring |
Implementation roadmap: the first 12 months
- Months 0 to 3, visibility: confirm the critical system list, inventory cloud tenants, edge devices and non-human identities, and make sure identity and cloud audit logs reach central collection. Nothing is changed in production yet, so there is nothing to roll back.
- Months 3 to 6, identity hardening: enforce phishing-resistant MFA in pilot rings, starting with administrators and senior officials, then all staff. Keep a documented break-glass process and monitor sign-in failures before widening each ring; roll back a ring if service desk volumes or failures exceed the agreed threshold.
- Months 6 to 9, edge and suppliers: remove or replace unsupported edge devices, apply KEV remediation timelines, and re-scope supplier credentials. Test supplier disconnection procedures in a planned exercise.
- Months 9 to 12, assurance and exercise: complete assessments for the critical systems, agree improvement plans, and run a cross-department incident exercise with the central cyber body and key suppliers.
Each phase should end with a short report to the board showing metric movement, not only activity completed. Where the department depends on central shared services for identity or monitoring, agree the phase plan with the service owner first, because a change in a shared tenant can affect other departments that use it.
Assurance regimes for national departments
The table summarises the regimes most departments will meet, as checked on the official sources in October 2026. Dates and status can change, so confirm against the source.
| Jurisdiction | Instrument | Who it covers | What it requires | Status |
|---|---|---|---|---|
| UK | Government Cyber Action Plan (DSIT) | Government organisations of all kinds | Sets expectations for how government organisations manage cyber security and resilience, using measurable objectives and outcomes | Published 6 January 2026; supersedes the Government Cyber Security Strategy 2022 to 2030 for the latest detail |
| UK | GovAssure | OFFICIAL government systems, including government sector critical national infrastructure | Assessment of critical systems against the NCSC Cyber Assessment Framework, with self-assessment, independent review and Targeted Improvement Plans through WebCAF | Operating; run by the Government Cyber Unit |
| US | OMB M-22-09, Moving the U.S. Government Toward Zero Trust Cybersecurity Principles | Federal civilian agencies | Zero trust actions across identity, devices, networks, applications and data | Issued 26 January 2022; core goals due by end of FY2024 |
| US | FISMA and CISA Binding Operational Directives | Federal civilian agencies | Agency security programmes, annual reporting, mandatory directives such as remediation of known exploited vulnerabilities | In force. See the FISMA Guide and the CISA Binding Operational Directives Guide |
| EU | Regulation (EU, Euratom) 2023/2841 | Union institutions, bodies, offices and agencies | A high common level of cybersecurity across Union entities | Adopted 13 December 2023; entered into force 7 January 2024 |
| EU member states | NIS2 Directive and national law | Public administration entities as each member state designates | Risk management measures and incident reporting | Depends on national transposition. See the NIS2 Transposition Tracker |
The UK CAF approach is outcome based: departments demonstrate achievement of outcomes rather than a fixed control list. See the NCSC Cyber Assessment Framework (CAF) Guide.
Governance and programme structure
A departmental programme needs a clear line of accountability from the permanent secretary or agency head to system owners. NIST CSF 2.0 frames this as leadership responsibility and accountability for cybersecurity risk (GV.RR-01) and integration with enterprise risk management (GV.RM-03).
| Role | Responsibility | Typical evidence |
|---|---|---|
| Accounting officer or agency head | Owns overall risk appetite; answers to ministers and the centre | Board minutes, risk appetite statement |
| Senior risk owner (for example SIRO) | Owns information risk, accepts residual risk for critical systems | Risk acceptances, assurance sign-offs |
| CISO | Runs the programme, reports metrics, coordinates with the national cyber centre | Programme plan, metrics pack, incident reports |
| System and service owners | Own security of their systems and their improvement plans | Assessments, Targeted Improvement Plans, remediation tracking |
| Commercial and procurement | Embed security in contracts and supplier management | Contract clauses, supplier assessments (NIST SP 800-53 SR-6) |
| Central government cyber body | Standards, shared services, assurance, incident coordination | Assessment results, shared threat intelligence |
- Identify critical systems: list the systems whose compromise or loss would most damage the department's mission (CSF ID.AM-05), including those held by suppliers.
- Assess: run the applicable assessment (for example GovAssure against the CAF profile) starting with the most critical systems.
- Plan: agree time-bound improvement plans for each gap, with owners and funding.
- Deliver in waves: identity and logging first, then endpoint and network controls, then application and data controls.
- Review: report progress quarterly to the board and to the centre, and reassess annually or after major change (GV.OV-01).
Priority technical controls
Most espionage intrusions against departments have relied on identity, email and cloud tenants, remote access, and unpatched edge devices. The controls below map to the M-22-09 pillars and are generally applicable outside the US too.
| Area | Control | Why it matters for departments | Reference |
|---|---|---|---|
| Identity | Phishing-resistant MFA for staff, contractors and partners; centralised enterprise identity | Stops credential phishing and session theft used against officials | OMB M-22-09; NIST SP 800-53 IA-2(1); CSF PR.AA-03 |
| Privileged access | Separate admin accounts, privileged access workstations, just-in-time elevation | Limits lateral movement after initial access | CSF PR.AA-01 |
| Devices | Complete asset inventory and EDR across the estate | M-22-09 requires EDR meeting CISA's technical requirements | OMB M-22-09; CSF ID.AM-01 |
| Networks | Encrypted DNS where supported, HTTPS for all web and API traffic, environment isolation | Reduces interception and limits blast radius | OMB M-22-09 |
| Applications | Application security testing and a public vulnerability disclosure programme | Citizen-facing services are exposed by design | OMB M-22-09 |
| Logging | Central log collection with retention, including cloud audit logs | Espionage is often found only through logs | NIST SP 800-53 AU-6, AU-12; CSF DE.CM-09 |
| Vulnerabilities | Prioritise known exploited vulnerabilities on edge devices | Edge devices are a common entry point | CISA KEV and BODs |
See the Phishing-Resistant MFA Guide, the OMB M-21-31 Logging Maturity Guide and the CISA Zero Trust Maturity Model Guide.
Shared services, cloud and suppliers
- Shared platforms: shared HR, finance, email and hosting services concentrate risk. Agree who owns monitoring, incident response and logs for each shared service, and make sure customer departments can see their own audit data.
- Cloud tenants: retire unused tenants and test environments after machinery of government changes, and apply the same identity and logging standards to all of them.
- Remote support and PAM suppliers: treat them as tier-zero suppliers, since their own keys can reach customer systems. Require scoped credentials, session logging and a fast way to disconnect.
- Supplier assurance: CSF GV.SC-07 expects supplier risks to be understood, recorded and prioritised; build security clauses and incident notification into contracts. See the Third-Party Risk Management Guide.
Where identity fits
Non-human identities are often the least governed part of a departmental estate: service principals in cloud tenants, API keys for inter-department data exchange, integration accounts for case management systems, and supplier keys for remote support. They frequently survive reorganisations because nobody owns them. Give each an owner and a purpose, store secrets in a vault, limit permissions to the interface they serve, and alert on unusual use. See the Public Sector Identity Security Guide and the Service Account Security Guide.
Decision guidance: small agency versus large department
- Small agencies and arm's length bodies: adopt central shared services (identity, SOC, email security) rather than building their own, and focus scarce staff on asset inventory, MFA, patching edge devices and supplier contracts.
- Large departments: run their own SOC with threat hunting for espionage tradecraft, manage multiple classification tiers, and maintain a programme office that tracks improvement plans across many systems.
- Build versus centre: where a central service exists and meets the department's needs, using it improves visibility across government; departing from it should be a recorded decision with a reason.
Framework mapping
| Programme area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|
| Governance and accountability | GV.RR-01, GV.RM-03, GV.PO-01, GV.OV-01 | PM-9, PM-10 |
| Critical system identification | ID.AM-01, ID.AM-05 | CM-8 |
| Identity and MFA | PR.AA-01, PR.AA-03 | IA-2, IA-2(1) |
| Logging and monitoring | DE.CM-09 | AU-6, AU-12, CA-7 |
| Suppliers and shared services | GV.SC-07 | SR-6 |
Detection and measurement
- Monitor: sign-ins to cloud email and tenants from unusual locations or token anomalies, new OAuth applications and service principal credentials, admin role changes, edge device logs, and supplier remote sessions.
- Critical systems assessed: percentage of critical systems with a current assessment and improvement plan.
- Phishing-resistant MFA coverage: percentage of staff, contractors and administrators enrolled and enforced.
- Log coverage: percentage of critical systems and cloud tenants sending logs to central collection with agreed retention.
- Known exploited vulnerabilities: median days to remediate on internet-facing systems.
- Non-human identity ownership: percentage of service accounts, service principals and API keys with a named owner.
Common failure patterns
- Assessment as paperwork: self-assessments are completed but improvement plans are not funded or tracked.
- Forgotten tenants and test environments: a test account without MFA and a legacy test OAuth application led to senior leadership mailboxes being read in the Microsoft Midnight Blizzard Breach.
- Relying solely on a provider's defaults for logging: advanced audit logging was what allowed government analysts to spot forged token use in the Microsoft Storm-0558 Key Breach.
- Supplier keys with broad reach: a stolen remote support API key gave access to Treasury workstations in the BeyondTrust Breach.
- Software supply chain trust: backdoored Orion updates opened a campaign that the White House said compromised nine federal agencies, covered in the SolarWinds Supply Chain Compromise.
- Orphaned systems after reorganisation: systems and accounts nobody owns after a machinery of government change.
Lessons from incidents
The Storm-0558 case is instructive for central government: according to the NHI Mgmt Group analysis, the State Department detected unusual mail access on 15 June 2023 through a custom alert on premium audit logs, and more than 500 accounts across 22 organisations had been read. The intrusion relied on a forged authentication token rather than any user's mistake. The lesson is that departments need their own visibility into cloud identity events and must not assume a provider's controls are sufficient. The BeyondTrust incident adds a second lesson: suppliers that hold keys into many government customers are themselves high-value targets and need tier-zero treatment.
Practitioner checklist
- Name accountable owners for every critical system, including those run by suppliers and shared services.
- Complete the applicable cross-government assessment for critical systems first and fund the improvement plans.
- Enforce phishing-resistant MFA for all staff, contractors and administrators.
- Collect and retain identity, cloud, endpoint and edge device logs centrally.
- Remediate known exploited vulnerabilities on internet-facing systems within the directive timelines.
- Retire unused tenants, test environments and accounts after every reorganisation.
- Inventory and own all service accounts, service principals and API keys.
- Treat remote support, PAM and identity suppliers as tier-zero and contract accordingly.
- Report outcome metrics to the board and the central cyber body quarterly.
Standards and references
- GOV.UK: Government Cyber Action Plan
- UK Government Security: GovAssure
- GOV.UK: Government Cyber Security Strategy 2022 to 2030
- OMB: M-22-09 Moving the U.S. Government Toward Zero Trust Cybersecurity Principles
- EUR-Lex: Regulation (EU, Euratom) 2023/2841
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
- CISA: Known Exploited Vulnerabilities Catalog
Related NHI Mgmt Group resources: Cybersecurity for Local Government Guide · Public Sector Identity Security Guide · FISMA Guide · NCSC Cyber Assessment Framework (CAF) Guide. This guide summarises government cyber security assurance regimes and is not legal advice.