Oracle Maps Its Security Programmes to the EU Cyber Resilience Act

Oracle is aligning its existing security and software development programmes with the requirements of the European Union’s Cyber Resilience Act (CRA), as the regulation introduces new obligations for manufacturers of products with digital elements.

The first major CRA milestone arrived on 11 September 2026, when vulnerability and incident reporting requirements became applicable. A broader set of cybersecurity requirements will follow on 11 December 2027, extending the regulation’s reach across the product development and support lifecycle.

For Oracle customers, the two deadlines create two different areas of focus. The first is whether vendors can identify, investigate and report serious security events within the required timeframe. The second concerns how security is built into products from development through ongoing maintenance.

Oracle Connects CRA Reporting to Its Existing Security Processes

Oracle says its existing vulnerability management and incident response capabilities provide the foundation for meeting the CRA’s reporting requirements.

Its Security Incident Management Policy gives the Chief Security Officer organisation responsibility for coordinating security event and incident preparation, detection, investigation, resolution and forensic evidence management across Oracle’s business units.

The company’s Integrated Cyber Centre provides central coordination for incident response, customer trust and security communications.

Several of Oracle’s existing procedures are closely aligned with the requirements of regulatory reporting. Business units are expected to investigate and validate suspected security events, preserve evidence, document incidents and response activities, escalate significant events and notify relevant parties.

Oracle also maintains procedures for maintaining the chain of custody during investigations and for collecting forensic information that may need to meet legal or regulatory requirements.

However, the scope of Oracle’s responsibility has an important boundary.

Oracle’s incident response processes cover suspected unauthorised access involving Oracle-managed assets. Customers remain responsible for managing access to their own cloud environments and monitoring their service tenancies using the security controls, logging and other tools available to them.

The 2027 Deadline Extends Security Into Product Development

The CRA’s December 2027 requirements take a broader approach by extending cybersecurity obligations across the product lifecycle.

Oracle points to its Oracle Software Security Assurance (OSSA) programme as a key part of its preparation for these requirements.

OSSA is Oracle’s framework for incorporating security into products deployed both on premises and through Oracle Cloud services.

The programme includes secure coding standards, mandatory security training for developers, automated security analysis and testing, vulnerability disclosure procedures and remediation programmes delivered through Oracle’s Critical Patch Update and Security Alert processes.

Oracle’s Secure Coding Standards provide an example of how these controls are applied throughout development.

Developers are required to follow the standards when designing and building Oracle products. Compliance is assessed throughout the supported life of those products, while the standards are updated as Oracle identifies new vulnerabilities and security risks.

The company has also expanded its secure development guidance to address emerging technologies, including artificial intelligence and machine learning.

Oracle says it continues to assess the requirements for the 2027 deadline as implementation guidance and supporting standards develop.

Two Deadlines Create Two Different Compliance Tests

The September 2026 reporting requirements and the December 2027 product security requirements should not be treated as a single compliance exercise.

The first deadline focuses on visibility and response. Vendors need processes for identifying serious vulnerabilities and incidents, preserving relevant evidence and providing information to regulators within the required timeframe.

The second focuses on product security by design. Vendors will need to demonstrate that security considerations are incorporated into development, maintenance, vulnerability management and the wider product lifecycle.

For enterprise technology buyers, this distinction provides a useful way to assess vendor readiness.

A vendor may have strong incident response capabilities while still needing to demonstrate how its development processes meet the broader product security requirements coming into force in 2027.

What This Means for ERP Teams

Regulatory reporting can move faster than patch cycles. Oracle typically delivers security fixes through its quarterly Critical Patch Update process, while the CRA introduces reporting obligations around actively exploited vulnerabilities and serious incidents. ERP teams should therefore understand how a vendor handles disclosure and communication when an incident occurs between scheduled patch releases.

The shared responsibility model is also a compliance boundary. Oracle’s regulatory reporting covers assets managed by Oracle. Customers remain responsible for their own cloud environments and any regulatory obligations that apply directly to them. Organisations subject to requirements such as NIS2 or DORA should not assume that a vendor’s CRA reporting will provide all the evidence they need for their own compliance obligations.

The CRA strengthens vendor due diligence. Security programmes such as OSSA have traditionally been important indicators of vendor maturity, but the CRA gives cybersecurity requirements a stronger regulatory foundation. ERP buyers can increasingly use these obligations as part of procurement discussions, contract negotiations and ongoing supplier assessments.

Ask vendors how the two compliance layers connect. ERP teams should assess both incident response and secure development practices. Questions should cover vulnerability disclosure, response times, evidence preservation, patching processes, secure coding, product lifecycle management and responsibilities between the vendor and customer.

Document the customer side of the shared responsibility model. Even when a vendor has strong security controls, customers remain responsible for their own configurations, identities, access controls and monitoring. ERP teams should maintain evidence showing how these responsibilities are managed within their own environments.

The Bigger Picture

The EU Cyber Resilience Act is changing the way enterprise software security is evaluated.

Security is increasingly becoming a regulatory requirement rather than simply a vendor assurance issue. For ERP providers, that means demonstrating not only how they respond when vulnerabilities emerge, but also how security is incorporated into the products before they reach customers.

Oracle’s approach shows how existing security programmes can provide a foundation for meeting the new requirements. The more significant test will come in December 2027, when the CRA’s broader product cybersecurity obligations take effect.

For ERP customers, the regulation provides another reason to look beyond security certifications and ask how vendors actually detect vulnerabilities, build secure