Blog
August 27, 2025
The European Union's Digital Operational Resilience Act (DORA) represents a major regulatory shift for EU financial institutions (and any financial entities that do business in the EU) with regards to their IT infrastructures. DORA went into effect on January 17, 2025, and impacts how banks, Fintech, insurance, and financial services providers approach Information and Communication Technology (ICT) risk management. The stakes are high: Organizations may face steep penalties, experience operational disruptions, and lose customers to competitors if they cannot demonstrate compliance with DORA.
This blog clarifies how DORA compliance specifically relates to the use of open source software and outlines the critical steps organizations should take concerning legacy systems and end-of-life (EOL) technologies. We'll explore what DORA is, examine specific requirements relevant to OSS, assess the risks of non-compliance, and lay out a strategic plan for meeting compliance.
What Is DORA?
DORA is a regulatory framework that standardizes how financial entities across Europe manage risk across their IT infrastructure. This comprehensive regulation creates uniform standards for digital operational resilience, replacing the patchwork of country-specific regulations that previously governed risk in financial services in the region. Instead of focusing on specific facets of risk management (i.e. data protection, disaster recovery), DORA takes a holistic approach to digital resilience. It covers everything from incident reporting and operational resilience testing to third-party vetting and ICT governance policies.
DORA applies to a broad range of financial institutions, including:
- Banks and credit unions
- Investment firms and asset management companies
- Insurance companies and financial services providers
- Cryptocurrency firms and digital asset service providers
- Third parties that provide ICT products or services to the finance sector (i.e. payment processing software)
The goal of DORA is to create a resilient and stable financial sector in the EU by harmonizing ICT security practices. Digital disruptions can cascade quickly through interconnected financial systems, making comprehensive risk management essential for sector-wide stability.
Back to topHow DORA Impacts Your Open Source Software
DORA's regulations extend comprehensively to all ICT assets, which explicitly includes software components, including open source. Two key articles from DORA's Regulatory Technical Standards (RTS) directly address software management practices that affect open source components:
Article 10: Vulnerability and Patch Management
This article establishes stringent requirements for tracking and managing third-party libraries, including open source components. It requires financial entities to establish procedures for timely identification, assessment, and remediation of vulnerabilities in all software components. Organizations must maintain comprehensive inventories (SBOMs) of all software components, monitor versions continuously, and implement processes for identifying and applying security updates.
Article 16: ICT Systems Acquisition, Development, and Maintenance
Article 16 mandates comprehensive source code reviews, including both static and dynamic testing protocols. Organizations must conduct thorough security testing of all software before deployment, including analysis of third-party components and dependencies.
The regulation requires systematic security assessment processes that evaluate the security posture of all software components throughout their lifecycle. This includes ongoing monitoring and reassessment as threats evolve and new vulnerabilities emerge.
Back to topThe Risks of EOL Software Under DORA
Using unsupported, End-of-Life (EOL) open source software directly conflicts with these requirements. EOL technologies no longer receive security updates or community support, creating a significant compliance gap.
When vulnerabilities are discovered in EOL software, organizations have no supported path to remediation. This situation violates both the vulnerability management requirements of Article 10 and the security testing mandates of Article 16, potentially exposing organizations to regulatory penalties and operational risks.
Deploying EOL open source software in a DORA-regulated environment puts your organization at greater risk for:
Security Exploits
EOL software is a prime target for cyberattacks because new vulnerabilities cannot be patched through official channels. Threat actors specifically target these known weak points, understanding that many organizations continue running unsupported software without adequate protection.
This situation directly violates DORA's resilience mandate, which requires organizations to maintain systems capable of withstanding cyber threats. Operating known vulnerable software fundamentally undermines your organization's security posture and regulatory compliance status.
Failed Audits and Steep Fines
DORA compliance audits will scrutinize ICT systems comprehensively, and unsupported software will be a major red flag for regulators. Auditors will specifically look for evidence of comprehensive vulnerability management and systematic security practices.
Organizations found operating EOL software without adequate risk mitigation measures like third-party LTS face potentially severe financial penalties. The regulation provides for significant fines that can reach substantial percentages of annual turnover, making non-compliance extremely costly.
Reputational Damage
Security breaches or compliance failures can erode customer trust, which is invaluable in the financial sector. Financial institutions depend on public confidence, and regulatory violations can have lasting impacts on market reputation and customer relationships.
The interconnected nature of financial services means that compliance failures can affect not only direct customers but also partners, counterparties, and the broader financial ecosystem. Reputational damage from DORA violations can persist long after immediate compliance issues are resolved.
Operational Disruption
Exploits targeting EOL software can lead to costly downtime, impacting business continuity and violating core DORA principles. The regulation specifically requires organizations to maintain operational resilience, making system availability a compliance requirement.
Unplanned outages resulting from security incidents can have a domino effect on connected systems, potentially affecting multiple business lines and customer services. Recovery from major security incidents often requires extensive remediation efforts that can disrupt operations for extended periods.
Back to topThe Two-Pronged Solution for DORA Compliance
Addressing EOL open source software challenges demands both immediate protection and long-term resilience. This two-pronged strategy ensures compliance while minimizing operational disruption.
Part 1: Immediate Stability with Long-Term Support (LTS)
Long-Term Support is a secure way to maintain EOL open source software through tested patches, bug fixes, and continuous vulnerability monitoring. LTS provides critical benefits for DORA compliance:
Instant Security Gap Closure: LTS immediately addresses the vulnerability management requirements by ensuring access to security updates for EOL software, providing protection against new threats while maintaining system stability.
Regulatory Demonstration: LTS demonstrates to auditors that your organization actively manages risks and maintains comprehensive security practices.
Migration Runway Extension: LTS "buys time" by extending the operational life of critical legacy systems, allowing for well-planned migrations rather than rushed, disruptive transitions.
OpenLogic currently provides LTS for:
LTS for Spring Boot, Spring Framework, Tomcat, and OpenJDK will also be available soon.
Part 2: Expert-Led Migration to a Supported Version or Alternative Technology
While LTS provides immediate stability and threat protection in the short term, the ultimate goal should be migrating to fully supported, modern technologies that align with organizational objectives and regulatory requirements.
Comprehensive Migration Planning: Expert-guided migration planning ensures systematic transitions that account for all technical, operational, and business requirements.
Careful Execution: You can minimize downtime and operational impact through careful planning, testing, and phased implementation.
Full Compliance Achievement: The migration process ensures that new systems meet all DORA requirements and provide enhanced resilience for future regulatory changes.
OpenLogic can serve as a trusted partner for migration services, providing unbiased guidance and technical expertise to ensure successful outcomes.
Back to topFinal Thoughts
DORA compliance is non-negotiable for EU financial institutions, who are facing increased scrutiny around the security and resilience of their mission-critical infrastructures, which almost certainly include open source components. Unfortunately, some organizations only realize they have EOL open source in their stacks after failing an audit or having it turn up on a scan — by which point, the damage is done.
Organizations that are proactive about managing their EOL OSS by securing long-term support and carefully migrating as soon as it is feasible will be better positioned to meet DORA requirements. OpenLogic can help on both fronts — talk to one of our experts today to take the first step toward DORA-readiness.
Additional Resources
- Blog - Security and Compliance Insights from the State of Open Source Report
- Blog - Unpacking Open Source Compliance
- Webinar - Why Open Source Compliance Matters
- Video - EOL Software Risks
- Blog - 5 Ways Perforce Helps With DORA Regulation Compliance
- eBook - Get DORA Ready: Avoid Penalties and Stay Secure