r/iam

Hi Everyone,

I’ve been scrolling through LinkedIn recently and noticed a surprisingly high number of US-based IAM professionals with the green OpenToWork banner. I am curious what may be the reasons.

1. US has more dynamic and competitive labour market, so it was always like this and for every area.
2. Layoffs in tech affecting also IAM pros.
3. AI & Automation decreased the need for IAM pros.
4. Consolidation on IAM products caused IAM teams to shrink.

Would love to hear your thoughts.

Hey everyone! I’m a Senior Backend/IAM Engineer at a large tech company with 10,000+ employees. I’ve been working with Golang for 8+ years, and for the last few years I’ve been focused mostly on IAM and security.

Our team builds and operates most of our internal IAM infrastructure, and all of our services are written in Go.

Some of the things we work on:
- employee identity lifecycle: onboarding, transfers, offboarding;
- automated access provisioning and revocation;
Active Directory and OpenLDAP;
- access reviews and least-privilege processes;
- Keycloak and Ory Hydra;
- OAuth 2.0, OIDC, SSO and 2FA;
- migrating our internal apps from Hydra to Keycloak.

I’m thinking about writing a few technical articles or maybe preparing a conference talk about real-world IAM engineering.

So I’m curious: what would you actually like to hear about? What IAM/security problems do you think aren’t discussed enough?

Happy to answer questions here too, as long as I can do so without sharing anything sensitive or company-specific.

Hey, looking for sailpoint alternatives for a mid size org and honestly the licensing is getting hard to justify rn.

We need something for iam, access reviews, sso and just the usual compliance stuff, but sailpoint feels like overkill for where we're at.
If anyone has moved off it recently, would love to hear what actually worked. thanks!

Hi,

We have a small platform where different agents handle different things for the same customer account. Eg, a support agent that talks to Zendesk, a billing agent for Stripe, one "ops" agent that talks to some internal APIs, plus a generic assistant agent that shows up in the app.

Internally they're all just LLM backed workers with tools, but they each have slightly different behaviour, prompts, access scopes, logging rules etc. Right now the way we identify them is kind of hacked together. We have agent ids in config, some names in the UI, some stuff in headers like x agent name, and then per tenant we sometimes clone configs because someone wants their "assistant" agent to behave more like support.

Its already getting messy In logs, you see a mix of agent id, display name, and whatever the caller put in. In our metrics, we have tags like agent type, agent role, agent namespace. Then routing decisions depend on a mix of user intent and these tags. Feels like we're piling identity onto identity and slowly losing track of what each agent is.

What im trying to clean up rn is:

Central naming / namespacing so an agent has one canonical identity

Something like agent classes vs instances so we can say "this is a support agent" with variants per tenant without duplicating logic everywhere

Clear separation between "who the user thinks they are talking to" and "which internal worker actually handled the request"

I keep bumping into tiny questions all over. Eg, when we spin up a new agent just for a one off workflow, do we give it a durable id and log it forever, or treat it as ephemeral. When we retire an agent, what happens to historical data and dashboards. When an agent calls another agent, which identity shows in the audit trail.

We also need some way to express permissions cleanly, like "support agent can call tickets api but not payments", without having permission sprawl per instance. Right now its half in code, half in config, and I lowkey hate it.

If you're running more than one agent in prod, how do you model identities and roles so it doesnt turn into a naming dumpster fire after a few months? Any tips or patterns appreciated, idk if I should lean more on something like service accounts, or treat agents closer to users in the system.

thanks in advance.

When we first switched to the new IAM system, it was a bit of a struggle, and even after many years I still feel like the existing test environments aren’t always enough—especially when you want to experiment with a new configuration, integration, or use case as a proof of concept. Existing configurations can conflict with the changes you’re trying to test, and IAM setups aren’t always easy to reproduce and test locally.

How do you handle this in your teams, regardless of whether the IAM solution is SaaS or on-prem? Do you have a separate environment, process, or approach for running POCs and validating IAM changes before they reach higher environments?

As a IAM architect, what Technical tools would you use if there was a big transformation project related to IAM that you are expected to work.

Also what level of information does an architect need to put in when designing a solution ?

for example in an IGA solution, we know usually 1 Source of truth and then there are various target apps that we show for provisining and governance, going beyond this what else needs to be shown ?

Hi Guys,

Experienced people who have worked with PAM solutions ( leaving the entra solution- PIM )
How is license fee calculated.
In a traditional IGA solution it would be per account basis but since for PAM we are talking about privileged accounts which are ideally supposed to be less than normal accounts ( but yes there can be cases where service accounts with high privileges are also counted) , in any case how is license fee calculated?

any inputs?

been doing a stack review for our org and the IAM market feels more crowded than ever, but half of it is repackaged provisioning with a new logo. we're on entra for the core directory, but a big chunk of our estate is legacy apps, homegrown stuff, service accounts nobody remembers creating, and a growing number of agents/bots that technically have credentials nobody's tracking. governance tools keep telling us we're compliant, but that's based on what's plugged in, not what exists.

what's in your stack right now that you'd recommend keeping, and what did you rip out?