Does the Cyber Resilience Act apply to a mobile app and its backend?
A standalone mobile app is a product with digital elements under the Cyber Resilience Act, and the backend modules the app depends on can become part of that product. The Commission's guidance says the regulation covers standalone software such as apps, and Article 3(2) brings remote data processing into a product when the manufacturer designed it, or had it designed under its responsibility, and the product could not perform one of its functions without it. The question for a product team is therefore not whether the app is in scope, but which server-side software the app actually relies on to function. The answer depends on two things: which backend modules the app calls directly, and which build variants the organization ships. The guidance limits remote data processing to the software modules responsible for the product's functionality and the interfaces they use. In the Commission's mobile banking example (section 8.3.1 of the guidance), the self-hosted banking interface that authenticates customers and submits their instructions is part of the product, while the account management and ledger systems behind it, which the app does not call directly, are not. Those systems remain external dependencies that belong in the risk assessment. Each build variant with different components or features is a separate product, so the mapping must be repeated for each one.
The organization owns the conformity work. Its engineers and compliance lead must map the app's calls to backend interfaces, record the result, and keep the technical documentation and support period commitments current. A partner can help prepare the systems, evidence and mapping, but only an independent body issues any assessment result where one is required. Before scoping, confirm with your legal or regulatory advisers and the guidance itself which modules the app invokes, and ask any outside party to show how each backend interface was traced to the product's functions.
Which backend services count as remote data processing
A backend service falls inside the CRA only when it is remote data processing under Article 3(2) of Regulation (EU) 2024/2847. The test has two parts. The processing must be designed by the manufacturer or carried out under the manufacturer's responsibility, and the product could not perform one of its functions without it. For a mobile app, this means the question is not whether a server exists, but whether the app depends on that server to do something it is meant to do. A sign-in service, a push notification relay or an API that returns the data a screen displays can meet the test. A cloud service the app never reaches is outside it, even if the same company runs it.
The Commission's guidance (C(2026) 5252, section 8.2) narrows the test further. RDPS covers the software modules responsible for the app's functionality and the interfaces those modules use. Back-end systems the app does not interact with directly are not RDPS. In the guidance's mobile banking example (section 8.3.1), the self-hosted banking interface that authenticates customers and submits their instructions is RDPS, while the account management and ledger systems behind it are not. Engineering teams should map each endpoint the app calls, trace which modules answer those calls, and record the boundary in the technical documentation. Ask whether a gateway, queue or database used only by those modules sits inside that boundary.
Backend systems outside the RDPS boundary are not left unaddressed. They remain external dependencies that the manufacturer must consider in its cybersecurity risk assessment, because a compromise of the ledger or a third-party identity provider can still reach users through the app. Confirm with counsel and your notified body or assessor, where one applies, how each dependency is recorded. Keep a dependency register that names each external service, its owner, its contractual security commitments and the evidence you hold about it. Note that the guidance itself is non-binding, so its examples should guide the analysis rather than replace it.
How the Commission's mobile banking example sorts backend systems
The Commission's guidance, in its mobile banking example (section 8.3.1 of the annex to C(2026) 5252), treats a self-hosted banking interface as remote data processing for the app. This is the component that authenticates the customer and submits their instructions to the bank. Article 3(2) of the regulation brings remote data processing into a product when the manufacturer designed it, or had it designed under its responsibility, and the product could not perform one of its functions without it. The app cannot log a customer in or send a payment instruction without this interface, so the interface sits inside the product's scope.
- Authentication path: the login and session handling the app relies on are in scope because the app cannot function without them.
- Instruction submission: the endpoints that receive customer instructions from the app are in scope for the same reason.
- Ownership test: the bank must have designed the interface or had it designed under its responsibility for Article 3(2) to apply.
- Obligations that follow: the bank must meet the Annex I essential requirements and the Annex I Part II vulnerability handling duties for this component, alongside the app.
- Scope limit: the guidance limits RDPS to the modules responsible for the product's functionality and the interfaces they use.
Before you classify the interface, confirm with your legal and product teams which services the app calls and who designed each one.
The account management and ledger systems behind the banking interface are not remote data processing of the app in the Commission's example. The app does not call them directly, and the interface mediates every request. The guidance (section 8.2) makes the same point generally: back-end systems the product does not interact with directly are not RDPS. This is a boundary on the product definition, not a statement that these systems are unimportant. They still carry security obligations under other frameworks and under the bank's own governance.
- Direct calls decide the boundary: if the app does not call a system, that system is outside RDPS for this product.
- Mediation by the interface: a system reached only through the banking interface stays outside the product even when the interface passes data to it.
- Other regimes: core banking and ledger systems are often in scope of DORA, NIS 2 or sector rules, which the CRA does not replace.
- Changing the architecture changes the answer: if the app starts calling a ledger service directly, reassess its status.
- Documentation: keep a dated architecture record that shows which systems the app calls, so the boundary can be reviewed.
Ask the architecture team for a current map of every call the app makes, including calls made by third-party SDKs.
Systems outside RDPS are not dropped from the analysis. The guidance expects the manufacturer to treat back-end systems the product does not interact with directly as external dependencies in its cybersecurity risk assessment. The assessment must consider how a compromise or failure in those systems could reach the product and its users, and it must record the controls the manufacturer relies on, including those provided by a third party. The RDPS systems, by contrast, are covered by the product's own essential requirements and vulnerability handling process.
- Two treatments, one assessment: RDPS components receive full product obligations; external dependencies are assessed and documented.
- Dependency register: list each external system, its owner, the interface through which failures would reach the app, and the controls in place.
- Third-party evidence: where a ledger provider or hosting vendor supplies controls, request contractual or audit evidence that you can reference.
- Review trigger: reassess when the interface changes, when a dependency changes owner, or when a new call path appears.
- Records: the risk assessment is part of the technical documentation the manufacturer must keep.
Confirm with your conformity assessment advisers how the treatment of each external dependency will be recorded in the technical documentation.
The Commission's example illustrates one architecture. It does not decide how any other bank, fintech or app developer should structure its backend, and it does not establish that every bank interface is in scope or that every ledger is out of scope. The outcome depends on which functions the product needs, which components the manufacturer designed, and which systems the app actually calls. A different design, such as an app that calls a payments gateway directly or a backend shared across several apps, can produce a different split.
- Illustrative, not binding: the example guides reasoning, but each product needs its own analysis.
- Function test: ask which product functions would fail without each component.
- Shared backends: a service used by several apps may be RDPS for each one that depends on it.
- Third-party SDKs: calls made by embedded libraries count as calls the app makes.
- Expert review: a legal or compliance review should confirm the classification before you rely on it.
Check whether your market surveillance authority or your legal counsel has issued a position that applies to your product type.
How build variants and updates change the placing-on-market date
The date a product is placed on the market decides which CRA obligations attach to it and when. Under the Commission's guidance, that date follows the software version and build variant, not the day a team last touched the code. Read the four cards together before deciding how your release train maps to regulatory products.
Build variants are separate products
Builds that ship different components or features, such as a consumer build with a payment module and a regional build without it, are treated as separate products under section 2.1 of the Commission's guidance. Each one needs its own risk assessment, technical documentation and support period. For a mobile app with white-label or market-specific builds, list every variant in your product register before you count how many products you have. A missing variant is a missing conformity file.
Store releases set the placing date
The guidance states that all copies of a standalone software version are placed on the market when that version is first offered. For an app distributed through public app stores, the first offer is the moment the version becomes available to users, not the moment the build was signed. Record that date per version and per variant, since it anchors the timeline for your support period. Ask your release engineers which artifacts are published to which stores and when.
Non-substantial updates keep the date
Updates that are not substantial modifications do not change the original placing-on-market date, according to section 2.1 of the guidance. Security patches, bug fixes and routine feature releases therefore sit inside the same product history. Your backend changes count here too, so confirm with your architects which backend changes alter the product's functionality. Keep a change log that shows why each update was judged non-substantial.
Substantial modifications restart the clock
A substantial modification is a change that alters the product's intended functions or risk profile in a way that requires a new conformity assessment, and it is the event that can bring a product placed on the market earlier under the regulation. Your legal and product teams should define the threshold in writing for each product line, and check it against the guidance before each major release. Treat any change to authentication, data handling or the remote backend as a candidate for review.
What update and support duties apply to an app
This sequence takes an app team from the security update mechanics required by Annex I Part I point (2)(c) to a fixed, published support end date. Each step closes with a record the team can show a market surveillance authority or a notified body.
Map the app's update path end to end
Engineering and product owners trace how a security fix travels from the team to the installed app on each platform, including app store review, any server-side components and any separately delivered libraries or plug-ins. Record each hop and who controls it. The output is an update path diagram per app variant that shows where the manufacturer can push a fix and where the user or the store controls delivery.
Decide automatic update defaults and opt-out
Product and security leads decide, for each app, whether security updates are enabled by default and whether they are applied automatically where the platform allows it. Where automatic updates are enabled, the design must offer a clear and easy opt-out. Confirm with counsel and the platform's own update rules what the store permits. The output is a signed design decision per app that states the default, the opt-out path and any platform limits.
Build update notification and postponement
Engineers implement the user-facing side of point (2)(c): a notification when a security update is available and an option to temporarily postpone it. Test each path on every supported platform, including the case where the store applies the update itself. The output is a test record showing each notification and postponement state, with screenshots or logs per platform and version.
Set the support period against expected use
Product owners set the support period for each app variant. Article 13(8) sets a minimum of five years, unless the product is expected to be in use for less than five years, in which case the period must match expected use time. Document the expected use basis for any period shorter than five years and have it reviewed by legal counsel. The output is a support period record per variant with the reasoning attached.
Fix the support end date at purchase
Legal and product teams write the support end date, stated at least by month and year, into the purchase flow, store listing and terms that a buyer sees before buying. Where it is technically feasible, add a notification to users when the period ends. Check that each build variant shows its own date. The output is captured store listing and checkout screens with the dates visible, plus the notification design or a recorded reason why it is not technically feasible.
Assign owners and keep dated evidence
The team names an owner for update delivery, notification testing and support date communication, and sets up a log of every security update shipped with its release date and the platforms it reached. Ask an independent assessor which records they will request, since the required evidence depends on the conformity route. The output is a named ownership list and an update log that can be produced on request.
Confirm the duties against the backend
Where the app depends on backend services that count as remote data processing, check that the update and support commitments also cover those services, so the app does not go unsupported while its server side changes. Confirm the scope of those backend modules with the Commission guidance and your own architecture review. The output is a written note that links each backend module in scope to the update and support commitments that apply to it.
What changes the answer for your app and backend
Scope for a mobile app is rarely settled by the app alone. The backend modules it calls, the systems those modules share with other products, the cloud services they depend on, the build variants you ship and the years the product stays in use all change what you must document and support. Check each factor before you fix a scope and a support period.
Backend modules the app calls directly
Map every backend module the app calls itself, such as the login service, the payment submission API or the messaging endpoint. Under the Commission's guidance, remote data processing is limited to the software modules responsible for the product's functionality and the interfaces they use, so the boundary follows the direct calls. Keep a current interface inventory with each module's owner and version, and record which backend systems sit behind those modules without being called by the app. Those systems are external dependencies for the risk assessment, not automatically in scope.
Shared backends across products
A backend that serves your app and also a web portal, a partner API or an internal tool needs a clear allocation of responsibility. If the shared modules are designed by or under your responsibility and the app could not perform its functions without them, they fall within remote data processing for the product. Document which modules serve which products, who controls each release, and how a change to a shared module is assessed against each product it touches. Without that record, you cannot show which parts of the backend your conformity file covers.
Third-party cloud services
Managed identity providers, push notification services, analytics SDKs and hosted databases can all sit inside the functions your app depends on. Where the backend relies on a third-party cloud service to perform a product function, that dependency belongs in your supply chain review, SBOM and vulnerability monitoring. Ask each provider for its security update process, its end-of-life dates and the evidence it can supply, and record the contractual terms that let you respond to a vulnerability within your own reporting timelines.
Build variants and distribution channels
Different store builds, white-label versions, regional variants or builds with feature flags can each count as a separate product when they differ in components or features. Each separate product needs its own technical documentation, its own record of when it was first placed on the market and its own support period. List every variant you publish, the components and permissions that differ between them, and the date each was first offered. Keep that register current, because the date a variant was first offered determines its regulatory path.
Expected use time and support period
The support period must run at least five years, unless the product is expected to be in use for less than five years, in which case it must match the expected use time. Set the expected use time from evidence, such as your typical device lifecycle, your app's minimum supported operating system versions and your product plans, not from marketing preference. Record the basis for the figure, and publish the end date with at least month and year at the time of purchase or download, since users must be able to see when updates stop.
How to scope a mobile app and backend for CRA readiness
This sequence turns a mobile app and its backend services into a defined product boundary, with the remote data processing, variants, support period and risk assessment that the CRA requires a manufacturer to document before placing the app on the EU market.
Inventory the app and every backend interface
Start by listing the mobile app's builds, its bundled software modules, and every backend service the app calls directly, including authentication, API gateways, push notification relays and update servers. Engineering owns the technical inventory, and product and legal teams confirm which features the app is marketed to perform. The output is a written inventory that separates the app's own code from each external interface it uses. The step is done when an engineer who did not write the list can trace each network call from the app to a named service.
Classify remote data processing services
For each backend service in the inventory, decide whether it is remote data processing under Article 3(2): it must be designed by or under the manufacturer's responsibility, and the app could not perform one of its functions without it. Limit this to the software modules responsible for the app's functionality and the interfaces they use, as the Commission guidance describes. Services the app does not call directly remain external dependencies to cover in the risk assessment. The output is a classification table with a reason for every service. Confirm borderline cases with counsel, since the guidance example for a mobile banking app shows that the answer depends on which systems the app actually interacts with.
Map variants and release dates
Identify every build variant, such as regional, white-label, tier-specific or store-specific versions, and record which components or features differ between them. Under the guidance, variants with different components or features are separate products, so each needs its own entry. Record the date each version is first offered, because the guidance treats all copies of a standalone software version as placed on the market when it is first offered, and updates that are not substantial modifications do not change that date. The output is a register of products and version dates that tells you which versions fall under the regulation and when their obligations start.
Set the support period and its end date
For each product in the register, set a support period of at least five years, or a shorter period that matches the expected use time if the product is expected to be in use for less than five years. Product management and legal sign off on the figure, and the support period must be consistent with what the business promises users. Article 13(19) requires the end date, with at least month and year, to be clearly stated at the time of purchase, so the store listing, terms and in-app information must reflect it. Confirm with your counsel how the end date will be communicated for each variant. The output is an approved support period and end-date statement for every product.
Confirm update mechanisms and user controls
Review how security updates reach users on each platform, including whether updates are automatic and enabled by default, how users are notified, whether they can postpone updates, and how the app behaves when the backend no longer supports an old version. Engineering confirms the mechanisms, and the output is a table of update behavior per platform, linked to the Annex I Part I point (2)(c) requirement. Note that app store rules and platform update controls may limit what you can do, so confirm these constraints before committing to a design.
Build the risk assessment across app and backend
Use the inventory, the classification and the variant register as inputs to a cybersecurity risk assessment that covers the app, the RDPS services and the external dependencies they rely on. Security engineering leads the work with product and legal input. The assessment should identify threats to the app and backend, the risk each one poses, and the Annex I essential requirements that address it. The output is a documented risk assessment with a named owner, a version date and a list of open risks. The step is complete when each identified risk maps to a control or to an accepted residual risk with a sign off.
Assemble the technical documentation
Gather the outputs of the earlier steps into the technical documentation the manufacturer must keep for each product: the product description, the inventory and RDPS classification, the variant and version register, the support period statement, the risk assessment and the evidence for each applicable essential requirement. Compliance and engineering own the file, and the test evidence should come from the security testing and build pipeline. An independent assessor will review this file if a notified body is involved, but the manufacturer is responsible for its accuracy. The output is a versioned technical file per product, with a check that every document points to the same product, variant and version. Ask any implementation partner to state in writing which parts of this file they prepare and which parts remain with your team.
What must be in place before a conformity review
A conformity review of a mobile app and its backend tests whether the manufacturer can show what the product is, what it talks to, how long it is supported and how it gets fixed. The five items below are the records a compliance lead should confirm before an assessor or notified body asks for them, and each one feeds the technical documentation.
Documented product boundary
Write down which software modules belong to the app and which backend services are designed by or under your responsibility and could not be removed without losing an app function. Under Article 3(2), those backend parts count as remote data processing of the product. Check the boundary against the Commission's mobile banking example: the customer-facing authentication and instruction layer is in scope, while ledger systems the app never calls directly are external dependencies to cover in the risk assessment.
Interface inventory
List every interface the app and its in-scope backend expose or consume: APIs, push notification channels, SDK callbacks, deep links, admin endpoints and third-party calls. For each one, record the authentication method, the data it carries and the owner. An assessor will test whether the inventory matches what the software actually does, so confirm it against the code and gateway configuration rather than an architecture diagram alone.
Support period statement
Set the support period in writing and state its end date with at least month and year. The period must run at least five years unless the expected use time is shorter, in which case it must match that time. Confirm the statement appears where the buyer sees it at the time of purchase, and that your app store listing, terms and release notes all say the same thing.
Update mechanism records
Keep records showing how security updates reach the app and the backend: release pipeline logs, signing procedures, store submission history, and the default update behavior on each platform. Where automatic security updates are enabled by default, confirm the opt-out is clear and the user can temporarily postpone an update. Record who can approve an emergency release and how quickly a fix has reached users in past cases.
SBOM-ready component list
Build a complete list of the software components in each app build and each backend service, including open-source libraries, SDKs, base images and third-party cloud services that the product depends on. Record name, version, supplier and license for each entry, and generate it from the build pipeline so it stays current. Confirm each build variant has its own list, since variants with different components are separate products under the Commission guidance.
Who owns the CRA work for a mobile app
The organization that places the app on the EU market is the manufacturer under the regulation, and it keeps the legal responsibility for the product. It decides which app and backend functions are in scope, classifies the product against the default, important and critical categories, performs the cybersecurity risk assessment, and maintains the technical documentation. It also owns the EU declaration of conformity and the CE marking, and it decides the support period and communicates its end date to users.
- Product classification: Decide whether the app or any backend component falls under an Annex III or Annex IV category, which sets the conformity route.
- Risk assessment and Annex I: Document how each essential requirement is met for the app and the remote data processing it depends on.
- Support period and updates: Set the support period, which must be at least five years unless expected use is shorter, and state its end date at the time of purchase.
- Declaration and marking: Sign the EU declaration of conformity and affix CE marking only after the applicable conformity assessment is complete.
- Ongoing vulnerability handling: Run the Annex I Part II process and the Article 14 reporting duty for the whole support period.
Confirm internally who holds each of these roles before any external engagement begins, because the signature on the declaration cannot be delegated to a consultant.
DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside the client's own infrastructure, and it can prepare the systems that sit behind a mobile app. Its role is to make the controls and evidence exist and to keep them reproducible. DeployOpen does not classify the product on the organization's behalf, does not sign the declaration, and does not issue audit reports, attestations or certificates.
- Interface inventory: Map which backend modules the app calls directly, which is the input for deciding what counts as remote data processing under the guidance.
- Update and logging configuration: Configure update delivery, automatic update settings with a clear opt-out, and logging that supports vulnerability handling and incident reporting.
- Hardening and backups: Harden the self-hosted backend components and document backup and restore procedures.
- Evidence preparation: Assemble configuration records, test results and change history that support the technical documentation.
- Fixed-scope delivery: Agree the scope, deliverables and timeline in writing before work starts, with ongoing support available through retainers.
Ask the partner to state in the statement of work which artifacts it delivers and which decisions remain with the organization.
Most products follow self-assessment under module A, so many mobile apps need no external body. A notified body becomes necessary in the cases the regulation sets out, such as certain important products where harmonized standards or common specifications are not applied in full, and for class II and critical products. Notified bodies are designated by Member States and listed in the Commission's NANDO system, and national market surveillance authorities check compliance afterward.
- Route confirmation: Confirm with the assessor whether the app's classification allows module A or requires a notified body.
- Review of documentation: Where a notified body is involved, it reviews the technical documentation and performs the assessment steps its route requires.
- Report or certificate: Only the assessor or notified body issues any report, certificate or attestation that it is entitled to issue.
- Market surveillance: National authorities may request documentation and test products after placing on the market.
- Independence: The assessor must be independent of the party that built the controls, so plan separate engagements where the same firm would otherwise review its own work.
Check the notified body's designation in NANDO before you contract, and confirm its scope covers your product category.
Questions teams ask about mobile apps under the CRA
Does the Cyber Resilience Act apply to a free mobile app?
Yes, a free app can fall under the CRA. The regulation covers products with digital elements that are placed on the EU market, and the Commission's guidance (C(2026) 5252, section 2.2) states that standalone software such as apps is within its reach. Price is not the test. What matters is whether the app is a product made available on the market in the course of a commercial activity, and whether it has a direct or indirect logical connection to data processing. Teams should check their own distribution model with counsel, because the answer depends on how the app is supplied, who supplies it and whether a company profits from it in any form. Open-source apps follow a different path, which the open-source guidance in the CRA section of this site covers.
Is a backend hosted by a cloud provider covered by the CRA?
It can be. Under Article 3(2), remote data processing is brought into a product when it is designed by or under the responsibility of the manufacturer and the product could not perform one of its functions without it. A cloud backend that the app depends on for its core functions can therefore be part of the in-scope product. The Commission's guidance (section 8.2) limits this to the software modules responsible for the product's functionality and the interfaces they use. Back-end systems the app does not interact with directly are not remote data processing, but they remain external dependencies that belong in the risk assessment. Hosting location does not decide the question. A backend running in your own cloud account, a third party's platform or your data center is treated the same way for scoping purposes.
How are build variants of a mobile app counted under the CRA?
Build variants with different components or features are treated as separate products. The Commission's guidance (section 2.1) says that all copies of a standalone software version are placed on the market when it is first offered, and that updates which are not substantial modifications do not change that date. For a mobile team, this means a white-label build, a region-specific build or a build with a different feature set may each need its own technical documentation, risk assessment and declaration. Teams should map variants early, record which components differ, and confirm with their assessor how shared code and shared backends are documented. Illustrative example: one codebase shipped under two brands with different payment modules would usually be tracked as two products.
What does the support period mean for a mobile app?
The support period is the time during which you must keep providing security updates for the app. Article 13(8) sets a minimum of five years, unless the product is expected to be in use for less than five years, in which case the period must match the expected use time. Article 13(19) requires the end date, with at least month and year, to be clearly stated at the time of purchase and, where technically feasible, users to be notified when support ends. For apps, the period also affects the backend, SDK versions and supported operating system levels, because a security fix that needs a server change still counts. Annex I Part I point (2)(c) expects vulnerabilities to be addressable through security updates, including notification of available updates and the option to postpone them where applicable.
Can our team do CRA scoping for our mobile app ourselves?
Yes, in most organizations the first scoping pass is done in-house, and it should be. The people who know the app architecture, release process and third-party SDKs can list the modules that deliver core functions, the remote services they call directly, and the build variants in use. The organization stays responsible for the conclusions. Outside help is most useful when the scope is contested, such as deciding whether a backend module is remote data processing, or when a regulated customer asks for evidence. Ask a consultant to review your scope document, the list of dependencies and the variant map, and to identify gaps against the Annex I requirements. Any firm that prepares this work does not issue a conformity declaration, which remains the manufacturer's responsibility.
What does outside help for CRA mobile compliance cost, and what drives it?
No price is fixed by the regulation, and DeployOpen does not publish a price list. A quote follows from a written scope. Cost is driven by the number of distinct products and build variants, the number of backend services that qualify as remote data processing, the state of existing documentation and SBOM practice, and whether penetration testing or vulnerability handling processes must be built from scratch. Some costs are one-time, such as the initial scoping, risk assessment and technical documentation. Others recur, including support period upkeep, vulnerability monitoring and reporting readiness. When requesting a quote, ask for the deliverables list, the systems and variants covered, what evidence is handed over, what is excluded, and which parts the organization must still do itself. Also confirm that the conformity route and any notified body fees are shown separately.
How DeployOpen prepares mobile app and backend evidence
DeployOpen's part of a CRA mobile project starts with a written, fixed scope that names the self-hosted backend components that the app calls directly, the remote data processing modules inside your infrastructure, and the update and logging channels that will support the support period. Agreeing that boundary early matters because it decides which services must be hardened and documented as part of the product, and which stay external dependencies covered only by your risk assessment. The scope document should also list the decisions still owed by your team, such as which build variants are in play and which support end date you will state at purchase.
Within that scope, DeployOpen implements and hardens the self-hosted backend components inside your own cloud accounts, data centers or air-gapped networks. The work typically covers the authentication and instruction-submission interface, access controls, secrets handling, and configuration of the update mechanism, including how security updates are announced to users and how postponement is handled. Logging is configured so that vulnerability and incident events can be traced to a specific build and component, which later supports Article 14 reporting. You keep ownership of your controls, your risk assessment and your product decisions. DeployOpen hands over the configuration baselines, runbooks and technical documentation so your own staff can operate and evidence them after the engagement ends.
DeployOpen prepares the systems, controls and evidence, but it does not issue audit reports, attestations or CRA conformity documentation on your behalf. The EU declaration of conformity and CE marking are your responsibility as manufacturer, and any notified body or other independent assessor you involve issues its own findings. Ask any implementation partner for a written list of the evidence artifacts it will deliver and confirm which of them your assessor expects. Guidance on applying the regulation is published by the European Commission's digital strategy pages, and your assessor's reading of that guidance should drive the final evidence set.
