EU Cyber Resilience Act: Requirements, Deadlines, and How to Prepare

What software teams need to know about CRA applicability, incident reporting, backend security, and recovery.

The EU Cyber Resilience Act (CRA) is changing how organizations approach security for software and connected products made available in the European Union. But not every application is covered, and not every organization has the same obligations.

For teams building fintech applications, healthcare technology, enterprise software, and other digital products, the first step is understanding whether the CRA applies to what you're building. The next is ensuring your applications, backend infrastructure, and security processes are prepared.

This guide explains the CRA's requirements and deadlines, how the regulation applies to SaaS applications and backend APIs, and the practical steps Xano recommends for strengthening security and incident readiness.

EU Cyber Resilience Act: Key Facts

The EU Cyber Resilience Act (CRA), formally Regulation (EU) 2024/2847, establishes cybersecurity requirements for certain software and hardware products made available on the EU market.

• Who it affects: Manufacturers, importers, distributors, and certain open-source software stewards involved with covered products.
• September 11, 2026: Mandatory reporting requirements began applying to manufacturers of in-scope products.
• December 11, 2027: Most broader product cybersecurity requirements become applicable.
• SaaS applicability: Standalone SaaS services are not automatically covered, but certain backend services necessary for covered products may fall within scope.
• Core requirements: Cybersecurity risk assessments, secure development, vulnerability management, security updates, technical documentation, and incident reporting.

For organizations building with Xano, the CRA reinforces the importance of understanding which systems support critical product functionality, how security responsibilities are shared, and whether incident response and recovery procedures are ready to execute.

Important: Using Xano does not automatically establish CRA compliance. Each organization is responsible for determining its obligations and implementing the appropriate controls.

What Is the EU Cyber Resilience Act?

The Cyber Resilience Act is an EU regulation intended to improve the cybersecurity of products with digital elements throughout their lifecycle.

Rather than focusing only on security at the point of release, the CRA addresses how manufacturers design, develop, maintain, update, and support their products.

Its requirements include secure product development, vulnerability management, security updates, technical documentation, and reporting of certain cybersecurity events.

When Does the Cyber Resilience Act Take Effect?

The CRA entered into force on December 10, 2024, with requirements becoming applicable in stages.

Date	What it means
December 10, 2024	The CRA entered into force.
September 11, 2026	Mandatory reporting obligations began applying to manufacturers of in-scope products.
December 11, 2027	Most broader product cybersecurity requirements become applicable.

These dates matter because certain reporting obligations are already in effect, even while organizations continue preparing for the broader requirements.

For official implementation guidance, visit the European Commission's Cyber Resilience Act page.

Who Needs to Comply With the CRA?

The CRA primarily applies to organizations making certain software or hardware products with digital elements available on the EU market.

It is not limited to companies headquartered in the EU. Organizations based elsewhere may also have obligations when they make covered products available in Europe.

The specific requirements depend on the organization's role.

• Manufacturers: Organizations developing or marketing covered products under their own name or trademark. They carry the principal responsibilities for product cybersecurity, vulnerability management, conformity assessment, and incident reporting.
• Importers: EU-based organizations placing products from manufacturers outside the EU onto the EU market. They must verify that applicable requirements have been met.
• Distributors: Organizations making covered products available through the supply chain. They have obligations to perform certain checks and respond to compliance or security concerns.
• Open-source software stewards: Certain organizations providing sustained support for open-source software intended for commercial activities. The CRA establishes distinct obligations for these organizations.

Product classification also matters. Certain products designated as important or critical face additional conformity assessment requirements.

Does the Cyber Resilience Act Apply to SaaS Applications and Backend APIs?

Not automatically.

One of the most important distinctions for software teams is the difference between standalone cloud services and products with digital elements.

A standalone SaaS application is not automatically covered simply because EU customers can access it.

However, the CRA can include certain remote data processing solutions developed by or under the responsibility of a product manufacturer when that processing is necessary for the covered product to perform one of its functions.

Consider a distributed mobile application that relies on backend APIs to perform essential functions. The manufacturer may need to evaluate those backend services as part of its CRA assessment.

By contrast, a standalone browser-based business application should not be assumed to fall within scope solely because it operates on cloud infrastructure.

For Xano customers, the important question is not simply whether an application uses a backend. It is whether the application qualifies as a covered product and whether its remote processing forms part of that product under the regulation.

Examples Relevant to Xano Customers

Industry	Example	CRA consideration
Fintech	A company distributes a mobile financial application to EU customers.	The distributed application may fall within scope, including qualifying backend services essential to its functions.
Healthcare	A company provides a connected wellness device and companion application.	The software and connected device may fall within scope, depending on their classification.
Healthcare	A company develops regulated medical device software.	Products covered by the EU Medical Devices Regulation or In Vitro Diagnostic Medical Devices Regulation are excluded from the CRA.
IT and cybersecurity	A company sells authentication software, password managers, or network management tools.	These may qualify as important products and face additional assessment requirements.
Enterprise software	A company distributes desktop software that connects to backend APIs.	The distributed software may fall within scope, with associated remote processing requiring evaluation.
Cloud software	A company offers a standalone cloud-hosted business application.	Standalone SaaS is not automatically covered. The product and service architecture must be assessed.

Our recommendation: Assess CRA applicability at the product level, rather than assuming every application in your organization has the same requirements.

Your legal, security, and compliance teams should determine which products are covered and which obligations apply.

What Does the CRA Require?

For manufacturers of in-scope products, the CRA introduces requirements intended to make cybersecurity part of the entire product lifecycle.

The core areas include:

1. Cybersecurity risk assessments: Identifying and addressing relevant risks throughout product design, development, and maintenance.
2. Secure product development: Implementing security controls appropriate to the product's risk profile, including secure configurations and protections against unauthorized access.
3. Vulnerability management: Establishing processes to identify, document, remediate, and communicate vulnerabilities, including those involving third-party components.
4. Security updates and support: Providing appropriate vulnerability handling and security updates during the applicable support period.
5. Technical documentation and conformity: Maintaining required documentation, completing applicable conformity assessments, and meeting declaration of conformity and CE marking requirements.
6. Incident and vulnerability reporting: Notifying appropriate authorities about actively exploited vulnerabilities and severe incidents affecting the security of covered products.

The exact requirements vary based on the product and the manufacturer's responsibilities.

A secure backend can support an organization's cybersecurity program, but it does not replace product classification, conformity assessment, documentation, or regulatory reporting.

What Are the CRA Incident Reporting Deadlines?

Under Article 14, manufacturers of in-scope products must report two categories of cybersecurity events when the applicable criteria are met:

• Actively exploited vulnerabilities: Vulnerabilities for which there is reliable evidence of exploitation by a malicious actor.
• Severe incidents affecting product security: Incidents meeting the CRA's severity criteria and affecting the security of a covered product.

The regulation establishes the following notification deadlines:

Reporting stage	Deadline
Early warning	Without undue delay, and within 24 hours of becoming aware of the qualifying event.
Initial detailed notification	Without undue delay, and within 72 hours of becoming aware.
Final report for an actively exploited vulnerability	No later than 14 days after a corrective or mitigating measure becomes available.
Final report for a severe incident	Within one month after submitting the 72-hour notification.

These are regulatory notification timelines, not deadlines for completing all remediation activities.

Not every service disruption, application error, or security event automatically triggers CRA reporting. Organizations must assess whether the relevant criteria are met.

Where Do Organizations Report CRA Incidents?

Organizations with mandatory reporting obligations submit their notifications through ENISA's CRA Single Reporting Platform.

Official reporting portal: https://portal.cra-srp.enisa.europa.eu/

The platform is operated by the European Union Agency for Cybersecurity (ENISA).

Organizations that may have reporting obligations should identify responsible personnel and prepare access to the reporting platform before an incident occurs.

Contacting Xano about a security incident and notifying EU authorities are separate actions.

Depending on the circumstances, additional obligations under GDPR, NIS2, DORA, or other applicable legislation may also need consideration.

CRA Readiness Checklist for Application and Backend Teams

Whether your organization is directly subject to the CRA or is strengthening its broader security program, these are practical areas to review.

• Determine product applicability. Identify products made available on the EU market and assess their CRA scope and classification.
• Map supporting systems. Document frontend applications, backend APIs, databases, authentication systems, and third-party dependencies.
• Assess cybersecurity risks. Identify potential vulnerabilities, critical functions, and the controls used to protect them.
• Review application security. Evaluate authentication, authorization, API security, access permissions, credentials, and environment separation.
• Establish vulnerability management. Define how vulnerabilities are identified, remediated, documented, and communicated.
• Assign incident response ownership. Identify who investigates incidents, makes escalation decisions, and determines whether regulatory reporting is required.
• Review backup and recovery capabilities. Confirm backup frequency, retention, recovery objectives, and restoration procedures.
• Test incident response procedures. Conduct tabletop exercises covering realistic security events and reporting deadlines.
• Prepare required documentation. For in-scope products, establish processes for technical documentation and applicable conformity requirements.

This checklist is a starting point for readiness planning, not a substitute for a formal CRA compliance assessment.

How Xano Recommends Preparing Your Applications and Backend

Regardless of whether a particular application falls within the CRA's scope, several security practices can improve your organization's ability to prevent, detect, respond to, and recover from incidents.

1. Understand Which Products and Systems Could Be Affected

Start by identifying the products your organization makes available in the EU and the infrastructure supporting them.

For applications built with Xano, this includes understanding how the following components work together:

• Frontend applications
• Backend APIs
• Databases
• Authentication systems
• Third-party integrations
• Supporting infrastructure and remote processing

Document which systems support critical functionality, where sensitive data is processed, and who is responsible for securing each component.

For example, consider a distributed financial application that uses Xano APIs to authenticate users and retrieve account information.

Its team should understand which backend functions are essential to the application, how access is controlled, and what would happen if those functions were compromised or unavailable.

This architecture map supports security risk assessments, incident investigations, and decisions about CRA applicability.

It also helps establish where your organization's responsibilities begin and end when working with external technology providers.

For additional guidance, review Xano's Shared Responsibility Model.

2. Review Your Backend Security Practices

A secure application requires more than secure hosting.

Application-level configuration, authorization decisions, and access controls matter just as much.

We recommend regularly reviewing your Xano environments, including:

• Authentication and authorization controls
• Access permissions for team members and application users
• API security and sensitive data exposure
• Management of credentials and third-party integrations
• Separation of development, testing, and production environments
• Logging, monitoring, and vulnerability remediation procedures

Xano provides backend development capabilities and security controls that can support these practices. However, customers remain responsible for configuring and securing the applications, APIs, databases, and integrations they build.

The objective is to make security review part of normal application development rather than something that happens only before a release or during an audit.

3. Establish a Documented Incident Response Plan

One of the most important steps an organization can take is establishing an incident response plan before an incident occurs.

The CRA's reporting requirements make timely detection, investigation, and escalation especially important for manufacturers of covered products.

A practical incident response plan should document:

• Detection: How suspicious activity, vulnerabilities, and potential incidents are identified.
• Ownership: Who investigates incidents and makes escalation decisions.
• Containment: How affected systems, endpoints, credentials, or integrations can be secured.
• Investigation: What information must be preserved to determine the scope and cause of an incident.
• Communication: When to notify internal stakeholders, providers, customers, or regulatory authorities.
• Recovery: How affected services and data will be restored safely.
• Review: How findings will be documented and used to improve security controls.

For organizations subject to CRA reporting, the plan should also identify who determines whether an event meets the notification thresholds.

This matters because discovering suspicious activity and confirming its full impact rarely happen at the same time.

Your team should know how to escalate a potential reporting event without waiting for every detail to become available.

4. Establish a Backup and Recovery Strategy

Backups are an essential part of operational resilience and incident recovery.

Whether an incident involves unauthorized changes, accidental deletion, application errors, or compromised data, recoverable backups can help limit disruption.

But simply having backups is not enough.

Organizations need to understand how frequently backups occur, how long they are retained, and how quickly data and services can be restored.

Understanding Xano's Backup Capabilities

According to Xano's existing backup guidance:

Plan	Backup capabilities
Paid plans	Automatic daily backups of server instances with a rolling three-day retention period.
Enterprise plans	Typically 30 days of rolling 24-hour backups, along with a seven-day point-in-time recovery log.
Free plans	Instance backups are not available.

Automated Xano backups are stored in the same region as the primary instance, but within a distinct zone to provide resilience against potential disasters at the main site.

Specific capabilities may vary depending on the plan, deployment model, and applicable agreement.

Customers can also initiate manual backups, subject to applicable platform and plan limitations.

For example, your team may choose to create additional backups before major application changes, data migrations, or deployments involving critical business information.

See Xano's Backup and Restore documentation for additional details.

Define Your Recovery Objectives

We recommend establishing:

• Recovery Point Objective (RPO): How much data your organization can afford to lose, measured in time.
• Recovery Time Objective (RTO): How quickly your systems need to be restored following an incident.
• Backup frequency: How often backups should occur to support your recovery objectives.
• Retention requirements: How long backups need to remain available.
• Recovery testing: How frequently your team verifies that backups can actually be restored.

Additional backups can strengthen your recovery strategy, but they do not replace appropriate access controls, incident investigation, or vulnerability remediation.

Restoring compromised data without addressing the underlying security issue can expose the application to the same problem again.

5. Test Your Response Procedures Before They're Needed

An incident response plan is only useful if the people responsible for executing it know what to do.

We recommend periodically running tabletop exercises that simulate realistic security incidents.

For example, imagine an attacker gains access to an administrative account used to manage a production application.

Would your team know how to:

1. Revoke compromised access and rotate credentials?
2. Investigate account activity and affected API endpoints?
3. Preserve relevant logs and evidence?
4. Contact Xano or other technology providers?
5. Determine whether regulatory reporting is required?
6. Restore normal operations safely?

For organizations subject to the CRA, exercises should also account for applicable notification deadlines.

The goal is to identify gaps in a controlled exercise rather than during an actual security incident.

What Should You Do if a Security Incident Affects Your Xano Account?

If you suspect a security incident involving your Xano account, workspace, or application, we recommend the following steps.

Step 1: Report the Incident to Xano

If you suspect a security incident involving your Xano account or the Xano platform, contact our security team.

Xano security incident reporting: security@xano.com

Provide relevant details, including affected instances, observed behavior, approximate timing, and containment measures already taken.

Avoid including passwords, access tokens, or other secrets in your initial email.

For backup restoration assistance, contact Xano Support at support@xano.com.

Step 2: Assess and Contain the Issue

Determine which systems may be affected and take appropriate containment measures.

Depending on the situation, this could include revoking compromised access, rotating credentials, restricting affected API endpoints, or temporarily disabling vulnerable integrations.

Step 3: Preserve Relevant Information

Document when suspicious activity was first observed, which applications or instances may be involved, and what evidence is available.

Preserve relevant logs and records according to your incident response procedures and retention requirements.

Step 4: Determine Whether Regulatory Reporting Is Required

If your organization is subject to the CRA, assess whether the event meets the regulation's reporting criteria.

Not every service disruption, application error, or security event automatically triggers mandatory CRA notification.

However, qualifying severe incidents and actively exploited vulnerabilities affecting covered products must be reported within the applicable deadlines.

Reporting an incident to Xano does not replace your organization's responsibility to meet its own regulatory notification obligations.

Step 5: Recover and Review

Once the issue is contained and investigated, follow your documented recovery procedures.

That may involve restoring data from a verified backup, updating compromised credentials, correcting access permissions, or deploying a security fix.

Afterward, document the root cause, actions taken, and improvements required to reduce the likelihood of recurrence.

Frequently Asked Questions About the EU Cyber Resilience Act

Does the CRA Apply to Companies Outside the EU?

Yes, potentially. Companies headquartered outside the EU may still have obligations under the CRA if they make covered products available on the EU market.

Does the CRA Apply to SaaS Applications?

Not automatically. Standalone SaaS services are not covered solely because EU customers can access them. However, certain remote data processing solutions necessary for covered products may fall within scope. Applicability depends on the product's functionality, architecture, and distribution.

When Does the EU Cyber Resilience Act Take Effect?

The CRA entered into force on December 10, 2024. Mandatory reporting provisions began applying on September 11, 2026, and most broader product cybersecurity requirements become applicable on December 11, 2027.

What Incidents Must Be Reported Under the CRA?

Manufacturers of covered products must report actively exploited vulnerabilities and severe incidents affecting product security when the regulation's criteria are met. A routine outage or software bug is not automatically reportable.

Does Using Xano Make an Application CRA-Compliant?

No. Xano provides backend infrastructure, security capabilities, and recovery options that can support an organization's security practices.

However, manufacturers must independently determine whether their products are covered and meet applicable cybersecurity, documentation, conformity assessment, and reporting requirements.

Building Resilience Goes Beyond Compliance

The Cyber Resilience Act reinforces an important principle: security doesn't end when an application is deployed.

For engineering leaders, the practical challenge is making security, vulnerability management, incident response, and recovery part of everyday operations without creating unnecessary complexity.

That means understanding which products carry regulatory obligations, knowing which systems support them, and ensuring teams have repeatable procedures for detecting, responding to, and recovering from security incidents.

At Xano, we're committed to providing backend capabilities, security controls, and recovery options that help customers build and operate applications responsibly.

While using Xano does not automatically establish CRA compliance, understanding shared security responsibilities and implementing appropriate safeguards can support your organization's readiness efforts.

Our recommendation: Determine your obligations early, document your incident response plan, review your backup strategy, and make sure your team knows exactly who to contact when something goes wrong.

The best time to test your incident response process is before you need it.

Official Resources and Further Reading

• European Commission: Cyber Resilience Act
• Regulation (EU) 2024/2847: Official Legal Text
• ENISA CRA Single Reporting Platform
• Xano Trust Center
• Xano Shared Responsibility Model
• Xano Backup and Restore Documentation

Disclaimer: This article is intended for general informational purposes only and does not constitute legal, regulatory, or compliance advice. Organizations are responsible for determining their own obligations under the EU Cyber Resilience Act and other applicable laws. We recommend consulting qualified legal and compliance professionals to assess your specific requirements.