Power electronics is a security domain, and pretending otherwise is how we end up with AI infrastructure that can be attacked from below the operating system. That is an unpopular position among people who spend their days on model weights and prompt filters, but the announcement Infineon made on 7 September 2026 is a good reason to revisit it.
The company introduced the TDA235E5 and TDA235E0, a dual-phase smart power stage family built for next-generation AI accelerators and vertical power delivery modules. The parts combine OptiMOS 6 MOSFETs with a dual-phase driver IC inside a 6 x 6 x 0.8 mm³ package, reaching a power density above 2 A/mm². Each device handles up to 300 A peak current and 120 A total design current, and they work with Infineon digital multiphase controllers for scalable multi-rail designs. Both side and vertical power delivery configurations are supported, and Infineon positions them for AI xPU accelerators as well as conventional server CPUs.
Read that as an engineering achievement and you will be impressed. Read it as a security researcher and you will notice something else: the control plane for hundreds of amps now sits on a digital bus, in a component most threat models never mention.
Why a power stage belongs in your threat model
My work at botsec.net is mostly about AI bots being manipulated, hijacked, or degraded by an adversary. The usual assumption is that the attacker operates in software, somewhere between the API gateway and the inference runtime. That assumption gets shaky the moment you remember that inference hardware is a physical system with a voltage regulation loop, and that loop is programmable.
A digital multiphase controller driving smart power stages is, functionally, a small computer with authority over the electrical conditions your accelerator lives in. Telemetry flows out. Configuration flows in. That is a control channel, and control channels attract attackers. I am not claiming any vulnerability in these specific Infineon parts, and nothing in the announcement suggests one. I am claiming that the general class of component deserves the same scrutiny we give a BMC or a firmware image.
The questions I would ask
- Who can write to the power controller at runtime, and through which host path?
- Is that write path authenticated, or does it inherit trust from whatever process happens to own the bus?
- Does anyone alert on unexpected configuration changes, or only on thermal and power-budget thresholds?
- Can power telemetry be read by tenants who should not be able to observe each other’s workloads?
Most operators I talk to cannot answer the first two without going to ask a hardware team. That gap is the actual finding here.
Density changes the consequences
Higher current in a smaller footprint is exactly what AI accelerators need, and it is also what makes the margin for error thinner. When 120 A of design current moves through a 6 x 6 mm part sitting directly beneath or beside the processor, the electrical and thermal behavior of that component is tightly coupled to whether the chip above it computes correctly. A power delivery path that is out of spec does not produce a clean crash. It produces the kind of failure that shows up as a wrong answer.
For AI systems, that matters more than it does for a web server. A bot that returns a corrupted token, a slightly wrong embedding, or a silently truncated computation looks like it is working. Availability failures get paged. Correctness failures get shipped. Any adversary who can influence the electrical environment of an accelerator, even at the margins, is operating in a layer where your monitoring stack has almost nothing to say.
What I would actually do about it
None of this argues against denser power delivery. Integration of the driver and MOSFETs into one qualified part, with a defined interface to a controller from the same vendor, is a better security story than a pile of discrete components wired together by whoever won the bid. Fewer seams, clearer ownership, one supply chain to verify.
The practical steps are unglamorous. Treat the power controller’s configuration as protected state and record its baseline. Audit which host software can reach the bus, and cut that list down. Feed power and thermal telemetry into the same place you keep security logs, not just the facilities dashboard. Ask vendors about firmware update authentication for anything on the regulation path, and get the answer in writing before procurement, not after an incident. When you build an accelerator card bill of materials, note the power stage and controller part numbers where your security team can find them.
Infineon shipping samples of a 120 A dual-phase power stage is a signal about where AI hardware is heading: more current, tighter packaging, more programmable control between the wall and the tensor cores. The defenders who notice that early will be the ones who still understand their own stack in two years.
đź•’ Published: