.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.
Related articles
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
- Make sure your brand is configured so the confirmation email and WDRP reminder look like yours, not ours.
- Customize your WDRP template to match your tone and support contact.
- 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
- 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.
- 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.
- 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.
- 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.
- For organization holders — be ready to provide a company-register extract (
company_register) or a formation document (company_statement) if DENIC asks. - 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.