been following a small startup in sydney thats working on decentralised IAM / security fabric stuff, and i think im becoming a bit of a fan of the idea.
what im trying to understand is why more people arent excited about this kind of thing, especially now that software is getting built faster with ai and security feels more chaotic than ever.
most apps still end up with a few scary central points of trust. auth provider, secrets manager, sessions, recovery flows, admin access, user db, that kind of thing.
if one of those gets breached or misconfigured, the blast radius can be pretty ugly.
the idea i find interesting is not really decentralisation for the sake of it. its more like, can we avoid having one big pile of sensitive stuff sitting somewhere in the first place?
i can imagine a few use cases where this might matter:
- apps where users own their data and choose what gets shared
- health / finance / legal apps with sensitive user data
- identity and access management
- key management / signing flows
- recovery flows where one admin or provider shouldnt have too much power
- ai-built apps where people might ship faster than they understand the security model
- apps that want security without holding all the sensitive stuff themselves
but i can also see why people might not bother. existing tools are pretty mature, and adding another layer to auth/security is not exactly something devs do for fun.
the questions i keep coming back to are:
- who runs the nodes?
- what happens if they go down?
- how does recovery work?
- does this make debugging painful?
- is the latency noticeable?
- does it reduce trust, or just move trust somewhere else?
- is Keycloak/Auth0/Okta/KMS already good enough for most teams?
i think the dx is probably the make or break part. if normal devs cant understand it, debug it, or integrate it without pain, it probably wont matter how good the security model is.
curious what people think. are there real use cases where decentralised IAM/security fabric makes sense, or is it just too much complexity for most apps?
also keen to hear what use cases im not thinking of, because im probably missing some obvious ones.
Top comments (2)
Really interesting framing.
My take is that most teams are not excited yet because the current model works well enough, until it suddenly does not. Centralized auth, secrets, sessions, admin access, recovery flows, and user databases are familiar tools. People know how to buy them, integrate them, monitor them, and explain them.
So the bar for anything new is high.
I do not think the question is “should everything be decentralized?” The better question is:
where is it dangerous for one provider, one admin, or one system to have too much power?
That is where this starts to make sense: health, finance, legal, identity, signing flows, recovery, high-risk admin actions, AI agents, and user-owned data.
The real test is whether it can disappear into the workflow. If devs can integrate it, reason about it, and troubleshoot it without having to become experts in the whole underlying system, then it has a chance. If not, it will probably stay niche.
It does not remove trust. It changes where trust sits, and limits how much damage one party can do alone.
For most apps, Keycloak, Auth0, Okta, or KMS are probably enough. But where one breach or bad recovery path could be catastrophic, splitting control starts to look less like extra complexity and more like common sense.
this is probably the cleanest way ive seen it explained.
the "where is it dangerous for one provider, one admin, or one system to have too much power?" question is basically what i was trying to get at.
i think thats why the idea feels more relevant now too. with ai agents, faster app building, and more stuff being automated, centralised trust can get messy pretty quickly if the wrong layer has too much control.