Skip to content
DEENContact
MenuClose

CRA Compliance Service – Online Wizards

DDAS · CRA compliance package

CRA Classification WizardCRA DoC Wizard

This wizard guides you through creating the Classification/Product Boundary Paper — the foundation for the later EU Declaration of Conformity under the Cyber Resilience Act.This wizard guides you through assessing the findings of the risk analysis and through creating the EU Declaration of Conformity under the Cyber Resilience Act — building on the DDAS handover package.

Process

  1. Enter access code
  2. Enter company and project details (taken from your saved progress when you continue)
  3. Upload the DDAS handover package; it contains your Classification Paper
  4. Answer the questions for the Classification Paper (not needed with the Basic package or for a follow-up run without changes)
  5. Part 1: assess the findings of the risk analysis
  6. Upload your PLC project data and send the data package to DDAS
  7. Part 2: answer the questions for the declaration (in either order)
  8. Create the declaration package, sign the declaration

Built for CODESYS-based machine programs and libraries. This wizard covers step 2 of a five-step overall process — more on that below.To assess the findings you need the signed DDAS handover package (step 4); for the Declaration of Conformity you also need a Classification Paper (step 2). This wizard covers step 5 of the five-step overall process — more on that below.

This wizard helps you classify your product under the Cyber Resilience Act; the Classification Paper is the basis for the later EU Declaration of Conformity. The manufacturer remains responsible for the accuracy of the content — this is not legal advice.This wizard helps you assess the findings and prepare the EU Declaration of Conformity under the Cyber Resilience Act. The manufacturer remains responsible for the accuracy of the content — this is not legal advice.

Explainer films

The service in two films

Overview 3:44 min

Deadline, core documents and the five steps, for a first impression.

Walkthrough 6:46 min

Working with the wizards, shown on a complete example run.

The films show the complete package. Voice-over: synthetic voice.

Deadlines

What the CRA requires, and when

In force since 11 September 2026

Reporting obligation Art. 14 CRA*

If you become aware of an actively exploited vulnerability or a severe incident affecting your product, report it via the ENISA single reporting platform:

24 h
Early warning
72 h
Notification
14 days
Final report, counted from when a fix is available; for an incident, one month after the notification

This also applies to products already on the market. The reports themselves are not part of this package — but the SBOM from step 4 shows you which components may be affected.

Also: inform the affected users Art. 14(8)*
Who
Reporting to the ENISA platform alone is not enough. You must also inform the affected users of your product, and where necessary all users, as soon as you are aware of the vulnerability or the incident.
About what
About the vulnerability or the incident itself and, where necessary, about measures users can take to mitigate the risk or correct the fault.
How
The CRA prescribes no particular channel. As examples it mentions publishing on your website or, where you can reach the users and the risk justifies it, contacting them directly. Where appropriate, in a structured, machine-readable format.

Your report goes to the CSIRT, the national computer security incident response team; in Germany this is CERT-Bund at the BSI. If you do not inform users in time, it may provide the information itself where it considers this necessary and proportionate. How it does so is not laid down in the CRA.

Applies from 11 December 2027

Full application Art. 71 CRA*

Every product placed on the market from then on must meet the requirements of Annex I and needs a conformity assessment, technical documentation, a signed Declaration of Conformity and the CE marking. Products placed on the market before then are only affected after a substantial modification.

This is exactly what this package is for. What you have in hand at the end: What you must keep

Also: handle and disclose vulnerabilities Annex I Part II, Annex II*
Contact point
You must provide an address to which anyone can report a vulnerability in your product, for example an e-mail address or a reporting form. The address belongs in the user information you supply with the product (manual or accompanying document under Annex II).
Disclosure policy
You must put in place and enforce a policy on coordinated vulnerability disclosure. It sets out how you receive, handle and disclose reported vulnerabilities. Where to find it is also stated in the user information.
Security advisories
Once a security update is available, you must publish which vulnerability has been fixed, which product is affected, what its impact and severity are, and what users should do.

The CRA does not specify where you publish the advisories. A fixed, public address makes sense, such as a security page of your own. It is not part of this package.

At a glance

Who does what, and what goes where

Exactly two packages travel between you and DDAS: your data package out, the signed handover package back. The third, the declaration package from the DoC Wizard, stays with you. DDAS prepares the basis for your legal assessment. DDAS reports findings; whether they are a risk is for you to judge. The assessment itself and the signature remain with you.

YOU · MANUFACTURERDDAS1OrderAccess codeNDA on request2 · YOUR DATAPLC project dataalways requiredClassification Paperoptional, needed for DoC3Review gatestructural check4SBOM & risk+ signed handoverDeclaration package · CRA-DOC5Assess findings& declarationrequired; DoC Wizardoptional, PDFData package · CRA-INPUTHandover · CRA-DELIVERYClass change in step 4 → back to step 2

YOU · MANUFACTURER

DDAS

1OrderAccess code, NDA on request
2 · YOUR DATAPLC project dataalways requiredClassification Paperoptional, needed for DoC
3Review gatestructural check
4SBOM & risk+ signed handover
5Assess findings & declarationrequired; DoC Wizard optional, PDF

Class change in step 4 → back to step 2

What’s inside?

What goes into your project ZIP?

One ZIP file with fixed folders. Prepare the files before you start; the wizard asks for them in the last step. The wizard names the ZIP file itself.

Confidential: Your project ZIP contains your program code. It is covered by the confidentiality rules of the DDAS terms and conditions; if you wish, you also conclude a non-disclosure agreement (NDA) with DDAS before uploading, also based on your own template. At project completion, 30 days after the handover, DDAS deletes your project data and all analysis results; only an order record without your files is kept.

Machine program (standard)

A finished product: runs on your machine as a boot application.

  • Original/RequiredBoot application (.app + .crc), plus delivered libraries and project file
  • MachineProject/RequiredExport of the whole machine project (.export) and project archive (.projectarchive)
  • Libraries/for your own librariesone .export per library of your own

Without source code (only if ordered): only Original/ with the boot application and compiled libraries. You choose the project archive separately when uploading; on your computer the wizard reads the list of libraries and the device from it, and the archive itself stays with you.

Library package (optional, booking required)

A building block: your customers build a machine program from it.

  • Package/RequiredYour .package, optionally with an application example
  • Libraries/for libraries in the packageone .export per library in the package
  • Original/only with an application exampleBoot application (.app) built from the application example

ExportAlways everything. In CODESYS, export the whole project with all objects (Project → Export…).

File namesFree. Only the folders and the file extension count. Exception: a library’s .export is named like the library itself.

PackingWindows 11: Select the folders, right-click → Compress to → ZIP File. Not possible: .7z, .rar, password, over 4 GB.

The wizard shows you the detailed guide with examples when you upload.

What is in the data package for DDAS?

  • …_PLC_Project.zipYour PLC project data: software export and project archive, or package, libraries, boot application (with “Without source code” only the boot application and compiled libraries, plus the list from the project archive) — always included
  • …_ClassificationPaper.zipRoute A: Classification Paper, your answers (…_Progress.json) and their checksums
  • Company and project detailsRoute B: manufacturer, project, version — instead of the Classification Paper
  • Company logooptional, PNG or JPEG; printed on a white background at the top left of all documents, ideally in landscape format
  • …_FindingStatements.jsonoptional, for a new version: your earlier assessments of the findings
  • Vorgaenger/for a new version or a correction: parts of your last handover from DDAS (manifest with signature, handover data, SBOM, Classification Paper ZIP), taken over by the wizard from the uploaded handover package
  • …_MANIFEST.sha256Checksum for each file in the package

Everything in one file (…_CRA-INPUT_EN.zip). With one button you tell DDAS that the package is ready; only its checksum is sent.

What is in the DDAS handover package?

  • …_CheckReport.pdfCheck report: which checks your data package and the results went through
  • …_DELIVERY.sha256 + .jwsChecksum of the check report and the results package, signed by DDAS
  • …_CRA-RESULTS.zipthe results package, signed by DDAS; inside:
  • SBOM/Software bill of materials in CycloneDX 1.6 and 1.7 and SPDX 2.3 and 3.0.1, each file signed by DDAS
  • RiskAssessment/Risk analysis for the machine program and libraries (PDF); for a new version with your earlier assessments next to the findings
  • Classification/Classification Paper as PDF and your Classification Paper ZIP (route A only); for a new version or a correction also the change record
  • Software/the files from your Original/ folder unchanged, e.g. boot application and delivered libraries, or the .package
  • …_CoverSheet.pdfCover sheet: overview of the delivery in four sections (delivered artifacts, analysis basis, CRA documents, verifying integrity)
  • …_CRA-ANNEX-I.jsonOverview: which Annex I requirements the analysis checks structurally (for the DoC Wizard)
  • …_CRA-HANDOVER.jsonHandover data: manufacturer, project, version, run type; the wizard picks up from it next time
  • …_CRA-FINDINGS.jsonthe findings of the risk analysis in machine-readable form (for the DoC Wizard)
  • …_MANIFEST.sha256 + .jwsChecksum for each file, signed by DDAS

All documents and file names in the language of your run, everything in one file (…_CRA-DELIVERY_EN.zip). The signature can be verified with the public DDAS key at keys.ddas.digital.

What is in the declaration package from the DoC Wizard?

  • …_DeclarationOfConformity.pdfthe Declaration of Conformity for signature, with a signature line
  • …_DoC_CoverSheet.pdfCover sheet: origin of the details and your next tasks, e.g. CE marking, publication, further languages
  • …_FindingStatements.pdfyour assessment of each finding of the risk analysis, with reasons
  • …_FindingStatements.jsonthe same assessments as a file, for the next version
  • …_Progress_DoC.jsonYour answers and assessments — so the declaration and the statement can be updated later
  • …_MANIFEST.sha256Checksum for each file in the package

Everything in one file (…_CRA-DOC_EN.zip). Created on your computer and not sent to DDAS. Only the signed declaration is legally binding (card 1 below).

Overall process

Five steps to CRA conformity

How to use the wizards is described in the manual: step by step, with the messages and how to resolve them.

This wizard covers step 2. It is part of a five-step overall process that also includes the software bill of materials (SBOM), the risk analysis and the EU Declaration of Conformity.This wizard covers step 5. It builds on the DDAS handover package and, for the Declaration of Conformity, on your Classification Paper as well.

Click a step for details.

  1. 1. Order and access code

    DDAS + Manufacturer

    You accept the offer and, if you wish, also conclude an NDA with DDAS. After payment, you receive your personal access code for the wizard with the license confirmation.

    With the order, the DDAS terms and conditions apply; they also cover the confidentiality and deletion of your project data. If you would like a non-disclosure agreement (NDA) in addition, also based on your own template, we conclude it with the order, at the latest before any project data goes to DDAS. After payment, DDAS issues the access code for your company; it is included in the license confirmation. For a new project, a kickoff meeting follows with guidance on the project data and the wizards. Important from the start: the CRA class from step 2 is preliminary — final only after step 4. A change in class can change the conformity assessment procedure. Also consider which language you need the documents in; it applies to the whole run.

  2. 2. Classification Wizard and project data

    ManufacturerThis wizard

    Product boundary, legal manufacturer and CRA class are captured in a structured way. You also provide your PLC project data — this is always required, even on the short route without the questionnaire.

    Result: a preliminary classification — final only after step 4.

    Captured here: what belongs to the product and what explicitly does not, product identity (and a product family, if relevant), the legal manufacturer, and a core-functionality check against the 26 categories of important and critical products under Annex III/IV CRA*. At the end, the wizard bundles your project files (software export, project archive, libraries, boot application; with “Without source code” only the boot application and compiled libraries, plus the list from the project archive) together with the generated Classification Paper into one checked data package. The result is a structured self-assessment — not legal advice.

    ROUTE A

    With Classification Paper: the questionnaire described above, then upload your PLC project data. Required for the Declaration of Conformity with the CRA DoC Wizard.

    ROUTE B

    SBOM & risk analysis only: Enter company and project details and upload your PLC project data, without the questionnaire. You can then assess the findings in the DoC Wizard; the Classification Paper needed for the Declaration of Conformity is missing.

    On both routes, the wizard checks your project ZIP before sending and calculates a checksum. What goes into the project ZIP is shown under “Project ZIP · structure” above. Optionally, upload your company logo; it appears in the header of all documents.

  3. 3. DDAS review gate

    DDASStructural check

    Hash comparison and a structural completeness check of the submitted documents and project files.

    No substantive or legal review.

    First, a hash comparison of the submitted data package; then a structural completeness check of the wizard answers and an intake check of the project files themselves: are the expected parts complete and undamaged? DDAS explicitly does not assess content at this stage.

  4. 4. SBOM, risk analysis & handover

    DDAS

    The CRA-AnalyseTool generates the software bill of materials and reports findings in the code and in the libraries. You receive everything in a handover package signed by DDAS.

    If a finding contradicts the preliminary class, the process returns to step 2.

    Whether a finding is a risk is for you to judge in step 5.

    The handover package (CRA-DELIVERY) contains the check report and the results package (CRA-RESULTS). The results package holds the software bill of materials (SBOM) in CycloneDX and SPDX, the risk analysis and the Classification Paper as PDF, plus a manifest with a checksum per file, signed with the DDAS key. The DDAS signature covers every file of the handover. It lets you show your customers and market surveillance where the SBOM and risk analysis come from and that they are unchanged, without managing keys of your own. The check report records which checks your data package and the results went through. It is the only delivery from DDAS. If the risk assessment shows that the preliminary classification does not hold, the process returns to step 2 with the new findings — the previous version is kept.

  5. 5. Assess findings and Declaration of Conformity

    ManufacturerThis wizardDoC Wizard optional

    You assess the findings of the risk analysis and issue the EU Declaration of Conformity. The CRA DoC Wizard guides you through both.

    The assessment and the declaration are required, the tool is not: you can also create both by other means.

    At the start, you upload the handover package, and for the declaration your Classification Paper as well. The wizard checks the DDAS signature and shows both parts in an overview. You choose the order; part 1 first is recommended.

    PART 1

    Assess findings: The risk analysis shows what stands out in your code and in the libraries. Only you know which of it is a risk for your product and how you deal with it. You record this for each finding and give your reasons. The result is your statement as a document of its own. The DDAS risk analysis remains unchanged.

    PART 2

    Issue the declaration: For this you need your Classification Paper. The wizard asks for the details it needs. The result is the Declaration of Conformity with a cover sheet as PDF, in the language of the Classification Paper; if a Member State requires further languages, the cover sheet lists them as a task. Sign by hand and scan, or sign with a qualified electronic signature.

    What is finished goes into the declaration package (CRA-DOC). It is created on your computer and does not go to DDAS; signature and responsibility lie with the manufacturer.

  6. Next version

    Manufacturer + DDASback to step 2

    If your software changes, the process runs again from step 2. What you have already worked out carries over.

    Earlier handoverKeep every delivery from DDAS. Next time, upload the latest one again; the wizard does the rest. DDAS compares the new version with the earlier one.
    Your statementAdd it to the data package. The new risk analysis lists it next to the findings.
    What has changedUnchanged findings stay assessed. The change record shows what has changed in the software, the paper and the findings. If you have only corrected your paper, DDAS recognises this.

    As long as the product boundary and core function do not change, the route “SBOM & risk analysis only” is sufficient.

After completion

What you must keep

The CRA* requires two things: the technical documentation and the Declaration of Conformity — for at least 10 years after placing on the market or for the support period, whichever is longer (Art. 13(13) CRA*). One set per product version.

Required by the CRA

1 · Required

Declaration of Conformity, signed

What
Your declaration that the product meets the requirements, signed by an authorised person.
Source
Created with the CRA DoC Wizard (card 4) or by other means.
Why
Required for every product placed on the market from 11 December 2027 (Art. 13(12), Art. 28 CRA*). The signed version is what counts.
2 · Required

Technical documentation

What
All documents demonstrating conformity (Annex VII CRA*).…_CRA-DELIVERY_EN.zip
Source
Partly from the DDAS handover package (DDAS keeps no copy, please archive it yourself), partly from you — see the box below. Besides the DDAS risk analysis, the assessment of cybersecurity risks includes your statement on the findings.
Why
Required (Art. 13(12), Art. 31 CRA*); market surveillance authorities can request it.

Recommended as evidence

3 · Recommended

Your data package for DDAS

What
Classification Paper with your answers (if created) and your PLC project data — exactly as you submitted them.…_CRA-INPUT_EN.zip
Source
At the end of the CRA Classification Wizard, step 2.
Why
Shows the data basis DDAS analysed.
4 · Recommended

Output of the CRA DoC Wizard

What
The declaration package: the Declaration of Conformity as a PDF for signature, a cover sheet listing your next tasks, your statement on the findings and your answers as a file.…_CRA-DOC_EN.zip
Source
On the overview of the CRA DoC Wizard, step 5 — only if you use it.
Why
With your signature, the PDF becomes card 1. Cover sheet and answers show how the declaration was produced. The statement documents how you dealt with the reported findings.

Card 2 in detail · Technical documentation under Annex VII CRA*

Our package is part of your technical documentation — not all of it.

Annex VII lists what the technical documentation must contain. On the left: the parts you receive from DDAS or produce with the DoC Wizard; on the right: what you contribute yourself.

In the handover package · step 4

  • Software bill of materials (SBOM): list of all software components of your product, in CycloneDX 1.6/1.7 and SPDX 2.3/3.0.1, signed by DDAS.covers: Annex VII, points 2(b) and 8
  • Risk analysis: assessment of the cybersecurity risks of your machine program and libraries.contributes to: Annex VII, point 3
  • Classification Paper as PDF: intended purpose, product boundary, software version and CRA class.contributes to: Annex VII, points 1(a), 1(b)
  • Signed manifest: one checksum per file. This lets you prove at any time that the delivery comes from DDAS and is unaltered.

Produced with the DoC Wizard · step 5

  • Statement on the findings: your assessment of the findings of the risk analysis, as a contribution to your risk assessment.contributes to: Annex VII, point 3
  • Standards information: which harmonised standards or specifications you applied.covers: Annex VII, point 5 (list)
  • Declaration of Conformity: the draft for signature.covers: Annex VII, point 7

Still to be provided by you

  • User information under Annex II, e.g. end of support, update route, reporting contactAnnex VII, point 1(d)
  • Design and development, system architectureAnnex VII, point 2(a)
  • Vulnerability handling: disclosure policy, reporting contact, secure update distributionAnnex VII, point 2(b)
  • Production and monitoring processesAnnex VII, point 2(c)
  • Risk assessment of the whole product in its intended useAnnex VII, point 3
  • Basis for the support periodAnnex VII, point 4
  • Test and inspection reports on Annex IAnnex VII, point 6
  • For hardware: photographs and illustrationsAnnex VII, point 1(c)

DDAS assessment, not legal advice.

Legal basis

* CRA = Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), OJ L, 2024/2847, 20.11.2024. All references to “Art.” and “Annex” on this page refer to this Regulation. Full text on EUR-Lex

DDAS meets the manufacturer obligations for its own products as well: security advisories, disclosure policy and CSAF feed are published at security.ddas.digital.

Continue to access codeContinue to access code

The wizards help with the classification, the assessment of the findings and the preparation of the EU Declaration of Conformity under the Cyber Resilience Act. The manufacturer remains responsible for the accuracy of the content — this is not legal advice.

Where the content comes from. The questions and notes in the wizards reflect Regulation (EU) 2024/2847 and the guidelines of the European Commission; the sources are listed under "Legal basis" for each question. You give the answers as the manufacturer, because only you know your product. DDAS helps with using the wizards at [email protected]. How your product is to be classified and which answer applies is for you to decide; if in doubt, consult your legal adviser. What a finished package looks like and which decisions the Classification Paper contains is shown by the sample package of a fictitious machine builder with a guide.

CRA Package 2026.1