How the example artifact on the other tab is produced: trigger, inputs, steps, and what "done" means. Guidance based on the CRA text — a starting point for your own process, not legal advice.

How it is created — ENG-REC-032 Storage Encryption Feasibility (Data at Rest)

Produces	ENG-REC-032 — evidence that data-at-rest protection is achievable on the intended hardware, or the record that forces a different one
Type	Product record, written once before hardware selection is final; re-run on any silicon change
Owner	Hardware Engineer with the firmware lead
Approves	Product Security Lead
Trigger	After the threat model identifies data worth protecting at rest, and before the MCU decision and board layout
CRA reference	Annex I I(4)(e) — protection of stored data, state of the art. An essential requirement, not a design preference

1. The question this answers

Can this product encrypt what it stores, on the silicon you intend to buy, inside its power and cost budget? Encryption at rest is mandatory where the data warrants it, so a "no" here is not a feature cut — it is a hardware decision. Made before layout it costs a BOM delta; made after the first production run it costs the project.

The record exists to make that decision reviewable later: an auditor reading the technical documentation sees why this MCU was chosen, and a successor engineer sees why the cheaper one was not.

2. Inputs

The threat model and risk assessment — they say which data is worth protecting and against whom. Encrypting everything indiscriminately is how the power budget dies.
The candidate hardware shortlist, with vendor security documentation: crypto engine, key storage, readout protection, secure boot, TRNG.
The hard budgets: average current, BOM ceiling, temperature range, and the functional requirements that constrain them (sampling rate, buffer flush interval).
The EOL check (ENG-REC-031) for the same candidates — a part that passes on crypto but not on SDK longevity is not a candidate.

3. Steps

Inventory what is stored, not what is transmitted. One row per data class: what it is, how sensitive it is, and where it will physically live — internal flash, external flash, MCU key storage. Sensitivity drives the requirement; location drives the mechanism.
Turn that into a requirement sentence before looking at any datasheet: keys in hardware-isolated storage, external flash encrypted with keys that never leave the MCU, internal flash protected against readout. Now you have a pass criterion.
Compare candidates on the security properties that actually differ: hardware crypto engine and modes, dedicated key storage versus key registers, readout/debug protection (including the family's bypass history), on-the-fly encryption for external memory, TRNG, secure-boot and anti-rollback support.
Measure the cost; do not estimate it. Run the representative write pattern on both dev kits and record the average current. Software AES versus a hardware engine is typically the difference between missing and meeting a battery target, and a number from a bench beats a number from a datasheet.
Say what the shortfall would cost functionally. "Candidate A fits the budget only at a 15-minute flush interval, which breaks the 5-minute data-granularity requirement" is the sentence that makes the decision for you.
Write the conclusion as a decision, with its price. Name the selected part, the accepted BOM delta, and where it was approved — the steering minutes reference belongs in the record.
Route the consequences. Mark the affected security requirement as feasible and hardware-backed, update the residual risk in the risk assessment, and let board layout start on the selected reference design.
Archive the bench data, not just the conclusion. Power traces and logs are what make this record evidence rather than an assertion.

4. Done when

Every stored data class has a confidentiality need and a planned location.
Each candidate is judged against the same criteria, including a measured energy cost.
The conclusion names one part, one BOM delta and one approval, with a date.
The security requirement it unblocks is updated, and so is the risk it mitigates.
Bench data is archived at a path the record cites.

5. Common mistakes

Deciding on the datasheet and discovering the power cost after layout. Encrypting the measurement buffer while leaving the identity key in plain external flash. Treating "the MCU has AES" as the answer — the engine is rarely the constraint, key storage and readout protection usually are. And running this after the hardware is committed, which converts a selection criterion into a residual risk you now have to defend.

6. In TRA Studio

Place this feasibility check as a pre-development activity in your Secure Lifecycle, assigned to the Annex I I(4)(e) requirement, so an unassigned encryption requirement shows up as an open gap while the hardware decision is still reversible. Record the responsible engineer and the archived bench data as the activity's artifact.