Step-by-step: escalate a registrar lock to secure a .app domain

Your .app domain stops resolving overnight. The registrar portal shows a status you did not set. Someone else's contact details appear in the RDDS record. A five-figure ransom demand arrives by email within hours. This is account compromise – and the window to reverse it closes faster than most brand owners expect.

To escalate a registrar lock and secure a stolen .app domain, you must move through three layers in sequence: an immediate registrar hold request, a formal abuse escalation with documented evidence of compromise, and – where the registrar stalls – either a UDRP complaint before WIPO or court-based relief. The .app registry (operated by Google Registry under ICANN accreditation) is a gTLD, so the full UDRP applies and WIPO's expedited track can deliver a decision in roughly one month for eligible cases. Speed is the critical variable; every hour the domain sits in unauthorized hands, its configuration drifts further from your control.

This guide walks each step, names the trap hidden inside it, and identifies when the standard path gives way to a faster or more powerful route.

Step 1: What governs a .app domain dispute – and why it matters before you act

The .app zone is a generic top-level domain, not a country-code zone, so the UDRP and the ICANN Registrar Accreditation Agreement govern both the dispute procedure and the registrar's obligations. That means the recovery toolkit available for a .com is equally available for a .app – including WIPO arbitration, the Forum, and the Czech Arbitration Court (CAC) as forum choices. It also means that ICANN's transfer-dispute and abuse-escalation procedures apply directly.

Why does this matter before you do anything? Because the wrong first move locks you into the wrong procedural lane. Contacting the registrar purely as a customer-service complaint treats this as an account issue; framing it immediately as an ICANN-policy abuse or a UDRP-eligible dispute gives the registrar a legal obligation to act, not merely a commercial incentive to help. We consistently advise clients to open the registrar escalation in the language of the Registrar Accreditation Agreement from the very first communication.

The .app registry also enforces HTTPS across all registrations – a technical detail that becomes relevant later, because a thief who has redirected your domain will have left certificate-transparency logs that can serve as timestamped evidence of unauthorized activity.

The trap in Step 1: Assuming that because this is "just a domain registration problem," ordinary customer support can solve it without legal framing. It rarely can.

Step 2: Freeze the domain – placing and enforcing a registrar lock

A registrar lock (status code clientTransferProhibited, sometimes combined with serverTransferProhibited) prevents the domain from being transferred away from the current registrar while the lock is active. Your first technical objective is to ensure that lock is applied – and applied at both the registrar and registry level.

If you still have any access to the registrar account, apply the lock immediately through the registrar's portal. Document that action with a timestamped screenshot. If account access has been revoked – the more common scenario in a hijacking – you must escalate directly to the registrar's abuse or legal desk, not the standard support queue.

What that escalation should contain:

• Your identity as the registered account holder, with supporting documentation (original registration confirmation email, payment records, earlier WHOIS/RDDS screenshots predating the compromise).
• A clear statement that an unauthorized transfer of account access or domain control has occurred.
• A request for the registrar to apply clientTransferProhibited and hold all pending outbound transfer requests under ICANN's Inter-Registrar Transfer Policy.
• A request to preserve all account-access logs, authentication event logs, and any change-of-registrant records – before any routine log rotation destroys them.

Log preservation is the trap here. Registrars rotate access logs on cycles as short as 30 days. If you spend two weeks in the standard support queue before reaching the legal desk, the access logs showing exactly how the account was compromised may no longer exist. Send the preservation demand in the first communication.

In our practice, we issue this escalation letter on the same day a client contacts us – often within the first working hours of instruction. The letter combines the account-holder identity proof, the lock request, and the evidence-preservation demand in a single document addressed to the registrar's legal or abuse contact, not its helpdesk.

If your .app domain has been moved without your authorization and you are unsure which escalation path fits your registrar, contact info@cognomenlaw.com for an immediate assessment.

Step 3: Document the compromise – what evidence decides the outcome

The strength of your recovery case – whether it proceeds through registrar escalation alone, a UDRP complaint, or court action – rests entirely on the quality of your documentation. Evidence that a panel or court can examine in concrete terms is evidence that moves a case forward. Assertions without records do not.

The core evidence set for a .app domain compromise includes:

1. Original registration records: The confirmation email from the registrar showing you as the registrant, the payment receipts (matching your identity), and the original WHOIS/RDDS printout with your contact data.
2. Pre-compromise RDDS screenshots: Screenshots taken before the incident, preferably with metadata intact, showing your registrant email and nameservers.
3. Access and authentication anomalies: Any email alerts from the registrar about password changes, two-factor authentication resets, or new device sign-ins. Even if you did not consciously save them, check your email archive. Registrars send these automatically.
4. Certificate-transparency logs: Because .app enforces HTTPS, every TLS certificate ever issued for your domain is publicly logged. Tools that query these logs will show you a timestamped history of certificate issuances – including any certificate obtained by the thief after the takeover. This is objective, third-party evidence of unauthorized use, and panels accept it.
5. DNS change history: Passive DNS databases maintain a historical record of nameserver and A-record changes. A sudden change in nameservers, correlated with your loss of access, is powerful evidence of compromise rather than authorized transfer.
6. The ransom or re-sale demand itself: If you received a demand by email, preserve the full email header. Do not delete it. This is frequently the clearest evidence of bad-faith intent.

We regularly advise registrants who underestimate the certificate-transparency record. It runs automatically in the background for every .app domain and costs nothing to query. In a case we handled in early 2025 involving a .app domain in the software sector, the CT log showed a new certificate issued approximately four hours after the account takeover – giving us an exact timestamp to anchor the entire evidence chain.

The trap in Step 3: Waiting to collect evidence until after you have sent the registrar escalation letter. Collect in parallel. Some evidence – particularly passive DNS records that appear in commercial databases – depreciates if the thief returns the nameservers to neutral settings to disguise the compromise period.

How do you choose between a UDRP complaint and court action for a .app hijacking?

For a .app domain, the UDRP at WIPO is usually the faster and cheaper route if the case fits the three UDRP elements of Paragraph 4(a): the domain is identical or confusingly similar to a trademark you hold; the current registrant has no legitimate interest; and the domain was registered and is being used in bad faith. In a post-hijacking scenario, the "bad faith" element is almost always straightforward – the difficult question is the first element, specifically whether you hold a qualifying trademark in the domain string.

The WIPO filing fee for a single-panel case covering one to five domains is USD 1,500. An expedited track can deliver a decision in roughly one month. The standard track runs about two months. The only UDRP remedies are transfer or cancellation – there are no damages, no costs awards.

Court action becomes the right choice in three scenarios. First, where you do not hold a registered trademark in the domain string and therefore cannot satisfy the first UDRP element. Second, where the identity of the thief is known and you want injunctive relief or monetary recovery, not just the domain. Third, where the registrar has refused to comply with the lock request despite a formal escalation and you need a court order compelling registrar action. In those cases, US anticybersquatting litigation – or, for non-US registrars, proceedings in the registrar's home jurisdiction through local litigation counsel in the relevant jurisdiction – may be the only path that reaches the conduct.

There is a middle path worth considering. Where a UDRP complaint is appropriate but the registrar has been unresponsive to the lock request, filing the complaint itself triggers ICANN-required notification to the registrar and typically produces the registrar lock as a procedural byproduct. In our practice, we have used this sequencing – escalation first, complaint filed within days if no response – to achieve the freeze on the domain while the merits proceed through WIPO.

Situation A: You hold a registered trademark, the domain was hijacked within the past few weeks, and you have the evidence set above. Route: registrar escalation simultaneously with a WIPO UDRP complaint; timeline roughly two months to transfer; filing fee USD 1,500 plus legal fees. Situation B: No registered trademark, but you have common-law rights and a documented ransom demand. Route: court action for cybersquatting in the applicable jurisdiction, with a DENIC-style registrar hold request or court-ordered freeze in parallel; timeline longer and cost higher, but monetary recovery is possible. Situation C: Unknown perpetrator, domain already transferred to a second registrar in a different jurisdiction. Route: UDRP combined with a registrar-abuse escalation to both the original and the receiving registrar under ICANN's Inter-Registrar Transfer Policy dispute procedure.

If a prior registrar escalation produced no action, or if the route between UDRP and court is unclear for your .app domain, email info@cognomenlaw.com to weigh the options.

Step 4: File the formal escalation – the inter-registrar transfer dispute procedure

Where the hijack involved a transfer of the domain to a different registrar – not merely a change of WHOIS contacts at the same registrar – the ICANN Inter-Registrar Transfer Policy dispute procedure becomes directly relevant. Under that policy, a prior registrant who disputes an unauthorized transfer can file a complaint with ICANN's contractual-compliance function, and the gaining registrar has a set period to respond and, if the transfer was unauthorized, to reverse it.

Filing this complaint is a distinct step from the registrar-abuse escalation in Step 2. Both should be pursued in parallel. The inter-registrar dispute process is procedurally lighter than a UDRP complaint, but it is also narrower – it addresses the authorization question, not bad-faith use or trademark rights. It does not produce a panel decision that settles ownership permanently.

What the formal escalation filing should include:

• The domain name and zone (.app).
• The losing registrar and the gaining registrar, with their IANA IDs if known.
• The date the unauthorized transfer was noticed and the date it appears to have been executed (from DNS records if no other source is available).
• The identity documentation already compiled in Step 3.
• A clear statement that the transfer authorization was not provided by the registrant of record.

The trap in Step 4: Conflating the inter-registrar dispute with the UDRP complaint. They operate in parallel and serve different functions. Filing one does not suspend or satisfy the other. In active cases, we typically run all three tracks – registrar escalation, inter-registrar dispute, and UDRP complaint – simultaneously, coordinating them so that evidence gathered in one strengthens the others.

Step 5: When does a UDRP complaint under the WIPO rules apply to .app?

The UDRP applies to .app because the zone is a generic top-level domain subject to ICANN's policies, and the registrar for .app registrations will be ICANN-accredited. WIPO, the Forum, and the CAC are all available as forums. WIPO and the Forum together handle the substantial majority of all UDRP proceedings.

In a post-hijacking scenario, the UDRP complaint asserts that the current registrant – whether the thief directly or a downstream transferee – holds the domain with no legitimate interest and in bad faith. The complaint does not need to prove the mechanism of the hijack; it needs to prove the three Paragraph 4(a) elements as they stand at the time of filing. The original registration by you, the trademark holder, is relevant context but is not itself one of the three elements. Panels assess the current registrant's conduct against the Policy.

For single-panel cases covering up to five .app domains, the WIPO expedited track can deliver a decision in roughly one month. The standard track runs about two months. The respondent has 20 days to file a response after commencement. A default – where the thief simply does not respond – does not automatically produce a transfer; the panel still applies all three elements, but panels have consistently noted that a failure to respond, combined with strong complainant evidence, weighs toward transfer.

Forum choice matters at the margin. WIPO has the most developed body of published decisions – useful precedent for post-hijacking scenarios. The Forum is comparable in fee structure and speed. CAC has the lowest entry cost of the three, beginning at roughly USD 500 to 800, which can be relevant where the .app domain at issue has a modest commercial value relative to the filing investment.

What happens after the panel decision – and what can still go wrong?

A UDRP panel order to transfer or cancel does not automatically execute. The registrar implements it, and the standard grace period before implementation allows the current registrant to seek a court stay in the registrar's jurisdiction. In practice, court stays are rare and typically unsuccessful in straightforward bad-faith cases. But the implementation window is real, and the domain is not yours until the registrar confirms the transfer.

After implementation, conduct a full account-security audit before you rely on the recovered domain for any production traffic. The same vulnerabilities that permitted the original compromise may still be present. Change all authentication credentials, enable two-factor authentication, and apply a registrar lock immediately upon recovery.

Certificate-transparency again becomes a tool here. After recovery, monitor CT logs for new certificate issuances against your domain. A new certificate issued after your recovery order but before registrar implementation can signal that the current holder is attempting to exploit the domain in the remaining implementation window.

In a matter we handled in summer 2025 – a .app domain used by a SaaS company, compromised through a credential-stuffing attack – we secured a WIPO transfer order and coordinated with the registrar on implementation timing specifically to close a CT-log monitoring gap the client had identified. The domain was back in verified control within approximately ten weeks of instruction.

The trap in this step: Treating the panel decision as the end of the matter. It is the end of the dispute procedure. Recovery and re-securing are two distinct operations. Do not skip the security audit.

Building a .app domain-recovery record: the evidence checklist

Practitioners and panels both benefit from a structured evidence record. Here is what a complete file should contain at the point of filing a UDRP complaint or opening a court action:

• Original registration confirmation and payment receipts proving registrant identity.
• Pre-compromise RDDS/WHOIS screenshots with timestamps.
• Certificate-transparency log queries covering the compromise period.
• Passive DNS records showing nameserver change history.
• Authentication event emails from the registrar (password reset, 2FA change, new device alerts).
• Any ransom or re-sale demand, with full email headers.
• Trademark registration certificate or evidence of common-law rights in the domain string.
• Screenshots of the domain's current resolution (parking page, redirect, or live site) with timestamps.
• The registrar escalation communications sent under Step 2, with the registrar's responses or non-responses.
• The inter-registrar transfer dispute filing confirmation, if applicable.

This list is not exhaustive. The specific evidence that becomes decisive varies by the facts of the case. But a file that contains all of the above gives counsel the raw material to move quickly across any of the three tracks – registrar escalation, UDRP, or court – without waiting for additional document collection.

Related at COGNOMEN

• Court action and domain theft recovery – when arbitration is not enough
• Step-by-step guide to recovering a hijacked .net domain
• Seeking a reverse domain name hijacking finding in a UDRP defense

Author: Adrian Harland — Court anticybersquatting and domain theft recovery. Meet the team.

Speak with Cognomen Law

For a scoped view of your domain matter, contact info@cognomenlaw.com. Discuss your matter

Domain in disputeYour sideI want to recover a nameI received a complaint — I need a defensePortfolio / brand protectionWhat happenedEmailI agree to the processing of my enquiry as described in the privacy policy.Assess my case

No obligation. Confidential. We reply within two hours in business hours.

This publication is general information and does not constitute legal advice. For advice on your situation, contact info@cognomenlaw.com.