No Privileged Accounts. So Who Got In at 03:00?

"Nobody has standing access to production." This sentence is heard in many organisations and is partly true in most: developers' direct production access has been closed, changes go through a pipeline, permissions per table are narrow. Then comes a question: "What about DBA accounts? Service accounts? The account a vendor connects with? The emergency account?" The answer is usually a pause and then: "Those are different, of course." This article is about those different accounts.

Where Is Zero Standing Privilege Heading?

The idea now has a name: zero standing privilege. Nobody has permanent access; the access needed for a job is granted for the time needed and revoked afterwards. Identity and access products increasingly apply this to databases and AI identities too. The idea is right. In practice two things happen:

• Standing privilege does not disappear overnight. There are years of accumulated accounts, service credentials and shared passwords.
• Removing privilege is not enough. You have to keep showing that it stays removed.

Three Layers: Enforce, Monitor, Prove

The privileged account problem has to be treated as three separate jobs. Expecting all three from one tool leads to disappointment.

1. Enforce. Remove standing privilege in the database, make access time bound, keep the password in a vault. This is the job of identity and access management and the organisation's decision.
2. Monitor. See all traffic to the database and catch the unexpected account. This is the job of database activity monitoring (DAM) and SIEM.
3. Prove. Show what was allowed, who approved it, which text ran and that it cannot be changed afterwards. This is the job of the governance layer.

SQL Change Guard does the third. It deliberately does not enforce: it is not a proxy and does not close accounts in the database. In sales language that can sound like a gap; architecturally it is a boundary and has to be stated honestly. The governance layer does not enforce, but it makes it measurable whether enforcement works, because the knowledge of what is allowed lives in it.

How Do You Test the Sentence "No Standing Access"?

The proof of that sentence is not a policy document. The proof is whether anything happens in production outside the list of allowed accounts. The design works like this:

• The product connects to the production server with a single account. That account sits on the "expected accounts" list.
• The product opens every connection under a name carrying role and request number.
• An event goes to the SIEM when execution starts and ends.
• If DAM shows DDL, DML or a permission command under an account outside this list, the SIEM raises an alarm. The organisation's own application accounts are on the organisation's own list.

So the sentence "nobody has access" tests itself one day. If it is wrong, a week later it lands in front of you as a morning report.

The 03:00 Reality

Removing standing privilege is easy; removing emergencies is impossible. When production is on fire someone has to get in, and there is no time for an approval meeting. The emergency path should be made provable rather than abolished:

• An emergency request is still a request. It asks for a reason (the incident number can be made mandatory by an organisation setting) and shortens approval steps but does not skip them.
• The trace is closed the next morning. An emergency execution is not considered closed until it has been reviewed. Records waiting for review sit at the top of the report.
• Some traces cannot be filtered out. The create, approve and execute events of an emergency request are ordinary events and can be filtered if the organisation raises the SIEM threshold. The ones that cannot be filtered are: the emergency review event, the ITSM gate exemption when ITSM is on, sign in with the emergency account, and events whose name means emergency, bypass or override. So an emergency monitoring rule should hang on "emergency executed and not reviewed", not on "emergency request opened".

The result: the person who gets in at 03:00 can get in. But at 09:00 the question "who got in last night, why, what did they run, has it been reviewed?" is answered on one page.

Can Someone Who Switches Off a Control Also Switch Off Its Trace?

The real danger of a privileged account is not its access. The danger is that the same person can change both the control and the record. So three things must sit in different places:

• The audit trail must be signed in a way the person who keeps it cannot change.
• An append-only ledger and a digest written outside on a schedule must make any rewrite of the trail detectable.
• A setting change that loosens a control must reach the SOC regardless of the filter.

This turns "how trustworthy is the administrator" into "would it be noticed whatever the administrator does". The second is a more defensible question.

Frequently Asked Questions

Is zero standing privilege enough on its own?

No. Removing privilege is not enough; you have to keep showing that it stays removed. Enforcement belongs to identity and access management, detection to DAM and SIEM, and evidence to the governance layer. The design is incomplete without all three.

How does emergency access become provable?

An emergency request asks for a reason (the incident number can be made mandatory by an organisation setting) and shortens approval steps without skipping them; emergency requests that have not been reviewed show in the report as awaiting review. The review event cannot be filtered out of the SIEM, so the monitoring rule should hang on "emergency executed and not reviewed".

Does SQL Change Guard close the privileged account?

No. SQL Change Guard is not a proxy and does not close accounts in the database. It makes it measurable whether enforcement works: the knowledge of the allowed account and the request lives in it, and the alert rule is written on the DAM and SIEM side.