# Hardware Physical Attacks: How to Think About Them > Secure-looking systems can still make the wrong decision, because the assumptions beneath those > decisions exist in physical reality and can be **observed, influenced, or disrupted**. This site > teaches a way of *reasoning* about that, across **side-channel analysis (SCA)**, **fault injection > (FI)**, and **glitching** (voltage / clock / EM / optical), written by and for people who have to > *defend* embedded devices, not just attack them. I'm a product security engineer focused on embedded, medical, and connected devices. I built this to help defenders understand how physical-world effects can flip the decisions that security mechanisms rely on, and to make that reasoning transferable to a device you have never seen. Every page is an original distillation of public research and practitioner knowledge, with links to the source material so you can go deeper. ## Read this first → **[[Every-Security-Boundary-Is-a-Decision|Every security boundary is a decision]]**: the one idea the rest of this site rests on. Security features reduce to decisions, decisions rest on physical assumptions, and those assumptions can be observed, influenced, or disrupted. This document explores the principle only, no hardware is required. Start here before any technique. ## Who this is for - **Security engineers new to hardware attacks**: each entry makes the *bench reality* explicit (what hardware, what setup, what success looks like, what fails), so you don't need prior glitching experience. - **People who design or secure embedded devices** (medical, industrial, IoT): the threat is mapped to defenses and to the frameworks you already answer to (MITRE EMB3D, IEC 62443, and FDA premarket guidance for medical). - **Researchers** who want a fast, cross-linked index of the field. ## What's coming This site is published in the open, one complete layer at a time. Next: the research corpus and its auto-generated maps (techniques, targets, defenses, tools, researchers, frameworks), a fully cited defender's whitepaper, and a hands-on voltage-glitching walkthrough you can run on hardware you own. Each will be linked here as it goes live. ## How this is made This is a distillation, not a reprint. See **[[About]]** for the method, the attribution and licensing policy, and the authorization/defensive scope every entry is written under.