NIS2 Compliance

The EU NIS2 Directive is coming into effect, introducing new obligations for both registrars and resellers. In our newsletters, we introduced important updates in our OT&E (Operational Testing & Evaluation) environment on 24th March 2025 that form part of our commitment to the EU NIS2 Directive (repeated below).

The updates are available in live environment since 25th November 2025.

Key Requirements Under NIS2

Article 28 of the directive applies to entities providing domain name registration services, including registrars, resellers, and providers of ancillary services (such as privacy and local presence services). Under NIS2, both registrars and resellers share the responsibility for ensuring that registration data is accurate and complete in our database. This includes essential data elements such as the registrant’s name, contact email address, and telephone number.

Additionally, NIS2 requires registrars and resellers to implement and publish policies to maintain accurate registration data, including adequate verification procedures. The publication of registration details of legal entities will become mandatory.

As a reseller, you have a direct relationship with customers, making your role in data accuracy critical. You are expected to:

• Verify that the data you submit to us has undergone appropriate verification procedures.
• Maintain logs documenting verification for each registrant contact.
• Inform your resellers (if applicable) of these requirements.

Basic Compliance Requirements:

• Ensure all mandatory contact fields (e.g., email, phone number) are correctly provided during domain registrations, transfers, and ownership changes.
• Validate registrant data using format checks (e.g., RFC standards for email/phone, ensuring postal codes have the right number of digits, etc) and verify it where feasible.
• Implement processes to detect and block requests containing incomplete or invalid registrant data.
• Use industry-standard best practice methods (e.g., email, phone, and name verification) to confirm registrant contact details.
• Inform your clients that the use of the Organization field in the registration data may result in the identification of the registrant as legal entity and therefore the publication of their information in the public registration database/query service.
• Keep logs documenting when and how registrant data verification has occurred.

Failure to comply with these requirements may result in:

• Rejection of registration requests.
• Suspension of registered domain names.
• In extreme cases, suspension of your account.

Please note that any fines applied to us by a registry operator regarding unverified registration data supplied by you may be charged to your account.

Upcoming Registrar Enhancements:

We will extend our existing validation and verification processes for gTLD domain names (see: https://kb.centralnicreseller.com/domains/icann/contact-verificationhttps://kb.centralnicreseller.com/domains/icann/contact-verification) to cover all domain registrations and contact data updates on our platform. Additionally, a non-intrusive validation of registrant telephone numbers will be introduced as part of this process. Please see details below.

• Annual registration data reminders (formerly WDRP) will now be sent for all domain names, regardless of the TLD.
• Weekly email reminders to resellers about identified incorrect or incomplete data.
• Introduction of a new optional contact extension to allow self-identification of entity type: X-LEGALFORM.
• Resume partially unredacted publication of registration data of legal entities, as identified by the use of the “Organization” field and the X-LEGALFORM extension.

Contact Verification Details

Additional parameters and responses will be introduced to allow the users to record details on the verification method used. For now, these parameters are optional. We will monitor how the different registries adapt NIS2 and adjust where necessary.

X-VERIFICATION-DATA0..n          = email|phone|name|address
X-VERIFICATION-TRUSTFRAMEWORK0..n = <TEXT> (Entity performing the verification/reseller’s internal trust framework)
X-VERIFICATION-TIMESTAMP0..n     = YYYY-MM-DD HH:MM:SS (Date and time of the verification, in UTC)
X-VERIFICATION-METHOD0..n        = auth|electronic_document|physical_document|vdig|bvr|pvr|data|reachability
X-VERIFICATION-REFERENCE0..n     = <TEXT> (Verifying entity's/reseller's unique reference ID for the specific verification process)
X-VERIFICATION-EVIDENCE0..n      = idcard|passport|population_register|residence_permit|proof_of_arrival|
                                   drivers_license|company_register|company_statement|bank_account|
                                   online_payment_account|utility_account|bank_statement|tax_statement|
                                   written_attestation|digital_attestation|postal_ver_transaction_log|
                                   email_ver_transaction_log|address_database
X-VERIFICATION-RESULT0..n        = success|failed

This change applies to the following API commands:

• AddContact
• ModifyContact
• StatusContact

NIS2 – Email Verification

We are extending email verification to all TLDs, covering both gTLDs and ccTLDs.

This applies to all TLDs, except fulfilment TLDs. Fulfilment TLDs will operate as they are currently.

From 25 November 2025, new domain registrations, transfer-in and owner-changes in the live environment will require email verification to be completed.

From 16th June 2026, email verification are now linked with the contact verification details. Once the email address has been verified, an x-verification-data0=email entry will be automatically added.

NIS2 – Phone Validation

There will be a syntax validation check on international phone numbers to ensure compliance to RFC5733.

Contact telephone number structure is derived from structures defined in [ITU.E164.2005]. Telephone numbers described in this mapping are character strings that MUST begin with a plus sign ("+", ASCII value 0x002B), followed by a country code defined in [ITU.E164.2005], followed by a dot (".", ASCII value 0x002E), followed by a sequence of digits representing the telephone number. An optional "x" attribute is provided to note telephone extension information. From 25 November 2025, this change will be applied to the following APIs in the live environment::

• AddCertificate (SSL API 2.0)
• AddCertificateContact (SSL API 2.0)
• AddContact
• ModifyContact

To ensure a smooth transition, we invite you to test these updates in OT&E ahead of the production rollout.

None of these enhancements should be code-breaking, but they may lead to a higher number of failed transactions if the data quality is low.

We encourage you to review these requirements and ensure your customers are properly informed and the contact data fields are submitted according to the base requirements. This will result in fulfilling the data quality requirements of the registries and avoiding unnecessary transaction failures or domain suspensions/deletions.

Please note that certain EU member states and the TLDs in those jurisdictions may have additional or even stricter requirements. We will inform you about such requirements, including special penalties for failure to comply with those special requirements by newsletter and updates to our TLD appendices when they become available.

For further details on our NIS2 compliance journey, please refer to our previous blog post.

Please note that nothing in this notification constitutes legal advice regarding any responsibilities you may have under NIS2.