.DE NIS2

DENIC NIS2 — what's changing for .DE domains

Following the EU NIS2 Directive and the German BSI Act, DENIC (the registry for .DE) is rolling out its new holder-data verification model in two phases. Phase 1 changed how holder data is collected and published. Phase 2 introduces risk-based verification with real consequences for unverified domains, including de-delegation and deletion without RGP.

Timeline at a glance

Date Phase What DENIC introduces
28 Jan 2026 Phase 1 Mandatory phone number, PERSON/ORG flag, expanded WHOIS publication, annual holder-data reminder, first-time email verification.
14 Apr 2026 Phase 2 (active) Risk-based assessment on domain requests, on-demand holder verification, quarantine and deletion without RGP for non-compliance.

Phase 1 — what's already in place

Phase 1 is about data quality and transparency. Most of it is handled automatically by Realtime Register on your behalf:

  • Mandatory phone number on all .DE holder contacts (EPP format: +CC.NNNNNNNN).
  • PERSON vs ORG flag — for organizations, holder data is also published in the public DENIC WHOIS.
  • Expanded WHOIS publication — registration date and administering DENIC member are now visible.
  • First-time email verification — when a new holder email is used, a confirmation email is sent. This is the existing Realtime Register contact-validation flow.
  • Annual data review (WDRP) — once per year, holders receive a reminder to confirm or correct their registration data.

✓ What you need to do for Phase 1

  1. Make sure your brand is configured so the confirmation email and WDRP reminder look like yours, not ours.
  2. Customize your WDRP template to match your tone and support contact.
  3. Ensure every new or updated .DE holder contact has a valid phone number and a working email.

Phase 2 — risk-based verification (from 14 April 2026)

From 14 April 2026, DENIC performs a risk assessment every time a domain request touches holder data. Based on the outcome, a domain ends up on a traffic-light scale — green (low), yellow (suspicious) or red (high) — and depending on the colour, DENIC may ask us to provide verification evidence for the domain holder within a strict deadline.

If the verification deadline is missed, DENIC will first de-delegate the domain (remove it from the .de zone), and eventually delete it — without a Redemption Grace Period. Once deleted for this reason, the domain cannot be restored.

Which requests trigger a risk assessment?

DENIC assesses risk on the following RRI requests:

  • domainCREATE — any new .DE registration
  • domainUPDATE — changes to a domain (contacts, nameservers, etc.)
  • domainCHHOLDER — holder change
  • domainCHPROV — provider (registrar) change / inbound transfer
  • domainRESTORE — restoring a deleted domain from RGP
  • contactUPDATE — updating a contact record

Important: even a "routine" nameserver change via domainUPDATE retriggers risk assessment. If the risk assessment flags the domain, the holder needs to be verifiable.

The .DE domain creation lifecycle

Every new .DE registration passes through pendingCreate while DENIC performs its risk assessment. The outcome determines what happens next:

The .DE domain creation lifecycle

Every new .DE registration passes through pendingCreate while DENIC performs its risk assessment. The outcome determines what happens next:

Risk levels — consequences and deadlines

Level Domain status Deadline What happens
Low (green) registered, delegated Business as usual. Verification results on file are success, or risk score is low.
Suspicious (yellow) registered, delegated 14 days Member & holder are notified. If verification succeeds in time → back to Low. If not → domain becomes High and is de-delegated.
High (red) registered, de-delegated (serverHold) 90 days Name servers removed from the .de zone. If no verification → domain contract terminated and domain deleted. No RGP — cannot be restored.

Deadline timeline — from suspicious to deletion

What happens if a flagged domain is not verified in time:

What Realtime Register handles for you

We've built DENIC's requirements directly into the platform. For Phase 2, you can rely on us for the following:

DENIC requirement How Realtime Register handles it
Email verification
claim: email / evidence: email_ver_transaction_log / method: reachability
When a holder email is used for the first time on .DE, our contact-validation flow sends a confirmation email. When the holder clicks the link, we log the event with a timestamp and reference — exactly the transaction log DENIC expects. This is forwarded to DENIC as a successful verification of the email claim.
Annual holder data review Our WDRP reminder is sent once per year, with a link to the holder's stored data and a pointer to the public WHOIS.
Mandatory phone number Enforced at contact creation and update. The platform validates the EPP format and rejects missing or malformed phone numbers.
PERSON / ORG handling & publication We map your contact type to the correct DENIC handle type, so organization holders are published correctly in WHOIS while private individuals stay protected.
Verification block on DENIC requests When verification evidence is available, we attach the [VerificationInformation] block (claims, evidence, method, timestamp, reference, trust framework de_denic) to the relevant contactCREATE / contactUPDATE request.
Deadline & message-queue handling DENIC sends domainStatusUpdate messages when a verification deadline is set. We ingest these, store the deadlines, and surface them so you can act in time.
Audit trail All verification events, confirmation clicks and DENIC responses are retained — DENIC requires evidence retention for 12 months and may audit the process.

Verification methods — what can prove what

DENIC accepts three claims — name, address and email — and defines which evidence (proof documents) combined with which method (how it was checked) can support each claim. Below is the full matrix, aligned with DENIC's specification.

Evidence DENIC value Supports claims Allowed methods
Email reachability — what Realtime Register already performs automatically
Email verification transaction log email_ver_transaction_log email reachability
Identity documents (PERSON holders)
ID card idcard name, address (if on document) auth (eID/eIDAS), vdig (PostIdent), electronic_document, physical_document, bvr (Photo-Ident), pvr (Video-Ident)
Passport passport name vdig, electronic_document, physical_document, bvr, pvr
Population register extract population_register name, address electronic_document, physical_document, bvr, pvr
Residence permit residence_permit name, address electronic_document, physical_document, bvr, pvr
Proof of arrival proof_of_arrival name electronic_document, physical_document, bvr, pvr
Driver's licence drivers_licence name electronic_document, physical_document, bvr, pvr
Organization documents (ORG holders)
Company register company_register name, address electronic_document
Company statement / formation docs company_statement name, address electronic_document, physical_document
Transaction records
Bank account payment record bank_account name data
Online payment account online_payment_account name, address, email data
Address & billing documents
Utility bill utility_account name, address electronic_document, physical_document
Bank statement bank_statement name, address electronic_document, physical_document
Tax statement tax_statement name, address electronic_document, physical_document
Postal verification transaction log postal_ver_transaction_log name, address vdig, reachability
Address database address_database address data
Attestation by already-verified parties
Written attestation written_attestation name, address, email physical_document
Digital attestation digital_attestation name, address, email electronic_document

Note: Our email confirmation flow covers the email claim. For the name and address claims, evidence-based verification (ID card, company register, etc.) is required — this is typically handled on demand when DENIC flags a specific domain.

What you need to do

  1. Clean registration data — for every new .DE order, make sure the holder's name, address, country, phone number and email are accurate and complete. Dummy values or placeholders are the single biggest cause of "suspicious" risk flagging.
  2. Make the customer click the confirmation email — our contact-validation mail is what DENIC accepts as proof of email reachability. If it's ignored, the email claim is unverified.
  3. Brand your outgoing emails — set up your brand and WDRP template so confirmation mails look familiar to your customers and don't get mistaken for phishing.
  4. React to verification requests quickly — when DENIC flags a domain, we notify you. For suspicious domains you have 14 days; for high-risk domains you have 90 days after de-delegation. Verification information (ID card, company register, etc.) must be supplied through our platform within those deadlines.
  5. For organization holders — be ready to provide a company-register extract (company_register) or a formation document (company_statement) if DENIC asks.
  6. Keep holder contact data under control — a holder change (domainCHHOLDER) retriggers risk assessment. The verification deadline follows the current holder and does not reset when the holder changes.

Frequently asked questions

Does every .DE domain require manual verification?

No. Only domains that DENIC's risk assessment flags as suspicious or high require evidence-based verification. For the majority of domains with clean, accurate data, our automatic email verification is sufficient for the email claim and the domain scores low risk.

What's the difference between domainCREATE and domainUPDATE for verification?

Both trigger a risk assessment. A domainCREATE puts the domain into pendingCreate while the assessment runs. A domainUPDATE runs the assessment on the existing domain and can transition it from connect back to pendingCreate if needed. The outcome (low/suspicious/high) works the same way. Holder changes (domainCHHOLDER) and provider changes (domainCHPROV) also trigger assessment.

What happens if a domain is deleted after failing verification?

It's gone. Unlike normal deletions, domains deleted for failed verification are not eligible for the Redemption Grace Period (RGP). The only path back is a new registration once the domain becomes available again.

Can we pre-verify holders before anything goes wrong?

Yes — and we recommend it for business-critical domains. If a contact already has a successful verification on file at DENIC, every subsequent request using that handle is automatically scored as low risk.

Does a multi-holder domain need every holder verified?

Yes. If the domain has more than one holder, every holder contact must be verifiable when DENIC asks.

Is the email confirmation click timestamped and logged?

Yes. We store a transaction log with the timestamp of the confirmation, the event reference and the outcome — this is what DENIC accepts as the email_ver_transaction_log evidence. DENIC requires this evidence to be retained for 12 months.

Questions? If you're unsure whether your setup is Phase 2 ready, or you've received a DENIC verification request and need help responding, reach out to our support team.

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.