I’m posting this because I’ve just had one of the most baffling and frankly unacceptable experiences I’ve ever had with an identity system. What happened here should not be possible in a modern authentication platform, let alone one run by Microsoft.

This is a fairly full account of what went wrong, why it’s dangerous, and why I’m genuinely shocked this system shipped in this state.
The only positive note: Copilot was trying to guide me through. We kept failing at every single step. I can't imagine how much worse this would have been without it. .(I'd probably have given up an hour ago and got on with my life)

---

1. Passwordless mode trapped my account in a broken state

My Microsoft account was passwordless. Windows Hello was unreliable. Passkey creation failed. YubiKey registration failed. That left Microsoft Authenticator push notifications as the only strong method.

Because of this, I could not remove the push method — even though it was the source of repeated MFA‑fatigue attacks.

A security system should never put a user into a state where they cannot remove an abused factor.

---

2. The “Remove” button did not remove what it claimed

When I clicked “Remove” on Send sign‑in notification, the UI attempted to remove the entire Authenticator registration instead of just the push method.
Then it failed.

This is misleading, dangerous, and contradicts Microsoft’s own documentation.

---

3. Passkey creation repeatedly failed with a generic error

Every attempt to create a passkey resulted in:

“We couldn’t create a passkey. Please try again.”

No explanation. No remediation. No fallback.
This is a security‑critical flow — it should never fail silently.

---

4. YubiKey registration also failed with no actionable information

I plugged in a known‑good YubiKey and got:

“Something went wrong.”

Again: no reason, no guidance, no logs.

---

5. The documented fallback URL for FIDO2 registration now redirects to the same broken UI

account.live.com/proofs/manage/additional used to be the workaround.
Now it redirects to the same modern UI that was already failing.

This removes the only escape hatch Microsoft previously recommended.

---

6. TOTP “last used” date is wrong and never updates

Despite using TOTP many times, the UI still claims:

“Not used since 2024.”

This is a known backend bug.
It misleads users into thinking their TOTP method is stale or non‑functional.
In a security dashboard, inaccurate metadata is not cosmetic — it’s a trust issue.

---

7. GitHub sign‑in forced me into a broken passkey setup

After signing in with GitHub, Microsoft immediately forced me into a passkey setup flow that was already broken.

This is coercive UX and creates a dead‑end for users whose hardware or configuration is incompatible.

---

8. No PowerShell or API exists for personal Microsoft accounts

There is no supported automation path to:

• remove MFA methods
• add MFA methods
• reset passkeys
• manage Authenticator registrations

This leaves users entirely dependent on a UI that is demonstrably unreliable.

---

9. The UI contradicts itself across pages

Different pages showed different states:

• Push removed in one place
• Still present in another
• TOTP usage not logged
• Passkey status unclear

This inconsistency makes it impossible to trust the security posture of the account.

---

The only way out was to re‑enable a password

In the end, the only way to break the dead‑lock was to turn off passwordless mode, add a password back to the account, and then remove the push method.

This completely defeats the purpose of passwordless security.

---

Why this is dangerous

This isn’t just a bad user experience.
This is a security failure.

A user under MFA‑fatigue attack should be able to remove the abused factor immediately.
Instead, I was trapped in a broken state where:

• I could not remove the compromised method
• I could not add a new method
• I could not register a passkey
• I could not register a hardware key
• I could not escape the loop without weakening my account

This is not acceptable for a consumer identity system used by hundreds of millions of people.

---

And finally: even posting this feedback was unpleasant

• Feedback Hub crashed
• TechCommunity hid the posting UI behind multiple layers
• Some pages returned “Internal Server Error”
• The public support page isn’t actually public
• The “obvious” places to post simply don’t allow posting anymore

It should not be this hard to report a serious identity failure.

---

What I’m asking for

1. Fix the passwordless dead‑lock so users are never trapped with a single failing method.
2. Fix the passkey creation flow so it provides meaningful diagnostics.
3. Fix the YubiKey registration flow so it provides actionable errors.
4. Fix the TOTP “last used” metadata so it reflects reality.
5. Restore a working fallback registration path for FIDO2 keys.
6. Ensure “Remove” removes the method it claims to remove.
7. Provide a supported API or PowerShell module for personal Microsoft accounts.
8. Audit the entire passwordless UX for failure‑mode safety.

I asked copilot to help me solve the original it patiently did its best. Maybe you should get some robot help too. This feels like millenial MSFT not the work of a $2trillion dollar "AI first" company that thinks it's on the verge of the singularity.

hi Addyman,

I’m not quite sure I follow: as soon as you secure your account using 2FA in any way, you’re asked to create a recovery code and keep it safe! This ensures that you can access your account at any time!

Recovery code

You can use this code to access your account if you lose access to your login details. Print it out and keep it in a safe place, or take a photo of it.

As YubiKey is an external tool, it will be difficult for Microsoft to display explicit error messages in this context. Should an error occur, it should first be investigated using the YubiKey software itself.

Thanks for replying, but I need to clarify something immediately because your response is based on a completely incorrect assumption.

My account was never locked. I was not trying to regain access to my account. I was trying to regain access to my security methods, which the system itself had locked me out of managing.

This is the core issue you missed.

1. The problem was not account lockout — it was being locked out of my own MFA settings

I could sign in just fine. What I couldn’t do was:

• remove an abused MFA method

add a new MFA method

register a passkey

register a hardware key

The system trapped me in a loop where every path to fix my security was blocked by the system itself.

This is not a standard “unlock your account” scenario. This is a broken identity flow.

2. The UI refused to remove the push method

Clicking “Remove” on Send sign‑in notification tried to delete the entire Authenticator registration, not just the push method — and then failed.

That is not user error. That is the UI behaving incorrectly.

3. The system demanded I add another strong method — then blocked every attempt to do so

You suggested I “just add another method.” I tried that. The system wouldn’t allow it.

Passkey creation failed with a generic error

YubiKey registration failed with a generic error

The fallback FIDO2 URL redirected to the same broken UI

So I was stuck in a state where the system required me to add a method, but also prevented me from adding one.

That’s the failure.

4. The only escape was to weaken my account

The only way out of this broken state was to:

disable passwordless

add a password

sign in with the password

then remove the push method

If a “passwordless” system forces users to weaken their security to escape a dead‑lock, that is a design flaw, not a user mistake.

5. This is a security issue, not a usability issue

The danger is simple:

A user under MFA‑fatigue attack should be able to remove the abused factor immediately. Instead, the system trapped me in a loop where:

I could not remove the compromised method

I could not add a new method

I could not register a passkey

I could not register a hardware key

I could not escape without reducing my security posture

That is the issue I’m reporting.

6. And finally: even submitting this feedback was unnecessarily difficult

Feedback Hub crashed

TechCommunity hid the posting UI

Some pages returned “Internal Server Error”

The public support page isn’t actually public

Reporting a serious identity failure should not require navigating a maze of broken tools.

I hope this clarifies the actual problem. This wasn’t an account lockout. This was a security‑method lockout caused by a broken passwordless/passkey flow — and it deserves attention from the identity engineering team.