USB armory: An Open Hardware Compact Secure Computer

What usbarmory/usbarmory is designed to provide

usbarmory/usbarmory is an open source hardware design implementing what the README calls a compact secure computer. The repository does not present itself as a general-purpose desktop project, a utility with a command-line interface, or a conventional software package. It describes a physical computer design intended for developers who want to examine, build, or work with the board and its associated software sources. The README directs readers to a project wiki for the main documentation and to separate ordering information if they want to purchase a USB armory board.

The intended audience is explicit. The README says the repository is aimed towards developers. It does not describe a consumer product with a prebuilt operating system image or a plug-and-play setup guide. The repository layout reinforces that interpretation. Its top-level entries include AUTHORS, README.md, hardware/, and software/. Hardware files and software files therefore have separate locations, but the README does not describe their formats, build systems, flashing procedures, or supported host environments.

This makes the project different from a repository whose first user action is to run an installer. USB armory starts with a hardware design and offers a software source area alongside it. A developer must establish whether the goal is to understand the board, obtain hardware, assemble a revision, or work on the associated software. The README does not collapse those tasks into one setup process.

Board models and repository boundaries

The README identifies USB armory Mk II LAN, USB armory Mk II, and USB armory Mk I as board models. It links to separate wiki pages for Mk II LAN and Mk II, and includes an image reference for the Mk I. These links indicate that board selection is a meaningful part of using the project. A reader cannot assume that documentation or design files for one model apply unchanged to another.

The repository itself is not a shopping page. Purchasing information is hosted in the project wiki, while the README focuses on the open hardware design, authors, documentation links, and licensing. That separation makes the repository useful as a design reference, but it also leaves an adoption gap. The README does not specify supported versions of Ruby, host operating systems, toolchain commands, fabrication files, or board assembly procedures. The top-level hardware/ and software/ entries are concrete boundaries, not evidence that every kind of build is supported.

For developers, the first decision is the board model, not an installation command. The project documentation should determine which revision is being used and which source subdirectories apply. The README does not provide that mapping. A change in board generation may also affect the applicable licence version, so the relevant source subdirectory should be checked before reuse.

The named models are useful for narrowing an investigation. They do not, by themselves, tell a reader which model is currently recommended, what hardware each model includes, or whether a particular model has a stable software workflow. Those details belong to the linked wiki pages or individual repository files.

Hardware sources and software sources in the repository

Based on the repository layout, usbarmory/usbarmory separates hardware design source from software source at the top level. The README describes the project as an open hardware design, while the software/ directory indicates that software assets are part of the repository. No further architecture can be confirmed from the README. It does not document a data flow, runtime process, firmware loader, network service, or operating system configuration.

This distinction is useful when judging adoption. A hardware design can be evaluated through its schematic or board documentation, while software adoption requires separate build, deployment, and maintenance information. The README does not say whether software/ contains firmware, host utilities, test code, or several of those categories. It also does not identify the relationship between a particular software directory and a particular board model.

Accordingly, the repository should be treated as an open hardware project with an associated software area, not as a complete software development kit based solely on the README. Confirm the directory contents, revision-specific instructions, and required tools in the repository and wiki before making a build or deployment plan. The source tree is an entry point for inspection, not proof that the complete device can be produced from the top-level listing alone.

Finding the board documentation before building anything

The README does not give installation steps, package-manager commands, build commands, flashing instructions, or configuration snippets. It says that the main documentation is in the project wiki and that people who wish to purchase a USB armory board should see the ordering information. Therefore, there is no confirmed first-use command that can be reproduced from the README, and none is invented here.

A practical first step is to identify the intended board among the listed models, then consult the corresponding wiki page. If the goal is physical evaluation rather than software experimentation, the ordering information is the documented route to obtaining a board. If the goal is software development, the repository's software/ directory and its applicable LICENSE files are the relevant starting points, but the README does not explain how to build or install anything from that directory.

The absence of a documented setup path is a practical limitation. A developer expecting a repository clone followed by a standard install command will not find one in the README. The project should not be described as having a known installation time, runtime dependency set, supported platform list, or firmware image based on the available documentation.

For a real first use, start by selecting the board model and locating its wiki page. The linked page is the place to verify required components, tools, and revisions. Without that revision-specific information, copying a generic build command from another hardware project would introduce assumptions that USB armory's README does not support.

CERN Open Hardware Licence and source responsibilities

The README states that USB armory is an open hardware design licensed under the CERN Open Hardware Licence. It also says that board revisions may have applicable versions and instructs readers to inspect the LICENSE files in each source subdirectory for applicable conditions. That wording is important because the repository contains multiple source areas and multiple board generations.

The licence information supports source inspection and reuse decisions, but it is not a complete legal analysis. The README does not reproduce the full licence text, and it does not state how the hardware and software portions should be combined in a particular product or distribution. It also includes a disclaimer that the source is distributed without warranties, including merchantability and fitness claims. No legal conclusion should be drawn beyond identifying the stated licence and the need to check the applicable files.

Because the repository has no GitHub releases in the repository information, upgrade planning must rely on repository changes and board-specific documentation rather than a documented release package. The last push was on 2026-08-28, but the README does not describe a release cadence, compatibility policy, or migration procedure. This is a source-based project, so understanding which files changed and which licence applies is part of evaluating an upgrade.

The licence path is concrete: inspect the LICENSE files in each relevant source subdirectory. Do not assume that the README's general statement settles the conditions for every board revision or every software file.

Maintenance limits and practical trade-offs

The repository is not archived, and its last push was on 2026-08-28. Those are the only maintenance facts available, so the project should not be described as having a confirmed support lifecycle, release schedule, or compatibility promise. The absence of GitHub releases is also relevant. There is no release artifact identified in the repository information from which an adopter could infer a stable version.

The main trade-off is between open design access and documentation depth in the README. Developers gain access to a hardware design and can inspect the hardware/ and software/ areas. At the same time, the README does not tell a new user how to assemble the board, obtain all required components, build the software, or deploy an image. Those are concrete adoption costs when the initial instructions remain in a wiki and revision-specific sources.

USB armory is therefore a poor fit for someone seeking a documented software-only installation or a ready-made compact computer purchase through the repository. It may fit a developer who already understands board revisions and is willing to follow the project wiki and inspect revision-specific source and licence files.

Maintenance also has a different meaning for hardware and software. A source change can affect design files, board revisions, documentation, or software without producing a GitHub release. The README does not explain how such changes are versioned for users, so compatibility must be checked against the specific board and source tree being used.

Why not choose a conventional single-board computer project

A conventional single-board computer project may be a more direct choice when the requirement is a documented Linux image, a known host build process, or a board that can be purchased and configured through a vendor-supported workflow. The USB armory README does not document those features, so the comparison concerns project approach rather than a claim about a named competitor.

USB armory takes an open hardware design approach. Its repository is organized around hardware and software source areas, board models, and wiki documentation. That can be appropriate for developers who want to work with the design itself or need a compact secure computer concept as a hardware project. A software-oriented alternative is more appropriate when the first priority is an immediately reproducible operating system installation, standardized expansion interfaces, or vendor-maintained images.

The choice depends on what is being evaluated. Do not select USB armory merely because the term compact secure computer sounds suitable. Verify that the specific board model, source revision, licence conditions, and available build or purchasing instructions match the intended use. If those checks fail, a more conventional single-board computer route may expose fewer undocumented steps.

For USB armory, the first verification is board-specific. The README links to Mk II and Mk II LAN documentation, while also naming Mk I. Determine which model is relevant, then inspect its source and licence context before assuming that the repository is ready for implementation.

Editorial conclusion

Adopt USB armory when you need an open hardware compact secure computer and can follow board-specific documentation. Do not treat it as a turnkey software package. Before starting, verify the board revision, applicable source licence, wiki instructions, and purchasing or build process.

Frequently asked questions

Official sources

1. Issues
2. README
3. usbarmory/usbarmory on GitHub