etsi

Technology standards across Europe are evolving to prepare manufacturers for the EU Cyber Resilience Act (CRA) that takes full effect in December 2027. The European Telecommunications Standards Institute (ETSI), one of the three official standards organizations recognized by the EU, launched an approval process for 17 key cybersecurity standards European vendors will have to meet under the CRA. The final draft standards, made available on August 13, cover 17 major product categories spanning network and edge devices, security solutions and internet-of-things (IoT) appliances: The proposed standards set out a list of minimum-security features manufacturers must implement to be CRA-compliant, allowing for the sale of their products in the EU from December 2027. Several of these proposed standards mandate modern cryptography, secure-by-default settings, a software bill of materials (SBOM) – a machine-readable inventory of software dependencies – and post-sale update capabilities. The standards have been submitted to 41 member organizations across Europe, including the national standardization bodies of the European Economic Area and Europe-wide industry and standards organizations, and are currently under public enquiry as part of the first phase of the approval procedure. Stakeholders are welcome to issue comments until mid-September to mid-November 2026, depending on the vertical. The final versions of these 17 cybersecurity standards are expected to be available by December 2026. They will apply to all manufacturers, importers, distributors, service providers and developers of commercially available hardware and software products sold in the EU from the end of 2027. ETSI and the other two EU-approved standardization bodies, the European Committee for Standardization (CEN) and the European Committee for Electrotechnical Standardization (CENELEC), have organized a series of workshops across Europe to help European small and medium businesses to comply to the CRA when it’s enforced.

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.

Europe’s digital identity wallet gets its first set of standards People across the European Union already use their phones for banking, travel, and government services. The European Digital Identity Wallet will bring those activities into one application, and the European Telecommunications Standards Institute (ETSI) has released the first standards that support it. What the wallet does The wallet lets EU citizens and residents prove their identity and share specific attributes, such as their age, a diploma, or an authorization. It works across government services, healthcare, banking, travel, education, and other areas. Each EU Member State will offer at least one wallet to its users, and the wallets connect to both public and private services across borders. Users sign in to online services through the wallet with one set of credentials. They can store and manage official digital documents, share verified information such as a diploma or a license, and sign documents with electronic signatures that carry legal weight. Privacy and security The wallets use strong cryptography and apply data minimization, so they share only the information a given service requires. They are built to operate the same way across Europe, which lets a wallet issued in one country function in another. What the first standards cover The first release contains more than 24 technical specifications. They cover wallet-specific attestation profiles, certificate policies, and trust list formats. They also cover remote signing protocols, identity proofing, and long-term data preservation. “Our goal is to make digital interactions across Europe as easy and trustworthy as possible, whether you’re travelling, studying, working, or accessing services online. ETSI has a long expertise in electronic signatures, cybersecurity and trust data management. The digital wallets are at the crossroad of these technologies and benefit from our experience,” said Nick Pope, who chairs ETSI’s Electronic Signatures and Trust Infrastructures committee. Pilots already underway The wallet is being trialed in large-scale pilots that cover government services, businesses, banking, vehicle registration, and travel. The work sits within a wider European effort backed by the European Commission and the European Economic Area. Work planned through 2027 ETSI’s Technical Committee ESI will continue this work through 2026 and 2027. It plans to turn the technical specifications into European Standards, fold in feedback from the large-scale pilots and early deployments, build interoperability and conformance testing frameworks, and add standards for more wallet components. The plan would give each of the European Union’s roughly 450 million citizens access to a wallet.

Week in review: Cisco SD-WAN 0-day exploited, Patch Tuesday forecast Here’s an overview of some of last week’s most interesting news, articles, interviews and videos: OWASP Agent Memory Guard: Stop AI agents from being weaponized through their own memory Agent Memory Guard is an open-source runtime defense layer that sits between an agent and its memory store, screening every read and write through a pipeline of detectors and a YAML policy. The project is the OWASP reference implementation for ASI06, Memory Poisoning, one entry in the OWASP Top 10 for Agentic Applications. Data discovery gaps that catch enterprises off guard In this interview with Help Net Security, Avani Desai, CEO at Schellman, talks about the gap between what organizations think they know about their data and what discovery scans turn up. She shares stories of shadow data in abandoned cloud storage, post-merger surprises where duplicated datasets slowed integration, and why synthetic data is overmarketed while confidential computing stays underappreciated. Zero trust physical security needs trust decisions at the edge In this interview with Help Net Security, Chuck Davis, VP, Global Information Security at Hikvision, explains how zero trust applies to physical security systems like cameras and door controllers. He breaks down how to make trust decisions at the edge without recreating old perimeter assumptions, why these devices should be treated as IT assets, and what the Mirai botnet taught the industry. A small Slovenian team handles 6,000 cyber incidents a year Online fraud complaints, ransomware cases, and phishing tips reach Slovenia’s national cyber response center in steady volume, and a team of around a dozen analysts sorts through them. Gorazd Božič, who manages SI-CERT at the public agency ARNES, described that work in an interview conducted in person at the Span Cyber Security Arena conference. He put the original proposal for a Slovenian CERT to ARNES leadership in 1994, and the center now records about 6,000 incidents a year, up from roughly 300 ten to fifteen years earlier. Only 11% of production agents pass the AI agent security bar Enterprise teams are running AI agents that write code, drive browsers, answer customer calls, manage cloud infrastructure, and query data warehouses with standing credentials. A new independent assessment of 100 production agents finds that nearly all of them carry the conditions for a single hostile document to take them over. Spotless compliance evidence can still hide a broken control In this interview with Help Net Security, Marc Rubbinaccio, Head of Cybersecurity and Compliance at Secureframe, explains where security teams go wrong when preparing for CMMC and FedRAMP 20x. The conversation covers how organizations check the 110 requirements but miss the 320 assessment objectives beneath them, why spotless SOC 2 evidence can hide a broken control, and how continuous monitoring is changing compliance work. OAuth marketplace apps keep access after publishers vanish Installing an app from the Google Workspace Marketplace or GitHub Marketplace can grant a third party access to company email, files, calendars, code repositories, CI workflows, organization settings, and secrets. Marketplace presence gives these apps the appearance of approval. The OAuth grants behind them often reach into business systems beyond the listed function. Thieves can pull off keyless car theft in under a minute and here’s how to stop them A keyless car can be stolen in under a minute. Two people, a pair of cheap radio amplifiers, and a fob sitting on a hallway table inside the house. That is enough. No broken glass. No alarm. No sound. The vulnerability runs across the global market. Germany’s largest auto club, ADAC, runs ongoing tests of keyless models against relay attacks. AgentGG: Open-source agentic SAST scanner Static analysis tools have spent years matching source code against known-bad patterns and handing engineers long lists of candidate issues to triage by hand. AgentGG approaches the same job with AI agents that read the code, follow imports, walk the call graph, and confirm a finding before they report it. The project is an open-source agentic SAST scanner released under the Apache 2.0 license. Hackers are exploiting Palo Alto GlobalProtect VPN authentication bypass (CVE-2026-0257) Authentication bypass vulnerabilities (CVE-2026-0257) in Palo Alto Networks’ firewalls that the company disclosed on May 13 have been targeted in “limited exploit attempts”. The good news, though, is that the company hasn’t observed any indication of successful lateral movement from the devices. How NIST fumbled management of the National Vulnerability Database A US federal watchdog has outlined how the National Institute of Standards and Technology (NIST) failed to effectively manage the growing backlog of unprocessed cybersecurity vulnerabilities in the National Vulnerability Database (NVD). Windows Netlogon RCE exploited, domain controllers at risk (CVE-2026-41089) CVE-2026-41089, a critical Windows Netlogon RCE flaw that allows remote code execution, is now actively exploited in the wild, the Centre for Cybersecurity Belgium (CCB) warned last Friday. CVE-2026-41089 is a stack-based buffer overflow vulnerability in Windows Netlogon, the service and protocol that handles authentication and security within a Windows domain environment. Google fixes actively exploited Android vulnerability (CVE-2025-48595) Google has announced the June 2026 Android security updates, which fix a bucketload of vulnerabilities, including a high-severity vulnerability (CVE-2025-48595) in the Android Framework that “may be under limited, targeted exploitation.” Autonomous AI-driven worm can reason its way through corporate networks Researchers at the University of Toronto, the Vector Institute, and the University of Cambridge have built and tested a proof-of-concept AI-driven worm that does not operate on a fixed list of exploits. Instead, it analyzes each target it encounters, reasons about how to attack it, and creates a strategy on the fly, all with the help of a small, free large language model (LLM) running directly on machines it has already compromised. Cisco SD-WAN 0-day exploited, no patch available (CVE-2026-20245) A 0-day privilege escalation vulnerability (CVE-2026-20245) in Cisco Catalyst SD-WAN Manager that has yet to be patched by Cisco is being leveraged by attackers. June 2026 Patch Tuesday forecast: Where are the CVEs? Forecast from last month was only partly right. After the Anthropic Mythos announcements and the deluge of newly discovered vulnerabilities from vendors like Mozilla, Microsoft’s updates were standard fare, 65 CVEs reported in Windows 11 and 58 in Windows 10. The modern-day business can learn a lot about risk from this year’s mega events Every year brings its share of global events, but 2026 is proving to be a banner year for mega-scale entertainment. The year got off to a roaring start with the Winter Olympics, and now anticipation is building for the fast-approaching FIFA World Cup. But amid the buzz, have you ever paused to consider the staggering level of risk inherent to such large-scale events? Or how impressive it is that organizers are able to manage that risk so successfully? From critical to controlled: Cutting vulnerabilities in a live manufacturing environment A vulnerability scanner flags a critical CVSS 10 vulnerability on an industrial asset. The report lands in the boss’ inbox and now he wants to know why we’re sitting on a critical vulnerability. In a normal IT environment, you patch it then close the ticket and call it a day. If, however, you’re in OT or dealing with ICS in a live manufacturing facility, it’s rarely that simple. Why you need BAS and autonomous pentesting together A new autonomous penetration testing tool delivers impressive results at first—finding critical issues, uncovering undocumented attack paths, and exposing forgotten accounts. But by the fourth or fifth run, the discoveries dry up. The tool keeps reporting the same stale issues, and the dashboard becomes another source of noise. What seemed like continuous validation quietly turns into a repeat of the same well-worn attack paths. Governing shadow AI without killing innovation In this Help Net Security video, Alan Snyder, CEO at NowSecure, talks about governing shadow AI without stopping innovation. He frames the problem as two opposing forces. Companies need to adopt AI fast because attackers and competitors will outpace them otherwise, but they also need to do it safely. What CISOs need to do about post-quantum migration in the next 24 months In this Help Net Security video, Garfield Jones, SVP Global Strategy and Research, QuSecure, lays out what CISOs should do over the next 24 months. A recent Google paper moved the expected arrival of a cryptographically relevant quantum computer from 2035 to 2029, leaving organizations about two and a half years to prepare. AI agent governance gets harder when agents outnumber your people In this Help Net Security video, Amit Gautam, CTO at Abluva, explains the security risks that autonomous AI agents bring into enterprise environments. EU organizations buckle under rising compliance pressure Cybersecurity governance in the EU is shifting under expanding frameworks such as NIS2 and DORA, while AI raises new questions for security teams. What the future brings is hard to predict, and organizations must find a way to cope. Antonija Vojnović, Governance, Risk and Compliance Department Manager at Span, spoke with Help Net Security at the Span Cyber Security Arena conference about how these regulatory frameworks are shaping compliance priorities and day-to-day decision-making. DNS-AID lets AI agents find and verify each other through DNS AI agents run across many platforms, and each one needs a way to locate and confirm the identity of the others it works with. The Linux Foundation’s DNS-AID project gives them that capability through the Domain Name System, the same address lookup system that has directed internet traffic for decades. The project lets AI agents and Model Context Protocol (MCP) servers use DNS as a global, vendor-neutral directory for publishing, discovering, and verifying one another. Brute-force attack triggers Dashlane account lockouts Password manager Dashlane has confirmed that a brute-force attack targeting user accounts triggered temporary account suspensions and authentication issues. The company first acknowledged the incident on May 31 after users reported receiving account suspension emails and experiencing login problems. Meta tries to get ahead of scammers before the World Cup begins Football fans are counting down the days until the FIFA World Cup begins, and scammers are doing the same. Last week, the FBI warned that cybercriminals are spoofing FIFA websites to steal personal information, sell fake tickets, and promote fraudulent hospitality packages ahead of the tournament. Sensitive government personnel data posted online, Spanish police arrest suspect The Spanish National Police arrested a man in Granada for allegedly leaking personal data belonging to members of several sensitive state institutions. 64,000 accounts exposed in breach of GTA V cheat service Atlas Menu Atlas Menu, a cheat service for Grand Theft Auto V and Counter-Strike 2, has been added to the Have I Been Pwned database following a data breach that exposed tens of thousands of user records. The incident exposed approximately 64,000 accounts, including email addresses, usernames, IP addresses, support tickets, and passwords hashed with bcrypt. Anthropic expands Project Glasswing to 150 organizations in more than 15 countries Anthropic is expanding Project Glasswing, its cybersecurity initiative built around the Claude Mythos Preview model, by adding about 150 organizations following several weeks of work with its initial group of partners, security firms, open-source maintainers, and government agencies. Malware campaign targeting Minecraft users infects over 116,000 systems A Malware-as-a-Service (MaaS) operation named WeedHack is targeting Minecraft users and allows threat actors to gain remote access to victims’ screens, webcams, and files through a web-based dashboard, McAfee researchers found. Microsoft responds to security challenges facing code, AI agents, and models Microsoft has introduced a series of security tools and capabilities focused on AI-driven vulnerability discovery, AI agents, and AI models. The updates include a multi-agent vulnerability discovery system, new controls for managing and securing AI agents, data protection capabilities, and tools designed to identify potentially vulnerable or compromised AI models before deployment. AI is helping low-skill hackers pull off advanced cyberattacks Anthropic has published an analysis of cyber-related misuse of its AI systems, examining 832 accounts that were banned for malicious cyber activity between March 2025 and March 2026. The company mapped the observed behavior to the MITRE ATT&CK framework, which documents tactics and techniques used by attackers. Attackers obtained encrypted password vaults from some Dashlane user accounts Dashlane has disclosed new details about a brute-force attack that let a threat actor access some customer accounts and copy encrypted vaults. Dashlane said it found no evidence that the attackers compromised its internal systems. The company first acknowledged the incident on May 31 after users reported receiving account suspension emails and experiencing login problems. 145 AI laws passed in 2025 and privacy teams aren’t catching a break 145 AI-related laws were enacted by state legislatures in 2025, and more than 1,000 additional bills were introduced or revised, according to DataGrail’s Privacy and AI Trends Report 2026. NVIDIA goes open source with a big batch of physical AI agent tools NVIDIA just dropped a big batch of open-source “physical AI” skills and tools, and they’re designed to make a roboticist’s life a whole lot easier. The idea? Take the messy, complicated work behind robots, self-driving cars, vision AI, and industrial digital twins, and break it into bite-sized tasks that AI agents can actually run themselves. Microsoft Defender Vulnerability Management gets a smarter exposure score Microsoft Defender Vulnerability Management’s updated exposure score model adds vulnerability risk signals and asset context to help teams understand where risk is concentrated and which remediation actions are likely to have the greatest impact. The model is available in public preview. This AI model backdoor attack stays hidden until you customize the model Most teams that deploy AI start with a backbone model. They download a large pre-trained system, adapt it to a specific task, and put it into production. The download step carries a security question: the origin of the model. A research team built an attack called BadBone. It plants a backdoor inside a backbone model. Downstream tasks that adapt the model inherit the backdoor. The name points at the target. Corrupt the skeleton, and systems built on top of it carry the flaw. OpenAI brings frontier AI to existing AWS environments OpenAI frontier models and Codex are now available on AWS, giving customers access to OpenAI capabilities within AWS environments and the controls needed to move more quickly from evaluation to deployment. These capabilities are available through OpenAI models on Amazon Bedrock, a platform for building generative AI applications and agents at production scale. The platform enables teams to build AI applications using AWS-native security and governance controls. KDE Linux security audit cuts kernel modules and unused packages KDE Linux, the in-progress operating system from the KDE community, removed several kernel modules and software packages after a security audit of the components shipped with the system. The work followed the discovery of multiple security issues in the upstream Linux kernel during the prior month. Codex knowledge work expands into research, reports, and spreadsheets Office workers in the United States lose hours each week to email triage and to searching for files spread across disconnected systems. Roughly 40 percent of US labor, about 72 million people, works primarily with information such as analysis, documents, designs, and communication. Research from the McKinsey Global Institute puts the average knowledge worker at 28 percent of the workweek on email and close to 20 percent on hunts for internal information or for colleagues who can help with specific tasks. Meta adds stricter guardrails for teen feeds Meta has expanded its Teen Accounts 13+ content settings globally on Instagram, Facebook, and Messenger. The safeguards are designed to help young users see age-appropriate content by default. The company also introduced Limited Content on Instagram for parents seeking stricter restrictions. Meta plans to roll out the feature on Facebook and Messenger later this year. Known vulnerabilities behind most application security incidents Eight in ten organizations took an application security hit during the past year tied to a vulnerability their team had already cataloged, according to a survey of 902 IT and security professionals conducted by the Cloud Security Alliance. The pattern points to a structural condition across the industry, where the window between identifying a flaw and closing it in production stays open long enough for attackers to act. Agent Threat Rules: Open detection rule format for AI agent security threats AI agents run inside coding assistants, MCP servers, and multi-agent frameworks, and the access that makes them useful also opens paths to prompt injection, tool poisoning, and credential theft. Public CVE feeds carry agent-execution flaws that reach production faster than the tooling built to catch them. Agent Threat Rules, or ATR, is an open detection format aimed at this category of attack. Microsoft Scout agent opens a new category of always-on Autopilots Workplace AI assistants have mostly waited for a prompt before doing anything. A user asks, the tool answers, and the exchange ends there. Microsoft is putting a different kind of agent inside its Office applications, one designed to keep operating in the background once a person stops paying attention. The company introduced Microsoft Scout, calling it the first entry in a category it labels Autopilots. New Android feature promises to spot deepfake scam calls Android is introducing fake call detection to help protect users from impersonation scams. The feature can detect and flag suspected spoofed calls when both parties use Phone by Google on Android 12 or later. It will roll out globally this month, starting with Pixel devices. ETSI sets security requirements for AI data centers and cloud platforms ETSI has published TS 104 033, a technical specification that defines security requirements for AI computing platforms. The specification establishes a security framework for platforms used to host AI applications in data center and edge computing environments, covering security functions, platform components, interfaces, and services designed to protect AI models, datasets, training processes, and inference workloads. Product showcase: Trend Micro Mobile Security detects scams in messages, QR codes, and websites Trend Micro Mobile Security for iOS protects devices from potentially harmful websites while browsing, blocks ads and personal information trackers, helps users avoid unsafe Wi-Fi networks, and monitors data usage. The app is available for both iOS and Android devices. Most pros have seen AI hallucinations in IT operations Autonomous AI is taking action inside enterprise IT environments. Software is restarting services, isolating risky devices, and applying patches without waiting for a human to approve the step. The capability is spreading at the same time IT professionals are reporting frequent encounters with AI output errors that can carry operational impact. Let’s Encrypt works toward post-quantum certificates at web scale Let’s Encrypt plans to pursue a post-quantum-safe Web PKI through Merkle Tree Certificates (MTCs), a new approach that adds post-quantum authentication to the web without sacrificing the speed and reliability that have made TLS universal. The project is targeting late 2026 for a staging environment that issues MTCs, with a production-ready environment planned for 2027. Photos: Infosecurity Europe 2026 Infosecurity Europe 2026 is a cybersecurity event that took place from June 2 to 4 in London. Help Net Security was on-site and here’s a closer look at the conference. Attackers already know the secrets are on your developers’ machines. Do you? In a recent GitGuardian analysis, an average of 150 secrets were found on a sample of developer endpoints. Private keys accounted for 38% of unique secrets, while cloud, identity provider, and secret management credentials (AWS IAM, Hashicorp vault) added another 22%. Simplify security management with CIS SecureSuite Platform CIS SecureSuite Membership simplifies the process with tools, benefits, and resources for implementing the secure recommendations of the CIS Benchmarks. With the release of CIS SecureSuite Platform, it’s now even easier for Members to harden their systems. Cybersecurity jobs available right now: June 2, 2026 We’ve scoured the market to bring you a selection of roles that span various skill levels within the cybersecurity field. Check out this weekly selection of cybersecurity jobs available right now. New infosec products of the week: June 5, 2026 Here’s a look at the most interesting products from the past week, featuring releases from Asimily, depthfirst, Diligent, Hyland, MazeBolt, and Noma.

ETSI sets security requirements for AI data centers and cloud platforms ETSI has published TS 104 033, a technical specification that defines security requirements for AI computing platforms. The specification establishes a security framework for platforms used to host AI applications in data center and edge computing environments, covering security functions, platform components, interfaces, and services designed to protect AI models, datasets, training processes, and inference workloads. “This work builds on the AI computing platform security framework we have previously developed and marks a significant step forward in establishing concrete and actionable security requirements for the platform itself,” said Scott Cadzow, Chair of the ETSI Technical Committee Securing AI. An AI computing platform is a computing platform intended to host AI applications. It provides the computing resources, storage, networking, and software components required to support AI workloads throughout their lifecycle. They are deployed in data centers and edge computing environments and often include AI accelerators such as GPUs and NPUs. AI computing platform structure overview (Source: ETSI) Security requirements for AI computing platforms The specification groups security requirements into identity management and access control, data protection, integrity protection, auditing, incident response, and resilience. Identity management and access control support the principle of least privilege and restrict platform access to authorized users and systems. Remote access to root-level accounts is prohibited. Integrity protection includes support for secure boot mechanisms that help ensure system components have not been altered. The platform must protect data transmitted to and from authorized entities against unauthorized disclosure. It must support backup and recovery of data at rest and system configuration information required for system restoration. The specification addresses risks specific to AI environments. AI models and datasets should remain protected while stored, transmitted, and processed. Shared AI accelerators such as GPUs and NPUs should provide isolation between users and workloads. The platform should detect attacks targeting AI inference processes and securely store AI-related logs for auditing and forensic analysis. It should support recovery of model training activities following failures or cyberattacks and maintain service availability during abnormal operating conditions. These requirements establish a foundation for secure and trustworthy AI operations in data center and edge computing environments. Security services for AI workloads The AI computing platform provides security services that protect AI models, datasets, training processes, and inference operations throughout their lifecycle. The specification identifies several core services, including protection of AI assets during transmission and storage, protection of AI assets during processing, AI accelerator resource isolation, training recovery, inference attack detection, secure logging, and Model Bill of Materials (Model BoM) support. These services support the confidentiality, integrity, availability, and traceability of AI systems. Encryption, integrity verification, tenant-specific key management, and hardware-bound decryption protect AI assets from unauthorized access and tampering. Resource isolation prevents tenants from accessing each other’s workloads in shared computing environments. Inference attack detection identifies attempts to extract sensitive information or compromise AI models. Training recovery services allow model training to resume after system failures or cyberattacks, reducing the risk of lost work. Secure logging protects AI-related records from alteration or deletion, while Model BoM services provide verifiable records of model development and training history to support auditing, forensic investigations, and model traceability. Mechanisms supporting the security framework To support the platform’s security requirements and services, the framework defines mechanisms for establishing AI confidential computing environments and securing communications between them. Key mechanisms include AI asset encryption and decryption, which protect models and datasets while stored or transferred, and AI confidential computing, which enables sensitive AI workloads to run within protected execution environments. The framework includes AI accelerator resource isolation to prevent unauthorized access between users sharing the same hardware resources. Additional mechanisms support recovery from failures, detection of attacks against inference processes, protection of AI-related logs from tampering, and Model Bill of Materials proof functions that provide evidence of the integrity and authenticity of information related to AI model development and deployment.

Advances in quantum computing could render traditional encryption methods obsolete by 2029, Google has warned. Quantum computing will use quantum mechanics to solve problems which today’s traditional binary computers simply can’t understand. The technology has the potential to revolutionize scientific and medical research, data analysis, machine learning and more. But it also poses a risk to cybersecurity as we know it, because quantum computers will be capable of breaking the public-key cryptography algorithms employed by most encryption systems used today. This puts sensitive information held by businesses, banks, governments, technology vendors and others, currently protected by traditional encryption methods, at risk of being accessed or stolen if traditional encryption is broken by adversaries. Consensus on when ‘Q-Day’ - the moment when quantum computers will be able to break existing cryptographic algorithms – will arrive is divided. The UK’s National Cyber Security Centre (NCSC) has suggested that organizations must be prepared to apply post-quantum cryptography by 2035, while the US National Security Agency (NSA) has set a deadline of 2033 for its security systems to be post-quantum resilient. Microsoft has also said by 2033 it aims to make its products post-quantum safe. Post‑Quantum Cryptography Deadline Could Hit by 2029 Google has recently said the deadline to secure the quantum era with post-quantum cryptography (PQC) migration could come as early as 2029. “Quantum computers will pose a significant threat to current cryptographic standards, and specifically to encryption and digital signatures,” the company said in a blog post, authored by Heather Adkins VP of security engineering and Sophie Schmieg, senior staff cryptography engineer. “The threat to encryption is relevant today with store-now-decrypt-later attacks, while digital signatures are a future threat that require the transition to PQC prior to a Cryptographically Relevant Quantum Computer (CRQC)” Store-now-decrypt-later attacks (also known as harvest-now-decrypt later) see threat actors steal sensitive data that’s currently encrypted but have plans to break that encryption when quantum computing technology allows them to do so. If Google is correct, this could now be as early as 2029. “This new timeline reflects migration needs for the PQC era in light of progress on quantum computing hardware development, quantum error correction, and quantum factoring resource estimates,” the company said. To help counter the potential security threat posed by encryption-breaking quantum computing, Google’s upcoming Android 17 operating system will be equipped with PQC digital signature protection using ML-DSA in alignment with the National Institute of Standards and Technology (NIST). Mark Pecen, chair of technical committee on quantum technologies at the European Telecommunications Standards Institute (ETSI), commented, “Google’s accelerated 2029 deadline reflects a shift from trying to predict Q-day to managing pre-Q-day risk.” “By moving earlier than government timelines, Google is effectively forcing the industry to treat post-quantum migration as an immediate operational priority rather than a future compliance exercise,” he added.

C’è qualcosa di profondamente inquietante nell’idea che il router Wi-Fi, anche quello usato per guardare serie TV in streaming o per far fare i compiti ai nostri figli, possa essere stato arruolato in un esercito digitale criminale a nostra insaputa. È esattamente quello che è accaduto con le botnet Aisuru, KimWolf, JackSkid e Mossad, che per fortuna sono state smantellate il 20 marzo 2026 in un’operazione internazionale coordinata che non ha precedenti per scala e complessità. Nelle quattro botnet insieme, infatti, si contavano tre milioni di dispositivi compromessi che hanno consentito tra l’altro anche di condurre attacchi DDoS che hanno raggiunto il picco di 31,4 terabit al secondo, una cifra che supera qualsiasi record precedente nel panorama delle minacce informatiche. I bersagli includevano sistemi del Dipartimento della Difesa degli Stati Uniti e infrastrutture critiche e aziende private in tutto il mondo. E, dietro a tutto questo, un modello di business sofisticato come quello del cybercrime-as-a-service in cui la capacità distruttiva veniva “noleggiata” al miglior offerente. Indice degli argomenti Secondo quanto comunicato dal Dipartimento di Giustizia degli Stati Uniti, l’operazione ha visto la partecipazione della Defense Criminal Investigative Service (DCIS) e dell’FBI sul fronte americano, del Bundeskriminalamt (BKA) e della ZAC NRW in Germania, e della Royal Canadian Mounted Police (RCMP) insieme a Ontario Provincial Police (OPP) e Sûreté du Québec (SQ) in Canada. Un’alleanza investigativa che ha portato al sequestro di domini internet e server virtuali utilizzati per il comando e controllo (C2) delle botnet, recidendo così il legame tra gli operatori criminali e i milioni di dispositivi infetti. Determinante il contributo del settore privato: dell’imponente operazione di polizia, infatti, hanno fatto parte anche una dozzina di aziende tecnologiche e organizzazioni di threat intelligence, tra cui Cloudflare, Akamai, Amazon Web Services e The Shadowserver Foundation, che hanno fornito supporto tecnico essenziale. Un elemento che merita attenzione inquanto è ormai evidente che, sempre più spesso, le grandi operazioni di contrasto al cybercrime non sarebbero possibili senza questa collaborazione pubblico-privato, a testimonianza del fatto che la sicurezza informatica è ormai una questione di ecosistema e non di singoli attori. Il meccanismo alla base di queste botnet era, nella sua essenza, alquanto semplice: trovare dispositivi IoT esposti su internet con vulnerabilità note o credenziali di default, infettarli con malware e aggregarli in una rete controllata centralmente dai server C2. Da quel momento in poi, ogni dispositivo compromesso diventava potenzialmente un’arma nelle mani degli attaccanti. Particolarmente preoccupante era la capacità dimostrata da KimWolf e JackSkid di compromettere dispositivi protetti da firewall tradizionali. Questo rappresenta un salto qualitativo significativo rispetto alle botnet di precedente generazione: non è più sufficiente posizionare un device dietro un NAT o un firewall perimetrale per ritenersi al sicuro. I criminali hanno affinato tecniche che sfruttano protocolli di rete legittimi, UPnP mal configurato o vulnerabilità nel firmware per raggiungere dispositivi teoricamente isolati. Una volta costruita la rete, gli operatori non la utilizzavano esclusivamente in proprio: la affittavano ad altri criminali attraverso un modello di cybercrime-as-a-service. I clienti pagavano per lanciare attacchi DDoS contro obiettivi specifici, spesso con finalità estorsive portate avanti con la rituale formula del “paga o la tua infrastruttura smette di funzionare”. Come riportato dagli investigatori, i danni per le vittime private hanno raggiunto decine di migliaia di dollari tra perdite dirette e costi di remediation d’emergenza. Al di là della straordinaria dimensione operativa, la vicenda delle quattro botnet smantellate dagli USA pone sul tavolo alcune questioni di carattere strutturale che, chiunque si occupi di sicurezza informatica, non può ignorare. Queste quattro botnet non sono un’anomalia, ma il sintomo di un ecosistema IoT strutturalmente fragile. Miliardi di dispositivi vengono immessi sul mercato con firmware minimale, password di default identiche per tutti gli esemplari del modello, nessun meccanismo di aggiornamento automatico e cicli di vita del prodotto che superano di gran lunga il supporto software del produttore. Quando un router da 30 euro resta in uso per 8 anni e smette di ricevere patch di sicurezza dopo 18 mesi dall’acquisto, il risultato quasi inevitabile è che diventa una risorsa per i criminali. Il volume di traffico raggiunto da queste botnet non è un numero da leggere distrattamente: per dare un’idea della scala, è sufficiente considerare che un attacco DDoS da 31,4 Tbps è sufficiente a saturare la connettività Internet di intere nazioni di medie dimensioni. Significa che anche organizzazioni con infrastrutture anti-DDoS robuste e progettate per assorbire picchi nell’ordine dei terabit, si troverebbero in seria difficoltà. Ciò significa che il settore della mitigazione DDoS dovrà necessariamente ripensare le proprie architetture di riferimento. Il fatto che tra i target figurino indirizzi IP gestiti dal Department of Defense Information Network (DoDIN) suggerisce che almeno parte di questi attacchi avesse una valenza strategica che va oltre la semplice estorsione economica. Non è possibile escludere che la capacità di queste botnet venisse utilizzata o venduta anche per finalità di disruption di infrastrutture militari e governative, con implicazioni che toccano la sicurezza nazionale. Questa operazione di law enforcement è una buona notizia, ma non risolve il problema alla radice. I dispositivi precedentemente infetti sono stati “liberati” dalla disconnessione dei server C2, ma restano vulnerabili e possono essere re-infettati in qualsiasi momento. Ecco le azioni concrete che consiglio, sia ai privati che alle organizzazioni. Cambiare subito le password di default. Router, webcam, NAS, smart TV, termostati intelligenti: qualsiasi dispositivo connesso alla rete deve avere una password univoca e robusta. Le credenziali di fabbrica sono pubblicamente note e sistematicamente sfruttate dai bot di scansione. Aggiornare il firmware. Verificare mensilmente se sono disponibili aggiornamenti per tutti i dispositivi IoT. Se un produttore non rilascia più patch, valutare la sostituzione del dispositivo o l’adozione di firmware alternativi open source (es. OpenWrt per i router). Segmentare la rete domestica. Se il router lo permette (come nella maggior parte dei modelli moderni), è utile creare una rete Wi-Fi dedicata per i dispositivi IoT, separata da quella usata per navigare con PC e smartphone. In questo modo, un dispositivo compromesso non avrà accesso diretto agli altri. Disabilitate UPnP e il port forwarding non necessario. L’Universal Plug and Play è una funzionalità conveniente ma pericolosa: permette ai dispositivi di aprire automaticamente porte sul router, facilitando l’accesso dall’esterno. Disabilitarlo se non strettamente necessario. Monitorate il traffico anomalo. Consumi di banda insolitamente elevati nelle ore notturne, rallentamenti inspiegabili della connessione: possono essere segnali di un dispositivo infetto che partecipa a un attacco. Alcuni router offrono strumenti di monitoraggio del traffico integrati. Inventario completo degli asset IoT. Non si può proteggere ciò che non si conosce. Il primo passo è un asset inventory aggiornato che includa tutti i dispositivi connessi alla rete aziendale, compresi quelli di terze parti (stampanti, sistemi di videosorveglianza, sensori industriali, dispositivi medicali). Strumenti come Nmap, Shodan Enterprise o soluzioni dedicate come Claroty e Armis possono automatizzare questa fase. Zero Trust Network Access per l’IoT. Abbandonare il modello “all’interno del perimetro ci si fida”. Ogni dispositivo IoT deve essere autenticato, autorizzato e monitorato come se fosse potenzialmente ostile. La microsegmentazione di rete con VLAN dedicate e regole di firewall granulari limita drasticamente il ragio d’azione in caso di compromissione. Threat intelligence e monitoraggio continuo. Iscriversi ai feed di threat intelligence rilevanti per il proprio settore produttivo e monitorate gli indirizzi IP pubblici delle infrastrutture aziendali su database come Shadowserver per verificare se risultano associati a botnet note. Implementare un SIEM con regole specifiche per rilevare comportamenti tipici dei bot (scansioni di porte, tentativi di connessione C2, picchi anomali di traffico UDP/ICMP). Piano di risposta agli incidenti aggiornato. Includere esplicitamente gli scenari DDoS e la compromissione IoT nel proprio Incident Response Plan. Definire in anticipo chi contattare (ISP, provider di mitigazione DDoS, CERT nazionale), quali sistemi isolare in via prioritaria e come comunicare con clienti e stakeholder durante un’interruzione prolungata. Valutazione dei fornitori IoT. Nei processi di procurement, introdurre criteri di cyber security by design: verificare che i produttori abbiano politiche di patch management chiare, tempi di supporto documentati e un processo di vulnerability disclosure. Preferire vendor che aderiscano a standard come ETSI EN 303 645 o le linee guida NIST per l’IoT. Dal punto di vista della gestione del rischio aziendale, questa vicenda ribadisce una verità scomoda e cioè che il rischio IoT non è un rischio tecnico di nicchia, è un rischio di business. Un’azienda che subisce un attacco DDoS da 30 Tbps, anche qualora dovesse disporre di un contratto con un provider di mitigazione, andrà di sicuro incontro a interruzione del servizio, danni reputazionali, possibili violazioni degli SLA con i clienti e, in alcuni settori regolamentati, obblighi di notifica alle autorità di vigilanza. Dunque, i danni indiretti spesso superano di gran lunga i costi diretti della remediation. È dunque opportuno valutare l’adozione di questi tre elementi a supporto delle organizzazioni: Assicurazione cyber: verificare che la propria polizza copra esplicitamente gli attacchi DDoS e le perdite da interruzione del servizio. Molte polizze “cyber” contengono esclusioni che emergono solo al momento del sinistro. Business Continuity Planning: testare il piano di continuità operativa almeno una volta l’anno con simulazioni realistiche che includano scenari di attacco DDoS prolungato. La gestione di crisi non si improvvisa sotto pressione. Supply chain security: se i fornitori o partner hanno dispositivi IoT compromessi nelle loro reti, il rischio può propagarsi verso di noi attraverso connessioni VPN, API o integrazioni di sistema. Estendete le vostre valutazioni di rischio all’ecosistema di terze parti. Lo smantellamento delle quattro botnet Aisuru, KimWolf, JackSkid e Mossad è un risultato straordinario, reso possibile dalla combinazione di capacità investigative internazionali e cooperazione pubblico-privato a un livello raramente raggiunto in precedenza. Ma sarebbe un errore interpretarlo come un punto di arrivo. I dispositivi vulnerabili che hanno alimentato queste botnet esistono ancora, a miliardi, connessi a Internet in tutto il mondo e, purtroppo, le tecniche di infezione sono documentate e replicabili con il modello di business criminale del DDoS-as-a-Service che si è dimostrato redditizio: dunque, possiamo ben prevedere che nuove botnet emergeranno o probabilmente già esistono, in fase di crescita silenziosa. La risposta strutturale richiede interventi su più livelli: regolamentazione più stringente sulla sicurezza dei prodotti IoT (l’EU Cyber Resilience Act va nella direzione giusta, ma i tempi di implementazione sono lunghi), responsabilizzazione dei produttori, educazione degli utenti finali e investimenti continuativi in capacity di threat intelligence e law enforcement specializzato. Nel frattempo, la prima linea di difesa siamo noi, aziende e privati che dobbiamo smettere di trattare i dispositivi connessi come gadget e iniziare a trattarli per quello che sono ossia endpoint di sicurezza che richiedono attenzione, aggiornamenti e configurazione consapevole. Il router del salotto (e, di conseguenza, anche quello aziendale) non è più solo un oggetto di consumo, ma un potenziale vettore di attacchi che possono colpire ospedali, infrastrutture critiche e sistemi di difesa. Vale la pena prendersene cura.

Audits for AI systems that keep changing Security and risk teams often rely on documentation and audit artifacts that reflect how an AI system worked months ago. ETSI’s continuous auditing based conformity assessment specification (ETSI TS 104 008) describes a different approach, where conformity is evaluated through recurring measurement and automated evidence collection tied to live system behavior. The specification addresses a common challenge in AI oversight. Models evolve through retraining, data pipelines change, and system configurations shift during operation. Oversight methods built around periodic reviews struggle to track those changes in a consistent way. Continuous auditing based conformity assessment, known as CABCA, treats change as an expected condition and builds assessment processes around it. Treating assurance as an ongoing activity CABCA defines conformity assessment as a standing operational function. Assessment runs in cycles that repeat throughout an AI system’s lifecycle. Each cycle gathers evidence from system artifacts such as logs, test results, model parameters, and data samples. Automated analysis compares that evidence against predefined requirements and metrics, producing an updated conformity status. Assessment cycles begin through defined triggers. Some triggers follow a schedule, such as regular reviews tied to time intervals. Others respond to events like model updates, data drift, or performance anomalies. Each trigger initiates the same core steps, creating a consistent flow from measurement to reporting. This structure aligns assessment activity with how AI systems operate in production environments. Monitoring, evaluation, and reporting occur alongside development and operational workflows rather than outside them. From high-level rules to measurable checks A central concept in CABCA is operationalization. Organizations start by identifying the requirements that apply to a specific AI system. These requirements may come from legislation, standards, internal policies, customer obligations, or sector rules. The scoping process consolidates those requirements into a single conformity specification. Operationalization translates that specification into quality dimensions, risks, metrics, and measurement methods. Quality dimensions include areas such as accuracy, bias avoidance, privacy, accountability, and cybersecurity. Each dimension links to identified risks that describe how the system could deviate from expectations. Measurable requirements and thresholds are then derived for continuous evaluation. The result is a set of machine-readable metrics that assessment tools can track automatically. This creates a direct connection between abstract obligations and observable system behavior. Continuous evidence and reporting Evidence collection under CABCA is automated and persistent. Measurements run continuously or at defined intervals and feed into an assessment engine. The engine evaluates results against thresholds defined during operationalization and produces findings that map directly to specific requirements. Reporting follows the same cadence as assessment. Conformity status updates reflect current measurement results and link back to supporting evidence. Reports persist over time, creating a record that shows how conformity status changes as systems evolve. Follow-up actions integrate into the same cycle. When teams apply corrective measures, subsequent assessment cycles evaluate their effect through updated measurements. This creates a feedback loop that ties remediation to verified outcomes. Assessment paths and external review CABCA supports multiple assessment paths. In a self-assessment path, the AI system provider reviews assessment results internally and records conformity status. This path suits organizations with internal assurance functions and established governance structures. A third-party assessment path allows external auditors to access assessment reports and evidence. The specification supports programmatic access through secure interfaces, enabling automated review and status updates by external systems. The framework also supports certification use cases. Continuous evidence streams produced through self-assessment or third-party assessment can feed certification processes. Certification bodies evaluate conformity based on current data rather than fixed review windows, supporting certificates that reflect ongoing system behavior. Defined roles and accountability The specification assigns explicit roles within the assessment process. The auditee, typically the AI system provider, manages scoping, operationalization, infrastructure, and execution of assessment cycles. The auditing party evaluates evidence and determines conformity status based on the selected assessment path. Risk ownership forms part of the recorded assessment data. Each AI system has named owners responsible for mitigation decisions and resource allocation. Ownership information persists alongside conformity status, supporting traceability and accountability. Alignment with regulatory obligations CABCA is designed to support regulatory frameworks that require ongoing oversight of AI systems. The framework links risk management activities, technical documentation, quality management processes, and post-market monitoring through a shared evidence base. Technical documentation and quality management artifacts draw from the same measurements used in assessment cycles. This creates consistency between operational data and formal conformity declarations. Evidence collected during operation feeds both internal governance and external review processes. “This latest Technical Specification is founded on a firm principle: trustworthy and accountable AI can only result from practical, auditable, lifecycle‑long compliance,” said Jürgen Großmann, Chair of the AI working group of ETSI’s Technical Committee for Methods and Testing for Specifications (MTS AI) “In laying down a clear framework for CABCA, ETSI bridges the gap between high-level legal obligations and the realities of modern AI systems in the field.” Read more: More employees get AI tools, fewer rely on them at work Review: AI Strategy and Security New intelligence is moving faster than enterprise controls

Encryption Backdoor in Military/Police Radios I wrote about this in 2023. Here’s the story: Three Dutch security analysts discovered the vulnerabilities—five in total—in a European radio standard called TETRA (Terrestrial Trunked Radio), which is used in radios made by Motorola, Damm, Hytera, and others. The standard has been used in radios since the ’90s, but the flaws remained unknown because encryption algorithms used in TETRA were kept secret until now. There’s new news: In 2023, Carlo Meijer, Wouter Bokslag, and Jos Wetzels of security firm Midnight Blue, based in the Netherlands, discovered vulnerabilities in encryption algorithms that are part of a European radio standard created by ETSI called TETRA (Terrestrial Trunked Radio), which has been baked into radio systems made by Motorola, Damm, Sepura, and others since the ’90s. The flaws remained unknown publicly until their disclosure, because ETSI refused for decades to let anyone examine the proprietary algorithms. […] But now the same researchers have found that at least one implementation of the end-to-end encryption solution endorsed by ETSI has a similar issue that makes it equally vulnerable to eavesdropping. The encryption algorithm used for the device they examined starts with a 128-bit key, but this gets compressed to 56 bits before it encrypts traffic, making it easier to crack. It’s not clear who is using this implementation of the end-to-end encryption algorithm, nor if anyone using devices with the end-to-end encryption is aware of the security vulnerability in them. […] The end-to-end encryption the researchers examined recently is designed to run on top of TETRA encryption algorithms. The researchers found the issue with the end-to-end encryption (E2EE) only after extracting and reverse-engineering the E2EE algorithm used in a radio made by Sepura. These seem to be deliberately implemented backdoors.

Cybersecurity researchers have discovered a fresh set of security issues in the Terrestrial Trunked Radio (TETRA) communications protocol, including in its proprietary end-to-end encryption (E2EE) mechanism that exposes the system to replay and brute-force attacks, and even decrypt encrypted traffic. Details of the vulnerabilities – dubbed 2TETRA:2BURST – were presented at the Black Hat USA security conference last week by Midnight Blue researchers Carlo Meijer, Wouter Bokslag, and Jos Wetzels. TETRA is a European mobile radio standard that's widely used by law enforcement, military, transportation, utilities, and critical infrastructure operators. It was developed by the European Telecommunications Standards Institute (ETSI). It encompasses four encryption algorithms: TEA1, TEA2, TEA3, and TEA4. The disclosure comes a little over two years after the Netherlands-based cybersecurity company discovered a set of security vulnerabilities in TETRA standard called TETRA:BURST, counting what was described as an "intentional backdoor" that could be exploited to leak sensitive information. The newly discovered issues relate to a case of packet injection in TETRA, as well as an insufficient fix for CVE-2022-24401, one of the five flaws that was documented as part of TETRA:BURST, to prevent keystream recovery attacks. The identified vulnerabilities are listed below - CVE-2025-52940 - TETRA end-to-end encrypted voice streams are vulnerable to replay attack. Furthermore, an attacker with no knowledge of the key may inject arbitrary voice streams, that are played back indistinguishably from authentic traffic by legitimate call recipients. CVE-2025-52941 - TETRA end-to-end encryption algorithm ID 135 refers to an intentionally weakened AES-128 implementation which has its effective traffic key entropy reduced from 128 to 56 bits, rendering it vulnerable to brute-force attacks. CVE-2025-52942 - End-to-end encrypted TETRA SDS messages feature no replay protection, allowing for arbitrary replay of messages towards either humans or machines. CVE-2025-52943 - TETRA networks that support multiple Air Interface Encryption algorithms are vulnerable to key recovery attacks since the SCK/CCK network key is identical for all supported algorithms. When TEA1 is supported, an easily recovered TEA1 key (CVE-2022-24402) can be used to decrypt or inject TEA2 or TEA3 traffic on the network. CVE-2025-52944 - The TETRA protocol lacks message authentication and therefore allows for the injection of arbitrary messages such as voice and data. ETSI's fix for CVE-2022-24401 is ineffective in the prevention of keystream recovery attacks (No CVE, assigned a placeholder identifier MBPH-2025-001) Midnight Blue said the impact of the 2TETRA:2BURST depend on the use-cases and configuration aspects of each particular TETRA network, and that networks that use TETRA in a data-carrying capacity are particularly susceptible to packet injection attacks, potentially allowing attackers to intercept radio communications and inject malicious data traffic. "Voice replay or injection scenarios (CVE-2025-52940) can cause confusion among legitimate users, which can be used as an amplifying factor in a larger-scale attack," the company said. "TETRA E2EE users (also those not using Sepura Embedded E2EE) should in any case validate whether they may be using the weakened 56-bit variant (CVE-2025-52941)." "Downlink traffic injection is typically feasible using plaintext traffic, as we found radios will accept and process unencrypted downlink traffic even on encrypted networks. For uplink traffic injection, the keystream needs to be recovered." There is no evidence of these vulnerabilities being exploited in the wild. That said, there are no patches that address the shortcomings, with the exception of MBPH-2025-001, for which a fix is expected to be released. Mitigations for other flaws are listed below - CVE-2025-52940, CVE-2025-52942 - Migrate to scrutinized, secure E2EE solution CVE-2025-52941 - Migrate to non-weakened E2EE variant CVE-2025-52943 - Disable TEA1 support and rotate all AIE keys CVE-2025-52944 - When using TETRA in a data carrying capacity: add TLS/VPN layer on top of TETRA "If you operate or use a TETRA network, you are certainly affected by CVE-2025-52944, in which we demonstrate it's possible to inject malicious traffic into a TETRA network, even with authentication and/or encryption enabled," Midnight Blue said. "Also, CVE-2022-24401 likely affects you, as it allows adversaries to collect keystream for either breach of confidentiality or integrity. If you operate a multi-cipher network, CVE-2025-52943 poses a critical security risk." In a statement shared with WIRED, ETSI said the E2EE mechanism used in TETRA-based radios is not part of the ETSI standard, adding it was produced by The Critical Communications Association's (TCCA) security and fraud prevention group (SFPG). ETSI also noted that purchasers of TETRA-based radios are free to deploy other solutions for E2EE on their radios. The findings also coincide with the discovery of three flaws in the Sepura SC20 series of mobile TETRA radios that allow attackers with physical access to the device to achieve unauthorized code execution - CVE-2025-52945 - Defective file management restrictions CVE-2025-8458 - Insufficient key entropy for SD card encryption Exfiltration of all TETRA and TETRA E2EE key materials with the exception of the device-specific key K (no CVE, assigned a placeholder identifier MBPH-2025-003) Patches for CVE-2025-52945 and CVE-2025-8458 are expected to be made available in the third quarter of 2025, necessitating that users are advised to implement enhanced TETRA key management policies. MBPH-2025-003, on the other hand, cannot be remediated due to architectural limitations. "The vulnerabilities enable an attacker to gain code execution on a Sepura Gen 3 device," the company said. "Attack scenarios featuring CVE-2025-8458 involve persistent code execution through access to a device's SD card. Abuse of CVE-2025-52945 is even more straightforward as it requires only brief access to the device's PEI connector." "From the premise of code execution, multiple attack scenarios are viable, such as exfiltration of TETRA key materials (MBPH-2025-003) or the implantation of a persistent backdoor into the radio firmware. This leads to the loss of confidentiality and integrity of TETRA communications."