UK NCSC

How industry, the NCSC and the FCA worked together to help organisations share information while protecting market integrity

Updated: The NCSC is encouraging UK organisations to take immediate action to mitigate a security issue affecting PHP (CVE-2026-109618 and CVE-2026-109619).

ASOS has said it is investigating a cyber incident and that some customer personal information may have been accessed.

The NCSC is urging UK organisations to promptly mitigate vulnerabilities affecting Citrix NetScaler ADC and Gateway, two of which are being actively exploited.

Defenders can’t use AI in the same way attackers can, but there’s much they can do to unlock the potential of agentic cyber defence.

Our view of good cyber adversary simulation – and how assured providers can deliver it.

Adversary simulation ('red teaming') tests your ability to prevent, detect and respond to cyber attacks.

Advisory on CHOSEN BRICK malware, including technical analysis and advice to help individuals and organisations protect themselves.

UK and allies provide advice to help organisations and individuals at risk detect and counter the threat from CHOSEN BRICK malware.

The hidden risks of shadow AI Understanding why staff use unapproved AI tools is key to managing the security challenges they can create. Over the past few years, the use of artificial intelligence (AI) has grown rapidly in many workplaces with employees increasingly exploring how such tools can be incorporated into their jobs. AI can help people complete tasks more quickly, improve decision-making, save costs and increase productivity. However, organisations’ policies and guidance, which should reflect and manage the risks associated with using these new technologies, have not always developed at the same pace. Rather than preventing them from using AI, this can mean employees turn to using AI tools that have not been approved by their organisation, introducing new cyber security risks that can be hard to identify. What is shadow AI? Shadow AI describes the use of AI technology which isn’t captured in an organisation’s approved systems and processes. It is a form of shadow IT (or ‘grey IT’). Recent research suggests that using shadow AI is widespread, with one study finding that nearly three-quarters of employees (71%) reported using AI tools that have not been approved by their employer. Where cyber security policies cannot meet business needs, organisations are likely to continue seeing their employees adopt new AI services before they have had time to assess them and provide approved alternatives. This trend is likely to be reinforced as AI capabilities become increasingly affordable and readily available. What are the cyber security risks of shadow AI? The use of shadow AI can create risks that organisations may struggle to identify and in turn manage, potentially resulting in breaches and security incidents. For example: Sensitive information may be exposed Providing shadow AI access to company or customer data likely increases the risk of data breaches, intellectual property loss and failure to meet regulatory requirements. Organisations can lose visibility and control of data Employees who transfer sensitive or proprietary information to consumer AI services will likely reduce the organisation's visibility and control over that information. This is because that information may be stored, retained or used to improve the service – outside established security and governance arrangements – unless specific privacy controls are in place. New opportunities for attackers AI agents are complex pieces of software that can have critical security vulnerabilities. If an attacker successfully exploits a vulnerability, they can gain access to the same data, services, and privileges that the agent has legitimate access to. Attackers are highly likely to use agents with looser guardrails to exploit any vulnerabilities or misconfigurations in the wider corporate IT system. Encourage staff to choose wisely The NCSC is not recommending that individuals stop using AI – but when turning to these tools for assistance with a work task, think carefully about which apps and services you are using before you share data. It may feel natural to stick with using the same AI service that you are familiar with from your personal life – but using systems that are not corporately approved can present real problems for your employer. Focus on reducing the risk For organisations, the challenge is ensuring that employees have access to AI tools that meet their needs while managing cyber risk appropriately. The use of shadow AI is unlikely to disappear completely. As with shadow IT more broadly, the goal should be to reduce risk rather than assume it can be eliminated. To do this, organisations should: adopt a positive cyber security culture. Encouraging open communication about cyber security issues means employees are much less likely to turn to shadow IT services, including shadow AI. Organisations that understand why people are using shadow AI are better placed to identify risks, provide secure alternatives and support innovation safely securely integrate AI systems into the workplace. Refer to the NCSC and international partners' guidance on careful adoption of agentic AI services You cannot manage what you do not know. By raising awareness of the risks of shadow AI use within your organisation and understanding the needs of employees, you can help them get the benefits of new technologies while using them securely.

Disruptive cyber activity highlights risk from internet-exposed systems and edge devices Targeting of operational technology reinforces the need for organisations to understand what is exposed to the internet, address avoidable vulnerabilities, and build long-term cyber resilience. What has happened? The NCSC has seen increased targeting of operational technology (OT) systems across multiple sectors globally, including in the UK. This has been carried out by a range of threat actors and resulted in some limited real-world disruption. Any organisation that uses, deploys or maintains OT systems should treat this development seriously and review their security posture accordingly. Who is affected? Any organisation with internet-exposed OT could be affected by this activity. Organisations should not assume that their OT is inaccessible from the internet without verifying it, as unintended exposure can arise through misconfigurations, legacy connections, or unmanaged assets. Wider context The NCSC has been engaging with sectors directly in response to this recent targeting and is now sharing this advisory to support national resilience efforts. For some time, the NCSC has been warning about a broader pattern of disruptive cyber activity carried out by state and non-state actors affecting organisations in both critical national infrastructure (CNI) and non-CNI sectors. Against the backdrop of technology-enabled uplifts in cyber capability and increased geopolitical instability, the NCSC assesses that the threat from state use of offensive cyber, including outside of conflict, has almost certainly increased. As a result of this wider context, it is essential that all organisations take action now given the developing threat picture. What should I do? In response to the observed disruptive activity, organisations should take the following actions: Build a definitive view of your OT architecture, including all assets, communications pathways and external connections. This will help identify internet-exposed systems, unmanaged assets and legacy connectivity that may introduce risk. Ensure OT devices, such as Programmable Logic Controllers (PLCs) and Human Machine Interfaces (HMIs), are not directly exposed to the public internet. Change default credentials and prevent the use of shared passwords on web interfaces, management interfaces, and management protocols. Use unique accounts for administrators, enable multi-factor authentication (MFA) wherever supported, and use stronger authentication mechanisms such as public/private key authentication if supported by protocols (eg SSH) instead of passwords where possible. Harden your OT boundary. Strictly control access to OT from external or untrusted networks. Ensure devices (such as industrial gateways, firewalls, routers and remote access appliances) that facilitate external connectivity are within vendor support, routinely updated by default, replaced before they reach their end-of-life (EOL), and that the management of these devices is only possible from a segregated management network that is not connected to the internet. Adopt secure versions of industrial and management protocols where possible. For industrial protocols this might mean migrating DNP3 to DNP3-SAv5, CIP to CIP Security, Modbus to Modbus Security, OPC DA to OPC UA. In management this includes but is not limited to removing the use of, telnet, SNMP v1, SNMP v2. Limit use of insecure protocols (where there is no secure alternative) to isolated network segments. Log and monitor all connectivity to and within OT networks, with particular focus on detecting attempts to communicate with OT assets such as PLCs and HMIs from unexpected devices, networks, or routes. As OT environments are typically static and predictable, baseline monitoring can be highly effective at identifying unauthorised activity, misconfigurations, or potential cyber compromise. There are multiple ways to achieve this such as ensuring PLCs are not left in PROGRAM or other maintenance modes. You should also ensure controller logic ues password-based write protection or equivalent mechanisms to prevent unauthorised changes to control logic from malicious endpoints. This reduces the risk of accidental modification and make it more difficult for malicious software or threat actors to alter operational processes. Segment management networks, OT control systems, and business IT networks to reduce the impact of a cyber incident. Separate systems based on their function and criticality and restrict communications between network zones to only those required for operational purposes. This helps prevent unauthorised access, limits opportunities for an attacker to move between systems, and reduces the likelihood that a compromise in one area will affect the wider environment. Maintain tested backups of OT systems, configurations, controller logic, and critical engineering data, and regularly practise restoration and recovery procedures. Ensure you can quickly isolate affected systems from the wider network and restore essential operations from trusted backups to minimise downtime and support safe recovery from cyber incidents. Backups should be designed to be ransomware-resistant. Implications for non-operational technology organisations While we have observed targeting of OT, there continues to be a broader pattern of disruptive cyber activity targeting internet exposed systems and edge devices affecting all sectors We have previously highlighted other activity such as that against poorly configured routers, published in July 2026 with international partners. For non-OT organisations, such activity highlights the importance of maintaining visibility of internet-exposed assets and edge network devices. Key actions include maintaining an accurate inventory of internet-facing systems, understanding the function and data flows of edge devices, applying vendor security updates promptly, retiring end-of-life equipment, disabling insecure management protocols such as SNMP v1, SNMP v2 and Telnet, and monitoring for unexpected configuration changes or outbound connections. Building long-term cyber resilience Effective cyber resilience requires organisations to be prepared before an incident occurs and capable of responding and recovering when one does. Organisations should review their readiness for significant cyber incidents, taking account of the NCSC's guidance on preparing for severe cyber threats, and ensure that arrangements for responding to and recovering from cyber attacks are established, maintained and regularly exercised in line with the NCSC's guidance on what to do when cyber attacks disrupt your organisation. All organisations should register for the NCSC's free Early Warning service to help identify publicly exposed vulnerabilities and other potential security issues affecting internet-facing systems, supporting efforts to detect and address risks before they are exploited. Cyber Assessment Framework Organisations that have embedded strong cyber resilience practices are better placed to prevent, detect and respond to cyber incidents before they cause operational disruption. The Cyber Assessment Framework (CAF) provides a comprehensive framework for assessing how well an organisation is meeting expected security and resilience outcomes. Boards should seek assurance that the outcomes and principles described within the CAF are being achieved across all systems supporting essential functions. Cyber Essentials Where the CAF is not appropriate, Cyber Essentials is an excellent first step in gaining assurance that your systems are protected against the most common threats. It is the minimum standard of cyber security recommended by the Government for organisations of all sizes.

Managing the cyber risk of agentic AI Use safeguards, sandboxing and active oversight to realise the benefits of autonomous systems while limiting the unintended activity. Agentic AI systems have shown potential to transform how organisations work, at times delivering unparalleled productivity gains. They can automate complex workflows, reduce routine effort and enable people to focus on higher-value tasks. As organisations deploy increasingly autonomous uses of AI at pace, it is important to consider how these systems behave when they do not function as envisaged or expected - and plan accordingly. Recently, there have been several incidents involving AI models and agentic AI systems carrying out unsanctioned or unintended activity. These events highlight why organisations need to carefully consider how these technologies are deployed, constrained, observed and responded to. AI cyber security continues to be a rapidly evolving field, and effective practice will continue to evolve as the technology matures and evidence bases are built. We will work with the wider cyber security community to continue to research, develop and evaluate approaches that help organisations deploy increasingly autonomous systems securely and confidently. The NCSC has been researching and experimenting in this area for some time and is working with partners to develop formal guidance which will build upon, and ultimately supersede, this blog. Until formal guidance is published, the NCSC is sharing interim practical advice, based on NCSC research to date, to help organisations make informed decisions about how to deploy agentic AI systems securely within their environments. This blog is aimed at system designers and operators who are: building environments where AI agents are intended to operate with significant degrees of autonomy concerned about the implications of an AI agent performing unintended actions because of the instructions it receives, the tools available to it, or the systems it can access The recommendations in this blog should be applied proportionately based on the level of autonomy each agentic AI system is intended to have. Not every deployment requires the same degree of autonomy. Some agents may simply assist a human user by making suggestions or carrying out tightly constrained tasks in a low-risk manner. Others may be trusted to take actions, access production systems and make decisions with little or no human intervention in potentially high-risk scenarios. The greater an agent's autonomy, the greater the potential impact if it: malfunctions unexpectedly accesses information it should not takes actions outside its intended scope And therefore the greater the need for controls. Being clear on the level of autonomy, and the level of risk you are willing to tolerate, will inform the design of controls that are proportionate to both the organisational benefits you aim to achieve and the consequences of a failure. Once you have identified how much autonomy an agent will have and the level of risk you are prepared to accept, it is important to understand the safeguards that already exist within the AI model, inference service and harnesses you are using. Many AI models include mechanisms designed to detect or prevent certain types of unwanted behaviour. These controls can provide a baseline level of protection. However, they should not be treated as holistic. Safety controls built into models may: be bypassed not provide adequate protection in higher-risk environments not be sufficient to manage risk appropriately on their own Understanding the safeguards that are available, their efficacy and their limitations, will enable you to determine what additional controls are needed. For applications where the consequences of failure are above tolerance, organisations should implement additional safeguards rather than relying solely on model-level or harness-level protections. Examples of further safeguards can include classifiers, deterministic provers and wider controls. Irrespective of the inbuilt controls, all deployments should be subject to robust observability, operational monitoring and response procedures. Key considerations 1 Identify what could go wrongDocument what is within and outside the scope of your intended activity, highlighting any ‘red lines’ that the agentic AI system must stay within. Before deployment, carry out threat modelling to identify the failure scenarios during the agent’s activities. Consider: - the prompt given to the agent - the networks and services the agent may be able to access and communicate with through the configured sandbox – either directly or indirectly Remember that an AI agent is not human. It does not have common sense or human traits, and may interpret instructions and goals in literal or unexpected ways. Use the results from your threat modelling to assess whether you accept the risks identified and whether any additional controls should be placed in and around the agentic AI system. 2 Prompt carefullyThe instructions and context given to an agentic AI system and its underlying model will influence the activities it carries out. AI agents can pursue goals in ways that are unintended or undesirable if those goals, or how you expect the agent to achieve them, are not clearly defined. The way a task is described can have a significant impact on the agent's behaviour. Before running an agent, think carefully about: - what it is to achieve - what actions it should be allowed to take - when it should stop and seek human approval – and ensure those approvals will be both guaranteed and gated Where possible, make your expectations explicit. Instruct the agent in both what it should do and what it should not do. For longer-running tasks, review how the agent handles context over time. Some agents may compress their context windows to use tokens more efficiently. Where appropriate, repeat critical constraints so they remain throughout the task. However, do not rely on prompting alone. You should combine prompts with technical and operational controls to provide defence in depth. 3 Set the right level of oversightConsider how much autonomy you want the agent to have. There are several approaches: - Human-in-the-loop: humans approve actions before they happen. - Human-on-the-loop: humans monitor actions and can intervene if needed. - Human-out-of-the-loop: AI acts autonomously without human review. The model you choose should inform your risk tolerance and the potential consequences if the agent behaves unexpectedly. Where unintended activity would have significant consequences, we recommend: - making named individuals or group responsible for agentic AI activities - maintaining human oversight of the AI agent’s actions - instructing agents to identify blockers or behaviours directly - using real-time monitoring alerts to identify unexpected or concerning behaviour - monitoring what the agent is doing so it can be stopped if necessary Using additional ‘judge’ AI models and agents can help manage an agent's activities. However, these agents and the approach should be independently evaluated for performance noting that they may also have limitations and second order effects. For higher risk scenarios, we recommend having human oversight alongside technically enforced controls. When events of consequence are flagged, humans should be able to investigate quickly and take action to limit any unintended impact. 4 Control the AI agent's environment with a robust sandboxAlways run AI agents within a sandboxed environment that controls and manages what resources can and cannot be communicated with, both locally and over a network. a. Decide what your agent can connect toFor high-risk activities, the most robust approach is to run your AI agent within an isolated and disconnected environment, with access to pre-downloaded tools and information. However, many use cases require the AI agent to communicate with external environments, systems and services including for access to the model. When this is necessary, apply sandbox isolations. b. Define the boundaries of the sandboxWhen designing a sandbox environment, think beyond the system where the: - AI agent scaffolding runs - AI agents commands run - inference infrastructure is - whether local, remote or as a service Where possible, these elements should be segregated from one another. Instead, consider everything the agent can access or influence, whether directly or indirectly. This includes: - Execution: between scaffolding, agent command execution sandbox and inference infrastructure - Network: what it can remotely access - Compute: what it can locally access - Credentials: what identity and roles it can impersonate or otherwise have access to, intentionally or not - Data: what data it has access to Some autonomous AI tools, such as OpenClaw and Hermes Agent, are designed to interact with large numbers of systems and services. The wider the access, the greater the potential impact if the AI agent malfunctions unexpectedly or is compromised. To help limit the agent’s potential impact - sometime described as its 'blast radius', you should try to restrict access to just the resources needed for the task being performed whilst monitoring for attempts at wider access. c. Restrict network accessWhere possible, deny all inbound and outbound network traffic to the AI agent’s environment by default. Then, only allow connections that are required, using allowlists. When selecting network sandboxing technologies, consider the security properties described in our cross domain approach and architecture guidance. Some use cases require internet access and allowlists may not always provide the level of control or granularity required. In these cases, consider using protocol- or service-aware proxies that allow connections only by exception and require manual approval before permitting communications outside of approved scopes. The following maturity model will help you assess your approach: - Level 1 (lowest): unrestricted network access - Level 2: access restricted to an allowlist of approved domains - Level 3: access restricted to just the API of the model - Level 4 (highest): no external network access, with the model hosted locally inside the network sandbox d. Strengthen compute and host isolationMany AI agent solutions include built-in sandboxing technologies. For some use cases, these may provide a sufficient level of protection. However, you should evaluate whether they are appropriate for your use case. For higher risk activities, consider enforcing stronger isolation using additional controls and solutions. When prompted or trained on the underlying model to do so, AI agents may be able to discover and exploit configuration issues, or potentially even vulnerabilities, in certain technical controls. If this event occurs, it could lead to a sandbox escape. To reduce this risk, use multiple layers of isolation and control whilst regularly validating configurations, potentially via agentic AI approaches, to identify weaknesses or misconfiguration. This should include explicit prompts to not: - connect to domains outside an allowlist - attempt to escape the sandbox Not all sandboxing technologies offer the same level of protection. Choose mature, trusted sandbox technologies that are designed specifically to isolate potentially malicious code and activities. The following maturity model will help you assess your approach: - Level 1 (lowest): no compute isolation. The AI agent runs on, or has remote access to, the host platform alongside other workloads and data - Level 2: the agent runs on the same host as other workloads, but is constrained using kernel primitives such as process separation and OCI containers which are properly configured. A residual risk of kernel exploit breakout remains - Level 3: the agent runs on the same host as other workloads but is isolated using virtualisation technologies - Level 4 (highest): the AI agent runs on dedicated hardware that is separate from other workloads e. Assign and limit an agent’s access to credentialsAll agents should be assigned their own unique identity in a class which differentiates them from human or individual systems. The credentials available to an AI agent form part of its potential 'blast radius' if it behaves unexpectedly. Credentials include API keys, OAUTH grants, SSH keys and any authenticated sessions the agent can access or use. These credentials allow the agent to perform actions using the identities and permissions associated with them. Where an agent has access to a host environment, such as a level 1 above (no compute isolation), it may also be able to use credentials that are available to the user account under which it is running. Where possible you should restrict the credentials available to the agent. Ensure it has only the permissions it needs for the task being performed and use credentials with the shortest possible lifetime. For some use cases, a proxy can help by injecting credentials into requests without exposing the credentials directly to the agent, which ensures the agent cannot use the credentials through an unexpected endpoint it finds access to. 5 Observability: log, audit and monitor agentic AI activity as part of security operationsWhile an AI agent is operating, you need a reliable way to access and analyse telemetry about the activities it's carrying out, both in near real time and afterwards. This should include: - chain of thought traces and transcripts from the AI agent - logging events from the wider sandbox environment - such as access logs, proxies and network traffic This observability telemetry is critical for actively overseeing an AI agent's activities in real time, and for investigating any incidents. Make sure you save and protect these logs appropriately. They may contain sensitive data so you should ensure they are protected from modification or deletion. Where possible, logs should be immutable so you can trust them during an investigation. You should also consider the attack surface created by your log collection infrastructure and whether an AI agent could abuse it to escape from its sandbox environment. Agentic AI activity should be treated as a form of user activity. It should therefore be included in 24/7 security operational monitoring and incident response responses, with appropriate action taken when events arise. This may include running initial experiments in office hours, when more human oversight is available. Once you are confident that all controls are effective, you can expand to overnight or weekend autonomous execution. For more information, follow our guidance on logging and monitoring, and incident management. 6 Make your AI activity easy to attributeIf your AI agent communicates with third-party systems, make it as easy as possible for those organisations to identify that the activity originates from you. Industry methods for doing this are still emerging, but examples include: - ensuring traffic originates from IP addresses that support reverse lookups - adding identifying headers to outbound communications as a form of watermarking, such as HTTP headers If you receive abuse reports or other communications about your AI agent’s activity, manage them in the same way as a vulnerability or abuse report, and follow an incident management playbook. 7 Emergency shutdown: maintain the ability to ‘pull the plug’If an incident is detected or reported, you should always be able to ‘pull the plug’ and halt autonomous AI agent activity immediately. This may mean more than stopping the agentic AI processes. Your controls should cover the wider system, allowing you to rapidly restrict network access to the agentic AI infrastructure and interrupt the communications between selected AI agents and the AI model inference infrastructure. Further reading The advice in this blog should form part of a wider approach to securing AI models and systems. Further information is available in: The ETSI standard, EN 304 223. Baseline Cyber Security Requirements for AI Models and Systems Thinking carefully before adopting agentic AI Careful adoption of agentic AI services AI security is evolving rapidly. As capabilities, use cases and standards develop, organisations should continue to review their controls and assumptions, and ensure that the level of autonomy they grant AI agents remains proportionate to the risk appetite of the organisation.

How BitLocker PINs help protect your data and devices Using a PIN mitigates many BitLocker vulnerabilities. Make sure you’re ready for the next one... The NCSC provides guidance on how to securely configure Microsoft Windows. This includes setting up BitLocker, which encrypts your device to protect the data and the operating system from tampering. Our guidance recommends that BitLocker be configured to require a PIN before decrypting your device. However, many organisations use BitLocker without a PIN, leaving their devices vulnerable. In this blog we explain why a PIN is so important, and what to do if – for whatever reason – you can’t use a PIN. Breaking BitLocker: vulnerabilities and WinRE BitLocker has been under increased public scrutiny in recent months, as vulnerabilities like YellowKey made headlines. By using the Windows Recovery Environment (WinRE), YellowKey was able to bypass certain BitLocker configurations, potentially decrypting drives that should have been protected. Whilst this issue was quickly patched, the severity of this finding left many concerned about the security of BitLocker. What is often missed in discussions around YellowKey is that it is not a new type of vulnerability; bugs in WinRE have been used to bypass BitLocker for years. Preventing these sorts of attacks is one of the reasons why NCSC guidance has always encouraged using a BitLocker PIN. And despite the hyperbolic descriptions of YellowKey’s author likening it to a backdoor, Microsoft have been very public about this. In 2025, Microsoft found and patched four very similar bugs, presenting them at the security conference BlackHat along with a blog explaining how these vulnerabilities work and how to protect against them. If I were trying to hide something, that’s certainly not how I’d start. The NCSC guidance recommends configuring BitLocker to require a PIN, which mitigates the YellowKey vulnerability. The underlying question though, is why do attacks like this keep happening? If WinRE is such a threat to BitLocker, why hasn’t it been fixed? The answer is that this problem is as much about conflicting design principles as it is about individual bugs. WinRE exists to ensure that you can retrieve your data even if something goes wrong. To do this, BitLocker deliberately does not encrypt the files associated with WinRE (because an issue with BitLocker might be the reason you need to recover data). This absence of encryption leaves a gap that can be used by exploits such as YellowKey, and as long as that design decision remains in place, vulnerabilities like YellowKey will continue to be found. This is why configuring BitLocker to require a PIN is so crucial. Requiring a user to authenticate before using WinRE helps to protect an element of Windows that is uniquely exploitable. In this respect, using BitLocker without a PIN will always be a half measure; it is only a matter of time before new vulnerabilities are discovered in an operating system as large as Windows. YellowKey was not the first time WinRE was used to bypass BitLocker, and it will not be the last. What if I can’t use a PIN? The NCSC appreciate that there will be cases where using a PIN is not practical. For example: where multiple users access the same device (such as in a ‘hot desking’ office) where a device is used in time-critical emergencies, so the extra seconds in takes to type in a PIN cannot be spared where a device needs to boot without human interaction (such as in a dangerous environment) Whatever the reason, if you can’t manually enter a BitLocker PIN in your deployment, some of the risk can be mitigated using a number of techniques: Use the same PINIf the only barrier is that users can’t remember a PIN, consider using the same PIN for Windows Hello and BitLocker. This isn’t practical for shared devices with multiple users, but otherwise it provides considerably more protection than not using a PIN, with nothing new for users to remember. Use Network UnlockIf a device is mostly used on a corporate network, consider using Network Unlock. This BitLocker feature allows you to skip the PIN prompt by reading the key from a trusted network. If the device is disconnected from that network (for instance if stolen), then the user will be asked for a PIN. Depending on your environment, this may remove almost all of the PIN prompts you would see whilst still providing a greater degree of protection than not using a PIN. For desktop devices, this is often the best option. Create a Startup KeyA spare USB stick can be turned into a Startup Key, which can provide a different kind of pre-boot authentication. A physical key like this can be lost or stolen, and users with multiple devices may struggle to keep track of several keys. But otherwise, this is a good option. If you do choose to use Startup Keys, ensure that you configure BitLocker to require both the TPM and the Startup Key (as all Windows 11 devices have a TPM). Conditional accessFinally, if there is no way to add pre-boot authentication to your device, consider how you are going to manage that additional risk. For example, you may wish to use conditional access policies to prevent these high-risk devices from accessing sensitive resources. Don’t do nothing Ultimately, you will be best positioned to determine the least disruptive way to protect devices that do not currently use a BitLocker PIN. But whatever you do, don’t do nothing. When it comes to BitLocker vulnerabilities, there will be a next time. Make sure you’re ready for it.

Help shape the future of resilient private 5G The NCSC wants to collaborate with organisations developing technologies and approaches for secure, resilient and deployable private 5G The National Cyber Security Centre (NCSC) is seeking to engage with technology partners, innovators, and industry leaders to explore the next generation of resilient and secure private 5G capabilities. This work is part of our extensive research portfolio contributing to our advice and guidance, shaping our services and the future products that will continue to protect the UK’s most sensitive information and capabilities. Private 5G is rapidly becoming a critical enabler for organisations that need secure, reliable, and high-performance communications. As adoption grows, the focus is moving beyond basic connectivity towards building networks that are resilient, secure, rapidly deployable, and capable of operating in environments where traditional infrastructure may be unavailable, degraded, or under attack. Future requirements for resilient private 5G Private 5G is transforming enterprise connectivity, industrial operations, critical services, remote working environments, and emerging digital applications. However, many deployments still rely on fixed infrastructure, conventional authentication models, and traditional security approaches that may not provide the operational and cyber resilience needed to support future use cases. To address these limitations, the next generation of private 5G solutions should: deploy rapidly with minimal specialist resources maintain connectivity when conventional backhaul infrastructure is unavailable provide enterprise-grade identity and access management detect, withstand, and recover from cyber incidents quickly support flexible and scalable deployment models deliver operational continuity in challenging environments We believe achieving these goals will require close collaboration between industry, innovators, and technology providers. Areas for collaboration To help realise the next generation of resilient and secure private 5G networks, we want to collaborate with organisations developing innovative technologies, products, services and research. We are interested in hearing from organisations with: established private 5G solutions emerging technologies research and development capabilities novel security approaches proven deployment experience innovative ideas that challenge existing assumptions The following areas are our current priorities for collaboration and innovation. 1 Deploying private 5G rapidlyWe are interested in compact, portable private 5G platforms that can be rapidly installed and made operational without compromising the performance, security, and manageability required for enterprise environments. Potential applications include: - temporary operational environments - remote and disconnected locations - emergency and contingency communications - event and venue connectivity - research, testing, and innovation platforms 2 Building resilient connectivity without fixed infrastructureReducing reliance on fixed infrastructure is one of the most significant opportunities offered by private 5G. We are interested in solutions that use wireless mesh networking and Integrated Access and Backhaul (IAB) to create flexible, self-forming, and self-healing communications networks. These capabilities could support: - rapid network expansion - coverage in challenging environments - greater operational resilience - more diverse infrastructure options - lower deployment costs and complexity 3 Enabling secure, identity-based accessAs private 5G becomes more closely integrated with enterprise identity systems, certificate-based authentication is becoming increasingly relevant. We are interested in approaches that explore: - EAP-TLS authentication - PKI integration - zero trust architectures - certificate lifecycle management - enhanced identity assurance for private mobile networks These capabilities could help organisations simplify security management while improving trust and control across enterprise environments. 4 Improving recovery and operational resilienceTo be resilient, private 5G networks need to remain available during incidents and recover quickly after disruption. We are interested in solutions that support the secure backup, protection, and recovery of critical private 5G services and subscriber data. These capabilities could help organisations minimise downtime and restore operations quickly following system failures or cyber incidents. 5 Improving security monitoring and threat detectionPrivate 5G introduces new visibility and security challenges across radio networks, transport layers, and core infrastructure. To address this, our areas of interest include: - 5G-specific intrusion detection - threat monitoring across network interfaces - detection of rogue network elements - signalling and protocol anomaly detection - security analytics and automation - integration with modern SIEM and SOC environments - applying machine learning to enhance threat detection capabilities where appropriate Intellectual Property considerations Organisations responding to this Expression of Interest (EOI) should note that the NCSC expects to retain ownership of any foreground intellectual property created as part of this project. Suppliers would typically retain ownership of their background intellectual property, including pre-existing products, software, tools, methodologies, and proprietary capabilities brought to the engagement. How to respond Organisations interested in engaging with NCSC are invited to submit an EOI by 5pm on 31 August 2026 via email to: Please include your: company name company correspondence address primary contact name primary contact role within the organisation primary contact email address We will use responses to identify organisations for potential future collaboration and procurement opportunities in resilient and secure private 5G. Important notice This EOI is issued by the NCSC for market engagement purposes only and does not constitute a commitment to undertake any procurement, award any contract, or fund any future activity. The information collected through this process will be used to identify organisations with an interest in this area and to inform any subsequent procurement or engagement activities that may arise. Any future opportunities will be subject to separate governance, approval, and procurement processes. The Procurement Act 2023 does not apply to procurement by the NCSC. Commercial Team, NCSC

The aim of the example is not to prescribe a single architecture or implementation. Instead, it demonstrates how organisations can use the NCSC’s Secure connectivity principles as a target state, while making risk‑informed decisions that reflect their own operational context, regulatory obligations and threat landscape. The example highlights how architectural choices, governance processes and operational practices all play a role in achieving resilient OT connectivity. In practice, organisations must balance security, safety, reliability and operational requirements, particularly where legacy infrastructure is involved. Throughout the example, the fictional organisation ‘Admin Corp Water’ works through the eight secure connectivity principles, illustrating how each one can guide design decisions such as reducing exposure, centralising connectivity, managing legacy protocols, strengthening boundaries and preparing for cyber incidents. This worked example has been developed in collaboration with the Industrial Control Systems Community of Interest (ICS‑COI) Boundary Expert Group. The group brings together practitioners from across critical national infrastructure sectors who are responsible for designing, securing and operating the boundaries between operational technology and external networks. Their insights helped shape both the original guidance and this worked example, ensuring the scenarios and design considerations reflect the realities organisations face when operating critical infrastructure. This publication also marks an important milestone for the community. It is the first time the Boundary Expert Group has directly authored content for the NCSC website, working collaboratively with the NCSC to validate the technical approaches against the secure connectivity principles. This model allowed practitioner experience and NCSC guidance to be combined to produce a practical and technically grounded worked example. We would like to thank those in this group who took time out of their busy day jobs to contribute to this work. We hope this approach can be repeated in future. Critical sectors often face different operational constraints, regulatory environments and threat contexts. Worked examples developed with sector experts can help illustrate how NCSC principles can be interpreted and applied in those different environments, supporting organisations to better understand how to turn guidance into practical implementation. By combining NCSC expertise with the experience of practitioners responsible for securing real operational systems, this collaboration aims to make guidance more accessible, more practical and ultimately more effective for the organisations that rely on it.

Making forensic observability the norm for network devices Progress is being made, but too many network devices still remain difficult to investigate after compromise Organisations' firewalls, VPN gateways and other network devices are increasingly targeted by attackers. This creates a shared challenge for both the vendors that build these products and the organisations that buy and operate them. When incidents occur, organisations need reliable ways to understand what happened and assess whether a device can still be trusted. This is why forensic observability matters. It enables defenders to investigate compromise using supported capabilities built into the product, rather than relying on reverse engineering, or specialist vulnerability research – as is still often the case. We are seeing encouraging progress across industry, but there is still some way to go before forensic observability capabilities become standard. Both vendors and buyers have a role to play in making this happen. What is forensic observability? Forensic observability means giving defenders reliable ways to understand what a device is doing, what it has done and whether it can still be trusted after an incident. This includes telemetry, logging, configuration state, and the ability to collect forensic data from both memory and data at rest. It also depends on transparency. When vendors make it easy to understand what software is running on a device – for example through version information or a software bill of materials – defenders can investigate incidents more quickly and confidently. As highlighted at the CYBERUK 2026 Technology Track panel on radical transparency, the NCSC is encouraging vendors to provide greater transparency because small design decisions can significantly reduce the time needed to triage and investigate incidents. The goal is simple: defenders should be able to investigate compromise using trustworthy information provided by the system in a way that makes it difficult for attackers to tamper with it. Why forensic observability matters for network devices But many network devices still provide only limited support for incident investigation. Forensic observability is particularly important for edge devices such as firewalls, VPN gateways and other network appliances. These systems often sit at trust boundaries and are increasingly targeted by sophisticated threat actors. To help address this challenge, in 2025 the NCSC published guidance on digital forensics and protective monitoring specifications for producers of network devices and appliances describing the capabilities that manufacturers should build into network devices and appliances. Incident response should not depend on workarounds Despite this growing focus, incident response on many network devices remains unnecessarily difficult. Too often, defenders must rely on improvised techniques, reverse engineering, or even zero-day vulnerabilities to understand what happened on a compromised device. In effect, they can have fewer tools available to them than the attacker. That should not be normal. Investigating a compromised device should not require discovering or exploiting vulnerabilities in the product itself. Instead, manufacturers should provide supported mechanisms for gathering the evidence needed to investigate incidents, assess impact and restore trust in affected systems. This benefits everyone involved in incident response: Defenders have access to the information they need to determine scope and impact Vendors reduce the need for unsupported investigative techniques Organisations can respond more quickly and confidently without relying on specialist domain knowledge Progress towards forensic observability Encouragingly, we are seeing meaningful progress from parts of the technology industry. Several vendors have begun investing in better logging, forensic data collection capabilities, and greater system transparency. To support this shift, the NCSC has been working with international partners to develop a reference architecture for forensic observability in network appliances and similar devices. The goal is to describe a practical approach that vendors can adopt to provide safe, reliable forensic access while maintaining strong security boundaries. A view from industry Vendors that have invested in forensic observability are already seeing its value in practice. Reflecting on its Pacific Rim campaign, Sophos said: we proved the value of extending detection and response techniques beyond corporate endpoints to firewall devices, and it materially reduced harm to our customers. The experience reinforced a simple principle: you can't just try to protect firewalls, you have to plan for when they fail. The NCSC's forensic guidance builds on that same thinking, giving manufacturers and buyers a blueprint for making network devices easier to analyse when they're compromised. We're using it to guide our own firewall roadmap, and we'd encourage anyone buying a firewall to make it part of their evaluation criteria. Three common misconceptions Despite the progress being made, there are still misconceptions about observability. Doesn’t this help attackers? No. One common concern is that exposing additional telemetry or forensic interfaces will provide attackers with more opportunities to exploit a system. But well designed observability features improve security rather than weaken it. Structured logging, authenticated collection mechanisms, and clearly defined forensic interfaces are safer than forcing investigators to rely on undocumented behaviour, or vulnerability research. Security engineering should assume that defenders will need to investigate systems under pressure and design for that reality from the outset. Won’t customers hate it? No. Another frequently cited concern is that customers may react negatively to increased transparency. But experience suggests the opposite. Organisations responsible for operating critical infrastructure consistently ask vendors for better visibility into the systems they deploy. Clear telemetry and forensic capabilities build trust because they allow operators to verify what their systems are doing and respond effectively when something goes wrong. Isn’t it too difficult? No. There is a belief that implementing forensic observability is too difficult. Although it does require careful engineering, the examples emerging from industry demonstrate that it is achievable. Vendors that prioritise observability early in the design process find that it becomes a natural part of their platform rather than an afterthought bolted on in response to incidents. Observability is ultimately about enabling defenders to do their jobs properly. When systems provide the information needed to understand their behaviour, organisations can investigate incidents quickly, confidently and safely. That is better for vendors, better for operators, and better for the security of the wider ecosystem. What next? Vendors: Following the NCSC’s guidance, build forensic observability into your products early in the design process. Buyers: If your edge devices don’t have this feature, push for it. The fastest route to widespread adoption may be for customers to ask for these capabilities as standard. By making forensic observability the norm, we can help organisations respond more effectively to cyber incidents – strengthening the resilience that underpins the UK’s security and economic growth.

When cyber attacks happen: helping organisations recover A highly disruptive incident can feel overwhelming. New guidance provides a framework for response and recovery. Some say they felt sick. Others say it was like being punched in the stomach. However it hits you, finding out that your organisation is the victim of a highly disruptive cyber attack is a real blow. And as technology evolves and cyber threats continue to grow in scale and sophistication, more organisations are having to prepare for the possibility of serious disruption. Your first reaction is likely to be an emotional one: shock at the news anger that your organisation has been targeted despair as the full impact of the attack becomes clear guilt that the organisation wasn’t as well defended as it could have been All of these feelings – and more – are normal. From day one, victim organisations need to recognise the toll the incident will take on people, work hard to support those dealing with it, and lessen the effects as much as possible. A framework for recovery Our new response and recovery guidance will guide you through a highly disruptive cyber incident. It shows that organisations can and do recover from even the most severe attacks and provides a framework to understand what has happened, deal with the impacts, and move forward to full recovery. The guidance is split into 3 sections, so that you can focus on the key aspects for the challenges you’re facing as your recovery proceeds. The first hours matter First is how to deal with the initial few hours and days, as you’re working out what’s happened, what the impact is and trying to coordinate your actions. It emphasises the importance of swift defensive actions, establishing governance and getting control of communications. It also covers the actions to get onto straight away that will help you further down the line and speed up your recovery. At the NCSC, we see serious cyber incidents all the time so we know the importance of bringing in qualified and experienced help, not just from a technical standpoint but from the reassurance it provides the victim that they're getting the best help available. That’s why we always recommend organisations secure the services of an NCSC-assured Cyber Incident Response (CIR) firm. Building your recovery programme The second stage is focused on building and implementing your recovery programme. This programme is key to getting your organisation back up and running, to minimum viable operations (MVO). Recovering core business functions quickly isn’t just about restoring technology; it’s about enabling the organisation to continue delivering services, supporting customers and maintaining confidence in its operations. All your actions must be driven by a business-led view on your most important business functions. Getting these back up and running, sometimes supported by temporary workarounds, brings you to the end of this second stage. Beyond recovery: rebuilding stronger The last stage is the longer term rebuild. This is a distinct shift from the recovery stage, and focuses on getting the organisation back to business as usual or – better still – stronger than before. It includes ensuring you address the issues that contributed to the incident occurring in the first place, and taking the opportunity to rebuild in a more secure and resilient way. For many organisations, that includes designing and building systems so that fundamentals – such as patching, configuration and access control – are possible and easier to achieve. Prepare before you need it: practice and test Of course, it’s best to prepare and practice for these types of incident in advance. Organisations that act early are often better placed to respond effectively, maintain critical operations and recover more quickly. The guidance will help you develop plans and test your response arrangements before an incident occurs. It’s a bit like training for a marathon. Reading about the race, buying the right equipment and writing a training plan are a good start. But it’s the actual running – regularly putting in the miles and building endurance – that prepares you for race day. In the same way, it’s vital that organisations don’t just document a plan, but actually practice and test their response to disruptive incidents. Testing failover systems, rehearsing shutdown and restart procedures, and rebuilding systems from backups can all provide valuable real world lessons. While tabletop exercises have their place, realistic response exercises can reveal issues that plans alone cannot. This helps organisations to: learn lessons they wouldn’t otherwise learn more importantly, build the ‘muscle memory’ needed to respond effectively under pressure Now it’s up to you to use the guidance to do just that.

Post-quantum cryptography (PQC) migration workshop report No organisation can navigate the migration alone; key takeaways from our first PQC migration workshop. In December 2025, the NCSC and Vodafone, with the National Cyber Advisory Board, hosted the first UK government and industry workshop focused on post-quantum cryptography (PQC) migration. The event brought together security leaders and those responsible for PQC in their organisations from across industry, academia and government. This energising and inspiring day reinforced a simple but critical point; no organisation can navigate the shift to PQC alone. However, you can only fit so many people in a room. So this blog aims to bring insights from the day to a wider audience. Why PQC migration matters As the NCSC has explained, in the future, a sufficiently powerful quantum computer will be able to break the public key cryptography that protects our networks and systems today. The mitigation to this threat is to migrate these systems to use PQC algorithms, which are based on mathematical problems that are not vulnerable to attack by quantum or classical computers. The NCSC has set out key milestones for migration to PQC, which are intended to drive immediate action. While future targets appear distant, 2028 and 2031 will come round quickly, and organisations need to act now to stay ahead. This is because migration to PQC is not just a technical challenge; it’s a global strategic resilience imperative across industries and governments. Why bring organisations together? There is no shortage of guidance on migration to PQC. But guidance alone is not enough. Making the PQC transition efficiently and securely requires close collaboration between experts in cryptography, cyber security and network operations, as well as those who understand the technical and business realities of the organisation undergoing change. For this reason, the workshop was designed to connect experts across disciplines, share real-world approaches and challenges, and build momentum for action through collaboration. In doing so, the following key themes emerged from the workshop. 1 Engaging the board and building the business caseOne of the strongest themes was the importance of executive sponsorship. PQC needs to be framed as a business risk and resilience priority, with a clear articulation of ‘why now?’ and ‘what is at stake if action is delayed?’ The workshop identified the following approaches that can help engage the board: - Emphasise the cost of delay: A strong message was that starting sooner will likely reduce future costs and complexity. Initiating planning and following recommended timelines can help to spread effort over time and reduce the risk of a costly, compressed transition later. - Connect to broader benefits: Link PQC effort to other organisational goals. For instance, a PQC migration programme can help address existing issues like legacy systems and overall cyber resilience. - Make it organisation-specific: Consider what your organisation’s priorities are, and how PQC migration may fit into them. This could include availability of systems, legal compliance, or simply the bottom line. - Identify a senior sponsor: This could be a CTO, CIO, CISO or another individual who understands the requirement and can represent it to their peers at board level. - Use peer and industry benchmarks: Board members often respond to what peers are doing. - Do the pre-work: Consider what activities can be undertaken in advance of (or alongside) engaging the board, to strengthen the business case. This could include engaging with the supply chain, doing initial discovery exercises or identifying critical assets. Understanding this background will help to make both the risk and the ask more concrete. - Prioritise: Prioritise migration of systems where a breach would have the greatest impact (such as those processing the most valuable data) as well as systems that take the longest time to migrate (such as when there’s a dependency on long-lived hardware). - Lay out a phased roadmap: Break the migration plan into clear phases with timelines, targets, required investments and skills/capabilities required for each phase. A step-by-step roadmap gives a structured view of how PQC migration will unfold, setting expectations on budget and resources whilst building confidence that there is an actionable plan. The NCSC’s guidance on PQC migration timelines includes suggestions on how to go about PQC migration planning. 2 Supply-chain readiness is criticalAn organisation’s quantum readiness is dependent on its supply chain and the readiness of suppliers. A key theme from the workshop was the importance of building PQC into supplier security assessments and sourcing. Participants emphasised the need to: - Engage suppliers early: Discussing PQC migration with suppliers should happen as soon as possible. Understanding (and influencing) your suppliers’ PQC roadmaps, as well as making your requirements known, is key to developing a realistic migration plan. Without supplier alignment, even well-planned migration strategies risk falling behind. - Make your requirements clear: An efficient and economical PQC migration will often take advantage of natural technology refresh cycles. This relies on products with PQC functionality (or the ability to be upgraded to PQC) being available when technical updates are planned. 3 Transparency and collaborationMigration to PQC is a complex process that requires expertise and experience across a wide range of topics. Ultimately, collective progress will determine national resilience. No single individual will have all the answers, so we need to work together. Participants highlighted the value of: - Industry transparency: Organisations undertaking PQC migration could publish blogs and reports on plans, approaches, progress and challenges. This would be valuable for organisations who are further behind in the process, particularly those with smaller security teams. Suppliers publishing their plans and progress would allow their customers to manage their own planning. Understanding challenges and lessons learned would help the NCSC to understand key technical issues that would benefit from further government guidance and support. - Cross-sector collaboration: Much of the approach to (and lessons learned from) PQC migration can be applied across sectors. Opportunities for cross-sector collaboration would enable sharing of best practice and re-use of proven approaches. - A united voice from industry and government: Organisations are more likely to invest in (and commit to) PQC migration if their competitors and partners are doing the same. Additionally, the UK will only be resilient to the threat from a quantum computer if all our key services, organisations and suppliers migrate. A united and consistent message from industry and government will support this. - Workshops, events and conferences: Events like this one are valuable for bringing together those who are involved in PQC migration, sharing expertise and learning from the experience of others. What’s next? The NCSC are keen to maintain the momentum of the workshop, and ensure that the conversation – and the action – continues. We are working with National Cyber Advisory Board to shape continued conversations on PQC across industry and government. If you are responsible for PQC migration in your organisation, and you would like to express interest in contributing to future discussions to share expertise and experiences, please get in touch using the PQC workshop feedback form A final thought We strongly encourage those of you with responsibility for cryptography and security to continue to progress your planning on PQC migration in your own organisations and sectors. The first steps (discovery, prioritisation and roadmap development) should be happening now, and will define success later. Meeting the threat from quantum computing may sound like a far-off challenge, but preparing for it is a priority today. By planning your migration now, and working together, we can help build a quantum-safe future for the UK that protects our critical systems, services and data.

Helping small businesses with free, hands-on cyber consultancy Cyber Advisors are offering free 30-minute consultations to help small businesses get started with cyber security. If you’re a small business, cyber attacks may feel like something that only large companies need to worry about. Companies with bigger budgets, more customers – and more to lose. And since you’re focused on keeping customers happy, managing cashflow and your day-to-day business, investing in cyber security can seem more like a costly distraction than a priority. The reality is that smaller businesses are frequently targeted, precisely because they’re less likely to have cyber protections in place. In other words, no business is too small to be a victim of cyber crime. In fact, in 2025, 65% of medium and 46% of small organisations reported a cyber breach or attack. We also know from our own research that many smaller organisations believe that cyber security is too complicated, too expensive, and doesn’t address the real-world risks that small businesses face. To help address this, we introduced Cyber Advisors in 2023, a network of cyber security consultants who’ve been assured by the NCSC to work specifically with smaller organisations. Cyber Advisors aren’t just technical specialists; they understand how to apply the advice from the experts at the NCSC in a way that’s practical, realistic and relevant for smaller businesses. For smaller organisations with limited in-house expertise, knowing where to start can often feel like the biggest hurdle. So many Cyber Advisors are now offering a free 30-minute consultation for small or medium-sized business (SMEs) who are looking to get started with Cyber Essentials, the government's baseline for cyber security. This no-strings-attached, introductory consultation can make all the difference, providing you with an opportunity to ask questions and demystify what can sometimes feel like a complex area. Since the option of a free consultation was introduced, over 760 small organisations across the UK have reached out to us. This has already led to well over 150 small organisations successfully gaining Cyber Essentials certification through this route alone, with more well underway. If you decide to use a Cyber Advisor, you will benefit from expert insights that explain how the 5 steps that make up Cyber Essentials can be applied to your organisation using practical, achievable steps. Whether it’s understanding security controls, identifying quick wins or avoiding common pitfalls, the consultation will help your organisation move forward with confidence. Cyber Advisors can also help you with other free tools from the NCSC. The Early Warning service, for example, warns you about potential viruses and vulnerabilities on your network, so you can act on them before they become bigger problems. If you employ a Cyber Advisor, they will also be able to help set up Early Warning, and use the alerts you’ll receive to improve your cyber security. Another tool, the NCSC’s free Cyber Action Toolkit, is a new way of providing advice in a way that engages small businesses, and more importantly, encourages you to take action. As you work through the toolkit, you’ll build layers of protection around your organisation which defends against common cyber threats such as email hacking, data breaches and ransomware. Ultimately, initiatives like these demonstrate that cyber security is within reach for organisations of all sizes, working across all sectors. With the right support, small businesses don’t need to tackle cyber security alone. You can confidently take practical steps to protect your operations, customers, and data with the support and expertise that’s perfectly tailored to you.

UK and Allies urge critical sectors to improve defences against Russian intelligence targeting New advisory highlights Russian state cyber actors’ global exploitation of poorly configured routers The UK and international allies strongly urge action to better defend against the threat from Russian state intelligence actors Advice follows the opportunistic exploitation of inadequately configured routers and network devices by Centre 16 of Russia’s Federal Security Service (FSB) Warning comes as the UK sanctions Russian state and criminal networks for cyber and hybrid operations and calls out the FSB for a reckless attack on Poland’s energy grid. Organisations in critical infrastructure sectors are being supported to better understand and defend against malicious activity, as the UK and international partners today call out techniques used by Russian Intelligence Services Alongside 18 agencies from 12 countries, the National Cyber Security Centre (NCSC) – a part of GCHQ – has published a new advisory highlighting the methods of Federal Security Service (FSB) Centre 16 cyber actors, who are exploiting vulnerable routers and opportunistically targeting networks belonging to critical national infrastructure (CNI) globally. Sectors most at risk from this global targeting, including communications, defence, energy, financial services, government and healthcare, are subsequently being urged to take action. This includes recommendations to use SNMPv3 and disable legacy SNMP versions, implement strong and unique passwords for network devices, and restrict access to management protocols through appropriate access controls. Centre 16, also known as Berserk Bear, Energetic Bear, Crouching Yeti, Dragonfly, Ghost Blizzard and Static Tundra, has been seen hunting for vulnerable routers by scanning the internet for devices that still use default or weak Simple Network Management Protocol (SNMP) passwords and community strings. Whilst the actor primarily uses SNMP scans to locate and compromise vulnerable routers, they have also exploited well-known vulnerabilities relating to Cisco devices, Cisco’s Smart Install (SMI) feature and web-portal flaws to gain control of network devices. Jonathon Ellison, NCSC Director of National Resilience said: The NCSC, alongside our international partners, have repeatedly exposed the advanced tools and coordinated campaigns of Russian cyber actors who persistently seek to exploit any vulnerability they encounter. “Today’s joint advisory provides decisive, actionable directions from the global security community that network defenders should implement to protect against Russian Intelligence operations and secure the UK’s critical infrastructure. “I’d strongly encourage all organisations, especially those entrusted with UK critical networks, to adopt these recommended measures immediately, thereby reducing the risk of compromise. Organisations are also encouraged to obtain Cyber Essentials certification, the government-backed scheme for all organisations to show they meet the recognised UK minimum standard for cyber security, and make use of the updated Cyber Assessment Framework, enabling them to assess their security maturity, address vulnerabilities and build their resilience against increasing threats. The advisory has been published on the same day as the UK government has sanctioned 24 individuals and entities behind destructive cyber and hybrid operations including cyber criminals involved in proxy networks linked to the Russian Intelligence Services. The UK together with EU member states has also today formally attributed the December 2025 attack on Poland’s energy grid to Russia’s FSB Centre 16 – an attack that if it had been successful could have caused 500,000 civilians to lose electricity. The NCSC has co-sealed this new advisory alongside agencies from Australia, Canada, Czech Republic, Denmark, Estonia, Finland, France, Italy, New Zealand, Poland, Sweden and the United States. It can be read on the NSA website: https://media.defense.gov/2026/Jul/09/2003959498/-1/-1/1/CSA_IMPROVE_ROUTER_HYGIENE.PDF

Cyber Essentials Pathways: from proof of concept to cyber confidence An alternative path to Cyber Essentials Plus certification, without compromising the integrity of the scheme. Large organisations often tell us the same thing. “We want to achieve Cyber Essentials Plus, but the way we operate does not align with the technical controls that Cyber Essentials Plus requires.” Complex architectures, legacy systems, and layered security requirements mean that a purely prescriptive approach can sometimes feel more like a constraint than something that enables better security outcomes. Pathways was designed to respond to this challenge, providing a way for organisations to demonstrate that their controls deliver equivalent (or better) protection, even where they differ from the standard Cyber Essentials model. Essentially, Pathways introduces flexibility without weakening trust. It’s all about giving organisations more than one way to demonstrate that they are achieving the same overall outcome, rather than implementing the individual security controls. It effectively provides an ‘alternative pathway’ to achieving Cyber Essentials Plus certification, without compromising the integrity of the scheme. Over the last 18 months, we’ve been running the Cyber Essentials Pathways Proof of Concept (PoC) to see if organisations can demonstrate that their alternate controls manage the risks covered by Cyber Essentials. This culminated in one of the PoC organisations demonstrating that they could achieve Cyber Essentials plus using the Pathways approach. In this blog we’ll explain what worked with the PoC, what didn't, what needs to change, and what happens next. What we learned The NCSC worked with 22 organisations, alongside IASME and their Certification Bodies, to: test how alternative controls could be assessed against Cyber Essentials requirements in a structured and defensible way understand what additional guidance and governance would be needed Some of what we learned confirmed our expectations, but some of it genuinely surprised us. In areas like patching, network segmentation and the management of unsupported systems, we saw meaningful improvements, even where certification was still in progress. In some cases, patching timelines were reduced dramatically, and previously weak areas (such as BYOD security) were strengthened. This matters because it reinforces a key principle; Pathways isn’t about certification for its own sake. It’s about improving how organisations manage risk in the real world, not just on paper. The Pathways process helped to shed light on where there was still risk and what form it took, allowing the organisation to plan how they would manage it. One of the clearest findings was that organisations were not reluctant to engage, far from it. The barriers weren’t about intent; they were about reality: defining scope in highly complex environments navigating internal governance and decision making understanding what was required, and when These are the practical challenges of operating at scale, and they help explain why progress was sometimes slower than we had expected. The PoC encouraged closer collaboration between organisations and Certification Bodies than in a standard Cyber Essentials engagement. The Certification Bodies didn’t simply assess; they played a much more active role in helping organisations understand their environments, guiding scoping decisions and supporting remediation. This increased engagement led to a better understanding of the intended outcome behind Cyber Essentials requirements. In fact, some organisations - having clarified and adapted their approach - were then able to achieve certification through the traditional route. So Pathways isn’t just about creating an alternative route to certification; it’s also about helping organisations engage more effectively with the scheme overall. Assessing alternative controls is not a simple mapping exercise. It requires a clear understanding of the intended outcome behind each control, and a structured way to assess whether that intent is being met, taking into account risk, coverage, and operational reality. Organisations need to clearly explain how their controls operate in practice, while assessors need a consistent way to evaluate that evidence without creating unnecessary burden. Where the appropriate evidence does not exist, the Certification Body needs to be able to carry out appropriate testing to assure themselves. During the later stages of the PoC, closer involvement from the NCSC helped ensure consistency in decision-making. Without that, there is a real risk of variability in how equivalence is interpreted. Without boundaries, shared understanding, and practical examples, there’s a risk of inconsistency or misinterpretation. These guardrails are essential to allow the Pathways approach to scale effectively. We recognise that a Pathways approach is likely to incur higher costs for organisations than the standard Cyber Essentials route. Assessing alternative controls demands additional effort from organisations to explain their approach, and from Certification Bodies to evaluate that approach and where necessary, undertake further testing. This reflects both the increased complexity and the more tailored nature of the approach, as well as the need for enhanced expertise within Certification Bodies to make sound judgments on alternative solutions. The PoC did what we hoped it would do; it proved that the Pathways model works. However, it also showed where we need to simplify, clarify, and make the approach scalable and sustainable. In particular, further work is needed to refine the methodology, improve usability, and ensure consistent application. During the pilot the increased risk from AI became very clear. At present, we assess that current AI capabilities are primarily being used by more sophisticated threat actors, so do not yet fall within the scope of Cyber Essentials (which is designed to protect organisations against attacks using publicly known tools and techniques). However, we recognise that AI is likely to be used to develop of commodity attacks, and that organisations will have to prepare to patch quickly, more often, and at scale. We are also aware that many organisations continue to face challenges in meeting the 14-day patching requirement following a vendor’s release, as mandated by Cyber Essentials. We will continue to monitor these developments closely and work with DSIT on any future consultation regarding the evolution of the Cyber Essentials control set. What happens next? We’re now ready to take the next step; opening Pathways to a broader (but still carefully managed) set of organisations, and testing how Pathways operates within the existing Cyber Essentials ecosystem, including Certification Body and Assessor qualifications. During this phase, we will build our knowledge of what works in particular contexts, and refine the methodology and supporting guidance. This approach allows us to scale carefully, maintaining trust in the scheme while continuing to learn and adapt. The NCSC will act as the authority for confirming that Cyber Essentials risk is being appropriately managed, working closely with IASME and Certification Bodies. Only when we have sufficient confidence and consistency in the approach will the NCSC step back. If your organisation operates at enterprise scale and believes Cyber Essentials Plus outcomes are achievable but difficult to demonstrate through the traditional CE approach, get in touch to discuss suitability, readiness, and potential engagement routes. Increasing flexibility, maintaining strength Cyber Essentials remains a cornerstone of the UK’s cyber resilience. Pathways isn’t about changing that foundation; it’s about giving organisations more than one way to demonstrate that they are effectively managing the most fundamental risk faced on a day-to-day basis, without lowering the standard. Cyber Essentials works because it is clear, accessible, and trusted and remains just as relevant when countering today’s attacks. Pathways must protect those strengths, even as we introduce more flexibility. We’re really grateful to all the organisations and Certification Bodies who contributed to the PoC. Their openness, expertise and willingness to work through new (and sometimes complex) challenges has been instrumental in getting us to this point. Personally, one of the most encouraging aspects has been seeing how organisations responded when given a bit more flexibility. Not by lowering the bar, but by engaging more deeply with what good security looks like in their environment.

Building more resilient CNI: what industry pen testers told us Pen testers suggest what organisations can do to make their job more difficult. For those of us working in operational technology here at the NCSC, part of our job is to engage with penetration testers. Also known as ‘pen testers’, it’s their job to try to break into systems, poke holes in your infrastructure and find any weak spots. These can then be patched to improve the system’s resilience against attackers who have the same skills, but bad intentions. In this blog, we’ll explain what pen testers told us when we asked: ‘What can organisations do to make your job harder?’ The pen testers all felt that when vulnerabilities are found (and they are rarely absent), it’s much easier to implement remediations if the system is ‘secure by design’, meaning it has been designed with security as one of the key requirements from the outset. Designing systems this way lays the groundwork for many of the technical controls that make attacks more difficult to carry out. One of the clearest examples of ‘secure by design’ is the adoption of network segmentation, particularly where it has been considered as part of the system design rather than added later. Network segmentation involves splitting a network up into smaller segments, either through high-level network design, the use of VLANs or firewalls, or through the management of users or groups with separate accounts for different network areas. OT systems should always be designed with clear separation between the OT control systems and the rest of your business infrastructure: the IT. From a security standpoint, segmentation helps to prevent hackers from moving laterally through your network, hampering pen testers who may have gained a foothold from making further progress. In the context of OT, this can mean avoiding impacts on your process and a potential loss of availability. Segmentation is not just about separating IT from OT; it is about controlling what crosses that boundary. Cross domain thinking helps define zones of trust and tightly manage data flows between them. Secure OT connectivity should minimise exposed connections, standardise access routes, and harden boundaries, while privileged access workstations (PAWs) provide trusted devices for privileged administration, reducing shortcuts and making lateral movement harder. Building on a securely designed and well-segmented environment, logging and monitoring become far more effective. One thing that certainly makes life harder for pen testers (but doesn’t necessarily hinder them) is when a system has: With both of these in place, you can have fun telling your pen tester whenever you see them popping up and trying things in different parts of your system. A purple team approach (a purple team combines blue teaming and red teaming activities) can help ensure that any vulnerabilities uncovered are understood and remediated. We can’t stress enough that even the best logging and monitoring capability is useless unless an organisation collects the right data, and responds to that data in the right way. Make sure that alerts are properly investigated, and that incident response plans are built, regularly communicated, and exercised with your teams. The NCSC has published extensive guidance on the topics above. If building a system from scratch, be sure to take into account our secure design principles. We also have pointers on how to implement effective logging and monitoring. If you are looking to have a system pen tested, and we recommend that you do, please consider one of the organisations on the NCSC’s list of assured providers, part of our CHECK scheme. If you are looking to pen test a system that includes operational technology, ensure that the people you hire have relevant experience in this area. Without this, a pen tester could miss vulnerabilities that may exist in that particular environment or, worse, could have unintended effects on your system that have real-world consequences. The points we cover here aren’t a complete checklist for defending a system against cyber threats, but they might just make pen testers work that bit harder to earn their fee.

The 'vibe coding spectrum' approach to AI-assisted software development Different code deserves different levels of oversight, so calibrate your approach to ‘vibe coding’ accordingly. AI-assisted software development has taken off. By now, most people are familiar with the term ‘vibe coding’; giving an AI agent a high-level prompt and letting it build your application with significant autonomy. You prompt, it codes, you review the output, rinse and repeat. The NCSC have previously written about the effects this could have on cyber security. And if you care about security, vibe coding can feel uncomfortable. AI models are trained on vast amounts of existing code, and some of that has security issues. When you let an AI loose on your code base with minimal oversight, there's a real risk it produces code with security vulnerabilities, with a measurable security gap in AI generated code (pdf). The other issue is that your code base could become complicated and confusing to understand, leading to further issues down the road with maintainability. Does this all mean that you shouldn’t use vibe coding? Not necessarily. It depends on what you're building. Vibe coding isn't always bad Here's the thing: not all code is security critical. A proof-of-concept to demo an idea to stakeholders? The risk profile is low. An internal tool for your team with limited risk? Maybe that’s manageable. Full vibe coding in these contexts can often be perfectly fine. But authentication logic for a public facing website? Code that processes sensitive customer data? Anything handling secret tokens or credentials? Safety critical code in a CNI system or code responsible for flying an aircraft? That's a different story. The consequences of getting security wrong in these areas can be severe: data breaches, compromised accounts, regulatory violations or worse. The risk isn't in using AI. The risk is not applying the right safeguards when the stakes are high. It's about recognising that different code deserves different levels of care and oversight. The vibe coding spectrum Vibe coding isn't binary. It exists on a spectrum, and you can position yourself anywhere along it depending on your context and risk tolerance. On the left: Manual human coding with some AI assistance. You're writing the code yourself, but your IDE offers AI-powered autocomplete. You press tab to accept suggestions, or you don't. You're in full control — the AI is just offering helpful tips. On the right: Full vibe coding. You provide a high-level, sometimes ambiguous prompt, and the AI has autonomy over architecture, code, modules, and tests. You might iterate through several prompting loops, but you're not editing or deeply reviewing the code — you're evaluating the output and prompting again if needed. In the middle: A large grey area in between with many variations. Maybe you're asking the AI to write specific functions or methods while you handle the architecture. Maybe you're writing tests manually and letting the AI implement code until those tests pass (test-driven development). Maybe you're specifying modules and reviewing what comes back. There are countless combinations here. It's about oversight, not avoidance Let's be clear; this isn't about saying ‘don't use AI for security-critical code’. AI can absolutely help you to write authentication logic, data processing pipelines and check your homework. The question is ‘how can you do this safely?' When you're building a mock-up to pitch an idea, letting the AI crack on with minimal supervision is fine. When you're building the authentication system that protects your customers' accounts, you need more rigour. You need to: reviewwhat the AI produces understandthe code checkfor vulnerabilities verifyit does what you expect When you do these oversight activities, you could even use another AI agent to help you. You also need to architect the wider system around your code, to minimise the impact of exploitation. Choosing your position The NCSC recommend that you think carefully about what you're building, understand the risk, and then slide along the spectrum accordingly. For example, you might slide right (towards ‘full vibe’) when: building prototypes or proof-of-concepts where speed is of the essence creating demos to communicate ideas working on internal tools with limited exposure no sensitive data or security functions are involved Slide left (towards manual) when: building authentication or authorisation logic processing sensitive personal data handling secrets, tokens, or credentials. anything safety critical, for example in Critical National Infrastructure (CNI). the consequences of a security flaw would be significant The NCSC worked with other governments, industry leaders and cyber security experts in ETSI’s ‘Technical Committee on Securing AI’ to develop Baseline Cyber Security Requirements for AI Models and Systems. You should consider these requirements (pdf) when you think your risk profile moves to the right of this spectrum. Looking ahead AI models are improving rapidly. It's possible that we'll trust vibe coding more overtime as models become more reliable and their outputs become more trustworthy. The spectrum might shift; what feels risky today might feel routine in a year. But we're not there yet. Calibrate your approach based on today's reality, not tomorrow's potential.

Software supply chain attacks: check your dependencies Attackers are compromising open source packages to spread malware. Cyber defenders are asked to review dependencies to reduce risks Modern software development has transformed how software is created, shared and reused – but recent attacks on these tools highlight the rapidly growing risks of using modern software ecosystems. Attackers are compromising open source packages at scale to spread malware in ways that can be difficult to detect and can do extensive damage. This blog, aimed at cyber security professionals, exposes the insidious nature of recent attacks, underlining the growing threat from software supply chains, and how attackers are able to exploit them. We explain how organisations can check if they have been affected by such a supply chain attack, and recommend actions to take to mitigate compromise and prevent further spread. This blog helps cyber defenders to better understand, mitigate and more effectively respond to the new open source software risks. Software supply chain attacks are evolving Widely used platforms and ecosystems enable developers to develop, collaborate and re-use software at a global scale. This allows teams to build software faster and reuse widely trusted components, that are secure, reliable and maintainable. But these ecosystems also create an increasingly complex set of dependencies. A single application may rely on a large number of third-party packages – including libraries, frameworks, snippets, software development kits, and others. Some of these will be less trustworthy than others. As an example, Node.js, Rust and Python are unusually exposed as they have minimal standard libraries. This increases use of third-party dependencies, and delegation of basic functionalities, and results in a heavy reliance on external registries. Moreover, many of these components are retrieved automatically through continuous integration and continuous delivery (CI/CD) pipelines, often without human intervention. It is this combination of automation, trust and scale which means that malicious code introduced into a single package can spread rapidly across many organisations and services before detection. Recent attacks show a changing and growing threat Recent attacks affecting widely used package managers such as npm and PyPI demonstrate how attackers have focused on maliciously exploiting the complex modern software supply chain. For example, in the May 2026 Mini Shai-hulud supply chain attack, the developer ecosystem – including CI/CD systems, package registries and developer tooling – was used to propagate malicious software. Damage from this attack was limited thanks to the speed at which it was discovered, but subsequent similar supply chain attacks have gone undetected for longer and spread more widely. How the modern software development ecosystem can be exploited The following are features of the modern software ecosystem that attackers are successfully exploiting at scale: Targeting developer environmentsDeveloper devices are usually less tightly controlled than managed corporate devices, which further increases the likelihood of compromise and credential theft of shared code or package registries. Rapid propagation across ecosystemsA single malicious package may spread quickly across downstream software products and services. The impact of compromising a lesser known, but critical, software component can have significant and far reaching impact for many organisations and systems. This complexity is especially visible in Node.js, as its highly modular packages depend on many smaller components. A single dependency may introduce a large number of transitive dependencies. Abuse of automationRecent attacks have exploited the considerable implicit trust in CI/CD and automation pipelines. The automation of updates, installation, and execution of scripts and packages allows attackers to execute malicious code. For example, Node.js and Python support scripts that execute on installation, and allow a malicious package to be run immediately. Without human intervention or approval, the code can simply propagate. Open publishing models increase exposureAnyone can upload a package, and maintainers are often implicitly trusted. While there are security controls for maintainer registry accounts, these are not currently enforced by all registry providers, for example, in the absence of globally enforced multi-factor authentication (MFA). Software ecosystems are taking action to address some of these issues, but organisations also need to take action to identify and manage the risks that arise from these attacks. Common attacker techniques You should be aware of the following methods seen in recent attacks: Maintainer account compromise - Attackers steal credentials or tokens that allow a malicious actor to update a trusted package. Abandoned package takeover - Attackers take over ownership of expired domains connected to package maintainers, or otherwise transfer ownership of a previously legitimate package. Typosquatting - Publishing packages using similar names or misspelling popular legitimate packages in the hope they are installed by mistake. Self-propagation - Using the credentials or tokens stolen from a previous attack to access or modify additional packages. How to identify if you’ve been affected You should take the following steps to assess exposure: Review dependencies - Audit recent package updates and version changes - Identify newly introduced or unexpected dependencies Monitor for unusual behaviour in: - CI/CD activity - network traffic - credential use Scan for known issues - Use dependency scanning tools to detect compromised packages Check developer and registry accounts - Look for unauthorised access or token use Maintaining a clear inventory of all software dependencies is critical – and we recommend reducing the size and complexity of dependencies wherever possible. This inventory can take whichever format suits the processes and culture of the organisation, such as a software bill of materials (SBOM). Immediate actions to reduce risk If you suspect you have been affected – or as a precaution – you should act quickly to reduce risk. Immediate actions include the following: Pause automatic dependency updates where compromise may be present. Review and approve new updates, dependencies or versions manually. Rotate exposed or potentially exposed credentials. Enforce MFA for developer and package registry accounts. Use private or trusted registries where appropriate. Strengthening your development approach These attacks highlight the need to revisit how dependencies are introduced and managed, as part of a secure development lifecycle (SDLC). Whilst Node.js, Python and Rust are considered higher risk for these attacks, it’s important to be aware that other languages, tools, and package repositories are also at risk. Use the Software Security Code of Practice We recommend you refer to the Software Security Code of Practice which provides a foundation for strengthening software development and supply chain management in organisations. In particular, you should: Review how dependencies are introduced and updated. Avoid automatically adopting new dependency versions without review. Find a balance between deploying patches quickly and updating dependencies slowly, to minimise the impact of compromise. Ensure deployments occur through controlled CI/CD pipelines rather than developer devices. Store sensitive credentials securely, avoiding exposure on developer workstations. Recent attacks have also targeted API keys and tokens used by developer tooling. If compromise is suspected, these credentials should be rotated immediately. In its SSCoP implementation guidance, the NCSC provides useful advice on understanding and assessing risks associated with third-party software dependencies. It will be updated shortly to include advice relevant to countering the new attack scenarios outlined here.

Designing secure access with ZTNA ZTNA is widely deployed, but often still built on old trust assumptions. New NCSC guidance explains how to design ZTNA architectures aligned with zero trust principles. Zero Trust Network Access (ZTNA) is often introduced to modernise access to applications. However, without changes to the underlying design, these deployments can continue to reflect older models of trust. In many cases, ZTNA tools are deployed in environments that still treat network location as a primary signal of trust. This means the tools may be new, but the underlying approach continues to rely on broad, network-based access rather than more granular, context-driven decisions. Our new guidance explains how organisations can design and implement ZTNA in a way that better aligns with zero trust principles, and supports modern network environments. The guidance focuses specifically on network access within a broader zero trust architecture. It: This guidance does not redefine zero trust, or prescribe a single technical solution, and is not intended to be used as a checklist or compliance framework. ZTNA decisions should always be shaped by an organisation’s users, systems, threats, and operational constraints. This guidance is primarily aimed at architects, security practitioners, and technical decision-makers responsible for designing or evolving access architectures. It will be useful whether you are: We recommend starting with the introductory sections to build an understanding of the core concepts of ZTNA before moving on to the sections on prerequisites and design requirements to help plan and implement your architecture. The final section on anti-patterns is particularly important because we see many ZTNA deployments fail, not because of missing technology features, but because legacy trust assumptions are carried forward into new designs. As with all the NCSC’s zero trust guidance, ZTNA should be considered as part of a wider architectural approach, rather than a standalone solution. If you have feedback on the guidance, please contact us at [email protected]

Agentic AI tools are starting to appear in real organisations, not just research labs. These tools don’t just generate content or predictions; they can plan, make decisions and take actions on your behalf. This capability can be beneficial, including in cyber defence, but it can also introduce new risks if used without care. 'Careful adoption of agentic AI services’ is new joint guidance, co-authored by the NCSC with international partners, that sets out why organisations should start small, use agents only for low-risk tasks, and apply established cyber security controls from the outset. This blog summarises the key points from that guidance, and will be of use to anyone involved in the design, development, deployment and operation of agentic AI systems. What is agentic AI? Agentic AI represents the next step for the most advanced generative AI (also known as ‘frontier AI’). Rather than outputting a prediction or new content, agentic systems can access data sources, remember context, make decisions, use tools, and take actions in pursuit of a goal. They can operate without continuous human intervention and even create sub-agents to complete specific tasks. This is what makes them useful, but also more hazardous than non-agentic AI tools. Agentic AI increases the risk Many risks associated with agentic AI are not new: access control, secure development, supply chain risk, monitoring, incident response and accountability are all still relevant concerns. Agentic AI systems also inherit known LLM risks like susceptibility to jailbreaking and prompt injection, with security challenges evolving as the technology matures. However, the extra autonomy and complexity of agentic systems can increase the attack surface and make behaviour harder to predict, test and govern. Additional risks include: broader access – agents can be permitted to access external systems, data and tools in ways that non-agentic AI systems are not unpredictable behaviour – especially when goals can be interpreted in ways that a human would not expect harder to spot problems – particularly when actions occur faster than humans can meaningfully review them challenging to explain – while the workings of non-agentic frontier AI systems are notoriously difficult to interpret, the range of behaviours and tools available to agents make it even more challenging to explain a particular course of action Approach adoption very carefully If an agent is over‑privileged or poorly designed, a single failure can quickly become a serious incident. It is crucial, therefore, to think before you deploy. Specifically you should: consider what could go wrong and how failures or misuse could affect operations reflect on whether AI is really needed, or whether a process could be simplified, removed or automated in a lower-risk way deploy agentic AI incrementally, starting with tightly bounded pilots using clearly defined tasks, and build confidence in the system before you expand the scope Develop and adopt agentic AI with security in mind Think about what could happen if an agent misunderstood its task, exceeded its intended scope or was manipulated, and never grant an agent unrestricted access to sensitive data or critical systems. Ensure you maintain ongoing visibility of the system’s operation, and understand how to retain meaningful human oversight and control. If you cannot understand, monitor or contain an agent’s actions, it is not ready for deployment Insist on human accountability A system may take an action, but humans remain accountable for: the decision to deploy it the access it was granted the safeguards around it the consequences of its operation You should be clear about who owns an agentic system, who approves its access, who monitors its behaviour, who reviews incidents, and ultimately who can stop it. These responsibilities should be defined before the agent is connected to real systems or data and, crucially, responsible individuals should be empowered and incentivised to intervene if necessary. Apply cyber security best practice As ever, following established best practice remains the starting point. Agentic AI risks and mitigations should be aligned and integrated with your existing security model and risk posture. ETSI EN 304 223: Securing Artificial Intelligence (pdf) outlines baseline cyber security requirements for AI systems writ large, including agentic systems. Practical steps include: apply least privilege – give agents only the minimum access they need, for the shortest time required limit scope – constrain what an agent can access, what actions it can take and when it can take them avoid long-lived credentials – use temporary credentials where possible and revoke elevated access when tasks are complete use secure defaults – design applications with safe configurations, secure protocols and appropriate validation understand dependencies – manage supply chain risk for third-party components, models, tools and integrations monitor behaviour – look for unusual or unexpected activity across tools, workflows and connected systems threat-model the deployment – consider how the system could be misused, manipulated or caused to behave unexpectedly plan for incidents – ensure response plans cover agentic AI failures, misuse and loss of control A cautious but practical approach Agentic AI is likely to offer significant benefits in many scenarios, particularly where tasks are repetitive, well-understood and low risk. The NCSC understand the desire to realise these benefits, and are encouraging responsible, thoughtful, and scalable adoption. Start small, apply existing cyber hygiene and governance from the start and plan for failure (including how you would respond to it). For more detailed mitigations, please refer to the full Careful adoption of agentic AI services guidance.

10 questions to ask when using AI models to find vulnerabilities Using artificial intelligence to find vulnerabilities can bring added security considerations. By now, most people will have heard the news. There is a new AI model in town, and you are feeling under pressure to use AI to to find vulnerabilities. Everyone is saying it will improve your security, and the board want to hear how many vulnerabilities you have found. So you set up an account with a popular AI model, hand over access to all your code, historic bugs and documentation, and give it access to your production environment.... HOLD ON! Let’s stop and think for a minute. Before you start using an AI model to find vulnerabilities, there are some important questions you should consider. 1. What are you trying to achieve by using AI? Hopefully your answer is ‘to improve security within my organisation’. However it’s important to remember that just finding vulnerabilities does nothing to improve your security. You could even make your security worse. 2. Is using AI the best way to improve security? The most important tool to improve your organisation’s security is the application of fundamental cyber security hygiene. A vulnerability on a system where a patch for it exists (but has not yet been deployed) or unauthorised access are much more likely to affect security than the exploitation of zero-days. So ask yourself, is your organisation carrying out best practice? Do you understand what software you rely on. What IT is in your estate? 3. Do I have a process to manage any vulnerabilities that AI finds? You need to be able to manage vulnerabilities well, whether found using AI or not, especially as the number of reported vulnerabilities increases. You want to know how to receive, prioritise and fix issues, without teams being overwhelmed. Make sure you consider fixing the cause of the vulnerability too. The NCSC’s Vulnerability management guidance is a useful resource for those looking to set up and improve their process. 4. How should I prioritise vulnerabilities? A system or product might have a lot of vulnerabilities, but the ones that attackers can exploit are the ones that need prioritising. Some vulnerabilities you might fix immediately, others might indicate you need a major rewrite to parts of code, or that you need to remove that attack service from your environment. There were over 40,000 vulnerabilities assigned CVEs in 2025. The CISA KEV says only about 400 new vulnerabilities were tracked as exploited, and only around 40 of those were zero-days when initially exploited. This is why prioritised patching is so important. 5. What are the risks when using AI to find vulnerabilities? Using AI isn’t risk free and there are many security implications to consider. These include: How could I leak information? How will I secure the infrastructure used? Have I sandboxed my system so that it can only talk to the LLM and my code base? Will I give access to my production environment? What permissions have I given the LLM? How can I avoid spending all my money/time/people finding vulnerabilities, and have nothing left to fix them? Do I understand the terms and conditions, and data retention policies? How will I ensure the activity is legal? 6. What AI model should I use? Different models have different properties. You don’t necessarily need access to the latest model; you can start using any model as this will build your experience and gives you an idea of the model’s capabilities. Before using a hosted model, the NCSC recommend you consider: the physical location and legal jurisdictions which apply to the hosted models any laws in that location and jurisdictions related to vulnerabilities 7. Where should I start? When using AI to find vulnerabilities prioritise your external attack surface. You should also look for ways to verify the results, by using both AI and humans. 8. What’s my long term plan to deal with new AI models? The NCSC's view is that keeping pace with frontier AI cyber developments will almost certainly be critical to cyber resilience for the decade to come. New models will come out, they will have different capabilities, and we expect these to improve. Therefore, you need to consider: How you are going to resource this long term? How will you respond to new models? How are you going to engage with your customers? How are you going to help customers if they are reluctant to install any updates? How are you going to respond to vulnerabilities found in devices/libraries/services you use? 9. Where do I need to invest in people? AI is a tool that attackers and defenders will use. Organisations will benefit from combining the capabilities of AI models with staff who understand security. We believe that AI models accelerate the skills of cyber security staff; they don’t replace them. 10. Do I know how everything we develop or use is patched? It’s really important to understand the patching regime in your organisation, and think about how it’s going to change over the next few years. The first step for many organisations involves understanding the entirety of their estate, and identifying the critical products and services. Good asset management and dependency management are crucial. These are the questions to ask yourself before using AI to find exploitable vulnerabilities. In the meantime, the NCSC will continue to publish content to help security professionals make sense of the fast-moving world of frontier AI.

Preparing for a ‘vulnerability patch wave’ Organisations must act now to prepare for a wave of patches that will address decades of technical debt. Whether they are technology producers and vendors, or consumers and operators, all organisations have ‘technical debt’; a backlog of technical issues – that is both expensive and time-consuming – as a result of prioritising short-term gains over building resilient products. Artificial Intelligence, when used by sufficiently-skilled and knowledgeable individuals, is showing the ability to exploit this technical debt at scale and at pace across the technology ecosystem. As a result, the NCSC expects there will be a ‘forced correction’ to address this technical debt across all types of software, including open source, commercial, proprietary and software as a service. This is why we are encouraging all organisations to prepare now for when a ‘patch wave’ arrives; a rush of software updates that will need to be applied across the technology stack to address the disclosure of new vulnerabilities. Prioritise external attack surfaces All organisations must take steps to identify and minimise their internet-facing (and other externally-exposed) attack surfaces as soon as is possible. As we’ve argued for some time, you should prioritise technologies on your perimeter and then work inwards covering cloud instances and on-premises environments. By doing this, organisations can reduce the risk that latent vulnerabilities pose when they become known and exploited by attackers. Where organisations cannot apply updates across their entire environment, they should prioritise applying updates to their external attack surfaces. Where capacity extends beyond the external attack surface, organisations should prioritise critical security systems. It is also important for organisations to realise that patching alone will not always suffice; some technical debt may be present in ‘end of life’ or legacy technology that is out of support, and so can’t receive updates. In such instances, organisations will need to replace technologies, or bring them back within support, especially where it presents an external attack surface. Prepare to patch quickly, more often, and at scale Building on the principles contained within our Vulnerability Management guidance, organisations should make plans to deploy software security updates quickly, more frequently, and at scale, including across their supply chains. We are expecting an influx of updates to address vulnerabilities across all severities, and expect a number to be critical. The NCSC recommends that: where automatic secure ‘hot patching’ is available (that is, patching that doesn’t involve service disruption), this should be enabled as a priority where automatic updates are available (including for embedded devices), this should be enabled to reduce the workload on support teams where neither of the above are available, organisations will need to ensure that processes and risk appetites support frequent and scaled-updating, noting the operational trade-offs around disruption and safety critical systems. A risk-prioritised approach such as the Stakeholder Specific Vulnerability Categorisation (SSVC) system can be used to prioritise installing the updates However, should a critical vulnerability be under active exploitation (especially one affecting an internet-facing system), then it is essential to accelerate the update process. Organisations can refer to the NCSC’s new guidance on ‘Responding to active exploitation of vulnerabilities’ for more information. To summarise, you should put in place a policy to ‘update by default’ where you always apply software updates as soon as possible, and ideally automatically. This should be at the core of your update management process, but we recognise that it may not apply in some circumstances (such as for safety-critical systems or operational technology). Beyond software updates Patching alone won’t address the systemic problems that my previous blogs have addressed. I’ve appealed to technology producers and vendors to ensure systemic technical security debt is minimised by including - where appropriate - memory safety and containment technologies such as CHERI and others. Similarly, for consumers and operators, a focus on cyber security fundamentals to raise resilience and to reduce the impact of breaches should be a priority. This includes adopting and fully implementing Cyber Essentials, or the Cyber Assessment Framework for organisations operating essential services (such as energy, healthcare, transport, digital infrastructure and government). For organisations facing elevated threats, the NCSC has also recently produced guidance on: Prepare for the patch wave now In conclusion, the NCSC advises all organisations, irrespective of size, to plan and prepare for the vulnerability patch wave. A good place to start is by reading the NCSC’s updated Vulnerability Management guidance. For larger organisations, we also recommend working to gain assurance from your supply chains both commercial and open source, so that they are prepared to navigate any required response.

Could your choice of metrics be harming your SOC? Poor metrics can render a well-intentioned security operation centre entirely ineffective. Security operation centres (SOCs) are a key defence in organisations, where skilled analysts use tools to hunt for attacks in the haystacks of logs. Unsurprisingly, SOCs are usually expensive to run, with costs that include staff, licenses and storage. As both an important defence and a pricey one, organisations are understandably keen to measure and assess SOC performance, whether the SOC is internal or outsourced. As SOCs typically use ticketing processes to track the handling of detections and incidents, a common approach is to evaluate a SOC's effectiveness by using the same key performance indicators (KPIs) or service level agreements (SLAs) used by other ticket-centric IT departments, such as IT service desks, customer support, or development teams. This will typically include measures like ‘number of tickets processed’ and ‘time taken to close a ticket’. SOC-specific metrics are also included, with a heavy focus on anything that can be: easily expressed numerically explained to staff who aren't security specialists Common examples include ‘detection rules written’ or ‘volume of logs collected’. Unfortunately, many of the most common SOC metrics provide no insight to seniors about the effectiveness of the SOC. In fact, inappropriate metrics can even distract and in the worst case harm a SOC's ability to detect and respond to attacks. The NCSC have seen SOCs with great potential rendered entirely ineffective through poor choice and application of metrics. How can metrics blunt a SOC? A consideration when applying metrics is that if they’re used to quantify performance, then staff are incentivised to ‘optimise’ metrics, and this can lead to some perverse outcomes. Let's consider some common SOC metrics, and how they can unintentionally degrade a SOC's ability to detect threats. Metric 1. Number of tickets processed When a suspicious pattern in logs triggers an alert rule, it typically produces a ticket for analysts to triage. The analyst assigned to the ticket then has to assess the alert, and make a call whether it might be: a real attack requiring escalation into an investigation/incident or a false positive due to a quirk of the alerting logic In the vast majority of SOCs I've observed, alert logic leads to a lot of false positives. I’ve seen ticket-focussed SOCs where as many as 99% of tickets were being triaged as false positives. This means that an analyst being measured on ‘number of tickets processed’ is incentivised to quickly find a reason to close it as a false positive, rather than to escalate or investigate it. Metric 2. Time taken to close a ticket Similar to the above, but the analyst is now also incentivised to click ‘false positive’ as quickly as possible. Metric 3. Number of detection rules A subtly dangerous metric as the benefits seem self-evident. It seems logical to presume that the more rules there are to 'detect bad things' will result in more chances to 'detect bad things'. Unfortunately this is rarely the case. Such a metric almost always leads to the perverse outcome of ‘alert inflation’; analysts are incentivised to write as many rules as possible, so the metric goes up. However, this leads to false positives as well as ineffective rules. At its worst, I've seen individual rules for individual Indicators of Compromise (IOCs) like an IP address. Metric 4. Volume of logs collected vs value of logs collected Effective detection needs good logs, and whilst logs are very useful for incident investigation, logs on their own won't help with detection. I've seen too many SOCs that are ingesting ever-increasing volumes of logs, but those logs often either have limited detection value, or the SOC isn’t using the logs for detection (no relevant alerts, or threat hunts that require those logs). I visited a SOC where one of their largest log feeds by volume had never been set up correctly, so they only had the first 30 characters of each entry. However, this had never been noticed, so they were not carrying out any meaningful alerting. Worse still, collecting increasing volumes of logs with limited value generally means the existing logs can be retained for less time (as additional logs will incur additional cost, or take up disk space) How should you measure a SOC? There is only one metric that shows a SOC’s efficacy: does it detect (and respond to) attacks in a timely manner? This is commonly metricised as ‘time to detect’ (TTD), ‘time to respond’ (TTR), or ‘mean time to detect/respond’ (where there is enough data to make a mean useful – for instance where a managed security service provider covers many organisations). However, this can be tricky to measure as an organisation's defence in depth means it should be a very rare event for an attack to make it into the organisation’s environment. As such, organisations may be unable to distinguish between: the SOC is effective but there aren’t many successful attacks successful attacks are or could happen, but the SOC is missing them To navigate this ambiguity, organisations can use red teaming and purple teaming to simulate attacks from the types of attackers that are more likely to target the organisation, and both techniques allow assessment and development of a SOC's ability to detect. The covert nature of red teaming can more accurately mimic a real attack, but purple teaming can often provide better value to a SOC (as the time saved through ‘not being covert’ can be put into greater coverage of attack paths). Another approach involves breaking down an attack into component (or atomic) stages, typically based on the MITRE ATT&CK framework, and conducting each stage in isolation as a test case that can be assessed as detected and escalated (or not). For example, ‘searching for passwords in a SharePoint’ could be a discrete step in many different attack chains. Some organisations then automate the steps on a regular basis, to test whether they are detected as part of reporting the TTD/TTR. This can be useful, but risks the perverse outcome of a SOC only detecting a specific/automated way of executing the step. In this example, if the organisation had a rule for people searching SharePoint for ‘password’, then an attacker searching for ‘passw’ might not trigger an alert. Seeing the assessment as something to hone the SOC (as much as test it) can help avoiding this trap. Whilst TTD/TTR are the only reportable metrics that demonstrate a SOC is working, a SOC manager is likely to want to track a number of other metrics to help them monitor the week-by-week health of their service. These metrics could include things like numbers of tickets, but crucially, those metrics should not be reported outwards (or arguably inwards, to the SOC analysts) lest they drive the wrong activities. What activities should help timely detection of an attack? If we accept (or a red / purple team assessment has proven) that a ticket-focussed SOC is less likely to detect attacks, what things can be done to increase the chances the SOC team will detect attacks? Opinions differ around this, but I’d argue that it requires focussing on analysts as threat and tech-aware, enabled experts, rather than a triage layer for tools and alerts. Effective detection needs analysts who: understand the systems they're protecting understand the threats are expert in the tooling they use have the data they need to spot abnormal behaviour are given the time to put it all together and hunt for threat Given the above, I’ve found a number of useful approaches: 1 Hypothesis-led threat huntingIn my opinion, threat hunting is the most effective activity a SOC can engage in. I generally favour ‘hypothesis-led threat hunting’. In this, an analyst (or team of analysts) creates a hypothesis for an attack that might be happening based on understanding likely attackers and their techniques, or on a tip-off of a specific attacker and their techniques. The analyst then looks to understand the techniques and searches for evidence in logs. In many cases the analyst won't find anything, but the real output of a hypothesis-led threat hunt is the increased understanding of the techniques, and the alerts (or hardening suggestions) that the analyst proposes following the hunt. 2 Maximal true positives / minimal false positivesEvery false positive harms your SOC by both distracting an analyst, and by incentivising them to expect false positives. SOCs should maintain hard thresholds for false positive rates when evaluating whether a detection rule is suitable for acceptance. Achieving this whilst detecting suspicious behaviour is hard, but is possible through understanding the organisation and its systems, and whittling down known false positive situations. A crude example is looking for PowerShell execution by anyone who isn't in an IT role, and then working down the few false positives that remain when writing the rule, so that any new PowerShell is an attack (or needs adding to the exceptions). A useful practice, particularly for a SOC transitioning from ticket-focus to analyst-focus, is a regular (fortnightly or monthly) review of any rules that are generating false positives and re-evaluating the detection logic or exceptions. 3 Awareness of threatsAnalysts need to know what they're hunting for, so metrics around their awareness of threats can be useful. This can be expressed in different ways such as completeness of documentation around a threat actor, or training, reports read and actioned. The MITRE ATT&CK framework is useful for breaking down the problem, and provides tools for seeing which attack steps are used by different attackers, allowing an organisation that understands which attackers may target them to prioritise learning into specific techniques. 4 Expertise in toolingTracking analyst skill development on the SOC’s tools through training and certifications is a useful exercise. The challenge is doing this whilst making sure analysts remain comfortable working across different tools, rather than getting hyper-focused on their preferred tool. 5 Engagement with the wider organisationAnalysts need to know ‘what normal looks like’ so they can detect abnormal activity. This means they need to understand their organisation, its staff, its systems, and how it functions. Metrics can include organisational systems/departments that are documented by the SOC. If a SOC is doing their job well, they will be spotting things that are anomalous (and potentially suspicious) that logs alone don't explain. The analyst will sometimes need to contact the user involved to get to the bottom of it. Such engagement is a great indicator as it suggests the SOC is spotting anomalies, but also the effect on the user is typically to inspire ‘good future security practice’, as long as the analyst is professional and not seeking to blame the user. IT admins/operations are a department that the SOC will often need to work with for various reasons, and the relationship should be bilateral. Tracking the net promoter score of the SOC by admins (and vice versa) can indicate whether there are issues in the relationship. 6 Analyst satisfactionA SOC job should be rewarding and involve learning about attackers, understanding techniques, applying it to data, and working with people across an organisation. If things are working well then analysts overall satisfaction should be high, whilst poor metrics or culture can often indicate miserable analysts. An overall measure of satisfaction such as net promoter score can help track this. 7 Relevant coverageWhilst log volume can be a misleading indicator, log coverage can be useful where the SOC understands the specific data it would need to detect attacks. Organisations often use the MITRE ATT&CK framework to assess the types of logging coverage needed for attacks of concern. Once the logging needs are understood, tracking the percentage of appropriate assets that are reporting the right logs can help ensure fewer blind spots exist. Organisations need to make sure they’re doing this with knowledge of their environment and the attacks they worry about, as simply tracking MITRE coverage can allow less scrupulous vendors who claim perfect coverage (in highly specific situations) to take advantage. Summary: bad metrics are worse than no metrics SOCs are crucial to most organisations' defences and, when done right, are a place where analysts develop and deploy their expertise to hunt and stop attackers. With the wrong metrics, a SOC is ineffective and the job is miserable, with analysts describing themselves as ‘ticket monkeys’ measured on clicking 'false positive' as quickly as possible, whilst being shamed for missing real attacks. If you’re worried your SOC might be falling into this trap, a red or purple team from a credible vendor will give you proof either way. In summary, organisations should avoid trying to measure a SOC with metrics focusing on tickets. At best it provides an inaccurate picture, and at worst it actively harms the SOC’s chances of being effective. Organisations instead need to measure whether the SOC actually detects attacks, and how long that takes, whilst driving activities that enable analysts to excel in their work and enjoy their career.

NCSC: Leave passwords in the past - passkeys are the future Passkeys are the more secure and user-friendly login method and should be the default authentication option for consumers. Passkeys should now be consumers’ first choice of login across all digital services, the UK government’s technical authority on cyber security has announced today (Thursday). Overhauling decades of security practice, the National Cyber Security Centre – a part of GCHQ – has taken the decision to no longer recommend individuals use passwords where passkeys are available because passwords lack the relative resilience to modern cyber threats. Passkeys are a newer method for logging into online accounts which do much of the heavy lifting for users, only requiring user approval rather than needing to input a password. This makes passkeys quicker and easier to use and harder for cyber attackers to compromise. A new technical report, published today on Day Two of CYBERUK – the UK government’s flagship cyber security event in Glasgow, shows that passkeys are at least as secure as, and generally more secure than, pairing the strongest password with two-step verification (2SV). The majority of cyber harms to individuals start with criminals stealing or compromising login details, making the adoption of passkeys a huge leap in boosting the UK’s resilience to phishing attacks. A number of popular online service providers already support passkeys, including Google, eBay and PayPal – and new data from Google shows the UK already lead global adoption of passkeys, with just over 50% of active Google services users in the UK having one registered. The NCSC stopped short of endorsing the adoption of passkeys last year due to some key implementation challenges. However, progress within industry means they can now be recommended to the public as the more secure and user-friendly login method and to businesses as the default authentication option to offer consumers. Adopting passkeys wherever you can is a strong step towards a safer, simpler login experience and I am pleased that we can now support uptake. The headaches that remembering passwords have caused us for decades no longer need to be a part of logging in where users migrate to passkeys – they are a user-friendly alternative which provide stronger overall resilience. As we aim to accelerate the UK’s cyber defences at scale, moving to passkeys is something all of us can do to improve the security of everyday digital services and be prepared for modern and future cyber threats. Jonathon Ellison, Director for National Resilience, NCSC Where a particular service does not support passkeys, the NCSC’s advice to consumers is to use a password manager to create stronger passwords and keep using two-step verification. Making passkeys the default authentication recommendation is a critical step towards revolutionising the way individuals use and access their online identities. The key benefits include: Fast, frictionless passkey logins can be completed up to eight times faster than signing in with a username, password and two‑step verification code. Passkeys are highly resistant to phishing attacks and cannot be intercepted, reused or guessed like passwords can. Users no longer need to meet additional requirements, such as creating complex passwords – or even remembering them at all. This prevents weak points and patterns developing across a user’s online presence. Safety and savings can go hand in hand for online service providers that make passkeys available for customers, replacing SMS-based verification systems which incur additional costs. Last year, the UK government announced it would roll out passkey technology for its digital services as an alternative to the current SMS-based verification system, offering a more secure and cost-effective solution that could save several million pounds annually.

New advisory highlights how to defend against attacker tactics believed to be used by China-linked actors to hide malicious cyber activity.

Defending against China-nexus covert networks of compromised devices Explaining the widespread shift in tactics, techniques and procedures (TTPs) towards networks of compromised infrastructure, and how to defend against it Summary With support from the UK Cyber League, this advisory has been jointly released by the National Cyber Security Centre (NCSC-UK) and international partners: Australian Signals Directorate’s (ASD’s) Australian Cyber Security Centre (ACSC) Communications Security Establishment Canada's (CSE's) Canadian Centre for Cyber Security (Cyber Centre) Germany Federal Office for the Protection of the Constitution - Bundesamt für Verfassungsschutz (BfV) Germany Federal Intelligence Service – Bundesnachrichtendienst (BND) Germany Federal Office for Information Security - Bundesamt für Sicherheit in der Informationstechnik (BSI) Japan National Cybersecurity Office (NCO) - 国家サイバー統括室 Netherlands General Intelligence and Security Service - Algemene Inlichtingen- en Veiligheidsdienst (AIVD) Netherlands Defence Intelligence and Security Service - Militaire Inlichtingen- en Veiligheidsdienst (MIVD) New Zealand National Cyber Security Centre (NCSC-NZ) Spain National Cryptologic Centre - Centro Criptológico Nacional (CCN) Sweden National Cyber Security Centre - Nationellt cybersäkerhetscenter (NCSC-SE) United States Cybersecurity and Infrastructure Security Agency (CISA) United States Department of Defense Cyber Crime Center (DC3) United States Federal Bureau of Investigation (FBI) United States National Security Agency (NSA) Its purpose is to provide network defenders with the tools needed to defend against China-nexus cyber actors and their tactic of using large scale networks of compromised devices (covert networks) to route their cyber activity. Introduction Over the past few years there has been a major shift in the tactics, techniques and procedures (TTPs) used by China-nexus cyber actors, moving away from the use of individually procured infrastructure, and towards the use of externally provisioned, large-scale networks of compromised devices. The NCSC believes that the majority of China-nexus threat actors are using these networks (hereafter “covert networks”), that multiple covert networks have been created and are being constantly updated, and that a single covert network could be being used by multiple actors. These networks are mainly made up of compromised Small Office Home Office (SOHO) routers, as well as Internet of Things (IoT) and smart devices. Anyone who is a target of China-nexus cyber actors may be impacted by the use of covert networks. They have been used by Chinese state-sponsored actors Volt Typhoon to pre-position offensive cyber capabilities on critical national infrastructure. The group Flax Typhoon used a different covert network of compromised infrastructure to conduct cyber espionage. The use of covert networks of compromised devices - also known as botnets - to facilitate malicious cyber activity is not new, but China-nexus cyber actors are now using them strategically, and at scale. This advisory describes the typical makeup of a covert network and what they are being used for. It also includes protective advice for organisations being targeted by cyber activity using a covert network as an access vector. Covert Networks Covert networks are used to connect across the internet in a low-cost, low-risk, deniable way, disguising the origin and attribution of malicious activity. Actors have been observed using them for each phase of their Cyber Kill Chains, from performing scans as part of reconnaissance, to the delivery of malware, communicating with said malware, and exfiltrating stolen data from a victim. They can also be used for general deniable internet browsing, allowing threat actors to research exploitation techniques, new TTPs, and their victims without attribution. Some covert networks are also used by legitimate customers to browse the internet, making it challenging to attribute malicious activity. There is evidence that covert networks used by China-nexus actors are created and maintained by Chinese information security companies. A network known to network defenders as Raptor Train, which in 2024 infected more than 200,000 devices worldwide, was controlled and managed by the Chinese company, Integrity Technology Group. This company was also assessed by the FBI to be responsible for the computer intrusion activities attributed to China-based hackers known as Flax Typhoon. “Botnet operations represent a significant threat to the UK by exploiting vulnerabilities in everyday internet-connected devices with the potential to carry out large-scale cyber attacks” NCSC Director of Operations, Paul Chichester Covert networks mostly consist of compromised SOHO routers, but they also pull in any vulnerable device they can exploit at scale. Raptor Train was made up of thousands of SOHO routers and IoT devices, such as web cameras and video recorders, as well as firewalls and Network Attached Storage (NAS) devices. The KV Botnet used by Volt Typhoon was mainly made up of vulnerable Cisco and NetGear routers. The edge devices were vulnerable because they were “end of life” – out of date and no longer receiving updates or security patches by their manufacturers. The cyber security industry has been aware of examples of these networks for some time and has publicly reported on the widespread scale of the threat and its implications. Mandiant Intelligence produced a public blog in May 2024 talking about covert networks in which they highlighted a key issue for defenders – indicator of compromise (IOC) Extinction. If a particular threat group could now come from one of many covert networks, each with potentially hundreds of thousands of endpoints, and each used by multiple threat actors, old network defence paradigms of static malicious IP block lists will be less effective. This is compounded by the dynamic nature of these networks where new nodes will be added as old devices are patched or removed from use. Typical Network Topology The number of covert networks used by China-nexus cyber actors is large, with new networks regularly developed and deployed. The existing covert networks change too, either because of defensive or legal action, or simply as a result of software updates and new exploits being used to target different technologies for incorporation into the network. Because of this, a description of all known covert networks in detail, including how they are constructed and how they communicate, would immediately be out of date – and for most network defenders would not be practically useful. However, most covert networks of compromised devices use the same basic set up. Understanding this generalised structure can aid researchers and defenders by helping them to understand which part of a network they may have found, and how to defend against it. The diagram above illustrates the basic setup of a covert network, where typically an actor will connect to the network via an on-ramp or entry node. Their traffic will be forwarded through multiple compromised devices, used as traversal nodes, before exiting the network from an exit node, usually in the same geographic region as the target. Protective Advice Defending from attackers using covert networks is not straightforward, and defensive tactics will be different based on the levels of resource and the nature of the target organisation. General advice for good cyber security practice should be followed, and some key messages can be found in the appendix of this advisory. The following advice is specifically tailored to steps which can be taken to combat the risk of attacks coming from large, dynamic networks of compromised devices. Further guidance for all organisations facing cyber security threats is available on the NCSC website. This guidance should be considered alongside all applicable laws and regulations of the UK and co-sealing countries relating to the security of networks and data. It will be each organisation’s responsibility to ensure compliance with any such laws and regulations. Organisations should note that following the recommended actions set out below will not remove all risks. All organisations The NCSC recommends the following steps for all affected organisations to either take themselves, or ask their managed service and/or security providers to investigate for them: Map and understand network edge devices, developing a clear understanding of organisational assets and what should be connecting to them. Baseline normal connections, especially to corporate virtual private networks (VPNs) or other similar services. - Would you expect connections from consumer broadband ranges? Leverage available dynamic threat feeds which include covert network infrastructure. Implement multi-factor authentication for remote connections. Smaller organisations should consider creating and actioning a free NCSC Cyber Action Toolkit. Larger or more at-risk organisations Some more comprehensive measures may be appropriate if the risk to an organisation is high enough, to be conducted either in-house or through a security provider: Apply IP address allow lists rather than deny lists for connections to corporate VPNs for remote workers. Use geographic allow lists or profile incoming connections based on operating system, time zones, and/or organisation specific system configuration settings. Implement zero trust policies for connections. Enforce machine certificates for Secure Sockets Layer (SSL) connections. Reduce the internet-facing presence of the IT estate. Investigate machine learning techniques to profile normal network edge activity to detect and block anomalies. The NCSC's Cyber Essentials can help protect organisations of all sizes. Largest or most at-risk organisations If Advanced Persistent Threat (APT) tracking is part of an organisation’s in-house capability, or if it is part of the service provided by a security vendor, consider tracking China-nexus covert networks as APTs in their own right. Active hunting – look for connections from IP addresses likely to be part of a covert network of compromised devices, for instance those hosting SOHO routers or IoT devices. Track and map covert networks reported by industry or government by looking at banners and certificates. Use threat reporting and threat feeds to create and implement dynamic blocklists and create alert rules to detect incoming threats. Consider using NetFlow feeds to look upstream and map covert networks to find new nodes. The NCSC Cyber Assessment Framework provides guidance for organisations under the highest levels of threat, including those operating essential services, in sectors such as energy, healthcare, transport, digital infrastructure and government. MITRE ATT&CK® This advisory has been compiled with respect to the MITRE ATT&CK® framework, a globally accessible knowledge base of adversary tactics and techniques based on real-world observations. Appendix: Cyber Security Best Practices In addition to the protective advice outlined in this advisory, a number of cyber security best practices will also be useful in defending against the activity described in this advisory. Protect your devices and networks by keeping them up to date: use the latest supported versions, apply security updates promptly, use antivirus and scan regularly to guard against known malware threats. See NCSC Guidance: https://www.ncsc.gov.uk/collection/device-security-guidance/policies-and-settings/antivirus-and-other-security-software Set up a security monitoring capability so you are collecting the data that will be needed to analyse network intrusions. See NCSC Guidance: https://www.ncsc.gov.uk/guidance/introduction-logging-security-purposes and https://www.ncsc.gov.uk/information/logging-made-easy Use modern systems and software. These have better security built-in. If you cannot move off out-of-date platforms and applications straight away, there are short term steps you can take to improve your position. See NCSC Guidance: https://www.ncsc.gov.uk/collection/mobile-device-guidance/managing-the-risks-from-obsolete-products Restrict intruders' ability to move freely around your systems and networks. Pay particular attention to potentially vulnerable entry points such as third-party systems with onward access to your core network. During an incident, disable remote access from third-party systems until you are sure they are clean. See NCSC Guidance: https://www.ncsc.gov.uk/guidance/preventing-lateral-movement and https://www.ncsc.gov.uk/guidance/assessing-supply-chain-security Deploy a host-based intrusion detection system. A variety of products are available, free and paid-for, to suit different needs and budgets.

Executive Summary: Defending against China-nexus covert networks of compromised devices What is the threat? China-nexus cyber actors have moved from using individually procured infrastructure to operating large scale “covert networks” – botnets built from compromised routers, and other edge devices. These networks are used for each phase of the Cyber Kill Chain, from reconnaissance and malware delivery, to command and control and data exfiltration against targets of espionage and offensive cyber operations. The threat is a dynamic, low-cost, deniable infrastructure model that can be rapidly re-shaped, rendering traditional static IP block lists ineffective. What is the impact on affected organisations? Covert networks enable China-nexus actors to launch cyber attacks against UK organisations, stealing sensitive data and potentially disrupting critical services. Because the covert networks are constantly refreshed and share nodes across multiple threat groups, defenders face “IOC extinction” – indicators of compromise disappear as quickly as they are discovered. Consequently, organisations that rely solely on static defences risk being bypassed, while those that adopt adaptive, intelligence driven measures can better mitigate the risk. What should I do? The NCSC and the Cyber League, in conjunction with the co-sealing agencies, have developed advice specifically to combat this threat. The advisory contains guidance for small, medium, and large organisations.All organisations should map and baseline their edge device traffic, especially VPN and remote access connections, and adopt dynamic threat feed filtering that includes known covert network indicators. Potential victims should implement two-factor authentication for remote access and, where possible, apply zero trust controls, IP allow lists, and machine certificate verification. Larger or high-risk entities should consider active hunting of suspicious SOHO/IOT traffic, geographic profiling, and machine learning based anomaly detection. Conclusion Promptly applying the recommended mapping, baseline, and zero trust measures is essential to reduce organisation exposure to China-nexus covert network attacks and to protect critical assets.

Passkeys are more secure than traditional ways to log in Passkeys offer a more usable, secure replacement for passwords and are already supported by most modern devices. At CYBERUK 2026 in Glasgow, the NCSC announced that we will begin recommending passkeys wherever a service supports them, and two‑step verification (2SV) where it does not. This shift will be reflected through our ongoing refresh of guidance rather than as a single sudden change. This is not a decision taken lightly. It is based on extensive engagement with websites, app developers, technology vendors and the FIDO Alliance, alongside significant technical and sociotechnical research carried out by the NCSC. As part of CYBERUK, we published a paper comparing – from an individual user’s perspective – the security properties of traditional multi‑factor authentication (MFA/2SV) and FIDO2 credentials, including passkeys. All credentials go through a lifecycle: they are created, stored and used, and often need to be synchronised, revoked or recovered. At different points in that lifecycle, credentials are vulnerable to different types of attack, and not all attackers have the same capabilities. By breaking authentication down in this way – and focusing on the most common real‑world attack techniques – it becomes possible to compare very different credential types in a consistent and meaningful way. Our analysis focused on the attacks most commonly seen against individuals today, including phishing, credential reuse and session hijacking. From this analysis, the NCSC assesses that: All traditional MFA methods – including passwords combined with SMS codes, email codes, time-based One Time Passwords generated by apps or physical tokens, push approvals – are inherently phishable. FIDO2 credentials, including passkeys, are as secure or more secure than traditional MFA against all common credential attacks observed in the wild. When user verification is required as part of the login, FIDO2 authentication constitutes multi‑factor authentication. Because FIDO2 removes the ability to cheaply reuse or relay credentials, large‑scale attacks directly targeting correctly implemented passkeys are unlikely. In short, when services support them, passkeys provide stronger protection for users than traditional MFA/2SV. Some concerns are frequently raised about passkeys. In practice, many are either manageable or apply equally to traditional approaches. Here are our answers to some of the most common questions: Passkeys can synchronise across devices using platform services. This is sometimes presented as a novel risk, but most people already rely on similar cloud‑based synchronisation for password managers, email and some authenticator apps. The key control is the strength of the authentication protecting the sync account – a requirement that already exists in many MFA deployments. Yes. Where user verification is performed (typically by however the user normally logs into their device), FIDO2 credentials combine something the user has (the cryptographic key) with something they are or know. Multiple factors do not need to be on multiple, separate devices, and many traditional MFA implementations already deliver all factors through a single phone. Traditional MFA can be effective, but it remains fundamentally vulnerable to phishing because secrets or approvals can be observed and relayed during a live session. Passkeys remove this class of attack entirely by cryptographically binding authentication to the legitimate service. As with any security control, passkeys are most effective when implemented and used sensibly. Users still depend on the security of their devices and credential managers, and services should give users clear ways to manage and remove credentials and to set up recovery options. Importantly, our assessment doesn't assume perfect usage or perfect implementation. Even under realistic conditions, passkeys offer stronger protection than the best implemented traditional MFA. For individuals logging into websites and apps, passkeys and other FIDO2 credentials are as secure or more secure than traditional MFA/2SV, and – when user verification is used – are themselves multi‑factor. Where services support passkeys, they should generally be used. Where they do not, traditional 2SV remains an important fallback. On a broader scale, moving towards phishing‑resistant authentication reduces one of the most persistent causes of cyber compromise. The technology is mature, the standards are established, and adoption now represents a practical opportunity to improve security for users and organisations alike.

New cross domain guidance for government, industry and the wider security community Ensuring cross domain technologies are better understood - and more easily deployed - across sectors. Cross domain technologies play a vital role in helping organisations to move data safely between environments with different security levels. The NCSC know this area can be challenging to navigate, which is why we’ve produced new guidance on Cross domain approach and architecture. The guidance makes the adoption of cross domain technologies more straightforward and more secure. This blog outlines what has changed, the reasons behind those changes, and what updates you can expect in the months ahead. A brief history of cross domain The NCSC and partners have developed cross domain solutions for many years, particularly in the defence and intelligence sectors. Organisations operating within these sectors have long required secure movement of data between systems operating at different security levels, and cross domain solutions have been central to meeting that need. These solutions delivered significant benefits, including: reduced cost by removing the need for isolated or duplicate systems improved architectures that allow systems to work together more effectively However, the threats we face today are more capable, more persistent, and more strategic. Systems that were never designed to operate in hostile environments are now targeted by sophisticated attackers, and organisations across sectors that were once unlikely targets — such as energy, industrial control, and wider elements of critical national infrastructure — are now firmly within scope. In fact, the new guidance should be used by any organisation where the threat model assumes systems will be under targeted attack, and the harm to the organisation from security compromise would be great (or where there is significant intellectual property). Our new approach to cross domain Many organisations contain systems that are interconnected in ways their designers never anticipated, and they rely on protocols that were not built to resist modern, sophisticated attacks. Attackers are increasingly able to uncover unknown vulnerabilities, and developments in AI will accelerate this further. Combined with supply chain changes that make it harder to gain deep assurance in products what are core to critical systems, cross domain is now an essential security approach for organisations operating across all sectors. Our revised guidance is designed to ensure that cross domain is easier to implement so it can be more widely adopted across disparate sectors. It reflects how modern systems operate and how organisations now use technology to deliver essential services. At its core, cross domain is about safely enabling business functions, even when those functions span systems with different levels of trust. This could include importing documents, enabling video communications, or interacting with services hosted in other environments, such as over APIs. Rather than focusing on fixed boundaries or specific technologies, the new approach looks at the end‑to‑end architecture needed to make these functions secure and reliable. A central part of this approach is developing an explicit understanding of: what data flows are required how systems are connected which threats are relevant, both individually and when systems are linked Cross domain uses a sequence of functions—often referred to as a pipeline—to build confidence in data as it moves between trust zones. Each function prepares the data so the next stage can safely process it, or ensures that only valid data leaves a zone. This ensures assurance is gained across the entire flow, not at a single point. Changes to the guidance Our new guidance will allow organisations to build systems that reflect the NCSC’s updated approach to cross domain. It explains essential concepts including zones of trust, trust boundaries, and control points. The guidance also reflects the need for flexible, layered controls, and largely replaces our older security principles for cross domain solutions. We do not recommend using the existing security principles for new end to end architectures, but they remain important for the NCSC’s Principles Based Assurance (PBA), so will be used to assure new cross domain products in the medium term. The NCSC’s original importing data and exporting data design patterns are being deprecated and in time will be replaced by new cross domain patterns. What’s next? We will build on this guidance to provide more details on how to architect and implement cross domain products, and are looking to include topics such as: a step-by-step guide to designing cross domain architectures, covering the key stages and considerations you need to take guidance on selecting appropriate technology to implement dross domain functions standardised cross domain patterns which will provide repeatable templates that will be applicable across a number of use cases We’ll let you know when this guidance is ready. In the meantime, we hope you find the cross domain guidance useful when designing your organisation’s data flows across zones of trust.

Every organisation delivering the UK’s critical services – whether in energy, transport, health, communications, financial services, or any other critical national infrastructure (CNI) sector – relies on uninterrupted digital operations. Disruption to those operations isn’t simply an IT issue; it’s a business continuity and national resilience issue. What is severe cyber threat? Recent high-profile cyber incidents demonstrate a clear and accelerating trend: highly capable threat actors are increasing both their intent and their ability to target organisations of national economic significance, to cause real-world operational disruption. At the same time, new technologies – like frontier AI – risk increasing the speed, scale and ease of attacks. This is what we mean by severe cyber threat. Severe cyber threat can result in attacks which lead to: extended operational downtime, with direct customer impact significant financial loss long-term reputational damage increased risks to public safety and national security A leadership responsibility Given the escalating intent and capability of cyber threat actors, organisations must treat the prospect of severe cyber threat as a credible and pressing risk. Preparing for this is a leadership responsibility. Effective preparation not only protects your organisation’s value, reputation and continuity of operations, it also serves a wider purpose. The ability to continue delivering essential services under sustained cyber pressure is critical to the UK’s national resilience and security. The time to act is now The NCSC Annual Review 2025 highlights the widening gap between the rising pace of cyber threat and the UK’s collective resilience – and the NCSC’s message is unambiguous: the time to act is now. When a severe cyber incident hits, it will be too late to start working out roles, responsibilities and decision-making thresholds, or building the necessary capabilities and processes, for the first time. Getting your organisation ready and building the level of required resilience need time – as well as strategic investment – which is only possible with: clear commitment from the organisation’s leaders organisation-wide collaboration engagement with suppliers and partners advance planning and action Prepare and plan your response That’s why we are asking leaders to take action now on the NCSC’s recently published guidance How to prepare and plan your organisation’s response to severe cyber threat: A guide for CNI, to make sure you’re ready to withstand, and ultimately recover from, such attacks. Key takeaways from the guidance 1 Resilience beats preventionThe reality is that cyber threats won't always be preventable, so in the event of severe cyber attacks – which for example shut down services or operations – organisations must be ready to continue operating through disruption and to undertake recovery activities, all whilst under immense pressure. This means: - mapping and understanding your most critical systems - planning how you would continue operations even if IT or OT systems were degraded - rehearsing defensive actions such as network segmentation, isolation ('islanding'), and system rebuilds - ensuring leadership understands the trade-offs between security and operational continuity Ultimately, resilience means being able to function despite setbacks, not just avoiding them. 2 Preparation must happen before the threat escalatesMany of the measures needed during a severe cyber threat – such as rapidly hardening defences or isolating networks – are complex and potentially costly. They may carry business impacts that make them disproportionate to implement today. But they cannot be improvised under pressure. Unless the necessary capabilities, controls, processes and decision-making arrangements have been built and rehearsed in advance, they will not be available to deploy at the point they become proportionate. Organisations must act now to put these measures in place. Connection to the CAF The NCSC’s Cyber Assessment Framework (CAF) helps organisations responsible for essential services achieve and demonstrate an appropriate level of cyber resilience. The new guidance builds on this by focusing specifically on how organisations should prepare for and respond to severe cyber threat. This context is the key distinction. An organisation may meet the expectations of the CAF under normal operating conditions, but may not have fully considered how its risk profile and response actions would change in the context of severe cyber threat. Organisations will need to revisit the CAF principles through this lens, and adjust their response actions as necessary. What to do next? Reading the guidance is the first step. Turning it into operational readiness is the next. Leaders should use this guidance to: test whether current plans hold up under severe cyber threat conditions identify decisions that would be hardest to make under pressure ensure those decisions are owned, understood, and rehearsed Then, embed the learning into your business continuity and resilience plans. The organisations that fare best in severe cyber incidents are those that have put in place the steps needed to withstand and recover from disruption – protecting essential services, business continuity, and their bottom line.

Retaining defensive advantage in the age of frontier AI cyber capabilities As AI accelerates vulnerability discovery, organisations must raise their security baselines to safeguard their cyber security. Richard Horne This blog post was originally published as a letter in the Financial Times 15th April 2026. A step change in frontier AI models’ capabilities to find vulnerabilities in code can ultimately be a good thing for our cyber security. Suppliers of technology can use AI to identify and fix vulnerabilities in their products and services throughout their lifecycles, keeping customers and users safe from new threats. But the path to reaching this point brings significant risk and requires urgent action. In the immediate term, we will increasingly see AI exposing those organisations that have not taken appropriate steps to safeguard their cyber security. AI will make it easier, faster and cheaper to discover and exploit weaknesses that previously required more time, skill or resource for attackers to identify. And the pressure on organisations to patch systems quickly will only grow more acute. That’s why it is more essential than ever that organisations ensure they are following established good practices, set out by the National Cyber Security Centre, to raise their security baseline. This includes reducing unnecessary exposure to attack, applying security updates rapidly, as well as monitoring for, and quickly responding to, malicious activity detected. These are technical actions, but they must be championed by all leaders and board members at organisations to have a positive impact. Cyber risk is business risk. A wealth of guidance and tools are available on the NCSC website to do this, and government-backed certifications such as Cyber Essentials give organisations and their customers confidence that critical disciplines are being practised. As our society navigates these fast-evolving capabilities, the NCSC will stay focused on its mission to protect the UK from cyber threats, working alongside industry and wider government, and we will continue advising on the risks and opportunities. By getting the fundamentals right and carefully adopting frontier AI models for good, network defenders can retain an advantage and help keep the UK safe online.

Artificial intelligence (AI) is no longer a distant or speculative issue for cyber security. The most advanced systems, often referred to as frontier AI models, are already showing results in specific steps of cyber operations, such as in helping identify zero days in widely used software, or solving cryptographic challenges. These models are changing the cost, speed and scale of operations for both attackers and defenders. It means tasks which once required specialist skills – such as writing exploit code, understanding system architecture or using attack tools – can increasingly be automated using AI in certain circumstances. Recent findings from the AI Security Institute (AISI) highlight an accelerated increase in the cyber capabilities of frontier models, and at a far faster pace than many expected. In specific cyber tasks, models already exceed what a skilled practitioner could achieve at lower cost. In parallel, publicly available examples demonstrate how these capabilities are already being used in practice, and how attackers could adopt them more widely. The implication is clear: defenders should assume that at least some attackers already have access to capable AI tools. Since frontier AI capabilities potentially strengthen cyber attackers, cyber defenders must use the same capabilities to drive defensive advantage. This blog helps cyber security professionals, decision makers and risk owners to better understand: how frontier AI capabilities are evolving how attackers are already using – or could use – these capabilities where frontier AI is most likely to deliver game-changing improvements in cyber defence It also explains the critical structural advantage defenders hold and how to retain that advantage to stay ahead of the attackers. Glossary of terms used (unless otherwise stated) refers to generative AI (GenAI) – the class of AI systems that can produce text, code and other outputs in response to prompts. (This is distinct from earlier forms of AI which have been used in the cyber security context for many years). refer to the most capable models available at any given time. It’s worth noting that capabilities developed in frontier models can be transferred into smaller, cheaper, or open-weight models through a process called distillation – meaning advances at the frontier set the direction of travel for the whole ecosystem. refer to broader AI systems that combine models with tools, workflows and human oversight. Examples include: agentic systems that take sequences of actions autonomously systems where humans and AI collaborate on tasks Many of the benefits and risks discussed in this blog are delivered by AI systems rather than raw model capability alone. How frontier AI capabilities in cyber operations are evolving Whilst safeguards applied by responsible model developers can limit misuse of AI, these protections can often be bypassed (and in open‑weight models can be removed or are absent from the start). Publicly-available AI model weights can be modified, and safeguards removed entirely. Reporting from multiple frontier labs over the last few years has shown attackers are using frontier AI models to aid their operations. For example: Anthropic’s Disrupting the first reported AI-orchestrated cyber espionage campaign Google’s Adversarial misuse of generative AI Open AI’s Disrupting malicious uses of AI In its recent research into measuring AI agents' progress on multi-step cyber attack scenarios, AISI evaluated the cyber capabilities of 7 frontier AI models, released before March 2026. Importantly, the capabilities are inherently dual-use, meaning the skills that could be used by attackers – such as identifying vulnerabilities and developing exploits – can also be used by defenders for security testing and hardening. The models were given specific tasks in 2 simulated environments (an enterprise network and an industrial control system) and left to operate autonomously. On the 32-step enterprise network attack, estimated to take a human cyber security expert approximately 14 hours to complete end-to-end, the best-performing model (Claude Opus 4.6, released February 2026): Averaged 15.6 steps, with extended processing time - which corresponds to roughly 6 of the 14 hours a human expert would need. Averaged 9.8 steps without extended processing time – up from fewer than 2 steps 18 months earlier. Completed its single best run in 22 of 32 steps. As of March 2026, no public model has completed the full scenario end-to-end. On the more complex industrial control system attack scenario, AI performance was significantly more limited. But even here there were early signs of progress: the most recent models were the first to make any consistent headway, and in some cases found attack approaches the scenario designers hadn't anticipated. In just 18 months, the best AI models went from barely making any progress on a realistic simulated enterprise attack to completing over half of it, and the cost of a full attempt is now around £65. Factors driving the rapid pace of improvement in offensive AI cyber capabilities There are 2 reinforcing trends driving this acceleration: The capability ceiling is rising fast. Each new generation of AI model is better at working through complex attack sequences than the last. The best model in early 2026 completed nearly 6 times more attack steps than the best model 18 months earlier. Running these attacks is getting cheaper, not harder. Giving the same model more processing time reliably improves results with no additional attacker skill required. At current pricing, a full attempt at this simulated attack costs around £65. This means the limiting factor is increasingly funding, not expertise. Current limitations of the AI models in attack scenarios Despite rapid improvement, AI models released before March 2026 still fall short of end-to-end completion of these complex attack scenarios. The main reasons for this limitation are: The amount of processing time. In several evaluations, models were still taking useful actions when they reached the end of the allotted processing time, meaning the results likely understate their full capability. Specialist knowledge gaps in areas such as reverse engineering, cryptography, and malware development. Performance drops sharply when attacks transition from reconnaissance and web exploitation to phases where there is less training data. Complex, multi-step coordination is unreliable. Models struggle with operations that require managing several concurrent processes in real-time. Models lose track over long operations which leads to lost context and missed opportunities. Results are inconsistent. The same model with the same amount of processing time can produce very different results across individual runs. It’s important to note that these aren't permanent barriers. They are areas where the rate of improvement has already been rapid, and where even modest extensions to processing time or human-AI teaming can result in substantial gains. It's also worth noting that these results likely underrepresent what current models are capable of, given the evaluations used a standard setup with no specialist tools or human involvement. Purpose-built approaches would almost certainly perform better. An important near-term advantage for defenders is that the activity of frontier AI models released before March 2026 tends to generate noticeable security alerts and is relatively easy to detect. Current models would likely be identified and disrupted before they managed to achieve the levels of progress outlined above – but only in environments with effective monitoring and the ability to respond. How frontier AI capabilities may be used to strengthen cyber defence With attackers already making use of AI to support their operations, defenders should also look to where AI can assist their work and increase their ability to protect systems at scale and pace. AI is already being used across many cyber security workflows, from analysing threat intelligence to alert triage, ensuring policy compliance, and finding vulnerabilities in source code. In some areas, these tools are delivering tangible benefits. More importantly, there are some areas of application where AI-enhancement is likely to be a game changer in how defenders operate in practice. Here we outline 3 of our top bets: AI-enabled security testing tools are making vulnerability discovery and penetration testing faster and more comprehensive. In limited settings these tools can now: scan systems continuously at machine speed identify vulnerabilities and misconfigurations test exploitability map complex attack paths that would traditionally take human testers many hours to uncover The majority of these tools still only identify problems rather than fix them, but systems are beginning to demonstrate autonomous remediation, including generating and applying code patches. Examples emerging from initiatives such as DARPA’s AIxCC challenge, Google’s CodeMender, and OpenAI’s Codex Security point to a future where vulnerability discovery and remediation happen far more quickly, reducing attackers’ windows of opportunity. Use in critical systems remains challenging, but the direction of travel is clear. AI, and in particular LLM-enabled tools and systems, have potential to help defenders: triage alerts make sense of patterns from diverse logs write summary reports to support analyst decision-making More significantly, in the future AI may enable a shift away from detection models that assume a human must review each alert. Future systems may retain far more contextual information over time, increase logging, initiate targeted investigations, or deploy deception techniques, such as honeypots, to gather intelligence on suspicious activity. This could improve detection of slow, subtle intrusions that often evade traditional approaches. Although these systems are still emerging and bring new risks, such as over-reliance on automated judgement and reduced transparency, they nevertheless represent a meaningful change in how defenders may detect and understand adversary behaviour. Some organisations are exploring automated response capabilities that can contain or remediate threats without any human intervention, such as: blocking traffic flows quarantining suspicious processes revoking user accesses When carefully designed, this can significantly reduce the time between compromise and containment. But it’s important to note that automating responses does also introduce substantial risk. Incorrect or overly aggressive responses can result in service disruptions, data loss, or operational failures – in some cases exceeding the impact of the original attack. Shaping the battlefield: how to retain the defender advantage in AI Despite the rapid improvements seen in successful use of AI capabilities for offensive purposes, defenders do still have some advantages over attackers. Defenders can (and must) work collaboratively across the globe, sharing their insights transparently and openly. Furthermore, market forces should drive the community towards building strong defences from AI attacks. But the key advantage in defenders' favour is that they have the ability to ‘shape the battlefield’; that is to shape their environment to make it work better for them and disadvantage the adversary. When applied defensively, AI can exploit this key advantage at scale, for example correlating signals across systems, understanding intended behaviour, and distinguishing genuine threats from benign activity. Used well, this can deliver disproportionate benefits to defenders (requiring attackers to be super stealthy and to successfully hide every time). But this advantage is not guaranteed. Where attackers adopt AI more effectively than defenders, or where baseline cyber security is weak, the quality of defensive data degrades and the information gap narrows quickly. AI-enhanced cyber security tools also introduce new complexity, creating additional dependencies and failure modes that may be difficult to detect or control. In line with the Government’s Code of Practice for the security of AI, these tools should be designed and deployed securely in their own right, and treated as part of the attack surface. The most effective actions are not novel or experimental. Since AI will more quickly enable rapid scaling of attacks against ‘soft' rather than ‘hard’ targets, strong baseline security is vital. To limit what AI-enabled attackers can achieve, ensure you have the cyber security basics in place, such as: accurate asset inventories robust access controls secure configuration comprehensive logging AI won’t compensate for weak security foundations, but it will amplify both strengths and weaknesses. Organisations that invest now in strong security baselines and carefully deployed AI-enhanced defence will be best placed to retain defender advantage as AI increasingly shapes the cyber risk environment. We’ll continue to share our informed thinking on the use of AI in cyber security, and will be updating the Intelligent security tools guidance in due course.

Vulnerability affecting F5 BIG-IP APM Organisations have been encouraged to take action against a vulnerability affecting F5 BIG-IP Access Policy Manager. The NCSC is encouraging UK organisations to take immediate action to mitigate an unauthenticated remote code execution vulnerability affecting F5 BIG-IP Access Policy Manager (CVE-2025-53521). F5 BIG-IP APM is a common component, especially within large enterprises. F5 has published an updated security advisory explaining that a previously disclosed vulnerability in BIG-IP APM has been recategorised as an unauthenticated remote code execution vulnerability CVE-2025-53521: When a BIG-IP APM access policy is configured on a virtual server, specific malicious traffic can lead to Remote Code Execution (RCE). F5 is aware of active exploitation of CVE-2025-53521 affecting BIG-IP APM. The NCSC is working to fully understand UK impact and any potential cases of active exploitation affecting UK networks. The NCSC recommends investigating for compromise on all affected products regardless of when the system was updated. F5 have published Indicators of Compromise. All organisations using BIG-IP APM are affected by this vulnerability. The NCSC recommends following vendor best-practice advice to mitigate vulnerabilities. In this case due to reports of in the wild exploitation, if you use an affected product, you should take these priority actions: The following NCSC guidance and services will help to secure systems:

How to secure your online meetings Advice for small and medium-sized organisations on choosing, setting up and using online meeting services safely Online meetings rely on digital tools to support collaboration, but they also introduce security risks. This guidance – aimed at small and medium-sized organisations – outlines steps to keep your online meetings secure; to protect sensitive information and reduce the risk of cyber attacks. For broader support on securing your organisation, you should visit the NCSC’s Cyber Action Toolkit. If you use an IT provider, refer to our Managed Service Providers (MSP) guidance to ensure your devices are being secured effectively. Follow these steps to secure your online meeting services. Choose a service that works for you: Only download apps from trusted sources like the Apple App Store, Google Play, or the provider’s official website. Avoid clicking on ads and unsolicited links, which may lead to malicious sites. Once you’ve selected your service, it's important to secure your account and control who can join your online meeting by following the below steps. For specific instructions, refer to the vendor support website of the service you're using. Only allow direct access to authenticated users and invited guests. Require passcodes for unauthenticated users. Use a waiting area (often referred to as the ‘lobby’) to verify participants before admitting. Consider blocking calls from outside your organisation and from unknown contacts. Never share meeting links or passwords in public spaces. If someone joins and you don’t recognise them, politely ask who they are before continuing. Check your surroundings before joining a call and consider using a background blur or an image for privacy. Get familiar with basic controls like muting your microphone, turning off your camera, and spotting when a meeting is being recorded. Review and adjust privacy settings to suit your needs before use. Know where recordings, transcriptions, chat logs and shared files are stored. Be aware of AI attendees - these tools may record, transcribe, or analyse meeting content. Understand what data they collect, how it’s used, and whether you can opt out. Check who has access to your data and how long it is retained. Only individuals and systems who genuinely need the information should be able to access it, and you should only keep personal data for as long as you have a clear reason to.