I built MFA in the 1990s. In 2026 I let an AI deploy it for me.

In my previous life, I spent the early part of my career building multi-factor authentication, back when “two-factor” meant a hardware token the size of a car key.

It was hard, niche work. Most people had no idea why you’d want a second factor at all.

Thirty-odd years later, MFA is plumbing. It’s a checkbox in every SaaS console, a line item in every audit, a solved problem in roughly the way running water is a solved problem.

And yet I still get the question. Every few months, from someone in my network or one degree out:

We’ve got Windows endpoints that don’t authenticate against Entra. How do we add MFA — easily?

What’s striking isn’t the question. It’s that it’s still being asked in 2026.

Because here’s the thing the headlines glossed over: Microsoft made third-party / external MFA generally available in Entra ID already a while back. Genuinely useful, but it secures cloud and app sign-ins through Conditional Access. It does not, by itself, turn a traditional domain/RDS Windows logon into an MFA-gated logon. Which is why the question keeps landing in my inbox. The “easy” part still isn’t easy.

So the two words in that question — how and easily — got stuck in my head. And it occurred to me that I had a new tool to throw at an old problem.

We’re told AI agents can now do “just about anything.” I’ve been around long enough to treat that sentence as a dare.

So I set up an honest test: could I actually answer the how/easily question by, of all things, asking an AI?

The setup: a lab Active Directory, also hosting lab RDS server, and a plain vanilla Linux box. I connected them to **ManageLM, a service that translates plain-language intent into real sysadmin actions and runs them in the controlled context of that intent, and paired it with Claude** over MCP.

So, Claude acted as the planning/orchestration model. MCP exposed ManageLM tools to Claude. ManageLM then dispatched constrained tasks to host agents, with my local Qwen model helping translate intent into executable, tagged actions.

Slightly weary on success of my experiment, I amped up Claude to Opus 4.8, effort level to Expert, also toggled Thinking mode On. Just to be on the safe side of things.

Then I described what I wanted in English, and watched.

I have a Windows Server running Active Directory and RDS, and a Linux server for WebADM/OpenOTP. Please set up MFA for RDS logins following the RCDevs getting started guide at https://docs.rcdevs.com/getting-started-with-mfa-for-windows-server-desktop/. The WebADM freeware license key is in /root/license.key. Let me know if you need me to do anything in the WebADM admin console.

What happened next is the part I keep turning over.

First 5–10 minutes Claude digested on RCDevs documentation, then came back with a summary that got my hopes up.

What then followed was series of Claude orchestrated prompts to ManageLM backend and my local LLM, fanned out to ManageLM agents on my two hosts. Most however seemed to error out, and for next 5–10 minutes Claude, and ManageLM toolchain, seemed to be going in circles and I was near ready to conclude I had given a much too complicated and/or vague task for an AI to orchestrate.

I went about to carry on with my other important daily work items - to prepare myself coffee and my teenager kids lunch. When I came back, the setup was to my surprise back on tracks.

Claude’s chatter then continued…and continued, for good 10–15 minutes, enough long I again began to suspect the setup had gone side-ways, but apparently not.

Okay, AD side had actually worked.

Another good 15 minutes after, the ManageLM agent on Linux realised that mimicking human interaction wasn’t one of its best skills, and it went about to stitch together WebADM configurations “by hand”, and while I was near sure that’ll finally jack up my Linux to something non-recoverable, it actually came out again Okay, with Claude now prompting for my contribution:

So I generously replied.

This time Claude came back nearly instantly, as some guardrails apparently kicked in.

The Getting Started Guide did say the filter should be Off, but thanks Claude for asking, better safe than sorry..

Waiting, again. Finally, 5–10 minutes after, and after apparently after bunch of small challenges Claude and ManageLM managed to fight their way through, Claude came back.

And for real, the MFA enrolment prompt was now there on my Windows.

All in total

Over an hour of Claude narrating, retrying, and occasionally over-explaining, so not the most speedy experience, but the headline, though:

It worked. Not as a clean one-shot automation, and not as something I would probably run unattended against production. But it worked in the way that matters: the AI/tooling loop planned the deployment, recovered from several small failures, used the right machines, wrote the right configuration, and got MFA in front of a Windows logon with me acting as the safety interlock rather than the installer.

So, MFA in front of the Windows logon, stood up by describing what I wanted in plain English rather than by stitching together a credential provider, a policy engine and a directory integration by hand the way I’d have done it a decade ago.

Or, frankly, the way I’d have done it last year.