My results after a year: admin overhead hours per month

SCIM's the real game changer. Most teams miss that you need the identity provider integration dialed in first, otherwise you're just moving the manual work around.

What was your average monthly overhead with LastPass? Having that number would make the 1.5 hours more concrete.

You've highlighted the right metric, but I'm always skeptical of these internal admin hour calculations. The 1.5 hours is impressive, but did you factor in the initial setup and configuration time for those SCIM workflows and custom groups? That's a substantial project, not free overhead.

My experience is that the real cost shifts from reactive firefighting to proactive system design and maintenance. You're not doing password resets, but you're now spending that "first week of the month" on audit work. That's still labor, just a different, hopefully more predictable, kind.

The true test is what happens when you change something. Wait until you have to modify those role-based groups or switch identity providers. The hour count might spike again. The efficiency is real, but it's often fragile.

You're right to call out the fragility. I've seen teams bake those setup hours into their first-year TCO and then get burned in year three when they need to restructure after an acquisition.

The audit work is the trade-off, but I'd argue it's a better class of problem. Instead of random 2am "I'm locked out" tickets, you're scheduling an hour on a Tuesday to check reports. That predictability lets you plan, and maybe even delegate it to a junior team member.

The real spike you mentioned, modifying groups or switching IdPs, that's where the initial design pays off or fails. A clean, documented group structure from day one makes those changes manageable. A messy one turns a simple change into a multi-day rebuild.

That 1.5 hour figure lines up with what we see managing ~50 developers with a similar setup. The key for us was treating our vault structure like infrastructure code.

We define custom groups and their vault permissions in Terraform alongside our other access policies. It sounds like overkill, but it means any change, like merging teams after an acquisition, is a PR review and a plan/apply, not a manual UI chore that risks drift. The initial setup is higher, but the ongoing maintenance and future-proofing is near zero.

Your point about the shift from reactive resets to scheduled audit work is the real win. That's operational maturity.

Infrastructure as code for access is the only sane way to handle it long-term. The manual UI process always drifts.

But you've now shifted the risk. That Terraform state file and the service account running the apply become your new single points of failure. If those credentials are over-permissioned or the state isn't locked, you've automated a breach.

Who has merge rights on that PR? That's your new change control bottleneck.

That reduction to 1.5 hours is really compelling. You mentioned the custom groups being a key part - how granular did you get with those role-based definitions? Did you find a sweet spot, or did you start broad and then have to break them down into more specific project-based groups later on?

Totally agree about that being a better class of problem. Scheduling audit work is so much less stressful.

I'm still new to this, so I'm a bit worried. What does "clean, documented group structure" actually look like? Is it just a simple spreadsheet mapping teams to vaults, or is there more to it?

That's a huge drop. I'd really like to hear what your monthly overhead was with LastPass for a direct comparison, even if it's just a rough estimate.

My team is considering a similar move, and the hardest part is quantifying the current pain to make the business case. Having that "before" number alongside your 1.5 hours would be incredibly persuasive.

Also, when you say "automated 90% of user lifecycle events," what was the remaining 10% you still have to handle manually? Is it just edge cases, or are there specific steps SCIM can't cover?

You're right to ask for the comparison number. We were tracking around 8 hours a month with LastPass, but that was just for the standard onboarding/offboarding. It doesn't count the "fire drill" hours for lockouts or failed shares, which probably added another 2-3 unpredictable hours on a bad month.

The remaining 10% is mostly edge cases and exceptions. SCIM handles the standard provision/deprovision from our IdP beautifully, but things like temporary contractor access to a single vault, or fixing a mis-provisioned user when our HR data is wrong, still need a manual touch. Also, any group that exists solely within the password manager (like a special project vault) and isn't tied to an IdP group has to be managed manually. It's a small percentage, but it's there.

That 8-11 hour comparison is exactly the kind of data point I was looking for, thanks. It makes the trade-off so much clearer.

You mentioned manual fixes for when HR data is wrong. Is that a regular issue for you? I'm wondering if there's a way to build some kind of validation step before the SCIM sync happens, or if that's just the nature of the beast.

Good question. From what I've learned so far, a spreadsheet is a good start, but it doesn't capture the logic.

You need to document the *rules* you decided on, not just the result. Like, "This Marketing group gets read-only to the Social Media vault because they only need to log in, not rotate passwords." That way, when a new person joins Marketing, you know exactly what to do without re-figuring it out.

What are you using to document it? Just a doc?

You're right that the initial project cost is real, but it's a capex vs opex trade. Spending two weeks of project time to eliminate a recurring monthly burden is an easy win, even in the most dysfunctional finance department.

The fragility part is the real insight. The setup itself is durable. It's the business logic baked into those groups that rots. When marketing decides they need write access to "just one" prod database vault, your clean structure is toast. That's when the 1.5 hours becomes 15.

Audit work is still work, but at least you can schedule it. Password fire drills happen at 4pm on a Friday.

That point about the business logic rotting is exactly what I'm worried about. We went through a similar process with our ERP permission roles, and it's the same story. You build a perfect role for the "Procurement Clerk," and then a year later someone in that role needs one special approval path for a unique supplier. Suddenly you have a "Procurement Clerk - Exceptional" role, and the sprawl begins again.

It feels like the clean group structure is a snapshot in time, and the audit work isn't just checking compliance, it's constantly evaluating if the snapshot is still valid. How often do you find you need to revise those core group rules versus just handling the one-off exceptions?

The "before" number is seductive, but I'd caution against leaning on it too heavily for your business case. It's a retrospective estimate, and nobody ever logged those "quick" Slack interruptions or the 20 minutes you spend untangling a shared folder mystery. The real pain is the cognitive load, not the clock.

As for the remaining 10%, it's the usual suspects: SCIM is great for the happy path defined by your HR system. When someone's title in Workday says "Engineer" but they need a one-off vault for a finance audit, the automation breaks. Or when you deprovision someone and need to manually reassign their personal emergency contact entries. The 10% is where all the weird, company-specific process cruft lives.