What Is Configuration Management in Hardware Engineering?

Software engineers have git. When something breaks, they run git blame. When they need to restore a known-good state, they check out a tag. The history is there, diffable, branching, and stored in something every developer understands.

Hardware engineers do not have this luxury. The configuration of a physical system is not a single file tree. It is a web of interdependent artifacts: mechanical drawings, electrical schematics, firmware images, material specifications, interface control documents, manufacturing process plans, and test reports — each artifact versioned by different teams using different tools, and all of them describing a physical object that cannot be rebuilt by cloning a repository.

Configuration management (CM) in hardware engineering is the discipline that makes this controlled. It defines which artifacts matter, establishes formally approved baselines, tracks every change and its rationale, and verifies through audit that what was approved is what was actually built. Done poorly, CM is paperwork. Done well, it is the only reliable way to know what you shipped, what changed since then, and whether the change was authorized.

The Four Pillars of Hardware Configuration Management

Hardware CM is organized around four functional activities. These appear in every major standard — MIL-STD-973, EIA-649, ISO 10007 — because they reflect the actual problem structure, not bureaucratic convention.

1. Configuration Identification

Configuration identification answers two questions: which items are subject to CM control, and how are they labeled and related to each other.

A configuration item (CI) is any hardware, software, or documentation designated for CM control. On a simple product, a single CI might cover the entire unit. On a complex system like a satellite bus, ground station, or avionics rack, configuration items are decomposed hierarchically — a system CI breaks into subsystem CIs, which break into component CIs. The granularity is a deliberate engineering decision, not an administrative one. Too coarse and you cannot isolate the impact of a change. Too fine and the overhead of controlling every fastener specification becomes unworkable.

Each CI is described by a set of configuration documentation: the drawings, specs, firmware, and test requirements that together define what the item is. These documents are themselves subject to control — they receive revision identifiers, and changes to them require authorization.

The output of configuration identification is a clear answer to: “What documents, at what revision levels, describe this item?“

2. Configuration Control

Configuration control is the process that governs changes to approved configuration documentation. It operates through a configuration control board (CCB) — a cross-functional authority that evaluates proposed changes, assesses their impact on cost, schedule, interfaces, and safety, and approves or rejects them.

A change doesn’t automatically flow from “engineer requests it” to “drawing updated.” There are formal stages: the engineering change proposal (ECP), the CCB review, the authorization, the implementation, and the verification that the change was implemented correctly. Each step generates a record.

This rigor exists because hardware changes have downstream consequences that software changes often do not. Changing a material specification may invalidate a test result. Changing a connector pinout may break an interface that a supplier’s firmware depends on. Configuration control forces those consequences to be identified before implementation.

3. Configuration Status Accounting (CSA)

Configuration status accounting is the system of record that tracks the current approved configuration of every CI and provides a historical log of every change. It answers: “What revision is the unit on right now? What was changed from revision B to revision C? Which units in the field are on which revision?”

CSA is not a passive database. It is an active discipline that requires updates to be timely, accurate, and complete. In practice, CSA is often where CM programs break down — the engineering database says one thing, the manufacturing floor has something slightly different, and the field service records tell a third story.

Automated tooling helps, but the root problem is organizational: CSA requires everyone who modifies a CI or its documentation to close the loop and record what they did. That requires process discipline that tools alone cannot provide.

4. Configuration Audits

A configuration audit is a formal verification that the actual configuration of a CI matches its documented configuration. There are two distinct types, and conflating them is a common error.

Functional Configuration Audit (FCA): Verifies that the CI performs the functions specified in its functional baseline documentation. This is essentially a test review — it confirms that test results demonstrate compliance with the performance requirements that were established and approved.

Physical Configuration Audit (PCA): Verifies that the CI as built matches the product baseline documentation — drawings, parts lists, firmware versions, material certs. The PCA walks the actual hardware and compares it, line by line, to the approved documentation. Discrepancies are not acceptable; they are either corrected or formally processed as changes.

FCAs typically occur before a product is released for production. PCAs typically occur before initial production units are accepted. On major defense programs, PCAs can take days and involve significant contractor preparation. The standard is unambiguous: if it’s on the drawing, it needs to be on the hardware, and if it’s on the hardware, it needs to be on the drawing.

Configuration Baselines: Controlled Snapshots, Not Backups

The concept of a configuration baseline is central to hardware CM and is frequently misunderstood. A baseline is not a backup. It is not a snapshot taken for safety. It is a formally approved set of configuration documentation that defines a CI’s agreed-upon state at a specific lifecycle milestone — and it carries contractual and program authority.

Three standard baselines appear in MIL-STD-973 and EIA-649:

Functional Baseline: Established after system-level requirements have been approved. Typically captured in a System Requirements Document (SRD) or equivalent. This baseline says: “We have agreed on what this system must do.” Changes to the functional baseline require the most scrutiny because they affect the fundamental performance contract.

Allocated Baseline: Established after requirements have been decomposed to the subsystem or CI level. The allocated baseline says: “We have agreed on how the top-level requirements are distributed across the architecture.” This is the baseline against which subsystem development proceeds.

Product Baseline: Established after design is complete and verified through FCA. The product baseline says: “We have agreed on the detailed design documentation that defines what is built in production.” This is the baseline that a PCA checks.

Changes to any established baseline require formal configuration control — CCB review, impact assessment, authorization, and updated CSA records. This is not bureaucratic friction. It is the mechanism that prevents informal changes from propagating undetected into production hardware.

How Hardware CM Differs from Software CM

The difference between hardware CM and software CM is not merely that one deals with atoms and the other with bits. The structural differences run deeper.

Software has unified diff semantics. Hardware does not. A change to a Python module can be expressed as a compact diff. A change to a mechanical drawing may mean a new revision of a PDF, a change to a 3D model in a PLM system, updated tolerances in a specification, and a new material certification from a supplier — none of which are automatically linked, and none of which can be understood from the change alone.

Software can be rebuilt from source. Hardware cannot. If you have the source code and the build system, you can reconstruct any version of a software artifact. A physical assembly built to drawing revision B cannot be reconstructed from drawing revision C — and the units in the field are whatever they were built to, regardless of what the current drawing says. This is why CSA must track which units are on which revision, not just what the latest revision is.

Software changes are cheap to execute. Hardware changes are expensive. A software patch can be deployed globally overnight. A hardware change may require updated tooling, supplier re-qualification, new test fixtures, scrap of inventory, and field retrofits. This is why hardware CCB processes are deliberately slower — the cost of an unauthorized or poorly analyzed change is much higher.

Hardware spans multiple disciplines. A firmware image is part of the configuration of a hardware product. So is the mechanical drawing, the circuit schematic, the cable assembly specification, and the acceptance test procedure. CM must span all of these, often across separate tools and separate teams. Software CM tools are not designed for this span.

The Standards That Define the Vocabulary

Two standards are worth knowing directly.

MIL-STD-973 (Configuration Management, now superseded by EIA-649 in most non-DoD programs but still referenced extensively in defense contracts) established the foundational vocabulary and process structure that the hardware CM discipline runs on. It defined the four CM activities, the three baselines, and the audit types described above. If you are working on a DoD acquisition program, your contract almost certainly references MIL-STD-973 or its successor.

EIA-649 (Configuration Management Standard, maintained by SAE International and GEIA) is the current consensus standard for CM in commercial and defense programs. The 2019 revision (EIA-649C) reorganized the standard around five CM functions: configuration management planning, configuration identification, change management, configuration status accounting, and configuration verification and audit. It is deliberately non-prescriptive about how organizations implement CM — it defines what must be achieved, not which tools to use or which forms to fill out.

Both standards share a core assumption: CM is a program-wide discipline with defined roles, authorities, and records — not a tool feature or a folder naming convention.

Requirements as a Layer of Configuration Management

A complete CM system has to control requirements, not just drawings and firmware. This is where many programs have a gap.

Requirements define the functional intent behind a design. When a requirement changes — a performance threshold is tightened, an interface constraint is revised, a regulatory mandate is added — that change has configuration implications. It may invalidate previous test results. It may trigger a change to the functional baseline. It may require re-analysis of downstream design decisions. If requirements are managed in isolated documents with no formal change control, these cascading effects are invisible until they surface as integration failures.

Modern requirements management platforms address this directly. Flow Engineering (flowengineering.com) takes a graph-based approach to requirements that maps naturally to the structure of a CM program. Requirements are nodes with explicit relationships to each other, to design artifacts, and to verification evidence. When a requirement is proposed for change, the impact is visible across the graph — which child requirements inherit the change, which test cases it invalidates, which design elements depend on it.

Flow Engineering’s baseline management capability lets programs create named, timestamped snapshots of the requirements set at any milestone — a functional baseline capture after PDR, an allocated baseline after CDR. These are not file archives; they are queryable states of the requirements graph, with full traceability to the change history between baselines. This is the kind of baseline management that EIA-649 expects to see at the requirements layer, and it is something that most document-based CM tools — which treat requirements as text attachments rather than structured data — cannot provide.

Where Flow Engineering fits in a broader CM program is well-defined: it manages the requirements layer. It does not replace a PLM system for drawing control or a firmware configuration management tool for binary artifact versioning. Its focus is the requirements graph, baseline management, and change traceability from requirements through verification. For teams running a complete CM program, that focus complements the rest of the infrastructure rather than competing with it.

The practical implication: when a CCB reviews an engineering change proposal, the impact assessment should include requirements-level analysis — which requirements are affected, which test cases reference those requirements, and which verification records may need to be updated. A requirements management platform that maintains structured traceability makes this analysis tractable. Without it, the CCB is approving changes based on incomplete impact data.

Practical Starting Points

If your program’s CM is currently informal or fragmented, the path forward has a clear sequence.

Start with configuration identification. Define what your CIs are before worrying about tooling. Agree on the hierarchy and the documentation set that describes each CI. This is a paper exercise, and it is the most valuable hour you will spend on CM.

Establish your first baseline before you need it. The functional baseline should be established when system requirements are approved — not after. Programs that skip formal baselining early often pay for it at CDR or during production, when “what we agreed to” becomes contested.

Treat requirements change control as CM. Changes to requirements are changes to the functional baseline. They require CCB-level review, impact assessment, and updated traceability. If your requirements tool does not support formal change control and baseline management, that is a structural gap in your CM program.

Audit early, not just at program close. Internal configuration audits conducted during development find problems when they are cheap to fix. FCAs and PCAs conducted for the first time at a program milestone reveal problems when they are expensive to fix.

Read EIA-649C directly. It is a readable standard — roughly 40 pages, not a dense military specification. The vocabulary it establishes — configuration items, baselines, configuration status accounting — is the shared language your whole program should use.

Configuration management is not what you do after the design is done. It is the structure that makes the design trustworthy — the system that lets you say, with evidence, that you know what you built, that it matches what you approved, and that every change since approval was authorized and understood.