# CHIPSEC: assessing PC firmware and platform security from Windows, Linux or the UEFI shell

> CHIPSEC is Intel's GPL-2.0 framework for inspecting hardware, system firmware and platform components. It is a low-level diagnostic tool, and the documentation expects you to know what you are doing before you run it.

**chipsec/chipsec** — Platform Security Assessment Framework

- Repository: https://github.com/chipsec/chipsec
- Stars: 3,310 · Forks: 618
- Language: Python
- License: GPL-2.0
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/chipsec-chipsec

## What CHIPSEC actually inspects

CHIPSEC is a framework for analyzing the security of PC platforms, and the README names three layers it covers: hardware, system firmware (BIOS/UEFI), and platform components. That scope is narrower than a general vulnerability scanner and wider than a firmware updater. It is for people who need to look at what the platform exposes below the operating system: the security test suite, the tools for accessing low level interfaces, and the forensic capabilities are the three things the README lists as the contents of the framework.

The audience is implied by the warning rather than stated outright. The README says the software is for security testing purposes, tells you to use it at your own risk, and points at chipsec/WARNING.txt before use. A tool that needs a warning file before first run is not aimed at a general administrator who wants a pass or fail score. It is aimed at firmware engineers, platform security assessors and researchers who already know which register or interface they are asking about.

One detail in the README matters more than it looks. Support for older Intel platforms lives on a separate branch, chipsec1, and the split is drawn by generation: client platforms before ADL (pre-12th Gen Core) and server platforms before SPR (pre-3rd Gen Xeon Scalable). If your fleet is older than that line, the default branch is not the one you want, and the README treats this as a first-order decision rather than a footnote.

## How the framework is put together

The repository layout shows the shape of the tool. Two entry points sit at the top level: chipsec_main.py for the security test suite and chipsec_util.py for direct access to low level interfaces. That split is the architecture in miniature. chipsec_main runs a set of checks and reports results; chipsec_util is the manual instrument you reach for when a check fails and you need to see the underlying value yourself.

The chipsec/ package holds the framework itself, and the repository carries separate requirement files per platform: linux_requirements.txt and windows_requirements.txt. The presence of drivers/ alongside those files tells you the framework does not talk to hardware from pure Python on a normal operating system. Kernel-level access is part of the design, and the setup.py file contains a NO_DRIVER_MARKER_FILE constant named README.NO_KERNEL_DRIVER, which indicates a build path that installs the package without the kernel driver.

There is also a chipsec_tools/ directory, a live_image/ directory and a debian/ directory, so packaging and a bootable image are maintained in-tree rather than bolted on. setup.py requires setuptools greater than 62.0.0 and raises a RuntimeError telling you to upgrade if the version is older, so a stale build environment fails at install time with a clear message instead of producing a broken tree. The version string is read from chipsec/VERSION, and the README states the release convention is major.minor.patch, with changes to arguments or calling conventions held for a minor version update. That convention is the most useful thing in the README for anyone scripting against the tool: patch releases should not move the interface out from under you.

## Installing CHIPSEC and running a first check

The README does not spell out install steps. It says instructions for installing and using CHIPSEC can be found in the manual, chipsec-manual.pdf, which ships in the repository root. Treat that PDF as the authoritative source for your platform, because the driver situation differs between Windows and Linux and the repository carries separate requirement files for each.

The setup.py file is present at the top level, which is the standard entry point for installing the package with setuptools. Because setup.py raises a RuntimeError when setuptools is older than 62.0.0, upgrade setuptools first if you are on an old environment:

```bash
pip install setuptools --upgrade
```

After that, installing from a checkout goes through setup.py. The repository does not document a specific pip command or a published package name, so install from the source tree you cloned rather than guessing a package:

```bash
python3 setup.py install
```

Once installed, the two top-level scripts are what you invoke. The security test suite is chipsec_main.py:

```bash
sudo python3 chipsec_main.py
```

Expect the run to need elevated privileges on Linux, because the framework accesses low level interfaces and the repository ships drivers for that purpose. If you want to query a specific interface rather than run the whole suite, chipsec_util.py is the other entry point:

```bash
sudo python3 chipsec_util.py
```

The README also states that CHIPSEC can be run on Windows, Linux, and UEFI shell, so the same framework is reachable from three environments with different privilege models. What you should see after a successful install is a run that reaches the test suite rather than failing on a missing driver or an import error; the setup.py NO_DRIVER_MARKER_FILE constant exists precisely because a driverless build is a recognised configuration, and a driverless build will not give you the same coverage.

## Where CHIPSEC is the wrong tool

The most concrete limitation is stated in the README itself: for older Intel platforms, the default branch is not the supported one. The chipsec1 branch covers pre-ADL client and pre-SPR server hardware. Anyone who installs the default branch on a machine older than that line and expects the full test suite to work is working against the project's own guidance. The README gives the switch as a single command, which is a strong hint that this is a common wrong turn.

The second limitation is the warning. The README opens with a note that the software is for security testing purposes, use at your own risk, and read WARNING.txt before using. A framework that reaches into hardware and firmware interfaces is not something to run on a production machine you cannot afford to disturb. The README does not document rollback, and it does not describe a safe mode; it points you at a warning file. If your workflow needs a guarantee that a scan leaves the platform untouched, that guarantee is not in the README.

The third limitation is scope. CHIPSEC analyzes PC platforms. It is not a general-purpose host security scanner, it does not assess application code, and the README's coverage statement is about hardware, system firmware and platform components. If your question is about a misconfigured service or a vulnerable library, this framework is not answering it.

Finally, there is the platform support question the README answers only indirectly. The contact note asks that AMD related questions go to Gabriel Kerneis at a French government address rather than to the Intel contact. That is a real signal about where AMD coverage sits: it is handled separately from the main Intel-focused effort, and you should not assume parity.

## CHIPSEC compared with vendor firmware update utilities

The obvious alternative for anyone touching firmware is the vendor's own update and configuration utility, which ships with the machine and is supported by the manufacturer. The difference in approach is fundamental. A vendor utility applies a known-good image or toggles a supported setting, and its job is to leave the platform in a state the vendor recognises. CHIPSEC does the opposite: it reads and exercises low level interfaces to find out what the platform actually exposes, including things the vendor never intended you to query.

That means the two tools answer different questions. If you need to know whether a specific firmware version is deployed, the vendor utility is the right instrument and CHIPSEC is overkill. If you need to know whether a platform component is configured in a way that weakens the boot chain, the vendor utility generally will not tell you, because reporting that is not its purpose.

The other realistic alternative is writing your own access code against the platform interfaces. CHIPSEC's value there is that it already packages the access layer, the test suite and the forensic tooling, and that it maintains a legacy branch for older silicon rather than dropping it. The cost is that you inherit a GPL-2.0 codebase and a tool that expects privileged access and a warning file. For a one-off register read, that trade is not worth it. For repeatable firmware assessment across a fleet, the packaging is the point.

## Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-22, two days before this writing. Releases have been frequent and recent: 2.0.8 on 2026-08-27, 2.0.7 on 2026-07-30, and 2.0.6 on 2026-07-01. That cadence is roughly monthly across the three most recent releases, and it is the strongest evidence available here that the project is being worked on. Note that the repository default branch is chipsec2, which is a separate matter from the chipsec1 legacy branch the README describes for older platforms.

The upgrade cost is partly bounded by the project's own convention. The README states that changes to arguments or calling conventions are held for a minor version update. In practice that means patch releases within 2.0.x should not break a script that calls chipsec_main.py or chipsec_util.py with existing arguments, while a move to 2.1 is where you should expect interface changes and re-test your automation. That is a stated convention, not a guarantee, and the README does not describe a deprecation window.

On licensing, the project is GPL-2.0. The setup.py header carries the standard GNU General Public License version 2 text and the contact address chipsec@intel.com. GPL-2.0 has distribution obligations that matter if you intend to ship CHIPSEC inside a product rather than use it internally as an assessment tool. This is not legal advice; if redistribution is part of your plan, the licence text in COPYING and LICENSE is what your counsel needs to read, and the README does not offer an alternative licence.

## Conclusion

Adopt CHIPSEC if you assess firmware on hardware you own or are authorised to test, and you are comfortable with a tool that talks to low-level interfaces. Do not adopt it for routine endpoint hardening or for platforms outside the Intel coverage the README describes, and check the chipsec1 branch note before assuming your older machine is supported. Verify first that your target platform matches the branch you intend to run, that you have read WARNING.txt, and that your install produces a working chipsec_main.py invocation before you build any assessment process around it.

## FAQ

### How do I install CHIPSEC?

The README does not list install steps; it says instructions for installing and using CHIPSEC are in the manual, chipsec-manual.pdf, which is in the repository. The repository also has setup.py, linux_requirements.txt and windows_requirements.txt, and setup.py requires setuptools greater than 62.0.0.

### How do I use CHIPSEC?

Two top-level scripts are the entry points: chipsec_main.py runs the security test suite and chipsec_util.py provides access to low level interfaces. The README points to the manual for usage instructions, and states the framework can be run on Windows, Linux, and UEFI shell.

### Does CHIPSEC run on Windows?

Yes. The README states CHIPSEC can be run on Windows, Linux, and UEFI shell, and the repository ships a windows_requirements.txt alongside linux_requirements.txt. The manual is the source for platform-specific install and usage instructions.

### What should I check before running CHIPSEC on an older Intel platform?

The README says support for older Intel platforms is on the chipsec1 branch, covering client platforms pre-ADL (pre-12th Gen Core) and server platforms pre-SPR (pre-3rd Gen Xeon Scalable). You switch with git checkout chipsec1.

### What licence is CHIPSEC released under?

GPL-2.0. The setup.py header carries the GNU General Public License version 2 text, and COPYING and LICENSE are present in the repository root.

## Sources

- [chipsec/chipsec on GitHub](https://github.com/chipsec/chipsec)
- [Issues](https://github.com/chipsec/chipsec/issues)
- [License: GPL-2.0](https://github.com/chipsec/chipsec/blob/chipsec2/LICENSE)
- [README](https://github.com/chipsec/chipsec/blob/chipsec2/README.md)
- [Releases](https://github.com/chipsec/chipsec/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/chipsec-chipsec