AA-sec logo AA-sec
Security Evidence

CRA Production and Monitoring Process Evidence: What Manufacturers Need to Validate

A practical guide to the production, development and vulnerability-handling evidence manufacturers should retain to show that CRA controls keep working over time.

AA-sec10 September 2026
  • CRA production monitoring evidence
  • Cyber Resilience Act production process
  • CRA monitoring process validation
  • CRA Annex VII production evidence
  • CRA manufacturer process evidence
AA-sec cover graphic for a guide to CRA production, monitoring and conformity evidence across the product lifecycle.

Under the Cyber Resilience Act (CRA), manufacturers need evidence that cybersecurity controls are not only defined but remain effective while a product is designed, developed, produced and supported. Annex VIII makes that operational: the manufacturer must take the measures necessary so that the relevant processes and their monitoring ensure that the product and the manufacturer's vulnerability-handling processes meet the essential cybersecurity requirements in Annex I.

For engineering organizations, this means CRA production process validation should not be reduced to a signed procedure or a final checklist. The useful evidence is the connection between the documented process, the controls that actually ran, the product or release they covered, the exceptions that occurred and the decision that allowed the product to proceed.

The CRA's main obligations apply from 11 December 2027. Manufacturers can use the preparation period to define which existing engineering and quality records already support the CRA and where product-security evidence is still missing.

Start with the legal distinction: documentation versus operation

Article 31 requires technical documentation to contain the relevant data and details showing the means used by the manufacturer to ensure that the product and the processes put in place by the manufacturer comply with Annex I. That documentation must contain at least the elements listed in Annex VII and must be drawn up before the product is placed on the market. It must also be continuously updated where appropriate, at least during the support period.

Annex VII therefore describes what the technical file needs to explain. It includes the product, applicable software versions, design and development information, production and vulnerability-handling processes, the cybersecurity risk assessment, specifications used, tests performed and supporting evidence.

Annex VIII addresses the conformity-assessment procedures. Under the internal-control route in Module A, the manufacturer must draw up the Annex VII technical documentation and take all necessary measures so that design, development, production and vulnerability-handling processes — together with their monitoring — ensure compliance with Annex I.

The distinction is practical:

  • the technical documentation explains the control system and preserves evidence;
  • the operational processes produce the product and vulnerability-handling outcomes;
  • monitoring shows whether those processes continue to work as intended.

A company can have excellent procedures and still have weak conformity evidence if it cannot show that the procedures were applied to the specific product or release being assessed.

Define the product and release scope before validating the process

Production and monitoring evidence becomes ambiguous when it is collected at company level without identifying the product state it applies to.

Before reviewing controls, establish a scope record containing at least:

  • product name and identifier;
  • hardware variant where relevant;
  • software or firmware version affecting cybersecurity conformity;
  • build or release identifier;
  • relevant configuration or feature set;
  • production location or delivery pipeline where relevant;
  • support-period state; and
  • the applicable cybersecurity risk-assessment revision.

The CRA does not prescribe this exact record format. It is an engineering control that helps connect Annex VII evidence to the product that is actually being placed on the market.

This is particularly important for software. A generic statement that "secure development is followed" says little about whether the release under assessment passed the intended security checks, used the approved dependencies or incorporated required remediation.

Validate design and development controls with execution evidence

Annex VII requires information on the design and development of the product, including relevant architecture information. Annex VIII then requires the design and development processes and their monitoring to ensure conformity.

A practical validation package can therefore include records such as:

  • approved security requirements derived from the cybersecurity risk assessment;
  • architecture or threat-model review outcomes;
  • secure-development criteria applicable to the release;
  • code-review or change-control records for security-relevant changes;
  • security-test results and identified deviations;
  • third-party component review or due-diligence records;
  • remediation decisions for vulnerabilities relevant to the release; and
  • approval evidence showing who accepted the final release state.

The objective is not to duplicate every engineering artifact into the CRA technical file. Preserve enough controlled references and evidence to demonstrate that the required controls were applied and that the resulting product state can be reconstructed later.

Treat production as more than manufacturing-line quality control

For hardware products, production evidence may include traditional manufacturing and quality records. For software and connected products, "production" also needs to be understood in the context of the product that is delivered: build pipelines, release packaging, configuration, artifact integrity and controlled deployment outputs may all influence whether the product placed on the market matches the assessed design.

Useful production evidence can include:

  • identification of the approved source or release baseline;
  • reproducible references to build or release jobs;
  • artifact identifiers and cryptographic hashes;
  • configuration and feature-state records;
  • checks that security-relevant production settings match the approved baseline;
  • manufacturing or provisioning test results where applicable;
  • signing or integrity-verification evidence without storing private-key material in the compliance record;
  • failed checks and their disposition; and
  • final release or batch approval.

The CRA does not mandate a particular CI/CD platform, signing system or manufacturing tool. The important question is whether the manufacturer can show that the delivered product remained within the assessed cybersecurity state and that deviations were controlled.

Monitor the process, not only the final product

Annex VIII explicitly refers to the monitoring of design, development, production and vulnerability-handling processes. A final product test alone may therefore be insufficient evidence of process effectiveness.

Process monitoring should answer questions such as:

  1. Did the required control run when it was supposed to?
  2. Did it cover the correct product, variant or release?
  3. Was the result within the defined acceptance criteria?
  4. If not, was the exception recorded and resolved by an authorised owner?
  5. Did a process change invalidate earlier evidence or require reassessment?
  6. Can the organization show the historical state that existed at the release decision?

Examples of useful monitoring records include completion rates for mandatory security gates, unresolved security exceptions, failed production checks, overdue vulnerability actions, deviations from approved configurations and evidence that process changes were reviewed before use.

Metrics are useful only when their meaning is controlled. A dashboard showing "98% security checks passed" is weak evidence if the organization cannot identify the missing 2%, whether those checks were mandatory and which product release they affected.

Connect monitoring to the cybersecurity risk assessment

Article 13 requires the manufacturer to perform and document a cybersecurity risk assessment and to update it as appropriate during the support period. The assessment determines how the Annex I requirements apply to the product and how those requirements are implemented.

Production and monitoring controls should therefore be traceable back to that risk logic. For example:

  • if the risk assessment identifies authentication as a critical control, release evidence should show how authentication-related requirements and tests were handled;
  • if a particular interface creates a material attack surface, production configuration should show that the interface remains in the assessed state;
  • if a third-party component introduces a security dependency, monitoring should preserve the component and vulnerability decisions that justify release; and
  • if the risk assessment changes after a new threat or vulnerability, the affected process and evidence requirements should be reconsidered.

This keeps process validation focused on cybersecurity relevance rather than turning it into a generic quality-management exercise.

Keep vulnerability handling inside the validation boundary

The CRA does not stop at the point of market placement. Annex I Part II defines vulnerability-handling requirements, and Annex VIII includes vulnerability handling among the processes whose operation and monitoring must ensure compliance.

Manufacturers should therefore retain evidence that the post-release process can identify, assess and remediate vulnerabilities in the supported product. Useful records can include:

  • vulnerability intake and source;
  • affected product and version analysis;
  • severity and exploitability assessment;
  • remediation or non-applicability decision with rationale;
  • security-test evidence for the fix;
  • affected release and update identifiers;
  • disclosure or advisory records where required; and
  • evidence that the security update reached the intended release channel.

The process record should preserve changes over time. Replacing an old vulnerability decision with a new one may destroy evidence of what the manufacturer knew and decided at an earlier point in the lifecycle.

Use exceptions as evidence, not as failures to hide

A mature control system will generate exceptions: failed tests, temporary deviations, unavailable tooling, late vulnerability fixes or production anomalies. The existence of an exception does not by itself prove non-conformity. What matters operationally is whether the manufacturer identified it, evaluated its cybersecurity relevance and controlled the resulting decision.

For each material exception, retain:

  • the failed or missing control;
  • affected product and release scope;
  • date and evidence source;
  • cybersecurity impact assessment;
  • corrective or compensating action;
  • responsible decision owner;
  • approval or rejection outcome; and
  • closure evidence.

This produces stronger evidence than a clean checklist that has been manually edited until every item appears green.

Revalidate when the process changes

Process evidence should not be treated as permanent. Changes to engineering or production can alter the assumptions behind earlier conformity evidence.

Trigger a review when, for example:

  • the build or release pipeline changes materially;
  • a new manufacturing site or provisioning process is introduced;
  • security testing changes scope or tooling;
  • signing, packaging or update-distribution mechanisms change;
  • a product variant introduces different cybersecurity behaviour;
  • vulnerability-handling responsibilities change; or
  • the cybersecurity risk assessment identifies a new control requirement.

The review does not automatically require repeating every historical activity. It should determine which evidence remains valid, which controls need to be rerun and which technical-documentation sections must be updated.

Build an evidence package that can survive an authority request

A useful CRA production and monitoring evidence package should let a reviewer move from requirement to product state to executed control without reconstructing the story from emails.

A practical package can contain:

  • the scoped product and release identity;
  • the applicable cybersecurity risk-assessment revision;
  • descriptions of relevant design, development, production and vulnerability-handling processes;
  • references to the controls required by those processes;
  • execution evidence for the assessed release or production state;
  • monitoring results and material exceptions;
  • corrective-action and approval records;
  • security-test evidence; and
  • links to the technical-documentation sections that explain the underlying design and process.

This does not mean exporting every record into one PDF. A controlled technical file can reference evidence held in engineering systems as long as the manufacturer can reliably retrieve the correct historical records and preserve their context.

Keep process evidence connected to lifecycle decisions

Production and monitoring evidence is most useful when it remains attached to the exact product, release, requirement and decision it supports. Otherwise, teams can accumulate large volumes of logs and reports without being able to show which evidence justified a specific conformity or release decision.

AA-sec is designed around traceability between requirements, security evidence, decisions and exact product or lifecycle context. It is intended to complement existing engineering, CI/CD and signing systems rather than replace them, so teams can keep scoped evidence references and lifecycle decisions connected without moving source code, product binaries or private-key material into the compliance record.

Key takeaway

CRA production process validation is not a separate certification exercise invented by the Regulation. It is the practical evidence problem created by Annex VII and Annex VIII: manufacturers need to document the relevant processes and be able to show that their operation and monitoring keep the assessed product and vulnerability-handling processes aligned with Annex I.

Build the evidence around exact product and release scope. Connect controls to the cybersecurity risk assessment, preserve execution and exception records, revalidate material process changes and retain enough historical context to explain what was known, checked and approved when the product was placed on the market.

Official sources