It's election time in Israel and the US and there is a lot of noise. Do you want a more minimalistic life? Company? Product? I'd frame the 3 principles of minimalist design as: 1. Simplicity — Remove everything that doesn't contribute to the purpose. Every element must earn its place. 2. Reuse — Prefer existing components, patterns, and solutions over creating new ones. Reduce duplication and unnecessary variation. 3. Clarity — Make the purpose, structure, and behavior immediately understandable. Minimize cognitive load. Or, more provocatively: Remove. Reuse. Reveal. - Remove what isn't essential. - Reuse what already works. - Reveal what matters.

From Sexy Starts to Messy Middles to Funky Finishes Why I'm writing this to you. As a serial Israeli tech founder specializing in cyber and privacy for medtech with customers like Amgen, Verily, Walmart Vision and innovative Israeli device companies, I realized MedTech CEOs have substantially more risk exposure than they think until it is too late. Most CEOs lack the quantitative exposure in dollars necessary to properly prioritize cyber investments to protect enterprise value. The first way to fix this is not intuitive - assume you will fail. Instead of success, assume you want to fail In this series of posts I will give you 23 anti-design patterns that guarantee failure and solution for each anti-design pattern. Anti-pattern 1 - BrainFog • Uncertainty on what your product does • Uncertainty on who it’s for Solution: Say your positioning in 10 words or less. • What does your product do, who it’s for?

Does reading security papers makes your RA/QA team better at pricing the CEO’s bets? The system lead at one of my startups worked at NY Life. The CIO allocated first hour of the day to read research papers. I loved the idea and adopted it as an SOP for my teams. A recent paper on Arxiv shows sensitive information recovered from an AI processor’s electromagnetic emissions. The POC uses a probe close to the silicon, controlled processor settings, and specialized measurement equipment. Interesting research. Now comes the work that matters for your device. Can someone get sufficiently close? Can they collect a useful signal through the packaging? Does the attack apply to your hardware and model? Would the information recovered have meaningful consequences? RA/QA can leverage side-channel attacks into design decisions. And you'll know if you read.

Your engineers, RA/QA and CFO love standardization of hardware and software. Could it also help an attacker study it and mount a side-channel attack? • Same processor. • Same runtime. • Same model. • Same configuration. That consistency helps engineering, manufacturing, support, and change control. It may also let an attacker study a unit they own before approaching one they don’t. For physical side-channel attacks, the important question is whether measurements learned on one unit transfer to another. That transfer is an assumption to test. Hardware variation, enclosures, interference, and operating conditions may change the result. Here is the risk story I would investigate: acquire a device → characterize its leakage → attempt inference on another unit. Where does that story become impractical for your product? Standardization creates commercial value. Understanding its security consequences helps protect that value.

Is encryption a magic bullet for medical devices? It wasn't even a required countermeasure in the HIPAA Security Rule. Thinking about what risks really count is the closest you'll get to magic bullets. So when your engineer says, “It’s encrypted.” • Which part of the patient’s journey does that protect? • What's encrypted? • Where encrypted? • How encrypted? A local clinical AI device runs in a Raspberry Pi edge device with a small local LM patient information → encrypted storage → inference → clinical output. Encryption protects the stored information. TLS protects information crossing a network. During inference, the processor uses the information. The side-channel research in my latest essay examines leakage from that computation through electromagnetic emissions. The researchers needed controlled conditions and a probe close to the processor. Applicability to a medical device needs its own assessment. But “we use encryption” does not answer that particular threat. That is why I like writing risk as a story.

Here's a question for RA/QA teams for validation - Who can get physically close to your AI medical device? And for how long? Imagine the same device deployed in three places: A controlled procedure room. A shared clinic. A patient’s home. The hardware and software are identical. Physical access is very different. For a side-channel threat, that difference matters. An attacker may need equipment close to the processor, time to collect measurements, and conditions that make the signal useful. Those requirements belong in the risk story. Who can approach the device? Can they touch or open the enclosure? Would anyone notice equipment placed nearby? A laboratory demonstration becomes relevant to your product only when you examine those assumptions.

RA/QA: “The patient data never leaves the device.” Would you sign off on that claim? Moving clinical AI onto the device has real advantages. Less dependence on connectivity. Faster responses. Less patient data sent to cloud services. But follow the data one step further: patient → prompt → processor → output. The processor has to use the sensitive information. Its physical activity can reveal information about what it is doing. The research I discuss in this week’s essay demonstrates that possibility under controlled laboratory conditions, with a probe close to the processor. That does not establish an attack from a hospital hallway. It does give RA/QA a new question

Local doesn’t mean private Side-channel attacks on edge AI in medical devices. I was a technician in a communications battalion in the Israeli Army. We provided communications infrastructure for an armored division. Two of us handled encryption of trunk communications. Our equipment sat in an armored van and the lines in and out were physical cabling. I was trained as a physicist. Sitting in the van - I often wondered how much of the radiation leaking from those cables could be remotely detected, and at what distances. Today - I got an answer to my old question. Researchers at University of Amsterdam recently demonstrated a proof of concept attack extracting output tokens and user prompts via electromagnetic emissions. See this article on Arxiv published Oct 9, 2026. The deployment of large language models (LLMs) on edge devices is largely motivated by privacy concerns over sharing sensitive user data with cloud servers. The authors demonstrate that keeping inference local does not eliminate privacy risks They put a near-field probe next to the processor and measured what the chip radiated while it was computing.

Federated learning does not assure patient data privacy Complex software systems are like dysfunctional families - they have unexpected threat surfaces. A new NeurIPS 2026 paper showed a proof of a federation learning threat surface: the model updates exchanged during federated training can contain enough information to reconstruct individual chest X-rays, CT images and pathology tiles. Model inversion attacks In federated learning, each hospital trains the model locally and sends gradients or updated parameters to a coordinating server. The server combines those updates into a shared model. The problem is that gradients are not harmless metadata. They encode information about the examples that produced them. Model-inversion attacks exploit that information to reconstruct training samples. Earlier attacks worked mainly against small batches or unrealistic configurations. Newer attacks—including Robbing-the-Fed, LOKI and Scale-MIA—use specially constructed model layers to recover inputs in closed form at clinically realistic batch sizes. In our models, that single failure mode averages a $4.1M+ single-loss expectancy. See arxiv.org/html/2609.38339v1

I confess that I've been blinded by speed. If you are fast - you can select a CRO at the last minute If you are fast - you can do an FDA cyber threat model 2 weeks before the submission. Is fast decision-making a double-edged sword? NIST recently joined the Gen AI bandwagon - recommending that Gen AI can compress the first draft of a cybersecurity assessment “from weeks to hours.” Speed is seductive AND deceptive. • It’s seductive because most CEOs wait until the last minute to make a risk management • In clinical trials - I've noticed that many life science companies make decisions on CROs a month before the first patient is recruited. And that’s for $10-100M bets. • In my cyber and privacy practice - my life science clients start working on FDA cyber and HIPAA compliance during a sales process with a customer or strategic partner. It’s deceptive because you can quickly end up with security theater - feeling secure instead of being secure.