Anti-Tamper

Exploitation of critical program information after you have lost physical control of the system. Anti-Tamper under DoDD 5200.47E assumes the adversary already holds the hardware — recovered from a crash site, captured, or bought through a foreign military sale — and asks how long the technology inside survives reverse engineering. That is a different threat model from cybersecurity, which assumes the system is still yours and the attacker is remote. A program can be fully compliant with its RMF controls and have no Anti-Tamper protection whatsoever.

Possibly, because the trigger is critical program information rather than classification. CPI is the element whose compromise would degrade combat effectiveness, shorten the expected life of the system, or let an adversary significantly reduce our technological advantage — and it is routinely unclassified. An algorithm, a signal processing approach, a materials process or a manufacturing tolerance can all be CPI while the document describing it is unclassified. CPI identification runs under DoDI 5200.39; Anti-Tamper is one of the countermeasures applied to what that analysis finds.

The Anti-Tamper plan is reviewed by the DoD Anti-Tamper Executive Agent, a role assigned to the Secretary of the Air Force and executed through the Anti-Tamper Executive Agent Program Office. The plan itself is an appendix to the Program Protection Plan rather than a standalone artifact, so it inherits the PPP's milestone review points. Programs that treat it as a document produced for a single review generally discover at verification that the design decisions it describes were never actually implemented.

Early enough that it constrains the architecture, which in practice means before the design is frozen. Anti-Tamper measures consume power, volume, weight, thermal budget and processing headroom, and several of them — secure boot chains, key storage, sensor-triggered responses — cannot be added to a completed design without reopening it. A programme that defers Anti-Tamper until it is preparing for a milestone review is choosing between a late redesign and a plan that documents protections the hardware cannot deliver.

Through independent verification and validation against the specific protections the plan claims, not through a design review of the plan itself. V&V is planned as part of the programme's test strategy and takes time and specialist facilities, which is why it belongs in the schedule from the start. The failure mode worth naming is a plan whose claims were written faster than the engineering behind them: verification is where that gap surfaces, and by then the schedule has usually closed.