A note from the workshop
Passwordless should not mean exitless.
A passkey can simplify signing in. That does not tell you where the credential lives, what unlocks it, or what happens if the device is unavailable. Today’s job is to draw that dependency chain for one account while everything still works.
Three useful checks
- Find the credential: Identify which device, security key, or credential manager holds the passkey.
- Map the dependencies: Record what unlocks that device or manager without writing down secrets.
- Check an alternate route: Keep a working session open while reviewing supported recovery options.
Put it into practice
Use an account you own on a trusted computer. Open its security settings directly. Google’s passkey documentation distinguishes supported devices and sign-in methods. Read your provider’s equivalent documentation instead of assuming every passkey behaves the same way.
Draw three boxes: account, credential location, and unlock method. Add a fourth for recovery. If every arrow ends at the same phone, note the dependency. A phone-based cross-device sign-in still depends on having access to that phone; a second screen alone is not a spare credential.
Review an already enrolled independent method, or follow the provider’s instructions to add one deliberately. Do not delete working credentials to make the rehearsal convincing. Keep the ordinary session open, stop if a warning is unclear, and use the lost-phone manual for a bounded sign-in test.
A credential and a recovery route are different things
A passkey can improve everyday sign-in while still depending on a device, a credential manager, or another account. Draw those dependencies before deciding that the spare route is independent. Two devices may look like two options but rely on the same synchronized credential store. That can be useful convenience without being a solution to every loss scenario.
Google’s documentation describes supported devices and alternative sign-in behavior, but another service can implement a different recovery policy. Keep the provider’s account rules separate from the place where the credential is stored. A label saying passkey does not tell you everything about device replacement, managed accounts, or what happens after access to the credential manager is lost.
Draw the dependency chain without exposing the key
Use a fictional account label such as personal-mail. Write a simple chain: account → credential manager → devices available to unlock it. Add the documented alternative sign-in or recovery route separately. Record labels and locations, never private keys, passwords, unlock codes, or screenshots of recovery secrets.
Now ask two different questions: what if the phone is unavailable, and what if access to the credential store is unavailable? The answers may differ. A second device that still requires approval from the missing phone is a dependency you should recognize, not a spare route you should assume.
- Open the provider’s security settings directly on a device you own.
- Identify where each listed credential lives and which devices can use it.
- Find the documented alternate route and its prerequisites.
- If an ordinary alternate sign-in is supported, try it on another trusted device while retaining your current signed-in session.
- Stop if testing would require deleting the only credential, disabling protections, or starting an irreversible recovery action.
If the alternate route circles back to the same phone
Record the loop exactly: “The spare laptop can start sign-in, but approval still goes to the unavailable phone.” That is a much better finding than a general note saying recovery configured. Read the provider’s supported alternatives and resolve the dependency while you still have working access. Do not remove a working method first to create the conditions of an emergency.
A managed account may give an administrator a role in recovery. A personal account may have different choices. Avoid copying somebody else’s setup from a screenshot without checking which account type and policy apply to yours.
Keep an evidence-based access map
A useful record names the route attempted, the trusted device used, the date, and the point where it succeeded or stopped. Successful sign-in demonstrates that path under those conditions. It does not guarantee recovery after every future combination of losses. Revisit the map after replacing a phone, changing credential managers, or closing an account it depends on. The object is to remove surprise dependencies while your ordinary sign-in still works.
Know the limits
A supported alternate route depends on the service and account policy. A successful sign-in today is evidence for that route, not a guarantee of future account recovery.
Record one credential location and one independent route using private location labels.
Print the private field sheet. Record actions and observations, not passwords, recovery codes, or private documents.
Keep exploring: the offline AI experiment, lost-phone recovery, or the Recovery Drill.
About this field note
Original CRYPT1K editorial guidance. Sources reviewed October 21, 2026. Procedures are reader exercises; no unperformed hardware, account, or AI test results are claimed. Character and artwork are fictional and AI-assisted.