The End of the Password: Passkeys, WebAuthn and the Anatomy of Phishing-Resistant Sign-In

The Hook: A Secret You Cannot Give Away

Picture an attack that has worked for thirty years and whose success rate does not fall as technology improves — it rises. Someone builds a page that looks like your employer's sign-in form. You type your password. The page relays it in real time to the real service, receives the prompt for the second factor, shows it to you, you type in the six digits from your app, the page passes them along — and at the end the attacker holds a valid session cookie. Your second factor prevented nothing. It merely made the attack four seconds longer.

This pattern is called adversary-in-the-middle, and the relevant tooling has been public, well documented and easy to operate for years. In its World Passkey Day 2026 assessment, Microsoft reports phishing campaigns whose AI-generated text achieves click-through rates as high as 54 percent — more than one in two recipients clicks. At the same time the company cites a remarkable counter-figure: in its own internal environment, 99.6 percent of users and devices have been moved to phishing-resistant authentication.

Those two numbers belong together, because they describe the same finding from two directions. As long as sign-in rests on the user knowing a secret and transmitting it to the other side, the user can be made to transmit it to the wrong other side. No training program changes this structural fact, because it is not a knowledge problem but a protocol problem: the password is a bearer token. Whoever holds it is in. It carries no information about whom it is currently being shown to.

Passkeys invert that property. They replace the shared secret with a key pair whose private half never leaves the device, and they bind every individual sign-in cryptographically to the domain that requested it. The decisive detail is not the biometrics, not the convenience, and not the disappearance of the input field. The decisive detail is that the browser tells the authenticator whom it is talking to, and that this statement is signed along with everything else. A signature produced for login.example-corp.com is worthless on login.example-corp.com.evil.net — not because a filter rejects it, but because mathematically it does not fit.

On 25 August 2026 the W3C published the third edition of the underlying standard, Web Authentication: An API for accessing Public Key Credentials – Level 3, as an official Recommendation. The FIDO Alliance estimates that roughly five billion passkeys are in use worldwide. The topic has therefore left the phase of promises about the future and entered the phase in which architectural decisions have to be made. This article explains the mechanism precisely enough that you could implement it — and then, just as precisely, where it does not protect you.

Part 1: Why the Password Fails — and Why MFA Only Delays the Failure

The Password as a Bearer Token

A password has one property that explains all of its problems: it is a reusable, transferable secret without context binding. Three adjectives, three classes of attack.

Reusable: the same secret is presented again at every sign-in. Whoever observes it once can use it arbitrarily often. A one-time code fixes exactly this property — and only this one.

Transferable: the user has to send the secret to the other side so it can be checked. It therefore necessarily exists, for a moment, outside their head: in the browser, on the wire, in the server's memory. Each of those stations is a place where it can be intercepted or misdirected. Server-side hashing with Argon2 or bcrypt protects the secret after verification, not while it is being delivered to the wrong recipient.

Without context binding: the secret itself contains no information about which service it is meant for. A password manager helps considerably here, because it introduces the context binding after the fact: it only fills the field on the stored domain. But that binding is a convenience feature of the client, not a property of the protocol — and the user can override it at any time by copying the value by hand.

What is remarkable is how good the password is in spite of all this. In 2012, Joseph Bonneau, Cormac Herley, Paul van Oorschot and Frank Stajano presented work at the IEEE Symposium on Security and Privacy that still provides the evaluation framework: The Quest to Replace Passwords. They assessed more than thirty alternative schemes against 25 criteria in three groups — usability, deployability, security — and arrived at a result that has accompanied the industry ever since: not a single scheme dominated the password across all three dimensions. Almost every alternative was more secure but harder to deploy or less convenient. The password does not win because it is good; it wins because in deployability it is close to unbeatable: zero cost, zero hardware, works on every device, every browser, in every country.

The relevance of that paper to passkeys lies exactly there. The interesting question is not whether passkeys are more secure than passwords — that is trivially yes. The interesting question is whether they have overcome the deployability deficit of all their predecessors. That is precisely what the development of recent years has been aimed at, and it is precisely where the compromises made by synced passkeys come from.

Why a Second Factor Does Not Solve the Problem

Multi-factor authentication is often sold as the solution to phishing. It is that only for certain factors. The common schemes fall into two groups whose behavior under attack could not be more different:

The decisive dividing line does not run between "one factor" and "two factors" but between schemes in which the user transmits something and schemes in which the device signs something about the context. Anything you can type, read aloud or tap can be relayed. The term of art in the standards literature is verifier impersonation resistance — resistance to an attacker impersonating the verifying service. NIST has since folded that term into the more common phishing resistance.

Those guidelines, NIST SP 800-63-4, were published in final form in August 2025, superseding revision 3 from 2017. The volume that matters here is SP 800-63B-4 on authentication and authenticator management. It states the requirement sharply for the first time: at Assurance Level AAL2, a verifier SHALL offer at least one phishing-resistant option, and for federal agencies its use is mandatory. At AAL3, phishing resistance is not an option but a requirement — and in addition the private key must be non-exportable. That single clause decides, as we will see, whether synced passkeys are admissible in high-assurance environments.

Part 2: The Anatomy of WebAuthn

Three Parties, Two Ceremonies

WebAuthn describes an interplay of three roles. The relying party (RP) is the service someone signs in to — the web application and its server. The client is usually the browser or the operating system; it is not merely a transport layer but carries the security-critical task of determining the origin of the request and attesting to it. The authenticator is the component that creates and uses keys: a secure enclave in a phone, a TPM in a laptop, a USB security key, or a password manager with passkey support.

Between those roles run two flows that the standard calls ceremonies: registration (navigator.credentials.create()) and authentication (navigator.credentials.get()).

Registration: A Key Pair That Exists Only for This Domain

At registration the server sends a PublicKeyCredentialCreationOptions structure to the browser. It contains, among other things, a fresh random challenge, the RP ID (in practice the domain, say example-corp.com), information about the user account, the accepted signature algorithms, and the requirements placed on the authenticator.

The authenticator then generates a new asymmetric key pair — typically ECDSA over P-256 or Ed25519 — exclusively for this RP ID. It keeps the private key, hands out the public key together with a credential ID as a handle, and optionally an attestation: a manufacturer signature stating what kind of device produced the key, identified by an AAGUID. The server stores the public key, the credential ID and the metadata. It stores no secret. A database breach at the service gives an attacker nothing they could sign in with — a difference from password hashes, which can be attacked offline.

What matters just as much is what does not happen here: biometric data never leaves the device. A fingerprint or face scan unlocks local access to the private key. The service learns only that user verification took place, never how. This is not an implementation habit but a property of the protocol: what travels in the signature is a single flag.

Authentication: Where Phishing Resistance Comes From

At sign-in the server sends a new challenge. The browser provides the authenticator with a data structure the standard calls CollectedClientData, transmitted in serialized form as clientDataJSON. According to the specification it contains:

• type — the kind of ceremony, that is "webauthn.create" or "webauthn.get",
• challenge — the server's random nonce, base64url-encoded,
• origin — the origin of the request as determined by the browser, meaning scheme, host and port,
• crossOrigin — whether the call came from an embedded context,
• optionally topOrigin — for calls from inside an iframe, the origin of the outermost document.

The client hashes this serialization. The authenticator signs the concatenation of that hash and the authenticatorData — the RP ID hash, the flags and the signature counter. The result goes back to the server, which verifies it with the stored public key.

And here is the whole trick, in one sentence: the origin field is not set by the web page but by the browser, and it is signed.

That does not make the phishing attack harder; it rules it out structurally. Let us play it through. An attacker operates example-corp-login.net and proxies everything to the real site. The user falls for it and confirms the sign-in with a fingerprint. Two things now go wrong, independently of each other:

1. RP ID scoping. The authenticator looks for a credential for the RP ID example-corp-login.net. There is none, because the key was registered for example-corp.com. The standard states this as a fundamental property: the RP ID of a credential determines its scope. The sign-in fails before anything is signed at all. The user sees no passkey picker — at best an error.

2. Origin binding. Even if the attacker somehow managed to obtain a signature, the signed structure would read "origin":"https://example-corp-login.net". The real server compares that field against its own expected origin and rejects it. The signature is not reusable, because it carries the context of its creation with it.

You can reduce this mechanism to a formula that recurs throughout cryptography: instead of presenting a secret, produce a proof bound to exactly the circumstances under which it is meant to be valid. It is the same idea as channel binding in TLS, or binding a token to an audience. The security comes not from secrecy alone but from context binding.

Flags, Counters and the Limits of Detection

The authenticatorData contain two flags that are frequently confused in practice. UP (user present) means that a person physically did something — touched the key, tapped the screen. UV (user verified) means the authenticator additionally verified the person, via biometrics or a local PIN. Only UV turns a passkey into a multi-factor proof in NIST's terms: possession of the device plus knowledge or biometrics. Anyone building a relying party has to set that policy deliberately and check the flags server-side — the library does not get it right automatically if you configure userVerification: "preferred" and then never examine the response.

The signature counter (signCount) is supposed to increase on every use per the specification; the server remembers the last value and can infer a cloned authenticator if it goes backwards. In the passkey world, however, this mechanism is largely devalued: synced credentials are deliberately copied to several devices, a monotonic global counter cannot sensibly be maintained across them, and many platform authenticators simply report zero. I am of the opinion that the counter should therefore be treated today as an optional signal: evaluate it when it is non-zero, but do not build a security architecture on it.

Part 3: From FIDO2 to Passkeys — What Changed

Two Standards, One System

FIDO2 is the umbrella term for two related specifications. WebAuthn governs how a web application and a browser talk to each other. CTAP, the Client to Authenticator Protocol, governs how the browser talks to an external authenticator — over USB (HID), NFC or Bluetooth Low Energy. Anyone using only platform authenticators, meaning a phone or laptop with built-in key storage, never sees CTAP; anyone deploying security keys depends on it entirely. CTAP is maintained by the FIDO Alliance and has expanded since version 2.0 mainly around enterprise needs: PIN management, credential management on the key itself, enterprise attestation.

Discoverable Credentials: The Username Disappears

The second technical step toward passkeys is inconspicuous and large in effect. Classic FIDO2 credentials were non-discoverable: the server had to send the browser a list of candidate credential IDs for the account, and for that the user first had to enter their name. Discoverable credentials — formerly "resident keys" — store the account information in the authenticator itself. The server now says only "any credential for this domain, please," and the client presents a picker of matching accounts. The username field falls away, and sign-in becomes a single step.

Exactly this combination — discoverable, platform-backed, convenient — received the marketing name passkey. Technically, a passkey is nothing other than a discoverable WebAuthn credential.

The Real Break: Synced Keys

The point at which passkeys depart from classic FIDO2 thinking is synchronization. Originally, non-exportability of the private key was the central promise: the key is generated in hardware and never leaves it. That is maximally secure and practically unreasonable, because it means: device lost, access lost — which is why everyone needs a second key, which is why almost nobody outside high-assurance environments did it.

The answer is multi-device credentials, colloquially synced passkeys. The private key is stored end-to-end encrypted in a sync service — iCloud Keychain, Google Password Manager, 1Password, Bitwarden — and distributed to the same user's other devices. Losing one device is no longer an exclusion event.

That compromise is precisely the answer to the deployability problem from the Bonneau framework, and one should be honest about what it costs: the trust boundary moves from a piece of hardware to the platform account and its recovery procedure. Whoever takes over the Apple, Google or password-manager account potentially takes over all the passkeys. The phishing resistance of the individual sign-in remains untouched — the attack simply moves up one level.

For a relying party to be able to see that difference at all, the standard introduced two flags: BE (backup eligible) says this credential is in principle syncable, and BS (backup state) says it is currently backed up. BE is immutable over the credential's lifetime; BS can change. A service aiming for AAL3 can refuse credentials with the BE flag set. A consumer service will welcome them, because they lower its support costs.

Cross-Device: Why QR Code plus Bluetooth

That leaves the case of signing in on someone else's computer, where none of your passkeys live. For this, FIDO defines the hybrid transport: the browser shows a QR code, the phone scans it, the actual sign-in then runs over an encrypted tunnel, and the phone signs.

The security-relevant part is unobtrusive and important: in addition to the QR code, a Bluetooth Low Energy message is required as proof of physical proximity. Without that requirement the QR code itself would be phishable — an attacker could display the code of their own session on a deceptive page and have the victim approve the sign-in. The proximity requirement makes remote attacks of this kind ineffective, because the attacker would have to be physically in the room. It is a good illustration of how, in protocol design, a threat analysis turns into a hardware requirement.

Part 4: WebAuthn Level 3 — What the Standard Codified in 2026

Level 3 became a W3C Recommendation on 25 August 2026; the FIDO Alliance commented on the publication at the end of that month. The character of this edition is typical of a maturing standard: it invents little and normalizes much that browsers have long been shipping. An overview of the additions and what they are good for:

Two items deserve emphasis.

Related Origin Requests solve a problem every internationally structured brand has. Because RP ID scoping — the actual phishing protection — is tied strictly to one domain, a passkey for brand.de was unusable on brand.fr. ROR allows publishing, at a well-defined location, a list of related origins permitted to use the same credentials. This is a deliberate, controlled relaxation of scoping, and it should be treated accordingly: that file is a security-critical artifact. Whoever can slip an entry into it widens the scope of other people's keys.

The PRF extension is the conceptually most interesting addition. It allows deriving a pseudorandom function from a passkey and thereby producing key material reproducibly, bound to that credential. The passkey stops being only a proof of identity and becomes a source of keys — the foundation for applications that want to encrypt data client-side and still keep it readable on several devices without the user managing a second passphrase. Anyone who has tried to build end-to-end encryption into a web application knows the point where it always falls apart: where does the key come from, and how does it reach the second device? PRF answers that with "from the sign-in, over the sync infrastructure that already exists anyway."

Part 5: Where Passkeys Do Not Protect You — An Honest Account

An article that stopped here would be advertising. The more interesting questions begin at the edges.

The Downgrade Attack: The Emergency Exit Is the Attack Surface

On 11 August 2025, Proofpoint described a technique that exposes the core of the problem. It does not attack WebAuthn — it goes around it. The attacker operates the usual AiTM proxy but presents itself to the real service as a browser that does not support FIDO2, by manipulating the user-agent string. The service reacts as designed and offers the user an alternative sign-in method. The user, who sees an error and wants to get on with their day, picks the authenticator app. From that moment it is an ordinary phishing attack with ordinary session theft.

Three things matter about this finding. First: at the time of publication Proofpoint had not observed this attack in the wild — it is a demonstrated technique, not an observed campaign. Second: against accounts that use only FIDO it does not work; ordinary phishing tooling simply runs into an error there. Third, and this is the lesson: the security of a sign-in system is the security of its weakest enabled method, not of its strongest. Anyone who rolls out passkeys while leaving SMS codes in place as a fallback has improved convenience and left the security level unchanged.

Account Recovery: The Actual Weakest Link

The same logic applies to recovery. If a service offers passkeys but allows a reset via an emailed link when a device is lost, then the security level of the account is the security level of the mailbox. That is not an implementation bug but a design decision, and it can only be made explicitly: either the account is recoverable over a weaker channel — in which case that channel exists for attackers too — or it is not, in which case some users will be permanently locked out. Synced passkeys soften this dilemma by making device loss less often existential, but they do not remove it.

The Endpoint Remains the Endpoint

Passkeys protect the sign-in, not the session. If an infostealer is running on the machine and reads the session cookie after a successful sign-in, the strength of the sign-in method is irrelevant. Session token theft is a growing class of attack for exactly this reason: it bypasses authentication entirely by starting after it. The countermeasures live on a different layer — binding tokens to the device, short lifetimes, continuous evaluation of signals — and anyone who takes passkeys to be the answer to this class has misunderstood their scope.

The Human Side: What the Empirical Research Shows

In 2020, Sanam Ghorbani Lyastani, Michael Schilling, Michaela Neumayr, Michael Backes and Sven Bugiel presented the first large lab study of passwordless FIDO2 sign-in at the 41st IEEE Symposium on Security and Privacy, under the title Is FIDO2 the Kingslayer of User Authentication?. The result was two-sided and remains instructive: participants were quite willing to accept security keys as a direct replacement for passwords — the handling itself was not the obstacle. The concerns arose elsewhere, namely at the change of factor category: from something you know to something you own. What if I lose it? What if it breaks? Where is my spare?

In hindsight, those findings explain why the industry took the road of synced passkeys rather than hardware tokens for everyone. The study identified an adoption barrier, and multi-device credentials are, at the protocol level, the answer to it. It is a neat example of usability research shaping standards development — and a reminder that the security question "is the key exportable?" and the adoption question "does the user feel up to this?" pull in opposite directions.

Privacy and Linkability

Because a separate key pair is created for every RP ID, passkeys are not linkable across services: two services cannot determine from the public keys that they are seeing the same person. That is a real privacy gain over federated login schemes, where an identity provider observes every sign-in.

Attestation is the point where this can erode. An AAGUID identifies not an individual but a device type or a credential manager — harmless in isolation, a contribution to fingerprinting in combination with other traits. The standard has always been aware of this and treats attestation as something requested deliberately, not as the default. For enterprise environments that must demonstrate only managed hardware is in use, attestation is indispensable; for a consumer service, attestation: "none" is usually the right and more data-frugal choice.

Part 6: Putting Passkeys into Practice

What the Relying Party Has to Store

If you implement this yourself — and mature libraries exist for C#, TypeScript and Python, so you should not write the cryptography yourself — you need essentially these fields per credential:

The recurring implementation mistakes are remarkably consistent: challenges are not stored server-side and therefore not genuinely checked for single use; the origin field is never examined; userVerification: "required" is requested but the UV flag in the response is ignored; and the expected RP ID is derived from the request instead of being configured statically. Every single one of those mistakes cancels exactly the protection the scheme was adopted for.

Four Decisions You Have to Make Deliberately

1. User verification: required makes the passkey a multi-factor proof and is the right choice for anything that is meant to look like AAL2. preferred is more convenient and may yield only proof of possession.
2. Attestation: none for consumer services, direct or enterprise attestation where managed hardware must be demonstrated.
3. Allow synced credentials? For consumer services yes, because they carry adoption. For systems with an AAL3 claim no — SP 800-63B-4 excludes exportable private keys there.
4. Fallback path: the most important and most frequently skipped decision. A second passkey on another device is a good fallback. An SMS code is not a fallback but a repeal of the scheme.

Migration Without a Cliff

The workable path to adoption uses exactly the Level 3 features from Part 4. Conditional Get brings passkeys into the existing sign-in form without rebuilding it. Conditional Create silently creates a passkey after a successful password sign-in, so the installed base grows without anyone clicking through a wizard. The Signals API keeps the account settings page and the credential manager in step, so deleted accounts leave no orphaned entries behind. And only once an account has two independent passkeys does it make sense to actually disable the password for that account — not before.

The Regulatory View

For European contexts, one distinction is worth drawing that often blurs. Passkeys are an authentication scheme: they prove that the same key holder as at registration is present. They say nothing about who that is. Schemes around eIDAS 2.0 and the EU identity wallet solve the other half of the problem: verified identity attributes with selective disclosure. The two do not exclude each other, they interlock — a wallet itself needs phishing-resistant sign-in, and a service that must have age or residence established gets nowhere with a passkey alone. When reading requirements, keep the question "which key?" separate from the question "which person?".

Part 7: The Underlying Principle

Step back, and the story of passkeys is a lesson in a particular way of solving security problems. For thirty years, phishing was treated as a behavioral problem: training, warning banners, simulated attacks, green address bars. Success was modest, because people were being asked to perform reliably a task they are not built for — comparing strings under time pressure.

WebAuthn treats the same problem as a protocol problem and moves the task to where it is easily solved: the browser knows with certainty what domain it is on. That certainty is pulled into the signature, and with it the decision the human cannot make disappears from the flow.

This pattern — do not request a security property, enforce it structurally — recurs throughout computing. Type systems do not make a class of errors less likely, they make them inexpressible. Memory-safe languages replace discipline with a guarantee. Capability-based security models replace access lists with unforgeable references. And in cryptography it is, again and again, binding to a context that makes a proof non-transferable.

The Central Takeaway

The practical lesson: the phishing resistance of a passkey lies neither in the biometrics nor in the disappearance of the input field, but in a single signed field that the browser sets and the server must verify — and it is exactly as strong as the weakest sign-in method left enabled beside it.

Four steps follow from that, and they work in any project. First: inventory every enabled sign-in and recovery path for privileged accounts and write next to each whether it is phishable — that list, not the existence of passkeys, describes your actual security level. Second: in your own implementation, explicitly verify four things — single use of the challenge, origin, the RP ID against a static configuration, and the UV flag in the response. Third: decide deliberately whether synced credentials are permitted, and derive the decision from the required assurance rather than from instinct — the BE and BS flags are what make it enforceable in the first place. Fourth: disable an account's password only once two independent passkeys are registered, and use Conditional Create to get there without pushing users through a wizard.

A Question to Think About

Synced passkeys traded a security promise for an adoption promise: the private key is no longer non-exportable, but billions of people use it. Measured in total harm, that is very probably the right trade — a moderately protected key everyone uses prevents more account takeovers than a perfectly protected one nobody has.

The question that follows is less comfortable than it sounds: this calculation shifts the residual risk from the many onto the few whose accounts are attacked individually and deliberately — and it ties the security of almost every sign-in to a handful of sync providers. Who in your organization actually decided which accounts belong in the first category and which in the second? Because in practice that decision is not made in a risk workshop. It is made implicitly, the moment someone enables the same authentication policy for every user group.

Cross-References in the Vault

• The Key That Dies After Every Message: The Signal Protocol, the Double Ratchet, and the Art of End-to-End Encryption – asymmetric cryptography serving the same idea: keys that are never transmitted, and security through binding rather than secrecy alone.
• The ID That Stays Silent: eIDAS 2.0, the EU Identity Wallet, and the Art of Revealing Only What Is Needed – the other half of the problem: passkeys prove continuity, wallets prove identity attributes.
• Proving Without Revealing: Zero-Knowledge Proofs from Ali Baba's Cave to zk-SNARKs – the same principle taken to its radical conclusion: producing a proof without showing the secret.
• Harvest Now, Decrypt Later: Post-Quantum Cryptography and the Race Against the Quantum Computer – why the signature algorithms behind WebAuthn have a limited shelf life and algorithm agility belongs in the data model.
• The Backdoor at the Heart of Linux: The XZ Attack and the Anatomy of a Supply-Chain Compromise – the attack that goes around authentication by altering the trust chain underneath it.
• Bits That Flip on Their Own: Rowhammer and the Physical Weakness of Computer Memory – a reminder that "the key never leaves the hardware" is a statement about hardware, which remains attackable itself.
• When the Processor Guesses Too Much: Spectre, Meltdown, and the Sin of Speculative Execution – the same lesson one layer down: security that rests on an abstraction ends where the abstraction leaks.

Sources

• W3C (2026): Web Authentication: An API for accessing Public Key Credentials – Level 3. W3C Recommendation, 25 August 2026. Editors: T. Cappalli, A. Kumar, E. Lundberg, M. Miller, Pascoe, N. Satragno. https://www.w3.org/TR/webauthn-3/
• FIDO Alliance (2026): WebAuthn Level 3 Is Now a W3C Recommendation. 31 August 2026. https://fidoalliance.org/webauthn-level-3-is-now-a-w3c-recommendation/
• National Institute of Standards and Technology (2025): Digital Identity Guidelines – Authentication and Authenticator Management. NIST Special Publication 800-63B-4, part of the NIST SP 800-63-4 suite, published August 2025. DOI: 10.6028/NIST.SP.800-63-4. https://pages.nist.gov/800-63-4/sp800-63b.html
• Lyastani, S. G., Schilling, M., Neumayr, M., Backes, M., Bugiel, S. (2020): Is FIDO2 the Kingslayer of User Authentication? A Comparative Usability Study of FIDO2 Passwordless Authentication. 41st IEEE Symposium on Security and Privacy (SP '20). https://publications.cispa.saarland/3146/
• Bonneau, J., Herley, C., van Oorschot, P. C., Stajano, F. (2012): The Quest to Replace Passwords: A Framework for Comparative Evaluation of Web Authentication Schemes. IEEE Symposium on Security and Privacy 2012, pp. 553–567. DOI: 10.1109/SP.2012.44. https://www.cl.cam.ac.uk/~fms27/papers/2012-BonneauHerOorSta-password--oakland.pdf
• Proofpoint (2025): Don't Phish-let Me Down: FIDO Authentication Downgrade. Threat Insight, 11 August 2025. https://www.proofpoint.com/us/blog/threat-insight/dont-phish-let-me-down-fido-authentication-downgrade
• Jakkal, V., Abdo, N. (2026): World Passkey Day: Advancing passwordless authentication. Microsoft Security Blog, 7 May 2026. https://www.microsoft.com/en-us/security/blog/2026/05/07/world-passkey-day-advancing-passwordless-authentication/

← All articles