Security / compliance auditCoffee and beverage manufacturer, anonymized × red9CS-0518
A health check on a production server exposed 17 over-privileged logins and an enabled 'sa' account
The problem. A coffee and beverage manufacturer asked us to look over the production SQL Server behind its operations. The 145-point health check turned up a wide-open security posture: 17 high-privilege logins, the built-in 'sa' account left enabled, no encryption anywhere, and no HA or DR to fall back on. On top of that, tempdb was eating about 55% of the whole instance, so the box was exposed and strained at the same time.
What we did. We ran the full 145-point health check, then handed back a report that ranked every finding by risk and effort, from the over-privileged access and the enabled 'sa' account up front to the missing encryption, the absent HA/DR, and the runaway tempdb behind them.
Red9 · Health Check Findings
Over-privileged logins
17 found
High-privilege accounts on one production instance, before any cleanup.
tempdb footprint
55% of box
Of the entire instance's resources, on a single database.
Critical gaps found
3
The 'sa' account enabled, no encryption in place, and no HA/DR.
Access
17 high-priv + 'sa'
exposed
Encryption
None in place
critical
HA / DR
None in place
critical
over half the box
one database
Where these numbers come from. The 17 logins and the enabled 'sa' account are counted straight off the security section of the health-check report, and the 55% is tempdb's measured share of the instance's resources. Every finding sits in the client's own report, each ranked by how much risk it retires.
The result. The manufacturer walked away with a ranked remediation plan and a clear price on a risk that had gone unpriced. Locking down the over-privileged access and the 'sa' account came first, then encryption and an HA/DR design, then reining in tempdb, in the order the report laid out.
The technical detail
What the audit turned up. One production instance carried 17 high-privilege logins with the built-in 'sa' account still enabled, no encryption at rest or on backups, and no Always On or failover cluster, while tempdb was consuming roughly 55% of the instance's resources.
What the report flagged first (findings summarized, identifiers withheld):
-- Red9 145-point health check: security & stability exposure
-- P1 access : 17 high-privilege logins; built-in 'sa' account enabled
-- P1 encryption : none (no TDE, no backup encryption)
-- P1 availability: no HA/DR (no Always On, no failover cluster)
-- P2 tempdb : ~55% of total instance resources on one database
Each item shipped with the remediation step and the rollback beside it, so the client could take the critical access and encryption gaps first and schedule the rest against its own calendar.
