---
title: "User onboarding"
manual: "Passkeys Backend Authentication"
version: "1.0"
permalink: "https://docs.typo3.org/permalink/netresearch/nr-passkeys-be:deployment-onboarding@1.0"
source: "DeploymentScenarios/Onboarding.rst"
rendered: "2026-09-20T16:07:13+00:00"
---

# User onboarding {#deployment-onboarding}

## Onboarding workflow with disablePasswordLogin {#onboarding-workflow-with-disablepasswordlogin}

When [disablePasswordLogin](https://docs.typo3.org/permalink/netresearch/nr-passkeys-be:confval-disablepasswordlogin@1.0) is enabled, the
extension enforces passkey-only login **per user**: password
login is blocked only for users who have at least one
registered passkey. Users without passkeys can still log in
with a password.

This enables a smooth onboarding workflow:

1.  **Admin creates a new backend user** with a password
    (as usual in TYPO3).
1.  **User logs in with their password** for the first time.
1.  **User registers a passkey** in
    **User Settings > Passkeys**.
1.  **From this point on**, the user must use their passkey
    -- password login is no longer accepted for this
    account.

> [!NOTE]
> An admin **cannot** register a passkey on behalf of
> another user. The WebAuthn ceremony requires physical
> interaction with the user's own authenticator (TouchID,
> YubiKey, etc.).

## Recovery scenarios {#recovery-scenarios}

If a user loses access to their authenticator:

1.  An admin revokes the user's passkeys via the
    [Admin API](https://docs.typo3.org/permalink/netresearch/nr-passkeys-be:administration@1.0). Each revocation is
    recorded with the admin's UID and timestamp for audit
    purposes.
1.  Once all passkeys are revoked, password login becomes
    available again for that user (the per-user enforcement
    lifts when no active credentials remain).
1.  The user logs in with their password and registers a
    new passkey.

> [!TIP]
> Consider requiring users to register at least two
> passkeys on different authenticators (e.g. laptop +
> phone) for redundancy.

## Containerized and multi-server deployments {#containerized-and-multi-server-deployments}

When running TYPO3 in Docker containers or behind a load
balancer, the file-based cache backends lose state on
container restart and are not shared across servers. This
affects nonce replay protection and rate limiting.

See [Multi-server cache backends](https://docs.typo3.org/permalink/netresearch/nr-passkeys-be:security-multi-server-caching@1.0) for Redis configuration,
and [Reverse proxy and IP detection](https://docs.typo3.org/permalink/netresearch/nr-passkeys-be:security-reverse-proxy@1.0) for rate limiting behind a load
balancer.

## Local development with DDEV {#local-development-with-ddev}

DDEV sites (`*.ddev.site`) use HTTPS by default and are
treated as secure contexts by browsers. Passkeys work out
of the box.

**Starting a DDEV environment**

```shell
ddev start
# Open https://mysite.ddev.site/typo3
# Passkeys work immediately
```

For `http://localhost` (without HTTPS), most browsers also
treat this as a secure context, so passkeys will work.
However, custom local domains over plain HTTP (e.g.
`http://mysite.local`) will **not** work -- WebAuthn
requires a secure context.

See also [Troubleshooting: HTTPS requirement](https://docs.typo3.org/permalink/netresearch/nr-passkeys-be:troubleshooting@1.0).

> [!NOTE]
> **See also**
>
> [Security: Production deployment requirements](https://docs.typo3.org/permalink/netresearch/nr-passkeys-be:security-deployment@1.0) for trusted hosts pattern,
> reverse proxy configuration, and multi-server cache
> backends.