Passkey Rollouts: How to Manage Client Access Without Storing Passwords
For over two decades, the web agency playbook for client access barely changed. Onboard a new client, collect a set of admin usernames and passwords, drop them into a password manager (or, too often, a spreadsheet), and hand out access across design, development, and maintenance staff.
That model is now running into a real wall — just not as fast, or as evenly, as agency marketing tends to suggest.
Major platforms are moving toward passkeys built on the FIDO2 and WebAuthn standards, and the pace differs a lot by vendor. A passkey relies on asymmetric public-key cryptography: the private key stays inside a device's hardware enclave or biometric vault and can't be copied into a Slack message or pasted into a standard password field the way a text password can.
You cannot copy and paste a developer's fingerprint or Face ID scan across an agency team.
As more clients adopt passwordless options to cut down on phishing and credential-stuffing risk, agencies need a plan for managing hardware keys, delegated roles, synced vaults, and access records — without ever holding a client's actual password. This guide covers the real architecture options, where major platforms actually stand as of September 2026, and how a lightweight record-keeping tool like InstaRenewal fits into that picture (and where it doesn't).
1. The Death of Shared Passwords: Why the Shift Matters
| Parameter | Traditional Passwords | Passkeys (FIDO2 / WebAuthn) |
|---|---|---|
| Secret model | Shared secret (user and server both know it) | Asymmetric key pair (private key stays on device, public key on server) |
| Phishing vulnerability | High — users can be tricked into typing secrets into fake forms | Much lower — credentials are cryptographically bound to the real site's domain |
| Shareability | High — can be copied, emailed, or dropped into a shared vault | Restricted — bound to a specific authenticator (device or hardware key) |
| Agency risk | High liability if a shared password vault leaks | Lower liability, since the private key never leaves the device — but a lost hardware key or misconfigured vault is now the failure mode |
When a client turns on passkeys for a primary identity provider — a Google Workspace account, Microsoft Entra ID, Cloudflare — they may no longer be able to hand you a plain password at all. If your onboarding workflow assumes a shared text credential for every root account, that workflow breaks the moment a client makes that switch. But as the next section shows, "major platforms have gone passwordless" is an oversimplification — support ranges from fully enforced to barely there.
2. Three Architectural Options for Agency Passkey Access
How does a multi-person agency team get administrative access to a client's site, registrar, host, or DNS panel once passkeys are involved? There are three broad patterns.
Architecture A: Enterprise Synced Passkeys (1Password, Bitwarden, etc.) Modern business password managers can store and sync WebAuthn passkeys inside a shared team vault, so authorized staff can each authenticate with their own device unlock. This works well for convenience but comes with a real trade-off: synced, cloud-backed passkeys are generally treated as meeting NIST's Authenticator Assurance Level 2 (AAL2), not the stricter AAL3, because the private key material is exportable and moves through a cloud sync service rather than staying locked to one piece of hardware.
Architecture B: Hardware Key Delegation (YubiKeys and similar) For high-value infrastructure — root domain registrars, cloud provider root accounts — agencies provision dedicated hardware security keys and register them as a client's passkey. This is the strongest option, but the "AAL3-compliant" label doesn't automatically apply to any hardware key. NIST SP 800-63B ties AAL3 to non-exportable, hardware-backed authenticators used in a properly configured environment. A standard YubiKey 5 Series device is FIDO2-certified and phishing-resistant, but formal AAL3/FIPS-grade compliance in regulated environments currently points specifically to Yubico's FIPS-validated line: the YubiKey 5 FIPS Series was certified to FIPS 140-3 in May 2026 (NIST Certificate #5291), with the older FIPS 140-2 certification scheduled to move to NIST's Historical List on September 22, 2026. Yubico's own guidance also notes that Chromium-based browsers currently lack the verifier-impersonation resistance needed for a full AAL3 deployment over WebAuthn alone — a detail that matters for agencies serving government or other AAL3-mandated clients, and one that's easy to miss if "YubiKey" and "AAL3" get treated as automatically synonymous.
Architecture C: Native Delegated Identity / Role-Based Access Instead of sharing a primary account at all, the client invites individual agency staff into the system directly — via federated SSO, an organization role, or a partner-delegation model — so each person authenticates with their own identity. This isn't hypothetical: Microsoft has been moving its entire partner ecosystem this direction. Partners who manage client Microsoft 365 or Azure tenants used to get broad, largely permanent access through Delegated Admin Privileges (DAP). Microsoft has phased this out in favor of Granular Delegated Admin Privileges (GDAP), which requires the client to explicitly approve narrower, workload-specific roles — often time-bound — instead of blanket admin rights, and it's now a mandatory model for Microsoft's Cloud Solution Provider partners. It's a real, already-mandatory example of exactly the "stop sharing the primary account" pattern agencies are being pushed toward everywhere else.
3. Where Major Platforms Actually Stand (as of September 2026)
The idea that "Google, Apple, Microsoft, WordPress, Shopify, Cloudflare, and AWS" have uniformly gone passwordless doesn't hold up well under scrutiny. Here's the more accurate, current picture:
- AWS: Root-user MFA has rolled out in stages — management-account root users in May 2024, standalone-account root users in June 2024 (when AWS also added FIDO2 passkey support as an MFA method), and all remaining AWS Organizations member-account root users by June 17, 2025, with a 35-day grace window per account. AWS discontinued its free MFA hardware security key giveaway program in November 2025; passkeys and third-party keys remain fully supported.
- Google Workspace: Passkey support is generally available to Workspace's full customer base, and admins can require "security key only" or restrict enrollment to physical keys for privileged accounts. Google's Advanced Protection Program goes further, requiring a physical security key or equivalent for enrolled high-risk accounts.
- Microsoft 365 / Entra ID: Supports FIDO2 security keys and passkeys directly, and — as noted above — GDAP is now the standard delegated-access model for partners managing client tenants.
- Shopify: Merchant admin accounts have supported passkey login since late 2024, but it sits alongside password login as an option rather than replacing it outright. Agencies managing client stores as Shopify Partners log in through a separate Partner Center account, not through the store's own passkey-enabled login.
- Cloudflare: Supports WebAuthn/hardware security keys, but as a two-factor method layered on top of a password — as of late 2025, users were still publicly asking Cloudflare for a true single-step, password-free passkey login. Treat Cloudflare today as "hardened with a strong second factor," not "fully passwordless."
- WordPress: Core WordPress has no native passkey login. Getting there requires a maintained third-party plugin (options include WP-WebAuthn, Multipasskey, and others), typically requiring WordPress 6.0+, PHP 7.3+, and an active HTTPS certificate — meaning WordPress passkey support is really "plugin support," and only as good as the plugin an agency chooses and keeps updated.
- Domain registrars: This is the most uneven category of all. Cloudflare Registrar and Spaceship (Namecheap's newer registrar brand) support WebAuthn/passkey login. GoDaddy's strongest available factor in most comparisons is an authenticator app, with SMS as a fallback — no hardware security key option in the mainstream flow. In other words, "enforce hardware passkeys at the registrar" is a real option for some agency clients and simply unavailable for others, depending on who they're registered with.
The practical takeaway: an agency's access-governance policy can't assume uniform passkey support across a client's stack. It has to be checked per platform, per client, and revisited as vendors change their support — which is precisely the kind of thing that's easy to lose track of without a record somewhere.
4. Operational Risk: The Physical Key & Identity Governance Gap
As agencies mix these three architectures across dozens of clients, the primary risk shifts. It's no longer "did a password leak" — it's "does anyone actually know who holds the physical key, which vault has the synced credential, or which agency email is still tied to an active client account."
A few scenarios worth planning for:
- The offboarded contractor. A freelancer's password-manager access gets revoked when the contract ends, but a personal YubiKey they registered directly against a client's hosting panel during an emergency fix never gets removed. The freelancer keeps working access indefinitely, and nobody notices until something goes wrong.
- The missing hardware token. A client's DNS breaks on a weekend, and the one registered hardware key for that registrar account is sitting in a locked drawer at the office.
- Silent policy changes. A client tightens their own Entra ID or Okta passkey attestation policy and revokes authenticators that no longer meet it. The agency's access breaks quietly, and it's often only discovered during a live outage.
None of these are password-database breaches. They're record-keeping failures — nobody wrote down who has what, or the record went stale.
5. Building an Agency Passkey & Governance Matrix
A workable SOP routes access requests by account criticality, and it should route around the platform gaps covered in Section 3 rather than assume every client system supports the same options.
+-----------------------------------+
| New Client Onboarding Request |
+-----------------------------------+
|
Is the system RBAC/SSO capable?
/ \
YES / \ NO
/ \
v v
+----------------------------------+ +----------------------------------+
| Architecture C: RBAC / delegated | | Can a passkey be synced to a |
| roles (e.g. GDAP-style invite) | | team vault? |
+----------------------------------+ +----------------------------------+
/ \
YES / \ NO
/ \
v v
+----------------------------------+ +----------------------------------+
| Architecture A: Synced passkey | | Architecture B: Hardware key |
| in a shared team vault | | (verify AAL3/FIPS status if the |
| | | client actually requires it) |
+----------------------------------+ +----------------------------------+Protocol by account tier:
- Tier 1 — Domain registrars, root DNS, root cloud accounts: Prefer device-bound hardware keys or direct SSO where the provider supports it. Note that not every registrar offers a hardware key option yet (Section 3), so this tier's policy needs a per-client checklist, not a blanket assumption.
- Tier 2 — Production hosts, CMS admin, CDN controls: Synced team-vault passkeys or delegated sub-accounts are usually workable here.
- Tier 3 — Plugins, marketing tools, analytics: Individual delegated invites (agency staff added directly by the client) are usually sufficient; a central passkey isn't necessary.
6. Where InstaRenewal Fits — and Where It Doesn't
It's worth being precise here. InstaRenewal is a renewal-date and asset-ownership record-keeping tool for agencies — it tracks domains, SSL certificates, hosting accounts, and plugin or software licenses, along with who owns each asset, who's responsible for paying for it, and when it's due to expire. Its own privacy documentation is explicit that it isn't built to hold passwords, API secrets, or private keys, and instructs users not to put them into its notes or asset fields.
That means InstaRenewal is not a credential vault, not a WebAuthn/AAGUID verification system, and not an automated security-audit or live-monitoring tool. It won't detect a registered hardware key, verify an attestation certificate, or generate a compliance report proving a client's systems are password-free. Nothing on the market that's primarily a renewal tracker does that, and it's worth being skeptical of any tool that claims otherwise.
What it's actually useful for in this context is more modest, and still genuinely helpful: giving an agency one place to write down, in plain language, how access to each client asset currently works — alongside the renewal date it's already tracking. A record for a client's domain registrar might note the provider, the renewal date, who owns the account, and a short access note such as "hardware key held by Alex R., backup key in office safe" or "agency accesses via GDAP role, reviewed quarterly." That's a manual note field, not a live security feed — but it turns "who has access to what, and does that need to change" from a question that lives in one person's head (or an outdated spreadsheet) into something the whole team can check.
That's also where it helps during offboarding: when someone leaves the agency, scanning the access notes across every client asset gives the team a starting checklist of accounts to review — a manual prompt, not an automated cross-referenced audit.
7. Implementation Plan: Moving an Agency Toward Passwordless Access
Month 1 — Infrastructure Procure FIDO2-certified hardware keys for core staff who need Tier 1 access (and confirm which specific model you need if a client requires FIPS/AAL3 compliance — a standard key and a FIPS-validated key are not interchangeable). Deploy or confirm a business password manager with passkey/WebAuthn support for Tier 2 vaults. Set up InstaRenewal asset records for existing client accounts and add a short access-model note to each one.
Month 2 — Client communication Update onboarding documentation to reflect the new standard, and let existing clients know the agency is moving away from requesting or storing plain-text passwords, and will instead ask to register a hardware key, issue an RBAC invite, or use a synced vault entry depending on the system.
Month 3 — Legacy cleanup Audit old password vaults account by account. Where the underlying platform supports it (checking against Section 3, since not all do yet), migrate to a passkey or delegated-role model and remove the old text password. Update the access note on the matching InstaRenewal record so the change is visible going forward.
8. Conclusion
The shift away from shared client passwords is real, but it's happening unevenly — some platforms already enforce phishing-resistant hardware keys for privileged accounts, others still top out at an authenticator app, and a few (WordPress core among them) haven't moved at all without a third-party plugin. An agency's job isn't to assume the industry has already arrived at "fully passwordless" — it's to know exactly where each client's systems actually stand today, pick the right architecture per account, and keep a plain, up-to-date record of who has access to what. A renewal tracker like InstaRenewal won't manage the cryptography for you, but keeping that access note next to the renewal date it's already tracking is a small habit that closes a real gap — the one between "we set this up correctly once" and "we still know how it works two years and three team changes later."
---
Sources checked for this piece: AWS Security Blog (root MFA and passkey rollout announcements), AWS "What's New" post on IAM MFA enforcement (June 2025), Yubico press materials and technical documentation on the YubiKey 5 FIPS Series and FIPS 140-3 validation, Google Workspace Blog and Workspace security documentation, Microsoft Learn documentation on GDAP, Shopify Help Center and Shopify Engineering blog, Cloudflare Community threads on passkey support, WordPress.org plugin listings, and InstaRenewal's own site and privacy policy.