Rome-based Exein said on September 15 that it has raised $270 million at a $1.7 billion post-money valuation, a large financing for a company focused on the part of cybersecurity most software buyers rarely see: the firmware and runtime layers inside connected devices. The round matters because it signals where investors think the next security bottleneck sits as AI moves off the screen and into robots, vehicles, industrial systems, medical equipment, and grid-connected hardware.
According to Exein’s announcement, the round was led by Headline and included Sofina, Goldman Sachs, the EIB Group through the European Tech Champions Initiative, KfW Capital, T.Capital, and existing backers. Exein said the financing was significantly oversubscribed and that the proceeds will support expansion in the U.S. and Asia-Pacific, acquisitions, and a product roadmap aimed at what it calls physical AI security. The company is also expanding a revolving credit facility led by J.P. Morgan, with KfW joining as an additional lender.
The real question for readers is not whether investors can produce another European unicorn. It is whether an embedded-security vendor can become a meaningful control point for physical AI systems — and what a device maker or infrastructure operator should verify before treating that claim as part of a safety or resilience program.
Why investors are backing the device layer now
Exein, founded in 2018, sells embedded and runtime security for connected devices. Its Photon product is described as a kernel-level runtime architecture designed to stop malicious execution before it occurs. That pitch lands differently in physical AI than it does in enterprise SaaS. When a cloud application is compromised, the damage is often confined to data, accounts, or business processes. When a robot, drone, controller, vehicle, or medical device is compromised, the consequences can spill into uptime, operations, and safety.
That helps explain why capital is flowing toward firmware, runtime enforcement, machine telemetry, and the OEM-and-silicon relationships needed to get security into devices before they ship. It also helps explain why regulation is becoming part of the commercial backdrop. As TechCrunch reported, Exein is targeting U.S. and Asia-Pacific expansion, with Asia-Pacific already accounting for about half of its revenue. At the same time, the EU’s Cyber Resilience Act has begun adding reporting obligations in 2026 and is scheduled to apply fully in December 2027, increasing pressure on manufacturers to show that connected products can be monitored, updated, documented, and defended.
That does not make Exein the default answer. But it does create a stronger commercial reason for OEMs, component suppliers, and operators to ask whether device-level controls are sufficient, auditable, and economical.
The gap between a big funding round and deployment proof
Exein says its technology is deployed across more than two billion connected devices spanning industrial automation, automotive, energy, healthcare, semiconductors, aerospace, and robotics. It also says it sees about 5,000 new, non-repetitive attacks per week across that network, five times last year’s volume. TechCrunch independently corroborated the funding, valuation, the more-than-two-billion-device figure, the kernel-level positioning, and Exein’s plan to release its first physical-AI foundation models in the first quarter of 2027.
What those numbers do not yet answer is the procurement question.
Coverage to date does not establish how many of those devices actively run Photon, how Exein defines an “attack” or “non-repetitive,” what share of those events were blocked, or which customers are paying for which level of service. A device count, even a very large one, can reflect different kinds of deployment: broad but shallow integrations through silicon or OEM partners, deeper installations in narrower fleets, or a mix of monitoring and prevention modes. For buyers, those distinctions are more important than the valuation.
The same caution applies to the roadmap. Exein says an agentic security architecture will ship by the end of 2026 and that its first physical-AI foundation models are expected in Q1 2027. That is a signal about where the company thinks the category is going: from static protection toward more automated analysis of machine behavior and threat telemetry. But it is still a roadmap, not field proof.
What OEMs and operators should ask before they buy
The embedded-security business is won or lost in integration work. Exein’s model depends on working with original-equipment manufacturers and silicon vendors, which means the technology must fit device-development cycles, certification processes, support contracts, and low-margin hardware economics.
For engineering teams, the first questions are technical and concrete. Which operating systems and chip architectures are supported? How does Photon interact with real-time constraints? What latency, CPU, memory, and power overhead does it add? What are the failure modes if the protection layer crashes, misclassifies behavior, or blocks a legitimate process? Can policies be tuned per device class without creating a support nightmare?
Then come lifecycle controls. How are patches delivered? What rollback options exist if an update breaks a field deployment? How do secure boot, signed updates, hardware roots of trust, and runtime enforcement work together? A kernel-level product can be valuable here, but it is not a substitute for those other controls. Buyers should treat it as one layer in a system that still needs segmentation, asset inventory, human incident response, and disciplined software maintenance.
Telemetry governance matters just as much. Who owns the machine data generated by detection and response? Where is it stored? How long is it retained? Can operators keep analysis on premises or within a specific geography? If a device is part of critical infrastructure or healthcare, the security stack has to fit data-handling rules as well as threat models.
Commercial diligence is equally important. What incident-response commitments are attached to the service? Is there a documented escalation path when a field device shows anomalous behavior? Does the vendor help generate SBOM-related evidence, vulnerability documentation, and reporting support relevant to the Cyber Resilience Act? And for commodity or low-margin devices, does the per-unit economics work once integration, support, and update obligations are included?
The most persuasive proof would be repeatable deployment evidence: named reference customers where possible, clear descriptions of integration effort, measured performance overhead, audited security outcomes, and examples showing how runtime protection reduced operational risk without destabilizing the device.
Exein has the capital to chase that proof at scale. The funding round shows that investors believe the control layer for physical AI could sit closer to the machine, not just at the network edge or in the SOC. Whether Exein turns that belief into a durable business will depend less on the headline valuation than on something harder to manufacture: evidence that OEMs can integrate the software cleanly, operators can trust its behavior under stress, and regulators will accept its outputs as part of a real compliance and resilience program.
By
By
By
By
