As AI transforms cybersecurity, OEMs must rethink embedded product security before tomorrow's threats become today's vulnerabilities.

In April, Anthropic announced Claude Mythos – its most capable AI model to date – but chose not to release it publicly due to unprecedented cybersecurity risk. Instead, Anthropic launched Project Glasswing, a defensive coalition of over 50 major technology organizations tasked with finding and fixing critical software vulnerabilities before similar capabilities proliferate.

For OEMs building connected EMS products, Project Glasswing signals an accelerating shift in the threat landscape, reinforces growing regulatory expectations around secure-by-design engineering, and creates practical opportunities to strengthen product security across the design, manufacturing and field-service lifecycle. Action taken now will compound in value.

Claude Mythos, Anthropic's publicly confirmed but unreleased frontier AI model, has demonstrated the ability to autonomously discover software vulnerabilities, prompting the launch of Project Glasswing, a defensive initiative that gives select technology partners early access to identify and remediate critical flaws. As AI accelerates vulnerability discovery, OEMs with long-lifecycle embedded products face increased exposure from software weaknesses that can persist long after certification. At the same time, cybersecurity regulations are becoming more closely aligned with product safety requirements, raising compliance expectations for manufacturers. While the challenge is growing, OEMs can reduce risk through practical, phased security improvements without undertaking a complete product redesign.

What is Claude Mythos?

Like previous Claude models, Anthropic’s newest frontier AI model, Mythos, is a general-purpose large language model (LLM) capable of reasoning, writing code and solving complex problems. What distinguishes Mythos from its predecessors is a step-change improvement in autonomous cybersecurity tasks.

According to Anthropic’s official system card and the Frontier Red Team blog, Mythos Preview demonstrated the ability to independently discover thousands of previously unknown software vulnerabilities across every major operating system and web browser, and to develop working exploits without human guidance.

Critically, Anthropic assessed that these capabilities exceeded those of previous models by a significant margin and were advanced enough to pose a dual-use risk: the same skills that accelerate the discovery of defensive vulnerabilities could, in the wrong hands, dramatically lower the barrier to large-scale cyberattacks.

On that basis, Anthropic decided not to make Claude Mythos Preview generally available.

What is Project Glasswing?

Rather than withholding its new model entirely, Anthropic launched Project Glasswing on the same day as the Mythos Preview announcement. Project Glasswing is a defensive cybersecurity initiative that provides controlled access to Claude Mythos Preview to a curated set of organizations responsible for globally critical software infrastructure.

Project Glasswing's launch partners include many of the world's largest technology organizations, including Amazon Web Services, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, The Linux Foundation, Microsoft, Nvidia and Palo Alto Networks.

More than 40 additional organizations with roles in critical software infrastructure have also received access. Anthropic has committed $100 million in usage credits to support participants, alongside direct funding for open-source security work.

Project Glasswing’s stated purpose is to use Mythos Preview’s capabilities to find and remediate critical vulnerabilities before similar AI capabilities become widely accessible, effectively creating a window for defenders to reduce the global software attack surface ahead of broader proliferation.

Anthropic has stated that it does not plan to make Mythos Preview generally available but intends to develop safeguards over time that will allow Mythos-class capabilities to be deployed safely at scale.

Why Project Glasswing Matters

AI can accelerate vulnerability discovery and exploitation. Traditional security research relies on skilled human analysts manually working through large code bases, or on specialized tooling that scans for known vulnerability patterns. Both approaches are time-intensive and produce incomplete coverage of complex, real-world codebases.

Advanced AI models like Claude Mythos Preview represent a different class of capability. These systems can read and reason about large volumes of code, identify subtle logical flaws and, in documented cases, autonomously develop working exploits. At a conceptual level, this shifts the economics of vulnerability discovery. Tasks that previously required months of expert effort may become achievable in hours or minutes.

Connected products can potentially be impacted. For OEMs whose products contain embedded software – whether in smart appliances, industrial controllers, medical devices or transportation systems – the relevant concern is not today’s adversarial capability, but the trajectory.

Two characteristics of embedded products make them particularly worth examining in this context:

• Long deployment lifetimes. Many embedded systems operate for 10–30 years after manufacture. Software that was considered secure at certification may contain latent vulnerabilities that were never identified due to prior tooling limitations, but could, in principle, be discovered by more capable systems in the future.
• Constrained update pathways. Unlike enterprise software, many embedded products lack reliable over-the-air update mechanisms, particularly in regulated environments. This can mean that even a known vulnerability remains unpatched in the field for extended periods.

Neither of these characteristics is new. What Project Glasswing signals is that the speed and breadth of vulnerability discovery may increase, and that the window between discovery and exploitation could shorten.

The extent to which these dynamics translate into actual attacks on specific embedded product categories within a defined timeframe is not precisely predictable, so OEM teams should treat this as a risk-planning horizon rather than a fixed outcome.

Implications for the EMS Product Lifecycle

Design and architecture. Secure-by-design principles are the most efficient point of intervention. Products architected with minimal attack surface, hardware-enforced trust boundaries, and defense-in-depth are more resilient to both current and future vulnerability discoveries, regardless of the discovery method. Threat modeling during early design stages, rather than as a late-stage audit, is increasingly the expected baseline under frameworks such as IEC 62443, ETSI EN 303 645 and the EU Cyber Resilience Act.

Component selection decisions made at the design stage, including the choice of third-party open-source libraries, connectivity stacks, and SoC firmware, determine much of the downstream surface of vulnerabilities. Proactive assessment of a component's security posture, including the history of known vulnerabilities and the vendor patch cadence, should be part of the standard design review process.

Verification and validation. Secure firmware practices, including code signing, boot chain integrity verification, and separation of privileged execution contexts, reduce the exploitability of vulnerabilities even when they are present. These practices are well-established; where they are not already implemented in a product line, prioritization is warranted.

Software Bill of Materials (SBOM) and Vulnerability Exploitability eXchange (VEX) documentation are increasingly required by regulation and customer procurement in sectors including medical and defense. Maintaining a current SBOM enables faster triage when new vulnerability disclosures affect components used in a product.

Fuzz testing at scale – the automated generation of malformed inputs to identify unexpected software behavior – is a well-supported technique for finding vulnerabilities earlier in the development cycle. AI-assisted tooling is beginning to improve coverage and efficiency here, offering OEM teams access to previously scarce capabilities.

Figure 1. As AI accelerates software vulnerability discovery, OEMs are being urged to strengthen secure-by-design practices, SBOM management and product lifecycle cybersecurity.

Manufacturing and supply chain. The manufacturing phase is a critical control point for device identity and cryptographic credential provisioning. Products shipped without unique device identities or with default credentials that are not changed at commissioning represent preventable exposure.

Secure provisioning, such as the controlled injection of unique keys, certificates and configuration at the time of manufacture, establishes a verifiable root of trust that supports lifecycle management.

Supply chain integrity, ensuring that components and firmware are authentic and have not been tampered with between manufacture and field deployment, is a related concern. Trusted component sourcing, chain-of-custody documentation and bill-of-materials verification are all relevant controls.

Field operations and lifecycle management. Over-the-air (OTA) update capability is increasingly a product design requirement rather than an optional feature. Products that can receive authenticated, integrity-checked firmware updates retain the ability to respond to newly discovered vulnerabilities throughout their deployed lifetime. Where OTA is not feasible – for example, in certain safety-certified environments – defined patch delivery and service processes, including field update procedures, provide a fallback.

Patch SLA policies with defined commitments to assess and respond to disclosed vulnerabilities within a stated timeframe are becoming standard in regulated sectors and are expected by sophisticated OEM customers. End-of-life strategies that define the point at which security support ceases and communicate this clearly to customers are equally important for long-lifecycle products.

What OEMs Should Do Now

1. Understand current exposure. The first step is understanding where an organization may be vulnerable. A cross-functional review involving engineering, cybersecurity, product management and other relevant teams can help assess what Claude Mythos and Project Glasswing could mean for the product portfolio. Products that rely on major operating systems, browsers or open-source libraries, such as the Linux kernel, common RTOS variants or networking stacks, should be identified and evaluated, as these technologies may have been analyzed through Project Glasswing. Key software suppliers should also be consulted to determine whether they are participating in the initiative or have received vulnerability disclosures through it, as well as to understand their expected patch release timelines. Finally, responsibility for tracking vulnerability disclosures should be assigned to a designated internal owner so critical updates can be evaluated and addressed as they emerge.
2. Strengthen the baseline. Strengthening the cybersecurity baseline begins with establishing a current Software Bill of Materials (SBOM) across the active product portfolio. Products without an SBOM should have one created, with third-party open-source components identified and their patch status documented. Existing update and patch policies should also be evaluated to identify products that lack over-the-air (OTA) update capabilities and to confirm that field update procedures are documented and can be executed when needed. Conducting a structured threat-modeling exercise on a flagship or high-revenue product using methodologies such as STRIDE or TARA can help identify design risks early, while a review of supplier security questionnaires and procurement criteria can ensure they address SBOM availability, patch cadence and secure provisioning capabilities.
3. Build systematic capability. Building long-term cybersecurity resilience requires security practices to become part of the product development and manufacturing process. Integrating fuzz testing or other forms of dynamic analysis into the firmware development pipeline can improve the ability to identify vulnerabilities early in development. Manufacturing processes should also incorporate secure provisioning, including the injection of unique device identities and cryptographic credentials on new or updated products. Organizations can further strengthen preparedness by conducting tabletop incident response exercises that simulate a publicly disclosed zero-day vulnerability affecting deployed products, helping uncover gaps in detection, triage and customer communication. Finally, existing cybersecurity practices should be benchmarked against the regulatory requirements of target markets to identify compliance gaps and prioritize future improvements.
4. Establish a durable posture. Creating a lasting cybersecurity strategy requires planning beyond immediate threats. A product security roadmap should outline priorities for architecture updates, secure-by-design requirements for next-generation products and plans for addressing technical debt in existing product lines. Patch service-level agreements (SLAs) should define response timelines for critical, high- and medium-severity vulnerabilities and be clearly communicated to customers. Regular third-party security assessments, including penetration testing, component vulnerability scanning and supply chain reviews, can help validate security controls and support regulatory compliance. In addition, close collaboration with EMS partners can strengthen secure provisioning, SBOM management and manufacturing-phase security practices as products move into new design cycles or production refreshes.

The emergence of AI-driven vulnerability discovery reinforces something we have observed building across our customer base over recent years: cybersecurity is no longer a separate workstream appended to a hardware project. It is a foundational quality dimension that affects design choices, supplier selection, manufacturing processes and field service expectations.

Taking a secure-by-design approach, we support OEM engineering teams in assessing product architectures for security risk early in the design cycle, including component selection, connectivity surface and debug/update interface exposure. We also offer SBOM and VEX support, helping customers develop and maintain software bill of materials documentation for products we manufacture, supporting traceability and vulnerability triage.

Our secure provisioning practices ensure manufacturing-phase provisioning processes that inject unique device credentials, cryptographic keys and configuration in controlled, auditable conditions, while our trusted supply chain practices include authorized channel procurement and component authenticity controls relevant to embedded product integrity.

When it comes to compliance-readiness, we assist customers in documenting manufacturing-phase evidence for cybersecurity regulatory submissions, including IEC 62443, ETSI EN 303 645, and the EU Cyber Resilience Act.

Post-production, we also offer lifecycle patch and field support by providing post-market logistics and field service options relevant to products requiring firmware update delivery or managed EOL transitions.

A Balanced Perspective

Claude Mythos and Project Glasswing represent a genuine inflexion point in the security landscape; what is unclear is the rate at which comparable capabilities will proliferate to other actors, the extent to which embedded product categories in OEM markets will be specifically targeted, and whether the defensive window created by Glasswing will close before widespread exposure occurs.

The responsible response is to treat AI-accelerated vulnerability discovery as a directionally established trend likely to intensify, without forecasting specific failure modes or timelines that cannot currently be substantiated. Overreaction – such as product recalls unsupported by specific evidence of vulnerability – is as counterproductive as inaction.

Anthropic’s decision to restrict Mythos and invest in defensive infrastructure reflects a considered judgment about dual-use risk. The EMS and OEM community can play a complementary role by building products that are harder to exploit, more transparent in their software composition, and more capable of receiving security updates throughout their operational life.

Ed.: This article is first published in the Escatec blog and is republished with permission.

Rajeshpal Singh is group corporate communications manager at Escatec. He holds a master's in international business.

• Next