Firmware Signing Boundaries for Calibration Data: Decide What May Change in the Field
Choose the signing boundary from who may change calibration, when it may change and which firmware interprets it. Embedding calibration in a signed firmware image couples every permitted adjustment to that image’s release process. A separate record can support independent service, but its consumer must enforce authorization, applicability and semantic limits.
This article provides an original architecture decision matrix. It uses NIST SP 800-193 (May 2018) and RFC 9124 (January 2022) as design references, not as a certification claim or calibration standard. No calibration values, device writes or signing operations were tested.
1. Classify data by effect and owner
Inventory executable code, hardware calibration, ordinary preferences, transient state and trust policy. For each class, identify who may authorize a change, which component consumes it and what could happen if it is wrong.
NIST SP 800-193 distinguishes critical platform data from code and notes that hard-coded data is protected with its code image. Its critical-data guidance includes authorized changes and input validation. Whether a particular calibration field is critical depends on the product; a file extension cannot decide that.
Keep device-specific safety limits authoritative. A valid signature shows authorization under a trust policy, not that a coefficient is physically correct, appropriate for the assembly or safe in every operating condition.
2. Compare three change boundaries
| Placement strategy | What a permitted change involves | Decision pressure |
|---|---|---|
| Calibration inside authenticated firmware bytes | New qualified image through the firmware release authority | Useful when data and code intentionally share one release lifecycle |
| Separately authenticated calibration record | Approved data-authority workflow plus consumer checks | Useful when calibration must change independently without granting code-update authority |
| Mutable settings under local access policy | Authorized local operation and semantic validation | Requires explicit justification for the integrity/authorization assurance supplied |
Do not select the third row merely to avoid a signing workflow. Determine whether the product’s threat model and access controls satisfy its actual requirements. Conversely, independent signatures do not remove the need for storage reliability or a qualified activation mechanism.
Write the operational consequence of each choice. If a service technician must update a per-unit parameter frequently, requiring an entire firmware release may be intentional, or it may create pressure for an unsafe bypass later. Resolve that ownership problem during design.
3. Make authorization scope narrower than file acceptance
RFC 9124 includes configuration data as a possible payload and separates component identity, authenticated payload type and actor rights. Those are useful design concepts; the RFC does not define a calibration envelope or the schema below.
For an independently authorized record, bind its purpose, component, format, applicability, generation and complete payload to the approved authentication mechanism. Define whether its authority may update calibration only, or also change executable content and trust settings.
Use distinct authorization decisions even if implementation constraints lead to shared cryptographic infrastructure. A key being trusted for firmware must not accidentally imply permission for every data operation, and a calibration credential must not acquire code-update rights by reusing a generic “valid signature” result.
4. Put checks at the consuming boundary
Name the component that verifies the record before using it. Bootloader verification of the executable does not automatically cover a separate configuration file later read by the application. Likewise, checking a record during download is insufficient if another writer can change it before consumption.
| Consumer gate | Question it must answer |
|---|---|
| Structure and resource bounds | Is the complete representation well formed and bounded? |
| Authorization scope | May this authority change this data class and component? |
| Applicability | Does the record belong to the intended unit/assembly and supported hardware contract? |
| Meaning | Are format, units, ranges and cross-field relationships approved? |
| Generation policy | Is replacement or restoration of this generation permitted? |
| Stable use | Will the validated bytes remain the bytes consumed? |
Define outcomes for unavailable or invalid data. Depending on the product, the approved response may be a limited operating mode or a service hold. Do not silently substitute another unit’s coefficients or generic defaults without explicit product authority.
5. Couple semantic compatibility without coupling every release
A separate record needs a supported-reader contract. Record which firmware interprets its format and units, and which calibration generations remain valid after an application rollback. This is an acceptance dependency even when the two artifacts are delivered separately.
Keep authorization and interpretation distinct: a permitted calibration authority can still produce a record in a format an older reader cannot understand. Reject that combination or use a separately qualified transition, rather than pretending that signature success proves reader compatibility.
Similarly, changing measurement hardware may invalidate a previously authorized record. Storage preservation and cryptographic validity do not establish physical calibration after an assembly change.
6. Qualify rights, not only damaged bytes
| Proposed fixture | Required decision evidence |
|---|---|
| Approved record from permitted calibration authority | Passes all applicable consumer gates |
| Valid signature from an authority lacking calibration permission | Rejected by operation scope |
| Calibration authority attempts an executable or trust-policy update | Rejected outside its authorized purpose |
| Authorized record with unsupported units or format | Semantic incompatibility remains visible |
| Authorized record with prohibited value relationships | Product-defined validation rejects without applying it |
| Record changes after validation | No use based solely on the stale result |
Use synthetic nonoperational data and approved test identities. Keep actual calibration tolerances and hazardous actuator settings out of illustrative fixtures. These tests are proposed, not executed, and do not replace physical measurement qualification.
Hypothetical independent service authority
A fictional laboratory display needs periodic calibration updates while its executable release remains unchanged. Embedding every record in firmware would place those service changes under the code-release authority. A separate authenticated record is considered so calibration staff can operate within a narrower permission scope.
The design is acceptable only after the consuming application enforces that scope and its semantic contract. Merely placing data in another partition does not create independent authorization, and a shared signing service does not automatically define the intended rights.
7. Record the chosen boundary
Deliver the data-class matrix, authority map, consumer checks, supported-reader relationship and observed fixture results. Link the decision to the approved storage/activation procedure without inventing its durability guarantees.
The outcome is a clear statement of what may change independently and who may authorize it. It is not a promise that signed calibration is physically accurate, safe for every device or compliant with a particular regulatory regime.
