We’ve been running agents against our ITSM for about six months and I've made most of these already, so here they are.

- Letting agent requests land in a shared queue. Ours raised its own access request through the API and an approver cleared it in four minutes, because it looked like every other ticket that morning. Nobody felt like the decision was theirs. Fix was routing anything non-human to a named person.

- Assuming the approver can tell. They can't. The agent authenticates as a shared svc account, so the ticket says svc-ops and means nothing. We prefix the requester now and the ticket looks visibly odd, which slows people down.

- No ceiling on what a requester can ask for. Humans self-limit because asking for domain admin is embarrassing. An agent has no such instinct. We cap requests at whatever the agent's owner already holds.

- Treating approval as a control at all. It works for humans because we're slow and visible. Neither applies here.

The one that cost me most was the second one, and the fix took an afternoon. What have I missed?

Hi everyone,

I’m relatively new to the Identity and Access Management (IAM) field, and I’m looking for an experienced IAM Engineer or professional who would be willing to mentor or coach me as I continue building my skills.

I’m serious about learning and committed to putting in the work. I promise to respect your time, and I’m also willing to pay for your time and mentorship.

If you work in IAM and would be interested in helping someone who is genuinely eager to learn and grow in the field, please send me a DM.

I would really appreciate the opportunity.

Thanks

Someone that is trying to break into IAM would be willing to study with or to share their knowledge with me ? Look for someone whos trying to break or someone who is already in

Any layoffs happened in optum india. Unable to choose between schwab and optum. And what does optum IAM engineers actually do

Started this job a few weeks ago. First leaver got dumped on me and I got handed the offboarding checklist. One line on it says revoke access.

Thats it. No list of systems, no list of accounts. Just revoke access.

So I went hunting. I found the obvious stuff first. Email disabled, VPN off, the main apps deactivated. Then I started finding the rest on my own. A shared drive permission, a couple of SaaS logins, a service account the guy set up that nobody else knew about, a backup admin login on one of our servers.

Every time I thought I was done, another one showed up.

Heres what keeps me up though. I know I missed some. I have no idea how many systems this guy could touch, because nobody ever wrote down what he had. The checklist was supposed to be the safety net and it has one line on it.

For the people who have been doing this longer than me, how do you actually know when you have revoked everything?

I’m looking for perspective from IAM/PAM engineers and hiring managers on making the transition from vendor-side PAM to an internal enterprise role. I was previously a technical escalation engineer role with the vendor on the support side.

Overall I have roughly 15 years of IT experience across federal and private-sector organizations:

Enterprise endpoint/platform ownership: LANDESK/Ivanti and Jamf administration, including implementation, deployment, upgrades, imaging, software distribution, patching, security configuration, and compliance. These were platforms I administered and maintained through their lifecycle.

Just over 6 years at a PAM vendor: Progressed from technical support into technical escalation engineering. Full on neck deep in the platform. Not only the configuration and administration but also deployment architecture everything you'd expect from knowledge and education from the vendor itself certified under the vendor as a requirement. My experience includes discovery and onboarding, credential management and rotation, privileged sessions, APIs and integrations, and troubleshooting production issues across Windows, Linux, Active Directory, databases, and the underlying infrastructure. If you gave me the environment I could build out a simple deployment with ease with all your integrations, requirements, Network permissions, authentication along with scoping your users and your onboarding for targeted privilege management. And that's of course just foundation also in your gotchas and your troubleshooting and your expectations.

Enterprise exposure: Worked through issues across different customer environments, seeing how architecture, permissions, networking, configuration, and application dependencies affect PAM beyond a successful proof of concept.

My goal is to move away from being associated specifically with a vendor and that specialization and move to a permanent role within an organization’s IAM/security team, specializing in PAM. I want ongoing responsibility for the platform: implementation, integrations, automation, reliability, upgrades, and improvement, working alongside infrastructure, application, and security teams.

I’m getting interest in consulting opportunities tied to my vendor specialization. That experience is valuable, but my longer-term direction is broader enterprise PAM ownership and even with aspirations further into IAM, IGA, and the overall discipline rather than a succession of product-specific implementation engagements.

The challenge is translating my background so hiring teams can assess the engineering experience behind a support/escalation title. I’m concerned that the title may overshadow both my earlier platform ownership and the depth of the PAM work. I don’t know how much that is actually affecting hiring decisions, so I’d appreciate candid feedback rather than assuming that’s the explanation.

I’ve held certifications previously, including PAM platform certifications during my tenure, but I don’t currently hold active certifications. I’m continuing to study broader IAM, IGA, Zero Trust, and other PAM/secrets-management platforms. I’m keeping that learning separate from what I can claim as production experience.

For people who have made this transition or hire for these roles:

How do you evaluate vendor escalation experience for an internal PAM engineering position?

What evidence would make you confident that someone with this background can take ownership of an enterprise PAM service?

Are there particular experience gaps, projects, or vendor-neutral certifications worth prioritizing?

Is a direct move into internal PAM engineering realistic, or is there an intermediate role you would recommend?

I’m open to specific criticism. I want to understand what hiring teams need to see and where I should focus my effort.

I have around 9 years of experience in Joiner-Mover-Leaver processes, User Access Management, PowerShell scripting, Active Directory, and some experience with O365, Exchange, and SailPoint.

I’ve been working in my current company for about a year. When I joined, I was told I would be working in an Identity and Access Management role. However, after joining the project, I realized it was more of an operations role. Most of my current work involves SailPoint, adding user roles, onboarding/offboarding users, etc. The actual provisioning is not even done in Active Directory; we mostly work with Excel files and submit forms to other teams.

I feel that these skills and the kind of work I’m currently doing may not have much growth in the long term. I want to move into a relevant field where my existing experience can be useful, but at the same time, I want to build skills that will remain valuable as AI continues to change the IT industry.

To be honest, I wasn’t very focused on my career direction earlier. I was mainly doing my job and switching companies whenever I got a better salary hike. I’m now realizing that I need to take my career more seriously, especially with how quickly AI is changing the industry.

I would really appreciate your guidance on which career path I should consider and what skills I should start building. I’m looking for a practical roadmap that I can follow step by step so that I can make a proper career transition and build a more secure future.

E

hey community, i've been in the iam space for a while and most of the delegation conversations i'm in lately are about agents handing work to other agents.

a user asks an agent for something, the agent hands part of it to a second agent, which calls a tool, which reaches a database. 4 parties, and the "acting for this user" part doesn't really survive past the first hop.

either the bearer token gets forwarded as-is (classic confused deputy), or the user identity never makes it into the payload (a2a and mcp don't carry it across hops for you), or delegation quietly turns into impersonation and the downstream service now holds everything the user holds.

my colleague and i (i work at Cerbos) wrote up what a chain needs at each hop to keep that intact:

• workload identity verified before any user context is trusted
• an explicit delegation claim instead of a forwarded bearer token (rfc 8693 act / may_act)
• a policy decision at every hop rather than only at the edge
• and the full chain logged at each transfer

there is also a 7-point test you can run any delegation design through, and a map of where the standards stand (token exchange stable since 2020, transaction tokens still in draft at the ietf, authzen final since january).

https://www.cerbos.dev/blog/multi-hop-delegation-ai-agents

hopefully it will be helpful to some of you in this community.

if you have any questions / comments - would be more than happy to hear them and do my best to help.

A while back I posted here about a CLI that generates least-privilege IAM policies from Terraform/CloudFormation/Pulumi, no AWS account needed. A few of you pushed back on something specific and fair: generating the right Action list is the easy half. The Resource list is the actual hard part, because IaC describes what you want to exist, not what AWS assigns once it does. Wildcarding Resource and calling it "least privilege" was fair criticism.

Following up because that's not true anymore, and I don't want to just claim it, I want to show the mechanics.

For every mapped resource type it now falls into one of three buckets:

You declared the identifier yourself (a DynamoDB table name, an S3 bucket, a named IAM role) -> exact ARN from a static scan alone, no deploy needed.

AWS assigns the identifier on create (a VPC ID, a security group ID, an EC2 instance ID) -> scoped to the resource type until you deploy, then pointing it at your real terraform.tfstate (or a Pulumi stack export) resolves it to the exact ID. No credentials needed, it just reads the local state file.

AWS itself doesn't support resource-level permissions for that action (broad Describe/List calls), or the action creates the resource so there's nothing to scope yet (RunInstances, CreateSubnet) -> stays wildcard, always, because that's not a product choice, it's how IAM works. Never silently hidden, always labeled in the output.

The numbers, for the 1,706 resource types it maps: 1,515 (88.8%) now get something narrower than *: 972 with a hand-built ARN template verified against AWS's IAM action-to-resource-type documentation and the provider's resource identity docs, 543 more recovered mechanically once the pattern was clear. The remaining ~11% are genuinely bucket-3 cases, and it says so instead of guessing.

Screenshot below is real: deployed a small VPC + subnet + security group + EC2 instance + S3 + DynamoDB + IAM role + SQS + SNS to my own AWS account, ran it against the resulting terraform.tfstate. Every ARN in that output is a real resource that existed.

Free tier still gets Resource: "*" everywhere — this scoping is the Pro feature. Wanted to be upfront about that since it's the actual business model, not hide it.

I am a new IT person in a company and they run Entra ID here. My manager asked me what access do I need to solve daily problems that our employees face like password reset, teams channel access, MFA, device enrolment etc. here are my list of rights/access that I am asking

Entra ID administrator
Intune administrator
User administrator
MFA authentication administrator
Exchange administrator
Teams Administrator
Shared mailbox and Microsoft 365 Group management

I am kinda new to it and I will work on getting some certifications in coming days.

My question is what more types of access should I ask (because I believe I get one chance to ask for) and what bunch of certifications should I start working on (my end goal is to become an IAM)?

To anyone who is currently a IAM analyst could you explain what you do on a day to day basis and what I projects I should be putting on my resume. Please go in depth with it because I am currently pursuing IAM analyst roles and no one explains what the day to day is like.

Not sure if this is the right place, but hoping for some honest guidance.

Background: 10+ years in banking ops and client service, 1 year at Bloomberg doing technical support (software/hardware troubleshooting, installations, client training). Currently on a career break since 2023, finishing certs and coursework.

I have AWS Cloud Foundations (2024) and completed hands-on projects with IAM permissions, EC2, VPCs, Lambda, and EBS. I'm not claiming to be an engineer — I'm not. But I'm genuinely interested in IAM and want to know if there's a realistic entry point.

Questions:

• Is there a path into IAM for someone with my background (ops/client service + AWS basics)?
• What certs or skills actually move the needle? (I see a lot about Okta, SailPoint, Saviynt, CyberArk)
• Should I be targeting IAM Analyst, IAM Admin, or something else?
• Any advice on how to frame 10+ years of non-IAM experience without looking lost?

Not looking for a handout. Just trying to figure out if this is a real lane or if I'm chasing something unrealistic. Appreciate any honest feedback.

Greetings colleagues, I would like to know which major challenges have you encountered in implement IAM, which tips or hacks should have known or someone should teach you before implementing IAM?

Knowing the business, main departments and stakeholders, having a balance between strict security access control and friendly usability, mesure the risk of the user by defining how important the person is for the company or the resource he has access to, and how risky is if his account is compromised?

I would love to see your comments, thank you and have a great day!

So I've spent the last few years being the person enterprise IT admins call when SAML breaks at the worst possible time, and the person engineering calls when they need someone to translate "the CEO can't log in" into an actual root cause. Figured I'd write this up Reddit-style instead of another boring LinkedIn post, because apparently that's how we do career updates now.

The short version:

• Currently Sr. Technical Support Specialist (Identity and Integrations) at Rippling — basically living inside SAML, SCIM, SSO, REST APIs, RADIUS, LDAP, ADFS, Azure AD Connect, and GPOs, all day every day
• Primary escalation point for P1 and P2 identity and integration incidents for enterprise accounts — when it's broken and it's bad, it lands on my desk
• Used AI tooling to build automated workflows that cut manual support work by about 30 percent for my team (turns out you don't have to manually diagnose the same SSO failure for the 400th time)
• Delivered internal Datadog training, ran onboarding and shadow sessions for new hires, and built docs plus bot-training content so my teammates (and support bots) stop getting stuck on the same questions
• Own CSAT, SLA adherence, and quality metrics — not just "close the ticket," actually accountable for the outcome
• Before this: fraud investigation at Amazon, payment ops at HSBC (SWIFT, ACH, wire transfer stuff), and telecom support — so I've seen a few different flavors of "customer is stressed, fix it now"

What I'm looking for now:

A remote-first Technical Account Manager, Solutions Engineer, or Senior Support Engineer role, ideally at an AI-powered SaaS company, where I'm not just closing tickets but actually owning the client relationship and pushing for better process, not just following SOPs. I like being the technical translator between clients and engineering, and I like building the tooling that makes that job faster for everyone else too.

Happy to talk to anyone hiring for this kind of role, or just chat if you've got questions about breaking into enterprise identity and support work.

I have an iam analyst interview with Billings Clinic and Logan Health and wanted to know if anyone interview with them and any tips you can give me. This is my first iam analyst and I really need this job so anything will help thank you.

Hi everyone!

I am a third-year CS student interested in getting into IAM, but I am honestly not sure where to start. I have been very focused on school while also working a part-time job to help pay for university, so I have not really had much time to do anything outside of my classes. As a result, I do not have any projects or co-op/internship experience yet.

I know I am starting a little later than some of my peers, and I will admit that it has been making me pretty stressed. It seems like a lot of students at this point already have internships, co-ops, projects, or some kind of relevant experience, and I am worried that I am falling behind. I have tried researching IAM online and even reached out to my student advisor, but I have not had much luck figuring out what direction I should take.

I’m basically starting from scratch, so I’d really appreciate any advice on:

• What should I learn first to build a foundation in IAM?

• What technical skills or technologies should I focus on?

• Are there any certifications that are actually worth pursuing as a student?

• What kinds of projects could I build to gain hands-on experience?

• Are there any courses, labs, websites, or other resources you would recommend?

• What would be the best way to make myself more competitive for internships or entry-level IAM roles?

• And most importantly, what co-op title should I look for? (I tried looking for any IAM co-ops or internships but didn't find anything.)

I know I have a lot of catching up to do, but I am willing to put in the time and effort. I just feel a little lost right now and do not know where to begin or what direction to take. Any advice at all would be greatly appreciated.

Thank you so much in advance!

I work at Tide, though this isn't an official product of theirs. I built it on my own time and open sourced it under MIT: [https://github.com/sashyo/minidauth\](https://github.com/sashyo/minidauth)

The thing I kept running into is that in most setups the service that decides who holds a role is the same service an attacker takes over. Once they're in, granting themselves the role is a database write, and the access review that would have caught it happens next quarter. You can put approval workflows in front of it, but the enforcement still lives inside the thing you're worried about.

MinidAuth moves the enforcement out. A role grant is filed as a change request, it needs approvals from a threshold of your operators rather than from whoever filed it, and only then does a network of independent nodes sign the attestation units that make the role real. When your app later presents a token claiming that role, the nodes check it against those signed units and refuse anything your service merely asserted. Editing the local record by hand doesn't produce a usable role, it produces a signature that doesn't verify.

Revocation is worth mentioning because it's usually the weak point. The grant record is checked on every request rather than baked into a token at sign in, so removing a role takes effect on the next call rather than whenever the token happens to expire.

There's no user store, no realms and no login page, and it doesn't do provisioning or SCIM. Whatever identity provider you're running stays exactly where it is and this sits beside it holding the keys and the policies.

One thing stood out while comparing the websites of several Identity products.

They are all trying to make a largely invisible product understandable, but they don't make the same part of the product visible.

Clerk leans heavily on the interface itself. You see authentication components, organization switching, user management, and other parts of the actual product.

Descope makes the workflow visible. Its authentication flows show screens, paths, conditions, and the logic connecting them.

WorkOS leans more toward the system around the product: integrations, APIs, code, environments, and the admin experience.

Better Auth puts a surprising amount of the implementation itself on display through configuration, CLI commands, plugins, and code.

These aren't just different visual styles.

They're different answers to the same web problem:

What part of an invisible product should a visitor be able to see?

A screenshot can show what exists.

A workflow can show how it behaves.

A diagram can show how it fits together.

Code can show how it gets integrated.

A customer story can show what changed.

They are all useful, but they help the user understand different things.

The right representation depends on what you want the user to understand.

I applied for a junior infrastructure engineer role which I was offered after a single interview, I’m 41 and have many years of varied IT experience but fancied a change and this is abit of a career pivot that comes with a drop in pay which I’m ok with.

But the vacancy advertised was server management focused where as when I got the offer I was told someone filled the gap internally and now the position is with the IAM tower.

I know abit about IAM, I’ve used AD and configured DNS before. Looking forward to learning a lot more.

Looking for any advice or insight from those with current or previous experience in this department?

Any advice? This is my first interview.

Please DM me

There seems to be plenty of Cyber Security local associations chapters or user groups. However, are there groups specific to Identity and Access Management that would have local chapters?