Neuromorphic AI Moves the Attack Surface Into the Device

A security camera at a warehouse gate, an implant that adjusts its own stimulation, a drone that tracks a moving target, a car that spots a pedestrian at night. Each of these is starting to carry a new kind of AI chip, and each of them is a physical object somebody can walk up to.

Most of the AI security work of the last three years has been about software. Prompt injection, model supply chains, agents with too many permissions: all of it assumes the AI is a program, running on a server or a laptop, made of code and a fixed set of weights. You can scan it, patch it, log it, and test it again after a change. Neuromorphic computing takes AI out of that setting and puts it inside sensors and controllers, where it runs on events and, in some designs, keeps learning. This post is about what that does to cybersecurity, and what organisations buying these devices should ask for now.

What changes when AI runs on events

A conventional processor works to a clock. Every tick, it fetches the next instruction and moves data between memory and compute, whether or not anything has changed. A neural network on a GPU processes every frame of a video in full, every time.

Neuromorphic chips borrow from the brain instead. Their artificial neurons sit idle until enough input arrives, then fire a short “spike” to the neurons they connect to. Computation happens only when something changes, and memory sits next to the neurons that use it. Event-based vision sensors, such as the IMX636 that Sony makes with Prophesee, work the same way: each pixel reports only a change in brightness, on its own schedule, with latency under 100 microseconds. A still scene produces almost no data. A moving one produces a stream of events.

The result is AI that runs on milliwatts. IBM’s TrueNorth fitted a million neurons into about 70 milliwatts in 2014. BrainChip’s Akida Pico, launched in 2024, has a core that draws under a milliwatt and targets wearables and sensors. At the other end of the scale, Intel’s Hala Point packs 1,152 Loihi 2 chips, 1.15 billion neurons and 128 billion synapses into a system Sandia National Laboratories took delivery of in 2024.

The commercial direction is clear even where products are early. Innatera launched Pulsar, a neuromorphic microcontroller for sensors, in May 2025. Mercedes-Benz is researching neuromorphic processing for driver assistance with the University of Waterloo. In March 2026, ForwardEdge ASIC, a Lockheed Martin subsidiary, selected BrainChip’s Akida for future aerospace and defence chips.

Three properties matter for security:

Behaviour depends on timing. A spiking network’s output depends on when inputs arrive as well as what they are. The same events in a different order or rhythm can produce a different result.

Some chips learn on the device. Loihi 2 supports programmable on-chip learning, and BrainChip describes Akida as capable of incremental and one-shot learning on the chip. Independent analysis of Akida suggests that learning is limited to the final layer, but the principle stands: the model in the field can differ from the model that shipped.

The AI lives inside a physical object. It sits in a camera, a car or a body, often outside any data centre, often within reach of anyone who can stand next to it.

Same AI, two settings

Six assumptions behind AI security

AI as softwareAI on a neuromorphic device

What sets its behaviourCode and a fixed set of weightsWeights, plus the timing of the events it receives

How the model changesOnly through a release someone shipsOn the chip, as it learns in the field

What counts as inputData, prompts and API callsLight, motion and sound; power and timing leak back out

Scanners and endpoint agentsRun against itNone exist for the chip

Fixing a flawVendor patch, with proof it was installedFirmware can be patched; learned behaviour must be retrained or rolled back

Where it sitsServer or laptop, behind access controlIn a camera, car or body, often within public reach

On an event-driven chip that learns, each assumption shifts. The attack surface moves into the physical world and the learning process.

Our comparison, drawn from the published research cited in this post.

Four routes into an event-driven device

Led by Maria Singh

Security teams are used to thinking about an AI system’s inputs as data: prompts, files, API calls. For an event-driven device, the inputs include the physical world, and the chip’s own physics leak information back out. We group the routes in four.

Route	What the attacker does	What the research shows	Who can attempt it
1. Sensor input	Shapes the events the sensor produces: flicker, patterns of light, crafted motion	Flashing-light triggers planted a backdoor in spiking networks fed by event cameras, with up to 100% attack success; common defences often failed (Riaño et al., 2024)	Anyone within line of sight of the sensor
2. Side channel	Measures power draw, spike timing or electromagnetic emissions while the chip runs	Electromagnetic analysis recovered the neuron parameters of every layer and the layer sizes of a spiking network (Probst et al., 2023); simulated power and timing traces leaked weights and thresholds (Nagarajan et al., 2023)	Someone with brief physical access and lab equipment
3. Fault injection	Glitches the power supply or fires a laser at the chip to disturb how neurons fire	Power and laser faults cut a spiking network’s accuracy by up to 85.65% (Nagarajan et al., DATE 2022)	Someone with physical access to the device
4. Learning	Feeds the device inputs designed to change what it learns after deployment	Backdoor triggers in neuromorphic training data reached up to 100% success with little loss of normal accuracy (Abad et al., NDSS 2024); attacks on learning in the field are a gap in the research	Anyone who can influence what the device sees over time

Our grouping. Findings from the papers cited; most are laboratory results on research chips, simulations or models. None describes an attack seen in the wild.

Sensor input is the route that should worry operators of public-facing devices most, because it needs no access to the device at all. An event camera responds to changes in light, so a flashing pattern is an input the chip has to process. In the Flashy Backdoor study, Riaño, Abad, Picek and Urbieta planted a backdoor that a flashing light could trigger in a real setting with event cameras, and pruning and fine-tuning defences often failed to remove it. Earlier work by Marchisio and colleagues showed that perturbing event streams could cut a spiking network’s accuracy by more than 20% on a gesture data set, although later research questioned how practical that particular attack was.

Side channels are an old problem in a new place. Cryptographers have spent decades stopping smart cards from leaking keys through their power draw. A spiking network is, if anything, noisier: a neuron that fires uses power, and when it fires depends on what it has learned. Probst, Brosch and Sigl at TU Munich used electromagnetic measurements to recover the parameters of a spiking network layer by layer. For a device maker, the trained network is often the most valuable thing in the product. For an operator, a recovered model is a map for building inputs that fool it.

Fault injection is the route of a determined attacker with the device in hand. Nagarajan and colleagues showed that disturbing the power supply or the neurons’ firing thresholds can wreck a spiking network’s accuracy. In a safety system, a fault that quietly stops a detector from detecting matters more than one that crashes it.

Learning is the route that is new to these devices, and the least studied. Backdoors in spiking networks are well documented when the attacker can poison training data: Abad, Ersoy, Picek and Urbieta’s Sneaky Spikes paper reached up to 100% attack success with triggers that change position and colour. What we could not find is published work on poisoning a chip’s learning after it is deployed. That is the attack on-chip learning invites: show a device a pattern often enough and it may learn to treat it as normal. The research gap is a reason for caution.

A survey published this year by Sorrentino, Picek, Batina and colleagues reaches the same conclusion we do: asynchronous, event-driven processing and the variable behaviour of the underlying devices create attack surfaces that conventional AI security does not cover.

Why the usual security tools miss it

Led by Maria Singh

An enterprise vulnerability programme rests on a few assumptions. You can find every device. You can install an agent or run a scanner against it. Its flaws get CVE numbers. A vendor ships a patch, and you can prove it was installed. You can collect logs and spot unusual behaviour. Neuromorphic devices break most of these assumptions at once.

There is no endpoint agent for a spiking processor, and no scanner that understands its weights. A flaw in how a network responds to flicker is a property of that trained model in that sensor, so it may never receive a CVE. The firmware around the chip can be patched, but a learned behaviour cannot be patched in the usual sense. It can only be retrained, rolled back or constrained. And the logs that exist tend to record the device’s decisions and leave out the events and learning that led to them.

The devices are also hard to find. A neuromorphic chip will usually arrive inside something else: a camera module, a sensor, a vehicle subsystem, a medical device. It shows up in procurement as a camera, not as an AI system, so it does not reach the AI register or the AI risk review.

Three things carry more weight as a result:

• Inventory by function. Record which devices contain AI that makes decisions, which of those can learn after deployment, and who owns each one. Ask suppliers directly; the chip will not announce itself on the network.
• Physical security as AI security. For devices within public reach, tamper evidence, enclosure design and shielding against side channels belong in the AI threat model. IEC 62443 component requirements and ETSI EN 303 645 are the obvious baselines for industrial and consumer devices.
• Watching outputs. If you cannot see inside the chip, you can still test what it does. Periodic challenge tests, with known inputs and expected outputs, show whether the device’s behaviour has moved.

The approved device and the device in the field

Led by Terence Kok

Every assurance process I have worked with assumes that the thing approved is the thing deployed. A model is validated, a risk assessment is signed, a conformity assessment is completed, and change control catches anything that alters it later. Software makes that workable, because changes come through releases that someone decides to ship.

A device that learns on the chip changes without a release. Each week in the field, its behaviour reflects what it has seen. A year after approval, the risk assessment describes a device that no longer exists, and nobody signed off the difference. In my view this is the larger governance problem, larger than any single attack, because it removes the basis for every assurance statement made about the device.

Two regulators have already written rules for this, and they agree on the approach.

The EU AI Act addresses high-risk systems that keep learning. Article 15(4) requires them to be built to eliminate or reduce, as far as possible, the risk of biased outputs feeding back into future operations. Article 15(5) requires resilience against attempts to alter their use, outputs or performance by exploiting vulnerabilities, which covers the sensor and learning routes Maria describes. Article 43(4) is the key clause for governance. A substantial modification triggers a new conformity assessment, but changes to a learning system that the provider set out in advance, at the initial assessment, and recorded in the technical documentation do not count as substantial modifications. Following the Digital Omnibus on AI, Regulation (EU) 2026/1744, high-risk AI embedded in products regulated under Annex I now applies from 2 August 2028.

The US FDA reached the same place for medical devices. Its final guidance on Predetermined Change Control Plans for AI-enabled device software, issued on 4 December 2024, lets a manufacturer describe planned changes, the protocol for making and testing them, and an assessment of their impact. Changes made within the plan need no new submission.

Both rules say the same thing: you may let an AI system change after approval, provided you decided in advance how far, how you would check, and what you would do if it went further. That is the principle we think every organisation deploying adaptive devices should adopt, regulated or not.

The EU Cyber Resilience Act adds the security side for connected products. Its duty to report actively exploited vulnerabilities and severe incidents has applied since 11 September 2026, including to products already on the market, and its full requirements apply from 11 December 2027. A manufacturer of a neuromorphic camera sold in the EU will need to show how it handles vulnerabilities in the device’s AI as well as its firmware.

A learning envelope for every adaptive device

Led by Terence Kok

We call the written limits a learning envelope. It is short, and it belongs in the device’s approval record and in the AI system register.

Element	Question it answers	Example for a learning access-control camera
What may change	Which parts of the model can update in the field?	Final classification layer only; feature layers fixed at approval
How far	What size of change is allowed before review?	Accuracy on the reference test set stays within 2 points of the approved baseline; false-accept rate never above the approved level
How it is measured	What test shows the device is still inside the limits, and how often?	Monthly challenge test with a fixed set of known faces, objects and light patterns, run on the device
What triggers action	What happens when a limit is breached?	Learning suspended automatically; owner notified within 24 hours
How to go back	Can the device return to a known-good state, and is that state protected?	Signed copy of the approved weights held off-device; tested reset procedure
Who owns it	Who signs off a change to the envelope itself?	Named business owner with security and risk sign-off

Our framework, informed by Article 43(4) of the EU AI Act and the FDA’s Predetermined Change Control Plan guidance. Example thresholds are illustrative.

A learning envelope at work

The device drifts, breaches its limit and is restored

Accuracy on the monthly challenge test, against the approved baseline

Schematic. The trace is illustrative; the 2-point floor is the example threshold in the learning envelope table above.

The envelope does three jobs. It turns a vague worry about drift into a measurable test. It gives the security team a signal that learning-route attacks would trip, because poisoning a device’s learning shows up as a change in its challenge results. And it makes the reset path a requirement at purchase, settled before any incident. A device that cannot be returned to a known-good state should not be allowed to learn in the field at all.

For devices that do not learn after deployment, most of this still applies. A fixed network on an event-driven chip still needs a challenge test, because sensor, side channel and fault attacks change its behaviour without changing its weights.

What to ask suppliers and owners

We would put these into procurement and design reviews for any device with embedded AI, neuromorphic or not:

1. Does the device learn after deployment? If yes, what changes, under what limits, and can learning be switched off?
2. What is the reset path? Is there a protected copy of the approved model, and has restoring it been tested?
3. What physical attacks has the supplier tested? Ask specifically about sensor manipulation, power and electromagnetic side channels and fault injection, and for the results.
4. How will vulnerabilities in the AI be reported and fixed? For products sold in the EU, the Cyber Resilience Act now makes this a legal question as well as a contractual one.
5. What can we test ourselves? A supplier should provide a challenge test set and a way to run it on the device in the field.

Questions for the board

We would ask management for written answers to five questions:

1. Which devices we own or sell contain AI that makes decisions, and which of those can learn after deployment?
2. For each device that learns, where is its learning envelope recorded, and who owns it?
3. When did we last test that each device behaves as it did when approved, and what did the test find?
4. Which of these devices are within reach of the public, and does our threat model cover light, power and electromagnetic attacks on them?
5. Can every adaptive device be returned to its approved state, and have we tried it?

Question five is the one we would ask first. A device that cannot be put back is one whose behaviour the organisation no longer controls.

Free tool

Agent Risk Assessment Matrix

Place an AI system on an autonomy and consequence grid and see which ISO/IEC 42001-referenced controls apply. A device that acts on its own and learns in the field sits in the top right; this shows what it should carry.

→

---

My thanks to Maria Singh, who co-wrote this post with me. Maria led the threat analysis: the four routes into an event-driven device and why enterprise security tooling does not reach it. I led the governance and regulatory sections and the learning envelope.

If your organisation is buying or building devices with embedded AI that learns, the learning envelope and the reset path are where I would start. My consulting work covers technology and AI risk governance for boards of regulated firms and public agencies.