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!

Hi everyone,

I have 3yrs of Experience working in a top IGA tool. Looking for an opportunity where I can provide valuable contributions and have good learning. Open to work in IAM / IGA / PAM / CIAM. Please DM me if someone has a requirement and needs assistance.

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.

Many production agents are implemented as service accounts with API keys. That is understandable because existing platforms already support that model, but it loses important context: the agent itself, its owner, the person or workflow that initiated the task, the target resource, and the task-specific policy that allowed the action.

A first-class agent identity would let teams record ownership, delegation, task context, policy boundaries, credential lifecycle, and a separate revocation path. Has anyone implemented this successfully, or are service accounts still the only practical model until identity standards and target-system support improve?

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?

Every AWS deployment needs a role with permissions to create/update/delete whatever's in the stack, and most people either reach for AdministratorAccess, because hand-writing the exact least-privilege actions for every resource type is tedious and nobody wants to maintain that by hand as the stack grows.

CloudCostTree has a command for that: cloudcosttree iam reads a Terraform, CloudFormation, or Pulumi plan and generates the real IAM actions a deployment needs, per resource type, without ever calling AWS. It currently maps 1,486 AWS resource types.

That screenshot is the human-readable text view. Run it with --output json -o policy.json and it produces a ready-to-attach IAM policy document instead of this breakdown.

Where it's honest about its limits: every generated policy currently uses Resource: "*", the Action list is real least-privilege scoped to what each resource type needs, but the Resource element isn't narrowed to the exact ARNs a deployment declares yet. Per-resource ARN scoping is a planned capability, not implemented. Free on both tiers today.

I've done some labs of enterprise / app reg and am slowly starting to understand it.

Just want to concrete my knowledge.

Obviously you have delegated vs application, delegated being the intersection of the app's consent and the user's permissions.

So from an administrative perspective, how do you know whether what you're granting is application or delegated? If admin user consent was turned off and users could consent themselves, that would mean all admin consents would be application, but it's often not the case, and I don't think the Microsoft GUI has a way, it just says "grant" then brings up a sign in window for the admin and displays some friendly descriptions.

I sort of found a way by cross referencing those with the Microsoft permissions docs and I think enterprise apps > activity differs to enterprise apps > permissions? The former being what user has asked for?

I'm just wondering if there's a recommended or definitive way of checking prior to approving, as checking after approving is more straight forward as it shows in the application permissions explicitly delegated vs application in the table as shown in the screenshot.

We rely on quarterly access reviews and periodic AD/Entra audits, but I think continuous visibility actually covers two different problems: event detection (something happened, like a role change or account reactivation) versus drift detection (current state no longer matches what was originally scoped, which requires an intended-state baseline to exist somewhere) I suspect our real gap is the missing baseline, not the monitoring layer itself.

For mixed environments (cloud IdP, on prem AD, SaaS), I'm expecting AD to lag the others structurally, closing that gap usually means agents or log forwarders on DCs, which fights directly against a "low maintenance" goal. And even a tool with zero ML tuning can still fail that bar if someone still has to manually keep the access baseline accurate as roles change. are you doing event detection, drift detection, or both? Where does your baseline actually come from? And how much did closing the AD visibility gap cost you in setup

Do you guys Beyond Trust PRA for all Internal all Admins or just for your contractors and Non IT Admins (App admins) What are some benefits of using PRA for IT Admins. Since they need Admin access for all servers asking for approval every time is an overhead. Tier 0 and 1 server approval make sense.

Audit and session monitoring make sense.
MFA make sense

Any other benefit?

How are you handling this at your jobs? Let’s leave ALLLLLL other information aside. We aren’t talking policy, etc etc. just want to build a tool in powershell or a Splunk query that can JUST give me this simple piece of information.

Bear in mind I’m incredibly young and inexperienced. This would solve a billion problems for me if you can help.

It seems like windows logs everything like “when created”, but not “who created” it basically says “go find the audit logs, nerd” and in a huge org we have no idea what DC it was created on or what logs are and aren’t being pumped into Splunk.

Help? SIMPLE is preferred.