How do attackers use hardware component substitution during baselining?

How attackers turn baselining into a trust anchor

Baselining works only if the initial measurement is honest. With hardware component substitution, the attacker changes a part before the organisation records the “known good” state, so the altered device becomes the reference point. That makes later integrity checks weaker because the baseline now reflects a compromised physical state rather than the original system.

The technique is effective in environments that trust procurement records, factory seals, or first-seen inventory too quickly. A substituted component can preserve normal device function while quietly shifting the system’s identity, firmware behaviour, or telemetry enough to survive casual inspection.

What the attacker is exploiting in the baseline process

The key weakness is trust establishment during onboarding. If the baseline is captured after the swap, defenders may compare future observations only against the malicious reference and miss the fact that the device was altered before acceptance. This is a form of pre-compromise insertion, not just a post-compromise tamper.

Component substitution is especially useful when defenders rely on a single acceptance step or treat hardware as trustworthy once it boots and responds normally. The attacker is betting that serial numbers, firmware fingerprints, physical markings, and procurement records are either not checked together or not checked at all.

How defenders should validate hardware before trusting the baseline

Baseline creation needs a verification step that is independent of the device’s own self-reporting. Compare serials, model identifiers, firmware versions, and hardware characteristics against procurement and receiving records before the device is enrolled into a trusted state. Where possible, inspect the component chain of custody and require sign-off before the first baseline is stored.

Use a process that makes substitution hard to hide, including physical inspection, inventory reconciliation, and acceptance testing that is separate from production onboarding. If the baseline is already established, re-check the device against original records rather than assuming the captured state is trustworthy simply because it is now “normal.”

Risk and Threat Considerations

Hardware substitution during baselining creates a trust failure that can persist for the life of the asset. Once the altered component is accepted as the reference state, later integrity monitoring may validate the attacker’s change instead of detecting it.

Failure mechanism: The attacker replaces or alters hardware before baseline capture, then relies on the organisation to record that altered state as legitimate and use it for future comparisons.

Impact: Defenders may lose the ability to distinguish genuine drift from the original compromise, which can weaken incident detection, inventory accuracy, and recovery confidence.

Practitioner Guidance

What to verify: Treat baseline capture as a controlled acceptance event, not a routine inventory task. Verify that hardware identifiers, firmware state, and procurement lineage all agree before the device is admitted to a trusted set.

Common mistake: Teams often trust a device because it boots cleanly or matches expected software checksums, but that does not prove the hardware itself was not substituted earlier in the lifecycle.

Practitioner takeaway: The most reliable defence is to establish trust from independent records before the first baseline is taken, because once a substituted component is accepted, every later comparison can inherit the attacker’s version of “normal.”

Related resources from NHI Mgmt Group

• Hardware Component Substitution During Baselining
• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?
• Why do attackers often check model availability before trying to generate content?