The EU Cyber Resilience Act’s vulnerability and incident reporting obligations became applicable on September 11, 2026, requiring manufacturers of covered products with digital elements to report actively exploited vulnerabilities and severe security incidents through the EU’s reporting framework. The obligations are designed to support coordinated awareness, information sharing, and response across the EU cybersecurity ecosystem.
Oracle addressed the milestone in a recent blog post on the EU Cyber Resilience Act, stating that its established vulnerability management and security incident response capabilities support its preparations for the reporting requirements. A second, larger deadline follows: on December 11, 2027, the CRA’s broader product cybersecurity and vulnerability management requirements become applicable across the product lifecycle.
The two dates split the compliance problem in half. The first tests whether a vendor can detect, document, and report security events on a regulator’s terms. The second extends cybersecurity obligations into how products are designed, built, and maintained.
Oracle Connects CRA Reporting to Existing Incident Response
Oracle’s preparation for the reporting phase rests on machinery it already operates. The company’s Security Incident Management Policy authorizes the Chief Security Officer organization to direct security event and incident preparation, detection, investigation, resolution, and forensic evidence handling across Oracle’s lines of business, each of which must implement timely corrective actions. The Integrated Cyber Center coordinates security incident response, customer trust, and security communications centrally.
Several of the policy’s operational requirements align with what regulatory reporting demands. Line-of-business incident response programs must investigate and validate that a security event has occurred, preserve evidence and forensic artifacts, document the incident and response activities, escalate events, and notify relevant parties. Oracle maintains formal procedures for chain of custody during investigations and can support legally admissible forensic data collection.
The policy’s scope has a clear boundary. Oracle responds to suspected unauthorized access to Oracle-managed assets, while cloud customers remain responsible for controlling user access and monitoring their own cloud service tenancies through available tooling and logging.
The 2027 Deadline Moves the Focus Into Software Development
The December 2027 requirements reach further back in the product lifecycle, and Oracle points to Oracle Software Security Assurance as its foundation there.
OSSA is the company’s methodology for building security into its products, whether deployed on premises or delivered through Oracle cloud services. Its programs include Secure Coding Standards, mandatory security training for development personnel, automated analysis and testing tools, and vulnerability disclosure and remediation policies delivered through the Critical Patch Update and Security Alert programs.
The Secure Coding Standards illustrate how those practices operate over time. All Oracle developers must apply the standards when designing and building products, adherence is assessed throughout the supported life of Oracle products, and the standards incorporate lessons from continued internal vulnerability testing. Oracle has expanded the standards to cover emerging technologies, including artificial intelligence and machine learning.
Oracle says it is continuing to assess and prepare for the 2027 requirements as implementation guidance and supporting standards evolve, building on its secure development and product security practices.
What This Means for ERP Insiders
Regulatory reporting clocks may run faster than patch cycles. Oracle delivers most fixes through a quarterly Critical Patch Update cadence, while the CRA compels rapid notification of actively exploited vulnerabilities. Regulators could learn of a flaw well before a fix ships, compressing Oracle’s disclosure calculus.
The shared responsibility line is now a compliance boundary. Oracle’s manufacturer reports to EU authorities will cover Oracle-managed assets, not customer tenancies. Customers with their own obligations under NIS2 or DORA cannot assume Oracle’s CRA filings substitute for evidence they must produce themselves.
CRA obligations give buyers new procurement leverage. Vendor security programs like OSSA were previously voluntary commitments enforced only by contract and reputation. Statutory backing lets customers anchor due diligence and negotiations to legal requirements, with regulators supplying enforcement pressure buyers never had.
