The Code establishes baseline cybersecurity requirements across the AI lifecycle and is expected to inform changes to international standards through the European Telecommunications Standards Institute (ETSI). To assist organizations in applying its principles, the government has also released an Implementation Guide, which expands on specific security measures. 

HackerOne offered input during the development of this Code, emphasizing the importance of independent security testing, AI red teaming, and vulnerability disclosure programs (VDPs).  HackerOne’s recommendations, submitted during DSIT’s Call for Views on AI Cybersecurity, highlighted the need for external validation, proactive security testing, and structured vulnerability reporting mechanisms to improve AI security.  

Who is the Code for?

The Code applies to developers, system operators, and data custodians involved in the creation, deployment, and management of AI systems. It sets out security measures covering five key phases: secure design, secure development, secure deployment, secure maintenance, and secure end of life. AI vendors who solely sell models or components without direct involvement in their implementation are not directly in scope but remain subject to other relevant cybersecurity standards.  

How can organizations align with the Code?

The Code introduces 13 principles to safeguard AI from cyber threats, including data poisoning, adversarial attacks, and model exploitation. Organizations that choose to follow the Code need to integrate AI security into system design, assess risks throughout the AI lifecycle, and maintain transparency with end-users. Key provisions include: 

• Ensuring AI security awareness among employees and stakeholders.
• Implementing supply chain security measures to prevent vulnerabilities in AI models.
• Conducting adversarial testing to proactively detect security weaknesses.
• Providing timely security updates and clear communication to end-users. 

How does the Code address Independent Security Testing and Disclosure for AI?

A key focus of the Code is the requirement for independent security validation systems. Developers must ensure AI models undergo security testing before deployment, and the Code stresses the importance of involving independent security testers with expertise in AI-specific risks.

Additionally, the Code mandates the creation and maintenance of a Vulnerability Disclosure Program (VDP) for AI systems. This program is vital for enhancing transparency, allowing security flaws to be responsibly reported and mitigated. 

The Implementation Guide further clarifies these expectations, emphasizing proactive security practices such as red teaming and adversarial testing. These techniques are essential for detecting vulnerabilities before they can be exploited, and the Guide offers practical steps to integrate these evaluations into the AI lifecycle. By following both the Code and the Implementation Guide, organizations can ensure a comprehensive, proactive approach to AI security – focusing on external validation, transparency, and ongoing testing to safeguard systems at every stage. 

What’s the likely impact?

The Code signals a shift toward stronger regulatory expectations for AI security. As cyber threats targeting AI continue to evolve, organizations that adopt these security principles will be better positioned to comply with future standards and regulations, protect their users, and build trust in AI technologies. 

The UK government has stated its intention for this Code to serve as the foundation for future ETSI standards, ensuring a unified and internationally recognized approach to AI cybersecurity. The government also plans to update the Code and the Guide to mirror the future ETSI global standard, reinforcing the alignment with international best practices. 

How HackerOne can help:

Organizations navigating AI security challenges need robust testing and vulnerability management solutions. HackerOne helps organizations align with the Code’s security requirements through: 

• Independent AI security assessments that align with Principles 9.1 and 9.2.1.
• Vulnerability Disclosure Programs (VDPs) to help meet Principle 6.4.
• Red teaming and adversarial testing to identify weaknesses before they can be exploited as mentioned in the Implementation Guide, sections 9.2, 9.2.1, and 11.2. 

Contact HackerOne to learn more about securing your AI systems. 

On January 31, 2025, the UK government published its AI Cyber Security Code of Practice, a voluntary framework aimed at mitigating security risks in AI systems. 

What Does DORA Regulate?

DORA applies to a wide range of financial entities operating in the EU, including banks, insurers, investment firms, and payment institutions, along with critical third-party service providers such as cloud and data providers. Essentially, any organization that provides key infrastructure for financial services will be required to comply with some or all of DORA’s operational resilience standards.

What Does DORA Aim to Achieve?

DORA’s primary goal is to enhance the digital resilience of the EU’s financial sector by ensuring that firms are well-prepared to handle and recover from Information and Communication Technology (ICT) disruptions. The regulation establishes a framework for cybersecurity and operational risk management across financial institutions, focusing on reducing the potential impact of cyber threats and system failures.

What Are DORA’s Security Requirements?

DORA mandates several key cybersecurity and operational resilience requirements for financial entities:

1. Risk Management Framework: Firms must implement comprehensive risk management practices to identify, assess, and mitigate ICT risks.
2. Third-Party Risk Management: Financial entities must ensure third-party service providers adhere to DORA’s security standards, including implementing particular contractual terms and conducting ongoing monitoring and due diligence.
3. Digital Resilience Testing: Firms are required to perform stress tests and regular pentests, in addition to threat-led penetration tests (TLPT) at least every 3 years, based on Regulatory Technical Standards (RTS) for TLPT expected to be adopted by the European Commission in early 2025.
4. Incident Reporting: DORA mandates a clear process for reporting major ICT-related incidents to regulators within specified timeframes.
5. Information Sharing: The regulation does not require but encourages entities to share cyber threat intelligence to bolster collective cyber security efforts across the financial sector.

How Does a Covered Financial Entity Demonstrate Compliance– and What Happens if it Doesn’t Comply?

Covered entities must ensure they meet DORA’s security standards by implementing appropriate risk management practices, third party oversight, and resilience testing. While fines or criminal sanctions are not included in the DORA regulation, individual EU Member States can institute penalties and criminal sanctions in their national laws. These may include fines of up to 2% of an entity’s total annual worldwide revenues or up to 1 million euros and even steeper penalties of up to 5 million for critical third-party ICT providers. Entities must also submit detailed reports outlining their efforts to manage ICT risks, test their resilience, and respond to cyber incidents.

When Do These Requirements Take Effect?

DORA entered into force on January 16, 2023, and the full compliance deadline was January 17, 2025.

What's the Likely Impact of These New Requirements?

DORA’s implementation will likely enhance the overall security posture of the EU financial sector by requiring financial entities to adopt stronger risk management frameworks and resilience practices. The regulation will also increase transparency, as firms must disclose to competent authorities information about their cybersecurity measures and third-party relationships. Overall, DORA aims to ensure that financial institutions are better prepared to handle emerging cyber threats, ultimately protecting consumers and the financial system as a whole.

We Might Be Subject to These New Requirements—What Should We Do?

With the January 17, 2025 deadline already passed, financial entities should review their existing cyber security policies and practices to ensure they meet DORA’s requirements.

HackerOne offers a comprehensive suite of security solutions designed to help financial services organizations meet DORA compliance requirements. Our portfolio includes CREST-accredited Pentest as a Service (PTaaS), Code Security Audits, Bug Bounty programs, and Spot Checks. This integrated approach aligns with DORA's mandates for regular and comprehensive ICT risk assessment and management, as outlined in Articles 24 and 25.

Contact HackerOne to learn more.

The Digital Operational Resilience Act (DORA), which came into force in the European Union on January 17, 2025, establishes comprehensive requirements for the financial sector to strengthen its resilience to ICT-related disruptions, including cyberattacks and technical failures.

Much attention has been paid to the incoming administration’s stated intentions to roll back regulations, as well as their criticism of certain cybersecurity and artificial intelligence (AI) policies adopted by the Biden administration. A more comprehensive review of policy statements and past actions suggests that the Trump administration will support strong cybersecurity defenses and best practices as well as practices that encourage the responsible and trustworthy development and adoption of AI.

The First Months

The new administration immediately put a hold on pending regulations, as is typical. In the first Trump administration and the Biden administration, the new White House Chief of Staff issued on Inauguration Day a memo to the heads of executive departments and agencies to immediately freeze any new or pending regulations to allow review by the new administration. The Trump administration also released a large number of executive orders on his first day of office, though only one addressed AI or cybersecurity in a material way (see below).

We expect that many members of Congress will reintroduce cybersecurity and AI legislation from the previous session, and new legislation on these hot issues will be introduced for the first time. 

Based on precedent, it is possible that Congress will use the Congressional Review Act to reject regulations that have already been enacted by federal agencies. The law, enacted in 1996, has only been used to overturn a total of 20 rules, with 16 of those actions taking place early in the first Trump administration with a Republican majority in both chambers of Congress. To take effect, the Congressional Review Act requires Congress to introduce a joint resolution within 60 Congressional session days of its receipt of the regulation, so only relatively recent regulations are subject to the law.

Cybersecurity Policy and Regulations

CISA

Republican lawmakers and incoming administration officials have criticized the Cybersecurity and Infrastructure Security Agency (CISA). However, these criticisms against CISA are largely not related to cybersecurity, but rather for perceived expansion beyond its core mission of protecting federal and critical infrastructure to address issues such as disinformation. The Republican Party Platform emphasized a commitment to “use all tools of National Power to protect our Nation's Critical Infrastructure and Industrial Base from malicious cyber actors. This will be a National Priority, and we will both raise the Security Standards for our Critical Systems and Networks and defend them against bad actors.” We expect the new administration to refocus CISA on cyber protection and scale back or defund disinformation initiatives, but not to dismantle CISA.

CIRCIA 

CISA is finalizing regulations to implement the Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA), enacted in 2022. The proposed rule requires a wide range of businesses in critical infrastructure sectors to report covered cyber incidents and ransomware payments to CISA. Many of the public comments, including those submitted by members of Congress that had sponsored the original legislation, argued that the draft regulations went beyond the intention of Congress by applying the rule to too many entities, requiring too many cyber incidents to be reported, and not providing enough reciprocity with similar cyber incident reporting regulations. Expect members of Congress to closely review and scrutinize the nature and scope of the final regulations.

Cybersecurity Executive Orders

The Biden administration released its second executive order on cybersecurity in his final week in office. The order focused on improving the United States’ defenses against the escalating threats from foreign adversaries, particularly the People’s Republic of China (PRC). 

The new administration will certainly review all executive orders issued by the prior administration and consider whether to repeal them entirely, repeal them and replace them with their own executive order, or take no action. Given the scope of the order and the new administration’s focus on cyber defense and countering the malicious activities of national adversaries, particularly China, a full repeal without replacement in the short term may be unlikely. It is worth recalling the Trump administration issued its own executive order on cybersecurity in its last day in office, which the Biden administration did not repeal.

Coordinated Vulnerability Disclosure Practices

Coordinated vulnerability disclosure practices, including the implementation of Vulnerability Disclosure Policies and the use of bug bounties by federal agencies have been supported by both the Trump and Biden administrations, are well established in federal agencies, and are unlikely to be rolled back. Russell Vought, who has been nominated to return to his prior role as Director of the Office of Management and Budget, directed federal agencies to implement such programs in a 2020 memo. These practices also enjoy bipartisan support in Congress, which is actively working to pass legislation to require the adoption of Vulnerability Disclosure Policies by federal contractors.

Artificial Intelligence

Both President Trump and President Biden issued executive orders related to AI. President Biden’s order directed over 50 federal entities to take more than 100 specific actions to implement its guidance in areas including safety and security, consumer protection, worker support, and consideration of AI bias and civil rights. Proposed rules resulting from the order include those proposed by the Department of Commerce that would require mandatory reporting to the federal government by leading AI developers and cloud providers. Republicans raised concerns about the order’s reliance on the 1950 Defense Production Act for its authority to require such disclosures, as well as the order’s impact on free speech, innovation, and focus on addressing bias and discrimination. The Trump administration repealed President Biden’s executive order on AI on its first day in office, honoring a commitment made during the campaign. In doing so, he issued his own order to remove barriers to American innovation and “to sustain and enhance America’s dominance in AI to promote human flourishing, economic competitiveness, and national security.” 

While the Trump administration is expected to take a lighter regulatory approach to AI, its past approach through executive order has recognized the importance of regulatory guidance, technical standards, and transparency and trustworthiness to realizing the benefits of AI innovation. As OMB Director, Vought issued guidance to federal agencies for regulation of AI applications, writing that “agencies should continue to promote advancements in technology and innovation, while protecting American technology, economic and national security, privacy, civil liberties, and other American values, including the principles of freedom, human rights, the rule of law, and respect for intellectual property.” The memo emphasized the importance of public trust in AI and the validation of AI systems while encouraging agencies to “be mindful of any potential safety and security risks and vulnerabilities. 

Congressional action on artificial intelligence has been limited to date with the executive branch stepping in to shape government policy and practices related to AI use and regulation. However, Congress and the states show willingness to take this issue up in the coming legislative term. 

Focus Areas for HackerOne and Our Partners

HackerOne’s policy team continues to advocate for the enactment of legislation and regulation that enhances cybersecurity defenses and promotes the responsible adoption and use of AI. This advocacy will continue across administrations and Congresses. Regardless of how the regulatory environment evolves, companies should continue to proactively identify and manage vulnerabilities in their own systems and AI models to protect their assets and maintain the trust of the public, their customers, and investors.

The transition to a new presidential administration and a change in control of the Senate raise questions about how cybersecurity and artificial intelligence (AI) policy and regulation will change and whether such change will be dramatic or more measured. 

HackerOne has partnered with security and AI communities to advocate for stronger legal protections for independent researchers. Most recently, HackerOne participated in a workshop hosted by leading institutions to discuss the need for legal safeguards for third-party AI evaluators and address the gaps in current legal frameworks. Despite the strong push for change, the Librarian’s ruling provided some clarity, but ultimately fell short of granting the full legal protection requested for AI safety research.

What is the DMCA and Why Does it Matter? 

DMCA Section 1201 makes it illegal to circumvent technological protection measures (TPMs) used to protect copyrighted works. Essentially, if software has security features, it’s against the law to break or otherwise bypass them—even for research purposes. 

Every three years the U.S. Copyright Office considers petitions for exceptions to this restriction. In 2015, the security community advocated for and received an exception for good faith security research. This year, HackerOne advocated for broadening this exception. 

While security research has legal protections under the law, it is not clear that the same protections extend to AI researchers. AI research, or red teaming, evaluates AI systems for more than just security - including safety, accuracy, discrimination, infringement, and other potentially harmful outputs. The absence of clear legal protections creates a chilling effect that may deter independent AI testing, which is crucial for the long-term resilience of the digital ecosystem—much like independent security research safeguards organizations by identifying vulnerabilities before they can cause harm.

AI platforms, in an effort to safeguard their systems, may block or ban researchers who attempt to find vulnerabilities or algorithmic flaws. In order to continue their work, researchers are sometimes forced to create new accounts or use proxy servers to bypass these access restrictions. While this circumvention is often necessary for identifying unintended behaviors and improving AI systems, in the absence of clarity around the DMCA 1201 exceptions, it comes with potential legal risk. 

HackerOne joined the effort to request the Copyright Office to grant clear liability protection for good faith AI research under DMCA Sec. 1201. The process took several months and multiple rounds of comments before the Librarian of Congress issued its decision on October 28, 2024.

What Was the Ruling?

The U.S. Copyright Office considered a proposed exemption to the DMCA that would allow researchers to circumvent TPMs in order to test and improve the trustworthiness of AI systems. This exemption would have enabled independent researchers to probe AI models for biases, harmful outputs, and other issues related to fairness and accountability, without the threat of legal action.

However, the Librarian of Congress ultimately declined to grant this proposed exemption. The decision was based on two determinations:

1. Insufficient Evidence: There was not enough evidence to prove that Section 1201 significantly deterred researchers from conducting the necessary red teaming and testing activities on AI models. While many researchers have raised concerns about the legal risks of conducting this type of research, the Copyright Office found that the existing framework of TPM circumvention protections did not present a significant barrier to their work.
2. Non-Circumvention of TPMs: Many of the techniques employed by researchers do not actually involve circumventing TPMs in the way Section 1201 was intended to prohibit. According to the ruling, most of the research methods in question do not technically involve bypassing access controls or security measures, which means they do not fall under the DMCA's anti-circumvention provisions.

The Implications for AI Research

While the rejection of the full exemption for AI trustworthiness research is a setback, it does provide some clarity in certain areas. The decision clearly states that many common testing methods, such as post-ban account creation, rate limiting, jailbreak prompts, and prompt injection, do not violate Section 1201. This clarification is a win for researchers, as it helps to reduce the uncertainty around these techniques and provides more legal confidence to pursue this critical AI research.

However, the ruling ultimately leaves AI researchers operating at times in a legal gray area which may result in an inability or unwillingness to fully test AI systems independently, especially in cases where flaws are deeply embedded in the technology.

As AI continues to evolve and impact all aspects of society, legal frameworks must evolve alongside these technological advancements. The additional clarity provided is welcome, but there is still much to be done to secure stronger, more comprehensive legal protections for good faith AI researchers.

Artificial intelligence is advancing faster than ever, but the legal system is struggling to keep up. A key challenge lies in clarifying how independent AI testing and research intersect with copyright law, particularly under the U.S.’s Digital Millennium Copyright Act (DMCA). In October, in response to advocacy by HackerOne and the Hacking Policy Council, the Librarian of Congress issued a ruling that lessened legal risk for independent AI researchers under DMCA Sec. 1201.

AI adoption is accelerating in the financial services industry, both as an asset for improving business operations and as a potential tool to defend against cybercriminals. At the same time, adopting AI systems expands the attack surface that financial institutions must protect. Within this context, the NYDFS guidelines highlight the need for proactive risk management strategies that encompass the unique challenges posed by AI technologies.

Cybersecurity Risks of AI

The NYDFS guidance outlines several key cybersecurity risks associated with AI, along with strategies for mitigating those risks:

• AI-Enabled Social Engineering: One of the most immediate concerns is AI’s potential to enhance social engineering attacks. With tools like deepfakes—AI-generated media that can mimic real people—attackers can create highly convincing phishing schemes. These attacks may occur via emails, phone calls (vishing), SMS (smishing), or even video conferencing, where the attacker impersonates trusted employees or executives.
• AI-Enhanced Cybersecurity Attacks: AI allows cybercriminals to amplify the potency, scale, and speed of their attacks. With AI, attackers can quickly scan and analyze vast amounts of data, identify and exploit vulnerabilities, deploy malware, steal sensitive information more efficiently, and develop new malware variants or ransomware designed to evade detection.
• Exposure or Theft of NPI: Financial institutions increasingly rely on AI to process sensitive data, including personally identifiable information (PII) and financial records. This growing reliance heightens the risk of exposure or theft of non-public information (NPI), which is protected under the NYDFS Cybersecurity Regulation.
• Supply Chain Vulnerabilities: As financial organizations integrate AI into their operations, they also depend on a range of third-party vendors and partners. This interconnectedness introduces the risk of cyberattacks targeting vulnerabilities within the supply chain, including AI systems or software that may have been tampered with or compromised.

Mitigating AI Cybersecurity Risks: Key Strategies for Financial Institutions

The NYDFS's guidance offers practical advice on how institutions can address these AI-specific threats and integrate them into their existing cybersecurity programs. Here are key strategies from the guidance:

• Risk Assessments and AI-Specific Programs: Under the NYDFS Cybersecurity Regulation, financial entities are required to perform regular risk assessments. According to NYDFS, these assessments must include AI-related risks. This involves not only evaluating the internal use of AI systems but also assessing the AI systems provided by third-party vendors. Institutions should also ensure that their incident response plans, business continuity plans, and disaster recovery strategies are tailored to handle AI-driven risks.
• Third-Party Service Provider Management: Given the interconnected nature of modern financial systems, managing third-party relationships is more critical than ever. Financial institutions must ensure that their third-party vendors—whether they are providing AI-powered services or supporting infrastructure—adhere to the same stringent cybersecurity standards. Regular assessments and audits should be conducted to ensure third-party systems remain secure.
• Access Controls: The NYDFS guidelines emphasize the importance of robust access control mechanisms, ensuring that only authorized personnel can access sensitive AI-driven systems. This includes implementing multi-factor authentication (MFA), role-based access controls (RBAC), and segmentation of sensitive data to reduce the impact of a potential breach.
• Cybersecurity Training: AI’s potential use in social engineering attacks makes cybersecurity awareness training more critical than ever. Institutions should regularly educate their employees about the risks of AI-enhanced attacks and equip them with the knowledge to identify and respond to potential threats. Employees must be trained to recognize the signs of AI-powered phishing attempts and social engineering tactics.
• Continuous Monitoring and Data Management: Financial institutions should implement real-time monitoring tools to detect anomalies and suspicious activities within their AI systems. AI-driven cybersecurity monitoring tools can help track and flag unusual patterns that could signal an ongoing attack or breach. Additionally, effective data management practices should ensure that sensitive data is encrypted, segmented, and protected against unauthorized access.

The Road Ahead: What's Next for AI and Cybersecurity?

The NYDFS's AI cybersecurity guidance underscores the need for financial institutions to proactively incorporate AI considerations into their risk management activities. While the guidelines focus on regulated entities, the risks and strategies outlined are universally relevant to many organizations using AI. As AI technologies become more pervasive, institutions of all sizes must also integrate AI-specific risks into their broader cybersecurity and risk management frameworks.

At HackerOne, we recognize that institutions need more than just traditional cybersecurity measures to address the growing risks posed by AI. That’s why we advocate for proactive, real-world testing through AI red-teaming. 

Red-teaming is a form of adversarial testing that can reveal flaws such as the potential for hackers to bypass AI security protections, as well as algorithmic safeguards against unsafe or harmful output. HackerOne’s red-teaming is driven by a community of ethical hackers whose creativity and expertise help organizations around the world stay safer and more secure. By uncovering AI vulnerabilities and algorithmic flaws early, institutions can take steps to mitigate them before they can be exploited by bad actors.

As regulatory requirements around AI and cybersecurity come into focus, institutions should view the NYDFS guidelines not just as best practices but as business compliance imperatives. Securing AI systems is no longer optional; it’s essential for protecting both organizational assets and customer trust.

The New York Department of Financial Services (NYDFS) issued new guidelines for financial institutions and other regulated entities to address the growing concerns over AI-related cybersecurity risks. While the guidance does not introduce new regulatory requirements, it clarifies how institutions can integrate AI-related risks into their existing cybersecurity frameworks, helping them meet the mandates of NYDFS's Cybersecurity Regulation.

Earlier this year, the Office of Management and Budget (OMB), which establishes budget rules for federal agencies, issued a memorandum on Advancing the Responsible Acquisition of Artificial Intelligence in Government which outlines for both agencies and the public significant aspects of responsible AI procurement and deployment. In particular, OMB’s memo embraced AI red teaming as a critical element of the acquisition of AI for U.S. government agencies.

Rules for U.S. Federal Agency AI Procurement

Last October, the Biden-Harris Administration published an Executive Order on the Safe, Secure, and Trustworthy Development and Use of Artificial Intelligence (AI EO). That expansive action set the tone for the US government’s approach to utilizing AI in a safe and secure manner and required OMB to provide guidance to US government agencies on how to manage risks when acquiring AI products and services.  

Consistent with HackerOne’s long-standing policy advocacy in favor of responsible AI deployment, we provided OMB with comments on how the security and safety best practices championed by HackerOne aligned with the AI EO and should be leveraged in OMB’s development of that guidance. Specifically, HackerOne cited the benefits of conducting AI red teaming, ensuring the transparency of AI red teaming methodology, and of documenting the specific harms and bias federal agencies are seeking to avoid. These suggestions drew on our extensive experience working with government agencies and companies to enhance cybersecurity and our use of similar best practices in testing AI models.

We were pleased to see that the memo reflects our core recommendations:

• Embracing AI Red Teaming: OMB has made it a requirement that agencies procuring general use enterprise-wide generative AI include contractual requirements ensuring that vendors provide documentation of AI red teaming results.

• Identifying Specific Harms: In addition to the categories of risk that vendors include, OMB has encouraged agencies to require documentation to cover AI red teaming related to nine specific categories of risk.  

The inclusion of these elements within the memo will help protect the security and effectiveness of the U.S. federal government by requiring that the AI products and services that undergird critical operations be proactively tested to identify potential risks and harms. It also further underscores the role of AI red teaming as a best practice that all companies should adopt to help ensure the safety and security of their AI products and services and to build the trust of their customers.

Learn more about AI red teaming with HackerOne.

The U.S. government’s approach to evaluating and adopting new technology for its own use often impacts private sector adoption. That’s why it’s significant that, while AI is already having a transformative effect on productivity across industries, the U.S. government is also seeking to harness the benefits of this emerging technology for federal agencies and has now developed criteria to guide its decision making while evaluating AI. As the U.S. government works to apply AI to critical U.S. government operations, it is vital that AI’s power is harnessed safely and responsibly—not only to ensure that the government’s own deployment of AI is secure and effective, but also because of the government’s ripple effect on standards and adoption of AI across all sectors.

The Event

In preparation for the election season, HackerOne planned and executed a unique live hacking event in coordination with the election security group within the Information Technology - Information Sharing and Analysis Center (IT-ISAC). Modeled after HackerOne’s existing live hacking events where technology owners and researchers work together to test targeted assets, IT-ISAC leveraged the collective experience of its advisory board for this first-of-its-kind event. 

HackerOne gladly provided its significant expertise and resources necessary to plan the live hacking event to help secure our elections. Three election technology manufacturers and 15 independent, vetted U.S. security researchers with hardware hacking expertise took part. Over a two-day period, these ethical hackers and election technology providers collaborated to explore potential security issues within election devices, which included controlled access to modern election technology with newly developed and not yet fielded configurations of the on-board software. The devices tested included digital scanners, ballot marking devices, and electronic pollbooks, emphasizing the technology that voters may encounter at a polling site.  In addition to the testing, the various expert stakeholders like HackerOne further enhanced collaboration and disseminated lessons learned across providers through panels and follow-up discussions. 

The Results

In a 48-hour testing window, the ethical hackers submitted 21 reports across the three election technology manufacturers. The attack vectors tested represented a range of election security threats, including ballot box stuffing, scanner denial of service, website URL squatting, and front panel workstation access. The result was more secure products and thus more secure elections, and a strengthened trust between the stakeholders.

This event built on previous efforts to support the adoption of Vulnerability Disclosure Programs (VDPs) by election technology manufacturers. A VDP is a “see something say something” policy that provides a secure channel for third parties to report potential vulnerabilities and security gaps directly to the affected organizations. With the assistance of former election officials, industry, and the security research community, including HackerOne, election technology manufacturers have increasingly implemented this security best practice. While most election technology companies now have VDPs in place, last year’s event brought more access to the various systems and reinforced the security-enhancing value of this collaboration. 

The Future

Following the success of the event, IT-ISAC has focused on updating and modernizing standards to better accommodate VDP and responsible disclosure within the industry and developing a framework for future iterations of this event. Stakeholders are exploring possible future events that aim to include a broader set of researchers, additional companies, and others involved in the election security process, including state and local election officials. This would not only expand the attack surface ethical hackers can test, but also empower them to focus on additional attack vectors. Protecting the integrity of our votes is vital and requires proactive approaches—like getting a bunch of experts in a room together to try to hack hardware—to identify and address vulnerabilities before they can be exploited.

Read the full Election Security Research Forum story >

There is nothing more fundamental to democracy than a free and fair election. Ensuring the security of our elections and election infrastructure requires much more than just vigilance during an election year. Fortunately, ethical hackers have risen to the challenge, strengthening the cybersecurity of our electoral systems over the past several years through collaboration with government and technology manufacturers. Last year’s election security research forum, which HackerOne cosponsored, is an example of this successful partnership.

To help organizations keep up with the shifting landscape of VDP mandates and recommendations, HackerOne has developed the Global Vulnerability Policy Map, an interactive map-based tracker. Users can see at a glance where VDPs are required, recommended, or announced but not yet implemented and click into each jurisdiction for more information.

Scrolling down to the table will show the basic information about each applicable policy. We’ve put together a bit of a primer on the table fields below to help users navigate the high-level policy table.

Field Definitions

Jurisdiction

The jurisdiction that the requirement or recommendation applies to. This is often a country, but it can also be a regional body like the European Union or international (as is the case for some of the standards).

Region

The geographic region in which the jurisdiction is located.

Requirement

Indicates if a particular entry is a requirement or a recommendation.

Policy

The title of the standard, regulation, or law that contains the VDP requirement or recommendation.

Applies to

Many of the listed requirements and recommendations are applicable to a particular type of organization (e.g., IoT device manufacturers).

Users can expand any entry with a click, which will also show the relevant text and provide a link to the original source material.  

Stay On Top of Evolving Requirements

We will periodically update the map and table to help keep organizations aware of the vulnerability disclosure landscape as standards, regulations, and laws increasingly incorporate VDPs. 

If you are looking for help to comply with a new requirement, align with a new recommendation, or adopt a cost-effective security best practice, HackerOne Response provides all the tools needed to launch a successful VDP from a single platform. Our out-of-the-box setup makes it easy to establish a vulnerability disclosure workflow for continuous security. Choose the best option to fit your team’s security goals:

• Essential: Start with a free self-serve VDP solution to follow best practices and help meet compliance mandates.
• Professional: Elevate vulnerability disclosure with advanced features and reporting for proactive security measures.
• Enterprise: Ensure enterprise-grade security and compliance with customizable solutions, dedicated support, and extensive integrations.

Contact us to discover which VDP plan is right for your organization and get your VDP started today.

Organizations are solely responsible for determining if HackerOne Response satisfies their applicable legal and regulatory obligations.

Thousands of organizations have already adopted vulnerability disclosure programs (VDPs) because they work. They are a proven and fundamental best practice that reduces cybersecurity risk. Governments and standards bodies have globally recognized the importance of this best practice, but it’s hard to keep track of these continually evolving requirements.

The CRA will be a game-changing regulation for software and connected product security. The CRA imposes cybersecurity requirements for manufacturers of software and connected products sold in the EU market (regardless of where the manufacturer is located). Below are  some of the requirements around the handling and reporting of vulnerabilities in connected devices and their software: 

1. Establish a coordinated vulnerability disclosure policy (CVD);
2. Address and remediate vulnerabilities without delay, including by developing and maintaining processes to ensure regular testing and provide security updates where feasible;
3. Report “actively exploited” vulnerabilities to their designated Computer Security Incident Response Team (CSIRT) and to the European Union Agency for Cybersecurity (ENISA);
4. Provide a Software Bill of Materials (SBOM) of the most significant software dependencies in the covered products.

The legislative act will next be signed by the presidents of the Council and of the European Parliament and published in the EU’s official journal in the coming weeks. The new regulation will enter into force twenty days after publication with most provisions applying three years after entering into force. Certain requirements like vulnerability reporting will kick in within 21 months.

HackerOne’s advocacy helped drive notable improvements to the CRA, including (1) enhanced protections for good-faith security researchers from mandatory vulnerability reporting and (2) provisions encouraging EU states to protect researchers from liability and ensure they are compensated for their efforts. Unfortunately, the CRA requires product manufacturers to disclose actively exploited vulnerabilities regardless of mitigation status or guardrails for how government agencies may use the vulnerabilities. HackerOne will continue to work with Member States during the implementation process to seek additional safeguards in this process.

For an in-depth understanding of the vulnerability handling and reporting requirements, dive into HackerOne’s summary.

The EU Council adopted the Cyber Resilience Act (CRA) this week. Here’s where we’re headed and what HackerOne believes should happen next. 

NIS2 focuses on strengthening EU resilience through new and amended obligations for cybersecurity risk management practices, incident reporting, and security audits. NIS2 imposes obligations on entities across critical sectors to adopt numerous cybersecurity measures, including controls related to vulnerability management and disclosure. NIS2 also introduces supervisory measures for national authorities in individual Member States, as well as stringent enforcement requirements. 

In addition, NIS2 establishes a framework for coordinated vulnerability disclosure (CVD) across the EU. NIS2 requires EU Member States to create policies for“managing vulnerabilities, encompassing the promotion and facilitation of” CVD, and for each Member State to designate one of its computer security incident response teams (CSIRTs) as a CVD coordinator. 

Brief Background on NIS2

NIS2 builds and expands upon the original NIS Directive, which was introduced in 2016 as the first EU-wide legislation on cybersecurity. Two notable differences from the first iteration of the directive are that NIS2 significantly expands the “essential” and “important” entities to which the directive applies, and imposes administrative fines in the event of non-compliance.

NIS2 applies to public or private entities that provide a service within the EU that is listed in Annex I (Sectors of High Criticality) or Annex II (Other Critical Sectors) of the directive. Under NIS2, the designation of “essential” or “important” is based on a company’s size and the criticality of the services they provide. “Essential” entities are proactively supervised, whereas “important” entities will fall under reactive supervision. 

Under NIS2, entities providing “essential” or “important” services must comply with the same set of 10 cybersecurity risk management measures, such as vulnerability handling and disclosure, testing the effectiveness of security safeguards, and incident response. Some of these measures will be further detailed in the Implementing Regulation (a draft is available here). NIS2 is a “minimum harmonization” law, meaning that Member States can, in some areas, impose additional obligations in their implementing laws beyond those set out in the NIS2 Directive itself. Topics covered by the Implementing Regulation, however, should apply consistently across member states.

For entities found out of compliance with NIS2, administrative fines can reach up to 10 million Euros, or 2% of the company’s annual revenue for “essential” entities, whichever is higher. Notably, NIS2 also mandates personal liability for corporate executives in the event of non-compliance. 

How to Prepare: Security Controls for In-Scope Entities 

Article 21 of NIS2 outlines ten cybersecurity risk management measures to be adopted by in-scope entities. This includes security in network and information systems acquisition, development, and maintenance, as well as vulnerability handling and disclosure. 

A robust vulnerability disclosure process, in addition to regular security testing like penetration testing, will help ensure organizations comply with NIS2, and identify and remediate security weaknesses in their systems more quickly and effectively. Implementing a strong CVD process will also help meet the requirements of any national transposition of NIS2 that go beyond the directive’s requirements, as is the case with the Belgian transposition which actually requires entities to implement a CVD policy. 

As the NIS2 deadline nears, in-scope organizations should take action now by establishing a vulnerability disclosure program (VDP). In September, HackerOne launched Essential VDP — a free, self-serve tier of HackerOne Response, our Vulnerability Disclosure Program (VDP) product. This product will be useful for “essential” and “important” companies that have to apply vulnerability handling and disclosure measures as part of their cybersecurity risk management compliance with NIS2. 

Additionally, in 2023, the NIS Cooperation Group released guidelines for Member States on implementing national CVD policies. The cooperation group is a platform for EU collaboration with representatives from EU Member States, the European Commission, and the European Union Agency for Cybersecurity (ENISA). The guidelines explicitly endorsed vulnerability rewards programs such as bug bounty programs as an impactful means of implementing CVD. 

CVD for EU Member States

As Article 12 of NIS2 outlines, each Member State must designate one of its CSIRTs as a coordinator for a national CVD program. The CSIRT coordinator will identify and contact the entities involved in a vulnerability disclosure, assist those reporting a vulnerability, negotiate disclosure timelines, and manage vulnerabilities that affect multiple entities. 

In addition, ENISA must develop and maintain a European vulnerability database, with “appropriate information systems, policies, and procedures….to ensure the security and integrity of the European vulnerability database.” Mirroring the functions of the U.S.-based National Vulnerability Database (NVD), this EU database will include information describing a vulnerability, the affected products or services, the associated severity, and the availability of related patches and remediation guidance. 

NIS2 Next Steps

The European Commission is expected to issue a finalized Implementing Regulation in the coming days. The Implementing Regulation will provide a consistent EU approach to incident reporting thresholds and cybersecurity measures. At the same time, member states are busy transposing NIS2 into their own national laws, a process known as transposition. 

Transposition of NIS2 presently has a deadline of 17 October 2024. Some Member States, like Belgium, have already achieved transposition, though several other Member States, like the Netherlands, have publicly stated they anticipate a longer transposition process, likely well into 2025. 

It will be important to track the European Commission’s forthcoming publication of the Implementing Regulation, as well as the progress of Member States’ transposition of NIS2 into their national laws. Tracking these and other developments will help businesses know what EU agencies and Member States expect with regard to NIS2 compliance.

Conclusion

Businesses should anticipate that NIS2 will come into effect at the EU-level over coming weeks and months. To help prepare, we recommend that businesses in the EU should determine whether they are in-scope for NIS2, and in which specific Member State jurisdictions. Businesses should work with their IT and compliance teams to determine whether their current security controls meet the risk management measures required under NIS2. HackerOne’s vulnerability management solutions, including our vulnerability monitoring and Essential VDP services, are an excellent way to begin fulfilling NIS2 vulnerability handling and disclosure requirements. 

By strengthening the security practices of important and essential entities, NIS2 will help protect health and safety and ensure critical services are resilient to disruption. HackerOne looks forward to working to achieve a high common level of security across Europe.

The European Union (EU) is poised to take the next step forward on implementing the second Network and Information Security Directive (NIS2). All eyes are now on the upcoming Implementing Regulation, which will detail incident reporting thresholds and cybersecurity measures that will apply to critical sectors across EU member states. As the EU Commission is expected to finalize the Implementation Regulation shortly, organizations can prepare by familiarizing themselves with the major requirements of NIS2.