We've been running Siemserva through beta testing with a group of IT pros over the past several weeks. Most of the feedback has been what you'd expect - performance notes, UI suggestions, questions about specific findings. Useful stuff. Normal stuff.
Then last week one of our testers sent a message that stopped me mid-coffee.
"I wasn't expecting it to know that."
Not a bug report. Not a feature request. Just that line, and then a long description of the session they'd just run. I'm going to share most of it here, because I think it captures something about what Siemserva actually is that our own marketing has struggled to fully express.
What They Did
Our tester - an IT admin managing a Microsoft 365 environment - connected Siemserva, kicked off a scan, and started asking questions in plain language. The scan ran 612 checks across Entra ID, Intune, Exchange, SharePoint, Teams, and OneDrive. Total findings: over 1,300. Time: a few minutes.
Before a single finding appeared, something happened that set the tone for the whole session.
The Senserva AI stopped and told our tester what it couldn't see.
Nine check groups had been skipped - Conditional Access policies, Authentication Methods, Sign-In logs, Risky Users, PIM Alerts, among others. Not silently. Not in a footnote. The Senserva AI surfaced it upfront, named every blocked group, identified the specific missing permission behind each one, and explained exactly which role elevation would unlock it - and what findings would likely appear once it could.
Our tester hadn't asked any of that. They hadn't noticed anything was missing.
That's the behavior most tools don't have. A scanner gives you what it found. This one told them what it couldn't find, why, and what it would be worth going back for. Before the session had really started, the Senserva AI was already reasoning about the limits of its own visibility - and treating that as something the tester needed to know.
"It felt like it already understood the environment before I asked anything."
Three Criticals. One Account.
The tester drilled into the critical findings and three of the four pointed to the same former employee - let's call him Alex - whose account had been disabled in Entra ID some time before. Someone did that step and closed the ticket. Standard offboarding, or so it appeared.
What was still live on that disabled account: five PIM role assignments including Global Administrator, a standing Application Administrator assignment with no activation requirement and no MFA prompt, and a Windows device last enrolled in June 2022 with tokens never revoked and an outdated OS. The Senserva AI's assessment was immediate: "Someone disabled the account, which created the impression the access was revoked. But it wasn't."
This is the most common offboarding failure pattern in Microsoft environments. The account gets disabled. The task feels complete. The access stays.
The Part That Hit Differently
Our tester asked the obvious follow-up: how would someone actually exploit this?
What came back was not a generic overview of Entra ID attack surfaces. It was a step-by-step reconstruction of an attack chain using Alex's specific account, his specific roles, his specific device - in the order a real attacker would move through them. The disabled account still has a password hash, and breach dumps contain billions of credentials. The standing Application Administrator assignment means no MFA challenge, no approval gate, no meaningful audit trail - an attacker who gets in is just in. From there, Application Administrator is enough to plant persistent backdoors in existing app registrations, redirect OAuth flows to silently harvest tokens from active users, and manufacture a path to Global Admin without touching any other account. Then they create a new admin account with a clean name, re-disable Alex, and walk away. To a casual observer, nothing changed.
Our tester read all of that mapped to their actual environment - their account names, their device IDs, their roles - in real time.
"I've read about this class of attack before. But seeing it mapped to my actual tenant, step by step, while I'm sitting there - that was different. That felt unworldly."
We Felt It Too. But Not Like That.
When our team was building and testing Siemserva, we had our own version of that moment. Watching the Senserva AI connect dots across findings we knew individually but hadn't fully assembled into a picture.
But there's a difference between that experience when you built the thing and having it arrive out of the blue on a Tuesday afternoon when you're just trying to run a security check. Our tester didn't know what was coming. They ran a scan expecting a list of findings and got a conversation that understood their environment well enough to walk them through exactly how it could be compromised.
That gap - between expecting a report and getting something that reasons about your environment - is what's hard to explain in product copy. It really is easier to just show someone.
From Finding to Fixed
The session ended with a PowerShell remediation script - seven sequential steps, confirmation prompt before each destructive action. Removing the standing role assignment, stripping the PIM eligible assignments, revoking active refresh tokens, deleting the stale device. Estimated cleanup time: 45-60 minutes. Three of the four criticals resolved in a single pass.
Siemserva runs on Windows and macOS. The whole loop - scan, conversation, report, remediation scripts - on whatever machine you're already on.
Siemserva is available on the Microsoft Store and at senserva.com. Free tier covers Entra ID, top 10 findings with full remediation detail, permanently. Paid starts at $99 a month.
Ask it something. See what it knows.
