Jump to a section
In this article
Executive Summary
Most cybersecurity practice assumes AI is software: code and a fixed set of model weights, running on a general-purpose processor, doing the same thing every time it gets the same input. Neuromorphic computing breaks each part of that. Brain-inspired chips such as Intel’s Loihi 2, IBM’s NorthPole and BrainChip’s Akida process information as sparse “spikes” that fire only when something changes, often fed by event-based sensors that report changes in light instead of full frames. Some of these chips can learn on the device after deployment. The security consequences follow directly. Attackers gain routes through the physical world, such as flashing light at a sensor, glitching the power supply or reading a chip’s electromagnetic emissions. Endpoint agents, vulnerability scanners and the patch cycle mostly do not reach the chip. And a device that keeps learning drifts away from the version that was tested and approved. Published research has already shown backdoors in spiking networks triggered by flashing light, power glitches that cut accuracy by up to 85.65%, and side-channel attacks that recover a network’s parameters. The EU AI Act and the US FDA both already have a rule for AI that changes after approval: set the limits of change in advance and document them. We recommend the same discipline for every adaptive device, whatever the sector.
1.15bn
neurons in Intel’s Hala Point, built from 1,152 Loihi 2 chips and delivered to Sandia National Laboratories in 2024
100%
the highest attack success for flashing-light backdoors against spiking networks fed by event cameras, in the Flashy Backdoor study
85.65%
the largest accuracy loss caused by power and laser fault injection on spiking networks, Nagarajan et al., DATE 2022
Sep 2026
when EU Cyber Resilience Act reporting duties for exploited vulnerabilities began (11 September), including for connected products already on the market
Core conclusions
- Neuromorphic devices move the attack surface out of code and into time, light and power. Threat models for these devices have to cover sensor inputs, side channels and fault injection, and the learning process itself.
- Most enterprise security tooling cannot see inside these chips. Inventory, tamper resistance and behavioural monitoring of the device’s outputs carry more of the load than scanning and patching.
- A device that learns after deployment needs a written learning envelope: what may change, by how much, how it is measured, and how the device is reset to a known-good state. The EU AI Act and FDA rules on systems that change after approval already work this way.
The argument, in ten slides
Save it, or send it to whoever approves the smart devices your organisation buys.
How we wrote this post
Maria Singh
Cybersecurity and AI risk
Maria led the threat side: the four routes an attacker has into an event-driven chip, what the published attack research shows, and why the vulnerability management tools she has run at enterprise scale do not reach this hardware.
Led: Four routes into an event-driven device and Why the usual security tools miss it
Terence Kok
AI governance and assurance
I led the governance side: what happens to an approval when the device keeps learning, how the EU AI Act and the FDA already handle AI that changes after approval, and the learning envelope we propose for every adaptive device.
Led: The approved device and the device in the field and A learning envelope for every adaptive device
We wrote the opening, the controls and the board questions together.
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.
Six assumptions behind AI security
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.
The device drifts, breaches its limit and is restored
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:
- Does the device learn after deployment? If yes, what changes, under what limits, and can learning be switched off?
- What is the reset path? Is there a protected copy of the approved model, and has restoring it been tested?
- What physical attacks has the supplier tested? Ask specifically about sensor manipulation, power and electromagnetic side channels and fault injection, and for the results.
- 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.
- 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:
- Which devices we own or sell contain AI that makes decisions, and which of those can learn after deployment?
- For each device that learns, where is its learning envelope recorded, and who owns it?
- When did we last test that each device behaves as it did when approved, and what did the test find?
- Which of these devices are within reach of the public, and does our threat model cover light, power and electromagnetic attacks on them?
- 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.
Evidence & Methodology
Hardware figures come from the manufacturers and are their own claims. Attack findings come from peer-reviewed papers and preprints, almost all laboratory work on research chips, simulations or models. We found no public report of these attacks on a deployed neuromorphic product. Regulatory points come from the legal texts and official summaries. The four routes, the learning envelope and the questions are ours.
| Claim | Source | Grade |
|---|---|---|
| Hala Point: 1,152 Loihi 2 chips, 1.15 billion neurons, 128 billion synapses, delivered to Sandia | Intel newsroom, 17 April 2024 | Vendor claim |
| Loihi 2 supports programmable on-chip learning; Akida offers incremental and one-shot on-chip learning | Intel, 30 September 2021; BrainChip AKD1000 product brief, 2025 | Vendor claim |
| Akida learning limited to the final layer | arXiv 2408.03336 | Reported |
| TrueNorth: 1 million neurons, about 70 mW | Merolla et al., Science, 2014 | Measured |
| IMX636 pixels report brightness changes, latency under 100 µs | Prophesee sensor documentation | Vendor claim |
| Flashing-light backdoor in event-camera spiking networks, up to 100% success | Riaño, Abad, Picek, Urbieta, arXiv 2411.03022, 2024 | Measured, preprint |
| Neuromorphic-data backdoors up to 100% success, little clean-accuracy loss | Abad, Ersoy, Picek, Urbieta, NDSS 2024 | Measured |
| Event-stream perturbation cut accuracy by more than 20% on DVS-Gesture | Marchisio et al., IJCNN 2021; practicality disputed by Büchel et al. | Measured, disputed |
| Power and laser faults cut accuracy by up to 85.65% | Nagarajan et al., DATE 2022 | Measured |
| EM side channel recovered neuron parameters and layer sizes | Probst, Brosch, Sigl, IACR ePrint 2023/505 | Measured |
| No published work found on poisoning on-chip learning after deployment | Our literature search, October 2026 | Our call |
| AI Act Art. 15(4), 15(5), 43(4); Annex I high-risk from 2 Aug 2028 | Regulation (EU) 2024/1689; Regulation (EU) 2026/1744 | Legal text |
| FDA PCCP final guidance, 4 December 2024 | FDA | Government guidance |
| CRA reporting from 11 Sep 2026; full application 11 Dec 2027 | European Commission, CRA summary | Legal text |
| Learning envelope elements and thresholds | Our framework | Illustrative |
Sources
- Intel. (2024, April 17). Intel builds world’s largest neuromorphic system to enable more sustainable AI.
- Intel. (2021, September 30). Intel advances neuromorphic with Loihi 2, new Lava software framework.
- Merolla, P. A., et al. (2014). A million spiking-neuron integrated circuit with a scalable communication network and interface. Science, 345(6197), 668-673.
- IBM Research. (2023). NorthPole: a new chip for AI inference.
- BrainChip. (2025). Akida AKD1000 SoC product brief.
- Prophesee. IMX636 event-based vision sensor.
- Riaño, R., Abad, G., Picek, S., & Urbieta, A. (2024). Flashy Backdoor: Real-world environment backdoor attack on SNNs with DVS cameras. arXiv 2411.03022.
- Abad, G., Ersoy, O., Picek, S., & Urbieta, A. (2024). Sneaky Spikes: Uncovering stealthy backdoor attacks in spiking neural networks with neuromorphic data. NDSS Symposium.
- Marchisio, A., Pira, G., Martina, M., Masera, G., & Shafique, M. (2021). DVS-Attacks: Adversarial attacks on dynamic vision sensors for spiking neural networks. IJCNN 2021.
- Nagarajan, K., et al. (2022). Analysis of power-oriented fault injection attacks on spiking neural networks. DATE 2022.
- Probst, M., Brosch, M., & Sigl, G. (2023). Side-channel analysis of integrate-and-fire neurons within spiking neural networks. IACR ePrint 2023/505.
- Sorrentino, F., et al. (2026). Emerging threats and countermeasures in neuromorphic systems: A survey. arXiv 2601.16589.
- European Parliament. Digital omnibus on AI. Legislative Train Schedule.
- EU AI Act, Article 15: Accuracy, robustness and cybersecurity, and Article 43: Conformity assessment.
- US Food and Drug Administration. (2024, December 4). Marketing submission recommendations for a predetermined change control plan for artificial intelligence-enabled device software functions.
- European Commission. Cyber Resilience Act: summary.
Why the AI Model Is the Weakest Link in Your Supply Chain
Integrity and provenance for the model inside the device.
Agent-Aware Vulnerability Management Ranks Flaws by What the Agent Can Do
How to rank AI flaws that have no CVE and no patch.
The Vulnerability Didn't Change. The Attacker Did.
Why risk acceptances need rescoring when attacker effort falls.
How AI Agents Turn Low-Rated Security Findings Into a Serious Risk
Ownership for risks that cross several systems.
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.
Was this useful?
