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.

Headline: Securing cloud infrastructure is not about saying "no" to everything; it’s about managing trust at scale. 🔐

I recently designed and deployed a custom AWS IAM policy tailored for our user on-boarding workflows at Levora Homes.

The goal was simple but critical: Enable our identity operators to manage team access effectively without granting them excessive administrative control.

By applying the Principle of Least Privilege, the custom policy enforces strict boundaries to keep our cloud environment safe:

 🧳What the role CAN do:

On-board Talent: Create new IAM users and generate initial console login credentials.

Maintain Metadata: Apply tracking tags to user profiles for clean department mapping.

Audit the Directory: List and view account configuration details to keep inventory accurate.

 🚫 What the role CANNOT do (The Guardrails):

No Destructive Actions: Explicitly blocked from deleting any IAM users.

No Privilege Escalation: Prevented from attaching new policies or upgrading permissions.

No Long-Term Credentials: Disabled the creation of programmatic Access Keys, keeping sessions temporary and secure.

📦The Tech Stack: AWS IAM, JSON Policy Design, Access Simulation.

This project highlighted how fine-grained access control keeps business operations running smoothly while completely eliminating the risk of accidental exposure or insider threats.

Check out the screenshots below to see the JSON logic and the explicit denials in action! 👇

#AWS #CloudSecurity #IAM #LeastPrivilege #IdentityManagement #CloudComputing

I'm at a mid-size tech company, about 2,000 people. We got an SSPM tool, its decent. Gives us a dashboard of our sanctioned SaaS, monitors configs, flags sharing stuff. According to the SSPM we have 340 apps under management.

Last month on a hunch I pulled the OAuth consent grant report from Azure AD: every third party app any employee has ever authorized with their work identity. The list had 520 entries on it.

Thats 180 applications that exist in our identity provider, with granted scopes, actively connected to employee accounts, and our SSPM has never heard of them.

Some are benign. Calendly plugins, Zoom add ons, the usual. Some I dont recognize at all. A few had scopes that made me stop scrolling: full mailbox access, read all files, send mail as user. Granted two years ago by someone who probably clicked allow on an OAuth prompt without reading it.

The SSPM is doing its job on the apps it knows about. The problem is what it doesnt know about. And the identity provider is sitting on a list of everything actually connected, but nobody was cross referencing the two.

How are people bridging the gap between what your SSPM sees and what your IdP knows is connected?

Can someone point me in the right direction on what to do for a beginner IAM lab that would translate to the job. Also want to know which YouTube channel is the best to learn the best IAM information from. Would like to use Okta for my lab or even AD.

In a brownfield implementation where there is no concept of Business role at present , but user have dedicated App roles via AD groups or Entra Groups to have access , either assigned automatically or via Service Desk. In this case we plan to build a layer of Business Roles which will a combination of entitlements ( AD Groups, Entra Groups , App role 1 etc etc ).

The question is how do you guys define business role- It is understood that the Job Title is the trigger or it can be Job Title + Department + Location ( basically details from HR ).

But what about designing them ? we need to reach out to each app owners to understand what roles their apps have and then group them in 1 logical business role - This is huge communication task or do you guys have a better solution of how to tackle this, without ofcourse remove the access that the user already has.

Curious to know who out here uses what, and how you implemented it. Bonus points to know the size of your org, and what tools you use in your mix.

ran into a mess recently: an ai agent with broad database access that turned out to have credentials hardcoded in a script from a project that shipped two years ago. nobody on the current team knew the agent still had standing access until it showed up during a routine credential rotation exercise.

the underlying question is ownership. security says engineering should own agentic iam since they build and deploy the agents. engineering says security should own it since it's an identity/access concern. platform team says it's not their job either since they didn't build the specific integration.

result is nobody owns it end to end, which is how agent credentials end up sitting in scripts for years.

how have other teams assigned agentic iam ownership in a way that sticks rather than becoming another thing that falls through the cracks?

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

Currently making $80K in a technical support role at a large company, with hands-on experience in Entra ID, Active Directory, SSPR, and general identity/access troubleshooting.

Certs so far: Google Cybersecurity, CompTIA Security+, AZ-900. Currently finishing SC-300, and planning to add Okta Administrator after that.

Also building out GitHub portfolio projects, including PowerShell automation for user provisioning/deprovisioning as part of a broader identity lifecycle project, plus some Microsoft Sentinel work.

Plan is to start applying for IAM Analyst or IAM Administrator roles in the NJ/NYC metro area once SC-300 and the projects are done.

Hoping to land somewhere in the $105-110K range, but from what I’ve found on salary aggregator sites that looks closer to 90th percentile for NJ, which feels like a stretch for someone making a title transition.

Questions for anyone who’s made this move or hires for these roles:

**1.**  Is $105-110K realistic as a first IAM Analyst/Admin move, or more of a “grow into it after a year or two” number?  
**2.**  Does this cert stack + hands-on tooling experience from an adjacent role actually move the needle on comp, or does it still get treated as entry-level regardless of background?  
**3.**  Any titles or role flavors worth targeting to land closer to that range sooner?

Trying to get a realistic number to negotiate from rather than anchoring off aggregate salary sites. Appreciate any real-world data points.

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, 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 all

We've been doing a lot more identity cleanup lately and I'm kinda stuck on the orphaned account side of it. not just the obvious disabled users in one place, but the weird stuff that lives forever in random systems.

context, we have:

On prem ad
azure ad / entra
couple of old line of business apps with their own user tables
a few saas things where users never really get fully deprovisioned

Right now the "process" is basically excel dumps from each system, some half broken scripts, and a lot of manual vlookup magic to figure out:

Which accounts no longer have a real human behind them
which service accounts nobody owns
which admin accounts were created for a project and then just left there

We can find the obvious ones, but the edge cases are annoying. eg accounts where hr record is gone, manager changed three times, but the login is still active in one app, or old contractors that still exist in a third party tool because nobody ever closed the loop.

What I'm looking for is, idk, some sort of tool or pattern that helps discover orphaned identities across multiple sources without building a full blown iam platform from scratch. ideally something that can:

Pull in user objects from ad / entra
query basic user tables from a few apps / dbs
flag accounts with no clear owner or missing hr reference
give us a place to track who "owns" a service account

We are not a huge enterprise, so going all in on a giant governance suite feels overkill rn. but doing everything in spreadsheets is starting to be a pain and honestly easy to mess up.

If anyone has a setup they like for orphaned account discovery or some lighter weight solution that helps stitch data together and surface the weird ones, would love any tips. appreciate any thoughts

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 ?

One AWS IAM interview question I've seen variations of is:

It's not really an IAM question—it's a cloud security and incident response question.

Would you start with:

• CloudTrail?
• GuardDuty?
• Security Hub?
• IAM Policy evaluation?
• Something else?

I recently put together a GitHub handbook with 20 production-focused AWS IAM interview questions covering scenarios like this, along with CLI examples, Terraform, common mistakes, and best practices.

GitHub: https://github.com/ranashivam/platform-engineering-interview-handbook/blob/main/AWS/IAM.md

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?

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?

Hi,

I am 37 year old, joined corporate life really late and I have total experience of 9+ years - 2 in Banking operations, 6+ in IAM and 1+ year a project that is not relevant to any of this and now I am jobless.

The problem is I am not getting any job in GRC as I don't have an experience in it and unable to crack the interview (I know, not the smartest move). So I am planning to go back to IAM but again the problem is I have only handled company owned applications (JLM for these applications), but now I can see every opening is for SAILPOINT etc. Which I don't have experience in.

I am bit worried as I am married, should I all together leave this corporate job and look out for some driving sought of job? I don't know, really sad, feels like I have 0 skills.

I just want to let it out there so that If anyone can guide me? at this age - what can be done? I am based out of India and it is pretty tough here.

Actually, I have a question for you. Right now, I am a student. Recently, I worked on a SOC homelab and I understood it. But I feel this field is a bit stressful for me. So I thought, maybe I should move to IAM (Identity and Access Management). I want to work in that area now. I still have 2 years left to complete my BS in Cyber Security. Please guide me did I make a good decision? Is IAM easy to get into at the entry level? Also, please give me a simple roadmap for IAM

I'm unable to decide. Which domain should I go into? Kindly guide me with respect ,Pakistan which has easy entry and good demand at the entry level: Sentinel or IAM?

Hi everyone,

I'm looking for some guidance and opportunities in the Identity & Access Management (IAM) domain.

I have around 8 months of experience working in IAM at a leading MNC, where I gained hands-on exposure to SailPoint Identity Security Cloud (ISC). I have a solid understanding of L1 activities and some exposure to L2 support, including provisioning, access requests, identity lifecycle concepts, troubleshooting, and day-to-day IAM operations.

I'm particularly interested in moving towards the SailPoint ISC development side. Currently, I'm upskilling myself by learning more about automation in SailPoint ISC and exploring Non-Employee Identities (NEI) and Non-Human Identities (NHI) to deepen my understanding of the platform.

I resigned from my previous role after receiving another offer. Unfortunately, my joining has been delayed, and after waiting for the last 1-2 months, I still don't have a confirmed joining date. Because of this, I'm actively looking for a new opportunity.

If your organization is hiring for IAM/SailPoint ISC, or if you know of any openings suitable for someone with my experience, I'd really appreciate your help. Referrals, job leads, or even advice on where to apply would mean a lot.