Zero Standing Privilege: Marginal Improvement on the Wrong Paradigm
Posted3 months agoActive3 months ago
gluufederation.medium.comTechstory
calmnegative
Debate
10/100
Enterprise SecurityPrivilege ManagementIdentity and Access Management
Key topics
Enterprise Security
Privilege Management
Identity and Access Management
The article critiques the concept of 'Zero Standing Privilege' as a marginal improvement over existing enterprise security paradigms, sparking a discussion on the effectiveness of current security approaches.
Snapshot generated from the HN discussion
Discussion Activity
Light discussionFirst comment
18m
Peak period
1
0-1h
Avg / period
1
Key moments
- 01Story posted
Oct 7, 2025 at 4:53 PM EDT
3 months ago
Step 01 - 02First comment
Oct 7, 2025 at 5:11 PM EDT
18m after posting
Step 02 - 03Peak activity
1 comments in 0-1h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 7, 2025 at 5:11 PM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45508721Type: storyLast synced: 11/17/2025, 11:08:56 AM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
It's hard to explain, but it reminds me of the Semantic Web, this totally artificial theoretical construct of how Things Should Be, but... it never worked out like that, and never will. Market forces just don't align with these ivory tower approaches of how things Ought To Be Done.
On the contrary, all too often worse is better, because it scales effortlessly, is faster, and much more importantly: cheaper.
This applies to priviliged identity management (PIM) and its variations.
What I see in most organisations is that the "least trusted" person, the outsourced subcontractor to the contractor, some below-minimum-wage person working out of Chennai is the "Global Admin" (or equivalent) and the CEO, CIO, CTO, and the CISO all have... no special rights. The same as a random secretary.
I see this pattern over and over, organisation after organisation. The exceptions are few and far between, so there must be a reason!
My best guess is that this is because as permissions delegation get finer and finer grained, then the manager delegating the permissions needs better and better knowledge of the technical task to be done in the future to properly and accurately delegate all -- not just some(!) -- of the permissions required to execute that task.
How would you delegate the permissions to fix an "error" (unspecified!) "somewhere" in the tangled network of servers and other equipment?
Remember: No gaps! No missing permissions! This has to be one hundred percent coverage, no edits on the fly, because this troubleshooting could be at 3am on a Sunday after a disaster that could stop the business operating on Monday morning.
No, getting woken up at 3:30am to delegate more permissions is not something most senior managers will accept. Even if they're forced to at gunpoint, what exactly are they going to do? The clock is ticking, the system is down, they don't even know where the problem is! If the +1 permission they just granted is not sufficient, they'll have to grant one more at 4:00am, then 4:30am, then 5:00am and so forth until the business is back up.
This means that with sufficiently fine-grained permissions, eventually the "delegator" has to be 100% involved throughout the entire time complex ad-hoc tasks are performed. This isn't just troubleshooting, it's consultants, it's new deployments, migrations, mergers, splits, role changes, reshuffles, or anything that wasn't 100% perfectly foreseen by the original security delegation architects.
Not to mention that "security architect" is a specialisation with very little overlap with any specific product or business system. The "person in charge" of some database, platform, or product is very unlikely to fully grok delegated ACLs, ZSP, PIM, etc...
This just doesn't scale. Managers overseeing, say, five staff can't be 100% involved in all five staff doing ad-hoc work. Even if they can make this work, what about the next level management, the level from which this manager gets their delegated permissions (which they can further delegate)? Run this up to the level of CIO and with a sufficiently specific access control design you'll have the CIO doing nothing else other than mashing buttons in the some security delegation system such as Active Directory!
It's just soooo much easier to give the lowly tech "Domain Admin" and be done with it.
The alternative with ZSP or whatever is Ivory Tower stuff that only works in "tech organisations" like FAANGs at a huge scale, and nowhere else. You need techs at every layer of management, sufficient scale to justify the effort and not be swamped in overhead.
PS: For comparison, I see a similar effect with ex-FAANG engineers recommending metrics for everything. That's great. I have apps that get 1 real transaction... per month. The other 99.999% of hits in the metric are GoogleBot and random drive-by hackers.