Kovoco kCheck can do the hard work for you — here's how to actually read the results.
If you've ever inherited a SQL Server instance and wondered what you were actually dealing with — who has sysadmin, which logins are SQL-authenticated, whether guest access is enabled anywhere — you know the problem isn't finding the data. It's organizing it into something you can act on.
There are lots of scripts on the internet you could use to gather this information--many that should be a standard part of a lot of DBAs' toolkits. They will query system views and Dymanic Management Views (DMVs) across your instance and return a structured picture of your security posture: server roles, database principals, permissions, orphaned users, cross-database ownership chains, and more.
The results are accurate. The raw output, though, is a wall of result sets that's hard to navigate when you're trying to prioritize a remediation list or explain something to a manager.
That's why we built the Kovoco kCheck.
What Kovoco kCheck Actually Checks
When you execute Kovoco kCheck, it runs a series of queries against catalog views like sys.server_principals, sys.database_principals, sys.server_role_members, and sys.database_permissions. It surfaces things like:
- Logins with
sysadminmembership (including ones you might not expect) - SQL-authenticated logins, which carry more risk than Windows-authenticated ones because they bypass Kerberos and Active Directory controls
- Database users mapped to logins, including orphaned users where the SID no longer matches a valid login
EXECUTE ASpermissions and ownership chains that can allow privilege escalation without explicit role grants- The
guestaccount — enabled in a database, it lets any authenticated login access that database without an explicit user mapping xp_cmdshellstatus and other surface area configuration options
None of this requires installing anything. You run the powershell file, a website will pop up and it queries your instance, and returns results. The data is already there in SQL Server's own metadata. Kovoco kCheck just assembles it.
What the Kovoco Security Check UI Adds
The Kovoco Security Check is a single HTML file. You open it in a browser, connect to your database, run the checks, and it renders the results into a structured, filterable interface.
The problem it solves is practical: when Kovoco kCheck returns a dozen result sets in SSMS, you're scrolling back and forth, trying to cross-reference findings. It's 2026, that's friction you don't need. Access all that data from a web interface.
The UI breaks the output into sections, makes it filterable by finding type, and formats it in a way that's easier to share — with a team, with a compliance officer, or with your own future self six months from now.
There's no backend. No login. No data leaves your machine. You're just parsing output in a browser.
It works with any modern browser and requires nothing beyond the HTML file itself.
When to Use This
The honest answer is: use it whenever you're doing a permissions review and you want to actually read the results.
Some specific moments where it earns its keep:
Onboarding to a new instance. You inherited something. You want to know if sa is enabled, who has sysadmin, and whether there are 40 SQL logins from 2014 that nobody's touched since.
Pre-audit preparation. PCI-DSS, SOC 2, and HIPAA all have requirements around least privilege and access control. Running Kovoco kCheck before your auditor does means you find the findings first.
Routine hygiene. Permissions drift. Service accounts accumulate roles. People leave organizations and their logins stay. Running this quarterly and reviewing the delta keeps the drift manageable.
Post-incident review. If something went wrong and you're trying to understand what access existed at the time, this gives you a fast read on your principal and permission structure.
The Kovoco Security Check is free, open source, and available on GitHub now.
Get it here: github.com/KovocoCarlos/KovocoSecurityCheck
If you're using Kovoco kCheck already and have opinions on what matters most in the output — or if you've run into edge cases where the results were misleading — drop a comment. That kind of feedback shapes what we build next.