NIS2 is the updated version of the European Union’s Network and Information Security Directive. It aims to establish “a high common level of cybersecurity across the Union,” partly by providing technical and operational requirements for digital infrastructure and service providers. These include specific requirements for domain registration providers that impact registries, registrars, and resellers. 

This post aims to help our resellers understand how NIS2 will impact the domain industry and OpenSRS platform, plus what action will be required on your part. The information here is not legal advice; you should consider whether you need to seek legal counsel to comply with local laws. We also want to draw attention to the fact that NIS2 includes specific requirements for hosting providers, which is a topic beyond the scope of this post. 

This post covers:

We’ll update this post regularly as EU Member States transpose the directive into local law, and individual registries update their processes accordingly. We’ll also update our resellers and newsletter subscribers via email (you can subscribe here). As always, we’ll provide you as much notice as possible about changes to our platform.

How does NIS2 impact the domain industry?

Article 28 of NIS2 lays out specifics around what domain registration data is collected and how it is disclosed, published, and verified. This sounds simple enough but there are a few complicating factors. The first is that the responsibility of fulfilling the Article 28 requirements is collectively held by “registries and domain registration service providers,” which can be interpreted to include both registrars and resellers. What’s more, the final provision of Article 28 states that “registries and entities providing domain name registration services” must “cooperate with each other” to avoid duplicative data collection. Another challenge is that NIS2 is a directive, not a regulation. It lays out specific results that must be achieved and EU member states must then “transpose” these requirements into their own laws. Each country can interpret the directive’s requirements differently. What does all this mean? We could end up with different requirements for each registry. For example, some registries will take on the task of data verification while others will pass it on to registrars and, by extension, resellers.

Some good news is that NIS2 is expected to primarily impact European ccTLDs. While gTLDs based in Europe do fall under the scope of NIS2, none have indicated they’ll be making changes. Presumably this is because they consider themselves already compliant, a result of the overlap between ICANN’s own contract and policy requirements and NIS2’s requirements. Furthermore, not all registries need to make changes to comply with their local laws; their current policies may be sufficient. We’ll provide more details as we receive information from our ccTLD registry partners and notify you of any additional actions you need to take.

What’s required and what it means for resellers

Article 28 of NIS2 outlines requirements for collecting, verifying, publishing, and disclosing domain registration data. In this section, we’ll break down all four topics but, based on what we know now, we’ll only be asking resellers to take action related to verification.

Data collection

What NIS2 requires

Member states must require registries and domain registration service providers to collect and store accurate and complete registrant data in a dedicated database. The database must include all information necessary to identify the domain name registrant. Specifically, this must include:

  • The domain name
  • The date the domain was registered
  • The registrant’s name
  • The registrant’s email address
  • The registrant’s phone number 
  • The admin contact’s email and phone number, if the admin is different from the registrant

What this means for OpenSRS

OpenSRS already collects this data set, which means there should be no changes to the registration data our resellers need to collect. You’ll continue to provide the same data you do today, whether via the API or Control Panel.

Though possible, it’s unlikely that ccTLD registries will request the collection of additional data elements beyond the set above.

Data verification

What NIS2 requires

Member states must require registries and domain registration service providers to have data verification procedures in place to ensure data accuracy and completeness. Legislators may interpret the word “verified” differently from country to country, which could translate to various accepted verification methods across impacted ccTLDs. Each registry will review its current verification processes against its updated local laws and make additions or modifications as it sees fit. 

It’s also possible that some ccTLDs will start to require the verification of additional data elements, such as the registrant’s postal address, which they already collect but which are outside the scope of NIS2.

What this means for OpenSRS and our resellers

Verification of the registrant’s email address

Some NIS2-bound ccTLD registries already have their own email verification process where they contact registrants directly. We don’t expect these registries to change their existing email verification processes.

Many impacted ccTLD registries will expect the registrar to ensure the email address is verified. To do this, OpenSRS will leverage our existing gTLD Registrant Email Verification process. On April 1, 2025, we will introduce new email and landing page templates for our Registrant Email Verification process. The new templates include minor changes to make the language suitable for both ccTLDs and gTLDs. Specifically, we’ve:

  • Removed mention of ICANN
  • Changed the phrase “will be suspended” to “may be suspended” to accommodate ccTLDs that do not suspend non-compliant domains.

You can view the content of the updated templates here.

If you’ve customized your Registrant Verification templates, your templates will remain unchanged—we won’t switch you over to the new versions. However, if you offer ccTLDs impacted by NIS2, you may wish to update your templates to reflect the changes highlighted above. 

If you have not customized your Registrant Verification templates, your registrants will start receiving the new versions as of April 1.

Where OpenSRS is responsible for Registrant Email Verification—as opposed to the registry themselves— we will:

  • Verify the email address upon registration, transfer-in, or renewal of the domain
  • Only verify each registrant once, regardless of how many domains they have. For example, let’s say the registrant already has a .com domain through OpenSRS. If they then register a .de domain using the same contact record (first name, last name, and email address), our system will recognize them as already verified. We won’t send them an additional verification request.
Verification of registrant name, phone number, and postal address

Most registries plan to take a “risk-based approach” to verification. This means they will request proof of verification on a case-by-case basis, for example, when irregularities are found in the registrant data set. Some will contact the registrant directly, while others will reach out to the registrar. This process is not entirely new. Today, registries regularly contact our compliance team to inquire about irregular or suspicious data and we in turn contact our resellers to confirm its accuracy. However, we’ll see these verification processes increased and expanded in light of NIS2.

Because of this “risk-based approach” to verification and the white-label nature of the OpenSRS platform, the responsibility for verifying the registrant name, phone number, and—where applicable—the postal address will fall to our resellers.

The accepted verification methods may differ from registry to registry but this will be the general process:

1. When registrant data needs to be verified, the registry will either:

  • Reach out directly to the registrant, or
  • Reach out to OpenSRS with a verification request.

2. When the registry contacts us, we’ll contact the reseller and ask them to provide logs to confirm:

  • When the data was verified;
  • What verification method was used; and
  • Whether the verification was successful.

The reseller will not need to provide the documents used for verification—just the logs demonstrating verification was successful.

3. Once we receive the logs from the reseller, we’ll forward them to the registry.

4. If the registrant data cannot be successfully verified, the registry may suspend/delete the domain after a certain period of time. The time allotted will differ from registry to registry.

What resellers need to do

  • Update your Registrant Verification email template: If you’ve customized your Registrant Verification email template, and you offer ccTLDs impacted by NIS2, you’ll want to update your templates to reflect our new suggested language. This can be done within the Messaging tab of your OpenSRS Control Panel.
  • Be ready to verify the registrant’s address and name for certain ccTLDs: Some country-code domains require additional verification of the registrant’s name and/or postal address. The accepted forms of verification may vary by registry, but will generally include government-issued IDs, financial statements, or other official documents.
  • Please ensure you are providing valid registrant phone numbers: Some registries will begin validating registrant phone numbers and flagging those that look inaccurate or incomplete. 
  • Keep verification logs: Be prepared to provide verification logs detailing how and when the data was verified and whether the verification was successful. You do not need to submit the actual documents used for verification.
  • Proactively check your data quality: To reduce the risk that your registrants’ data will be flagged for review, we recommend proactively checking your existing registrant data to ensure accuracy and completeness.
  • Respond to requests to correct registrant data: Some registries have started flagging incomplete or inaccurate registrant data for existing domain registrations. If any of your domains are flagged, OpenSRS will email you detailing the issues and the necessary steps to correct the data.

Data publication

What’s required

Member states must require registries and domain name registration providers to publish non-personal domain registration data in the public Whois. However, we will not do this by default.

What this means

Today, each ccTLD registry operates its own public Whois. In fact, when someone uses Tucows’ Whois Search for a ccTLD, we just pull through data from the registry’s database. However, the data housed in the registry’s database is whatever we provided to them. Today, to comply with GDPR, we send placeholder registrant data to most registries by default as a means to redact the real data. If a specific registry requests that we send the real registrant data, we do so as long as we have a GDPR-compliant contract with them. Some ccTLD registries may decide to request and publish additional data in light of NIS2. However, at this point, none of our registry partners have announced updates to their Whois that would require technical changes from resellers.

Data disclosure

What’s required

Member states must require registries and domain name registration providers to respond to requests to access registrant data within 72 hours.

What this means

This won’t require any action from resellers. OpenSRS currently receives data disclosure requests through our Tiered Access directory. We also receive gTLD requests through ICANN’s RDRS. If legitimate interest is demonstrated, we grant the requestor access to the data via our Tiered Access Compliance and Operations directory. We don’t anticipate any changes to our current disclosure process, though we’ll now need to meet a 72-hour turnaround time for TLDs under the scope of NIS2.

Timelines and TLDs in scope

Many of our European ccTLD registry partners are still finalizing their own policy changes to comply with their local laws.

To help you understand which ccTLDs are affected, and what changes have been announced by the registries, we’ve put together a list of the European ccTLDs we offer. We will update it as we receive more information from our registry partners.

Recap and reseller checklist

We’ll update this checklist as new information becomes available.

  1. Subscribe to our newsletter to receive NIS2-related updates from OpenSRS—if you have an account with us, you’ll receive these automatically.
  2. Consider seeking legal advice to ensure compliance with your local laws, if applicable.
  3. Update your Registrant Verification email template: If you’ve customized your Registrant Verification email template, and you offer ccTLDs impacted by NIS2, you’ll want to update your templates to reflect our new suggested language. This can be done within the Messaging tab of your OpenSRS Control Panel.
  4. Be prepared to verify the registrant’s address and name for certain ccTLDs: Some country-code domains require additional verification of the registrant’s postal address and/or name. The accepted forms of verification may vary by registry but will generally include government-issued IDs, financial statements, or other official documents.
  5. Please ensure you are providing valid registrant phone numbers: Some registries will begin validating registrant phone numbers and flagging those that look inaccurate or incomplete. 
  6. Be prepared to keep verification logs: Be prepared to provide verification logs detailing how and when the data was verified, as well as whether the verification was successful. You will not be asked to submit the actual documents used for verification.
  7. Proactively check your data quality: To reduce the risk that your registrants’ data will be flagged for review, we recommend proactively checking your existing registrant data to ensure accuracy and completeness.

Respond to requests to correct registrant data: Some registries have started flagging incomplete or inaccurate registrant data for existing domain registrations. If any of your domains are flagged, OpenSRS will send you an email detailing the issues and the necessary steps to correct the data.