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 and 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’s required

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

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’s required

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

Verification of the registrant email address

Some NIS2-bound ccTLD registries already have their own email verification process in place, where they reach out to 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 Verification process. We’ll make minor copy changes to our Registrant Verification email template, so it can be used for both gTLD and ccTLD registrations.

Where we are responsible for email verification, OpenSRS will verify the email address upon registration, transfer-in, or renewal of the domain. However, registrants only need to respond to the verification email once, regardless of how many domains they renew, transfer, or purchase. 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. 

If we do send a verification request and the registrant fails to respond, it’s likely the domain will eventually be suspended. We will share more about what this process will involve as soon as we’re able.

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 reach out to 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

  • You’ll need to put a process in place to verify the registrant’s name and phone number. We expect that, in the majority of cases, verifying the registrant’s phone number will simply involve checking to see whether it’s correctly formatted. 
  • For a few ccTLDs, you will need to put in place a process to verify the postal address. The forms of verification accepted will depend on the registry but will likely be limited to government-issued IDs, financial statements, or other official documents. 
  • You’ll need to be prepared to send us verification logs that include how and when the data was verified and whether verification was successful. You don’t need to provide the documents used for verification.
  • To reduce the risk that your registrants’ data will be flagged for review, you may want to proactively check the quality of your existing registrant data. 
  • If you’ve customized your Registrant Verification email template, you may wish to update the text once we’ve modified the template. We’ll let you know when the updated template becomes available for review.
  • Some registries are starting to flag inaccurate and incomplete data proactively. If any of your registrants are flagged, OpenSRS will send you an email that outlines the errors in the domain’s data and what you need to do to correct them.

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

EU member states need to transpose NIS2 into law by October 17 2024, so we should have a clearer sense of each registry’s implementation timeline as this date approaches. Typically, there is a buffer period between when a law is passed and when impacted entities need to come into compliance. However, this is not a guarantee.

We’ve put together a list of the European ccTLDs we offer for your reference. Many of them will implement changes related to NIS2 and we will update you as we receive information from our registry partners.

At this point, here’s what we do know. Four EU member states have transposed the directive into law: Belgium, Croatia, Hungary, and Latvia.  

The remaining 23 states will need to transpose the directive into law by 17 October: Austria, Bulgaria, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Ireland, Italy, Lithuania, Luxembourg, Malta, Netherlands, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, and Sweden.

Some of these ccTLD operators have been able to start preparing in advance of finalized changes to their local laws and have provided timelines. For example, DENIC (.de) and NIC.AT (.at), have confirmed that their policy changes will likely take place in March 2025.

Recap and reseller checklist

As NIS2’s October 17 deadline approaches and local laws are finalized, we’ll have a clearer sense of how verification procedures will work across impacted ccTLDs and when the changes—where required—will take effect. For now, here’s how you can start preparing: 

  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. You’ll need to put a process in place to verify the registrant’s name and phone number. We expect that, in the majority of cases, verifying the registrant’s phone number will simply involve checking to see whether it’s correctly formatted. 
  4. For a few ccTLDs, you will need to put in place a process to verify the postal address. The forms of verification will depend on the registry but they will likely be limited to government-issued IDs, financial statements, or other official documents. 
  5. You’ll need to be prepared to send us verification logs that include how and when the data was verified, and whether verification was successful. You don’t need to provide the documents used for verification.
  6. To reduce the risk that your registrants’ data will be flagged for review, you may want to proactively check the quality of your existing registrant data. 
  7. If you’ve customized your Registrant Verification email template, you may wish to update the text once we’ve modified the template. We’ll let you know when the updated template becomes available for review.
  8. Some registries are starting to flag inaccurate and incomplete data proactively. If any of your registrants are flagged, OpenSRS will send you an email that outlines the errors in the domain’s data and what you need to do to correct them.