Passkey Support

Please note that this feature request is for the ability to create and store passkeys in Hudu, not to log into Hudu with a passkey.

The Hudu Team Before passkeys ship, the browser extension's session model needs to be fixed, because everything built on top of it inherits the same problem.

Two things people should be aware of:

1. The extension has no session timeout. Sign in once and it stays signed in indefinitely. There is no idle expiry and no forced re-authentication.

2. IP restrictions do not apply to the extension. You can lock the Hudu web app down so nobody can sign in outside your approved ranges, and a tech with the extension already signed in can still use it from anywhere, at any time. The control is bypassable by design.

A question for the team that I haven't been able to test: if a user account is disabled, are active extension sessions revoked immediately? If not, that's an offboarding problem on its own.

The practical consequence: a lost or stolen laptop where BitLocker happened to be off, and whoever has it holds standing access to the vault from any network, with no expiry.

This is already why we don't store TOTP in Hudu. If the password and the second factor both come out of the same permanently signed-in extension, there is no second factor. We pay for a separate platform purely to hold MFA. I have raised this with Hudu directly.

What I'd actually want, and to be clear I am not asking for re-authentication on every OTP reveal or autofill, which isn't workable day to day:

• A configurable session timeout on the extension, with re-authentication after it expires. ScreenConnect's extension is the model here.

• Passkeys should not live in the browser extension at all. Mobile app only.

• In the mobile app, tie stored passkeys to the device's secure element (Secure Enclave / StrongBox / TEE), so the keys are Device-bound and can't be lifted off the device AND not synced.

• New device enrolment requires admin approval before it can hold or assert anything.

• Assertion happens the way FIDO2 hybrid transport already works: unlock the phone, scan the code on screen. That keeps possession and user verification where they belong, on the phone, and gives you proximity as a bonus.

I understand not everyone wants that level of friction, so make it a policy option rather than the default. But it needs to exist for those of us who don't want a single lost laptop to become a full compromise across every client we manage.

Some of the comments below are from 2023! How has it been 3 years and this is still not developed?

Please add support for Passkeys.

This should be a top priority on the roadmap!!

Now with MS forcing passkeys, can this be reviewed and moved to the top of the list? Right now we are having to use a separate password manager to handle passkeys and it is going to get worse now with the MS announcement.

With Microsoft's recent plan to enforce passkeys, this is definitely a must-have.

Threw in another upvote. We currently have to have client accounts split between Hudu and Keeper depending on who actively has passkeys configured.