Invalid Provider

Hello @f1alan !

That’s really unexpected for sure. I wasn’t able to reproduce this behavior on my end, so I’d like to gather a bit more information to help us narrow it down.

Could you please let us know:

• Which type of Passkey provider are you using (e.g. platform passkey such as Windows Hello, Touch ID, Face ID, or a security key such as YubiKey)?
• Could you open your browser’s Developer Tools (F12), reproduce the issue, and share any errors shown in the Console tab?
• Are you using the native WordPress login page, or a custom login form/page? If it’s a custom login, does the same issue occur on the default WordPress login page as well?
• Which PHP version is the site running?
• Are you using a 2FA method along with the passkeys or just passkeys alone? Can you elaborate on the method used if that’s the case etc.
• Finally, can you confirm which WP 2FA version you upgraded from before testing 4.0.0?

Once we have this information, we’ll be in a much better position to investigate the cause of the “invalid provider” error.

Hello @f1alan,

Thank you for the detailed answers, this helps a lot. The fact that you get “invalid provider” while only using TOTP method (and no passkeys at all) is exactly the odd part, and the 500 on validate_2fa tells us something is failing server side rather than in the browser.

You are describing two separate problems here (the “invalid provider” error on the legacy UI, and the new UI not prompting for 2FA plus the settings page redirecting to your profile), so let’s start with the first one and dig into that 500 error:

1. Please enable debug logging by adding this to your wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

2. Reproduce the “invalid provider” error, then check wp-content/debug.log and paste the PHP error(s) logged at that moment. That 500 will have a fatal error or exception behind it, and that is the single most useful thing you can send us.
3. A screenshot of the login screen at the moment “invalid provider” appears would also help, so we can see exactly where in the flow it happens.
4. Does this happen for all users on the site, or just your account? And if you temporarily enable another 2FA method (for example email OTP) for a test user, does that method fail the same way, or is it only TOTP?

On the plugin conflict side, I agree wp-hide-security-enhancer is a reasonable suspect, since it rewrites login paths and filters exactly the kind of requests involved here. I understand it is not easy to disable, so let’s look at the debug.log first, as it may point us straight at the culprit without needing to touch it.

The new UI behaviour you describe (no 2FA prompt and the settings page redirecting to your profile) is also not expected, and the fact that it only works when selected from the initial popup is a really useful detail.

Let’s get to the bottom of the 500 first, since there is a fair chance the two share the same root cause.

Thank you so much for the feedback, @f1alan! I’m really happy to hear everything is working again, and I’m confident this conversation will help other users who might run into something similar.

It’s a bit unexpected what could have caused this, especially since nothing has changed on our end regarding passkeys. For now, we’ll treat it as an edge case and keep an eye out for any similar reports so we can investigate further if needed.

I also wanted to thank you for all the time and effort you put into helping us debug this. The additional details you shared were extremely valuable, and we’ve noted everything down. We’ll do our best to improve the experience and prevent similar issues in future releases.

Finally, if you’ve been happy with both the plugin and the support you’ve received, we’d really appreciate it if you could leave us a review. It only takes a minute, and it genuinely helps us out:

https://wordpress.org/support/plugin/wp-2fa/reviews/#new-post

Thanks again, and if you run into anything else, don’t hesitate to let us know!