A passkey can make it harder for an impostor to sign into your account. It does not automatically stop the service operating that account from reading your documents. Confusing those two properties turns a genuine improvement in authentication into a promise the login screen cannot establish.
Suppose a company replaces passwords with passkeys for its document portal. That can be a sensible investment. The separate question is whether the portal stores readable documents, keeps their decryption keys, or receives only encrypted material that a user’s device can open. The login method does not settle the answer.
What WebAuthn actually standardises
The W3C Web Authentication specification describes public-key credentials used in registration and authentication ceremonies. A relying party verifies evidence produced through an authenticator. This is a mechanism for authenticating access, not a blanket statement about how the service handles the content behind that access.
There is an important qualification. WebAuthn’s PRF extension can support designs that derive cryptographic material for application purposes, including client-side encryption. That possibility does not mean every passkey login uses it. An implementation must explain the derivation, recovery and device-change behaviour before the feature becomes evidence about document confidentiality.
Calling all passkeys “only login” would therefore also be inaccurate. The useful distinction is between the authentication protocol and the additional application design built around it. Ask what the deployed service actually does, rather than assuming every supported extension is active.
Draw the two decisions
One decision asks whether this account may request a file. Another asks which component can transform the stored ciphertext into readable content. A service can enforce the first decision carefully while retaining complete technical ability to perform the second.
An imaginary procurement exercise makes the difference clear. Supplier A supports passkeys but decrypts files on its server. Supplier B also supports passkeys and describes client-side decryption with separately managed keys. Both may offer strong authentication. Their confidentiality boundaries are not interchangeable.
This does not make Supplier A fraudulent or useless. Server-side processing may be an explicit requirement for search or collaborative editing. The purchasing error would be to buy that design while believing it excludes the server from readable content.
Recovery is part of the product
Ask what happens after every authorised device is lost. If a help desk can restore account access, determine whether that also restores access to encrypted content. There may be different mechanisms for these outcomes. A recovery document should name them separately.
Then ask how a second device acquires whatever it needs. Does an existing device approve it? Is a separate recovery secret involved? Can the service replace an encryption identity without an existing participant noticing? These questions describe an assessment method, not an allegation about a named supplier.
A practical acceptance test uses synthetic files and a disposable test account. Register a credential, add a second device and exercise the documented recovery path. Record which steps required an existing secret. Successful sign-in proves that the account was recovered; successful file decryption requires a separate observation.
The administrator question
Paweł Makowski’s privacy work repeatedly returns to the intermediary: what can an operator do without the person whose information it holds? For an IT buyer, the answer needs a component-level explanation. Administrative access, the ability to replace software and possession of a content key are distinct powers.
A system may keep content keys away from a storage administrator while still depending on trusted client software. That is a meaningful boundary, but it is not a claim that administrators have disappeared or that compromised devices are harmless. Document the boundary you can demonstrate.
The Bringing Privacy Back analysis of key recovery develops the recovery side of this question. It should be read alongside the authentication design, rather than treated as a competing explanation. Protecting an account and controlling readable content are complementary tasks.
Evidence that earns a purchasing decision
A credible proposal identifies the deployed authentication mechanism, the location of content decryption and the recovery authority. It also provides a safe way to test the claims. A polished screenshot showing a passkey prompt is not a substitute for this evidence.
The UseCrypt technology library is a place to examine the project’s documented approaches. Claims about historical Safe key management should remain separate from claims about current Messenger authentication. A shared brand does not make those implementations identical.
Passkeys deserve adoption on their actual merits. Their success should raise expectations for the rest of the product, not end the inquiry at the login screen. The final question remains who can read the file after the right person has signed in.
