Reddit is where security practitioners tell the truth. No job titles on the line, no vendor relationships to protect, no LinkedIn performance. Just practitioners describing what is actually broken, to other practitioners who know exactly what they mean.

We reviewed 1,053 posts and 16,428 comments from r/sysadmin, r/cybersecurity, r/activedirectory, and related communities, searching for identity and access management (IAM) threads: risk posture, provisioning, deprovisioning, access reviews, least privilege, and service account governance.

What came back was not surprising. It was familiar. The same five failure modes surfaced repeatedly, across company sizes, industries, and tech stacks. These are the stories that got the most comments, the most upvotes, and the most responses from people saying: This happened to us too.

Failure mode 1: Access at hire is almost always too broad, and nobody revisits it

A new finance analyst joins on a Monday. Their manager submits a ticket: "set up like Sarah." Sarah has been at the company for eight years, has rotated through three teams, and her permissions have accumulated with every move. IT copies the whole profile because writing a custom one would take an hour they do not have, and the analyst needs to be productive by Tuesday morning.

Three months in, the new hire has read access to AP approval workflows, wire-transfer initiation rights from an AP stint two years ago, full employee compensation data in Workday from an FP&A rotation, and a shared S3 bucket from a project that ended last year.

The post that captured this dynamic got 4,397 upvotes and 720 comments. The audience recognized both sides. Some had been the new hire who inherited a profile they did not ask for. Some had been the person who copied it, under time pressure, because scoping access correctly takes longer than the onboarding window allows.

Access at hire defaults to broad because the friction of scoping it correctly is higher than the friction of granting it. Nobody returns to review it later because there is no trigger. The new hire becomes part of the environment. Their access becomes assumed, not verified.

By the time anyone looks, the entitlement picture is too complex to unwind manually. Most orgs never look until an audit forces them to.

Failure mode 2: Least privilege breaks down wherever developers are involved

A post on r/sysadmin asked: do you give software engineers local admin rights?

408 comments. No consensus.

Security says no. Developers say yes, or they cannot work. The most upvoted response: "They create the revenue. You do not prevent them from getting their job done. Integrate security at the right levels."

The detail worth noting: multiple commenters reported that developers at their org had switched to Mac specifically to avoid their Windows access approval workflow. The security friction was high enough that people routed around it entirely.

When people route around a security control, the control does not disappear. The visibility does. Access is still being granted. It is just happening outside the process, without a record, and without oversight.

This is what happens when least privilege gets deployed as a restriction rather than an architecture. The options become binary: blanket admin or blanket denial. Both create costs. Blanket admin creates risk. Blanket denial creates ticket volume, frustration, and eventually, workarounds.

The model that resolves this is elevation on demand: scoped to the task, time-limited, logged. Developers get what they need without friction. Security gets a record of what happened and when. Most orgs do not get there because building it correctly takes more upfront investment than either shortcut. So they pick the shortcut and inherit the problem.

Failure mode 3: Offboarding is only as good as the access inventory behind it

Two posts. Same root cause. Very different scale.

The first: a former contractor at a waste management company was terminated, posed as a different contractor to recover credentials, then ran a script that reset 2,500 passwords across the organization. Employees were locked out company-wide. Damages reached $862,000.

The top comment: "How does this even happen?"

The gap between "we fired them" and "they can no longer access anything" was wide enough to walk through.

The mechanics, once visible, are straightforward. Contractor access was not scoped. Deprovisioning was manual and incomplete. No flag triggered when a terminated identity re-authenticated under a different name.

The second post was framed as dark humor. A developer had created a kill switch in his employer's systems, a function named "IsDLEnabledinAD" that would lock all users out of their accounts the moment his Active Directory account was disabled. When he was terminated, it triggered. The resulting disruption cost the company significantly and the developer four years.

The most upvoted response, with 1,281 upvotes: "I incorporate kill switches into all my employers' systems. Not intentionally. It is just that my design decisions are so poor that everything will soon quit working if I am not around."

That joke landed because it is accurate. Undocumented dependencies on individual accounts, processes that run under a personal user identity, and integrations that will break when someone leaves are not exceptional. They are the default state in orgs that provisioned fast and never inventoried thoroughly.

Offboarding coverage is only as complete as the access inventory behind it. Apps that were not in scope when the integration was built do not get deprovisioned automatically. They get deprovisioned when someone remembers to include them. Most orgs have not finished that inventory.

Failure mode 4: The audit that revealed a documentation problem, not a security one

A security practitioner posted this during their SOC 2 renewal:

"We are going through our Type 2 audit, and the auditor is asking for access review evidence for all of 2024. No one stored anything. No exports, no certifications retained, nothing in the ticketing system. The person who owned SOC 2 for us left six months ago. Now leadership is asking me to recreate what happened last year."

Top community response: "You cannot. And will fail the audit."

A separate post described the quieter version. "We have always had sensible operational practices. Access approvals happened. Change reviews happened. Now that we are dealing with formal audits, suddenly everything needs to be written, tracked, and evidenced. The frustrating part is the work itself has not changed much."

One response cut through the thread: "Auditors do not question whether you are capable. They question whether your processes are repeatable and reviewable."

That sentence contains the whole problem.

Both posts describe the same structural failure. The security work was real. Someone checked permissions when things felt off. A manager approved access at onboarding. Stale accounts got cleaned up. But none of it left a record. Without a record, a year of legitimate governance is indistinguishable from no governance at all.

The teams that pass audits without a scramble are not doing more security work. They are doing the same work in a way that produces a record automatically, not retroactively.

The annual scramble to prepare evidence is a symptom of a process that was never designed to generate it continuously.

Failure mode 5: Non-human identities are accumulating access that nobody is governing

A practitioner shared this one as a confession:

"I named all the databases and service accounts after my cat, Mr. Whiskers. Fast forward: I left the company. Two years later, they offered me a job again. The environment is still running with MrWhiskersDB and MrWhiskersService."

The community's reaction was laughter, then recognition. Replies stacked up with variations on the same story. Service accounts tied to personal user identities that had since been offboarded in HR but were still running production workflows. Servers named after fictional characters, credentials that outlived the person who created them by years.

It was not a theoretical gap. A vulnerability in Microsoft 365 Copilot, disclosed by security researchers, showed an AI agent with broad service account permissions being hijacked through a malicious email, with no user click required. The agent processed the instruction, exfiltrated data, and covered its tracks. The attack surface was not a misconfigured human account. It was a non-human identity operating with permissions that were never revisited after provisioning.

Service accounts outnumber human identities in most enterprise environments. They accumulate permissions at provisioning time, and those permissions are rarely, if ever, revisited.

This is the fifth failure mode, and it is accelerating. Service accounts do not trigger joiner-mover-leaver workflows. They do not appear in quarterly user access reviews because they are not users in the traditional sense. AI agents, automated workflows, and SaaS integrations are creating new non-human identities faster than most IAM programs were designed to handle. The governance gap is not a new problem. It is an old problem that is now growing faster than the orgs that have not addressed it can ignore.

The pattern behind all five

Read across the five stories, and one thing becomes clear. They are not five separate problems. They are five angles on the same one.

Access at hire defaults to broad because scoping it correctly takes time nobody has. Reviews do not leave records because the process was never instrumented to generate them. Least privilege fails under developer pressure because binary controls create workarounds. Offboarding leaves gaps because the access inventory was never complete. Non-human identities accumulate unchecked because governance programs were built around humans.

In every case, access was easy to grant and invisible to govern.

The practitioners posting these stories are not describing edge cases or negligence. They are describing the default state of organizations that grew, moved fast, and kept deferring the governance work that felt less urgent than shipping. Most of them know what good looks like. The gap is operational, not conceptual.

Opti was built for this gap. Not to run a better annual access review, but to make governance continuous: access visibility that does not depend on someone remembering to run a project, evidence that exists before the auditor asks for it, and coverage that extends to the service accounts and AI agents that the quarterly UAR has never reached.

The five failure modes in this piece are not cautionary tales. They are the status quo. The question is how long your org stays there.

See how Opti approaches continuous identity governance. Request a demo at opti.ai.