Passwordless access designed around devices you control.
DeadArk uses passkeys for everyday sign-in and an ARK KIT recovery path when a new device needs authorization. Security should feel stronger without becoming heavier.
Calm, readable policy pages inside the same system.
These pages should feel authoritative without dropping out of the DeadArk design language. The goal is clarity, not spectacle: stronger rhythm, stronger hierarchy, and direct explanation.
How passkeys help
Passkeys replace reusable passwords with cryptographic credentials protected by your device. That means no password to remember or reuse, phishing-resistant sign-in, and authentication tied more directly to the devices you control.
Everyday sign-in stays simple
DeadArk uses Face ID, Touch ID, or your device PIN for normal entry. The goal is a security model that feels lighter during daily use while still improving protection against common account attacks.
Recovery remains deliberate
ARK KIT recovery words authorize access when a device is unavailable or new. Recovery is separate from daily sign-in on purpose so that emergency access does not become your normal workflow.
Authorize new devices intentionally
A new device should not silently inherit trust. Device authorization is a deliberate step so users can control which hardware participates in their identity.
Trust pages should still route people into the right DeadArk context.
These pages are not isolated legal dead ends. They should explain the rule or safeguard clearly, then point people toward the correct surface for access, security, recovery, or broader system understanding.
DeadArk App
Use the app for sign-in, account recovery entry points, and the broader identity context behind device access.
Route here when the next step is account action rather than only reading about security
Authorize device
Use the device authorization flow when a passkey exists but this browser or device has not yet been approved.
Route here when the problem is a new device or recovery path rather than ordinary sign-in
Security docs
Use Docs when the user needs more exact procedural guidance around passkeys, recovery, or device authorization.
Route here when the next step is reference material rather than direct app action
A secure system should make the normal path easy and the sensitive path deliberate.
That means ordinary sign-in should feel calm and local to the device, while recovery remains explicit and intentional. Users should always understand whether they are signing in normally, authorizing a device, or recovering access.
Help should stay available in context.
If someone asks a security question inside DeadArk, the answer layer should distinguish between routine sign-in, new-device authorization, and recovery. Security help is most useful when it responds from the actual access state instead of repeating generic passkey advice.
Even trust and policy flows should make sense relative to the wider app, the user's active identity, and the focused surface they came from.