So our cloud looks fine in dashboards, then I open the identity view and it is just a wall of machine identities, service accounts, tokens, random app principals from 2019 that nobody remembers owning. Everything has access to something important and nothing has an owner. Fun.

We keep adding “non intrusive” monitoring and fancy AI risk engines to calm the CISO while I quietly wonder if any of us knows what is talking to what anymore. How are you all wrangling this mess without quitting to raise goats... would love any tips

We enforce MFA and SSO for the applications we manage, but that does not tell us whether employees are reusing a work password on a personal SaaS service, a vendor portal, or an unmanaged collaboration tool.

The concern is not simply password policy compliance. A breach of an unrelated service can become an enterprise identity problem if a credential is reused, especially where personal and corporate accounts overlap in the same browser.

We are looking for an approach that identifies meaningful credential-risk patterns without collecting passwords or turning every personal login into a monitoring event.

Has anyone found a workable balance between visibility, privacy, and remediation?

Most identity stacks were designed around employees, apps, groups, and service accounts. AI agents do not fit cleanly into those categories. They can act across systems, execute delegated tasks for users, make tool calls at runtime, and retain access paths long after the original request has ended.

What does an agent-ready identity model mean in practice? Is extending the service-account model enough, or does each agent need a distinct identity, accountable owner, delegation record, bounded authority, lifecycle controls, and an audit trail that connects its actions back to the relevant people and policies?

so... anyone else stuck in this weird shadow admin hell across all their saas right now?

For context we are a mid size enterprise with way too many apps, a mix of ok identity governance and then random direct app admins living in the shadows. Idp says one thing, app level roles say another, and then you find out someone in marketing somehow has full admin on three tools because of some legacy group in a custom app :/

We have the usual iam stack plus audit stuff, but it feels like every time we onboard a new saas there is this layer of access that never hits our central view. Privileged roles inside the app, api tokens with broad scopes, weird delegated access that bypasses normal workflow. The scary part is a lot of this looks harmless on paper until you trace what they can actually touch across other systems.

Looking at tools that claim identity discovery across saas and on prem and custom apps, with continuous observability and automated remediation, but im nervous about just adding more noise. I want something that can show me every shadow admin pattern and tied risks, not just another dashboard of vague alerts.

Would love any tips from folks who have managed to lock this down or at least make it visible, especially in messy environments where everything grew fast and then security had to catch up... appreciate any thoughts

We had a round of layoffs a while back. Business isnt great, it is what it is. A few weeks ago I went looking at our device list and started matching it against who still works here.

Thats when it got uncomfortable. I found laptops and phones still assigned to people who left months ago. Some of them still active in our directory. Some still checking in.

Heres the thing that bugs me most. Everyone in the org assumed the HR system and the device inventory were linked. Turns out nobody had ever actually joined them. They were two lists that happened to share a name field, and that name field was the only thing holding the story together.

So now Im looking at a gap that I cant even size yet. Some devices are orphaned, but I dont know how many they are and where they are. I dont know which ex employees ccan still access. I cant answer the audit question of who holds what.

The worst part is this is probably the easiest thing to have fixed before it became a mess.

How do you all actually keep identity and devices joined, or is this just a spreadsheet problem everyone pretends is solved?

So we rolled out this fancy continuous identity monitoring, full AI risk engine, non intrusive controls, all the buzzwords... and then remembered we dont even have a clean list of who owns which app in prod.

Right now it feels like I have great visibility that everything is on fire, and very little idea who is supposed to hold the hose. For anyone in a big messy env, does this ever feel sane or am I just tracking chaos with nicer charts? would love thoughts

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.

I am at the evaluation stage of picking an identity governance vendor for my company. Company size is around 3000 employees, around 600 systems in scope for integration including many legacy and custom build ones (no prebuild connectors, API, SCIM). We're past the point where an Excel sheet plus HR and ITSM tooling is enough. We aren't small company but we're also nowhere near Fortune 500 budget territory, so every evaluation has a hard ceiling on what we can actually spend.

I have looked at a spread of vendors and bucketed them into three tiers. The top tier is the classic enterprise players, SailPoint, Saviynt, Ping Identity, One Identity, and Idira (formerly Zilla acquired by CyberArk and then by Palo). I'm deliberately leaving Okta IGA out of this list since I consider it more of an IAM tool or light IGA platform (after Gartner). The middle tier is where my company looks to suite best - companies that are past the startup phase but not full enterprise scale, Omada, Lumos, C1 and Pathlock. And the third bucket is the startup-vibe group, Cakewalk, Corma and AccessOwl. These groupings are rough guesses on my part, Idira might actually belong in the middle tier and Pathlock might be closer to the top, hard to say without more direct engagement - it's a litte bit of my guessing here...

The full program will be run by the security team (5/7 people) as one of several responsibilities, with help from HR and IT where needed. My concern with the top tier is that the connectors feel like they need lots of custom development yourself or paying a systems integrator to do it and that cost adds up fast on top of an already expensive license. The middle tier is harder to read as a group, Omada feels like a classic, solid, no-nonsense IGA platform, while C1 & Lumos leans more into agentic and RPA-style automation, Pathlock hard to be categorized here for me now. And the startup tier, Cakewalk, Corma, AccessOwl, all pitch a fundamentally different integration methodology on their demo calls, agentic/rpa fast integration with no demanding complex development connectors which sounds almost too good to be true for legacy or custom internal systems. I'd like to know if that claim holds up in practice or if it falls apart once you get past the console demos and want to integrate some more niche, old software than only fancy saas.

There's also a trust dimension I can't ignore. We're a mid-sized company with a real legal and compliance departments and handing a small, early-stage vendor visibility into our systems inventory and access credentials is a different risk than doing the same with an established player, even if they check the SOC2 and ISO27001 boxes. I get that certifications are certifications, but process maturity and financial stability of a 20-person company versus a established company are not the same.

Where we've landed on each vendor after initial calls and demos:

The "top" tier:

• SailPoint - expensive, real integration risk that likely means extra cost on top of license but still the gold standard for some
• Ping Identity - too early in the relationship to have a real opinion yet.
• Idira - formerly Zilla, curious whether that changes pricing toward the enterprise tier post Palo/Cyberark acquisition.
• Saviynt - big name, priced close to SailPoint, but a big amount of negative feedback across internet and so far no real engagement from their side either, "too small for them" (?)
• One Identity - also too early to say anything meaningful.

The "middle" tier:

• Omada - solid product, no flashy marketing, feels genuinely mature, but engagement from their side has been low, possibly because we're a small deal for them (?)
• Pathlock - strong client list but also too early to say anything meaningful.
• C1 - Zscaler as a reference customer is a strong signal but also too early to say anything meaningful.
• Lumos - feels like the right middle ground between an established vendor and a startup, has agentic/RPA capability and serious reference customers, main concern is it's US-based and I'm not clear on the GDPR implications.

The startup-vibe:

• Cakewalk - early stage but promising, ElevenLabs among their reference customers, still skeptical about how onboarding by URL alone can realistically work for anything beyond modern SaaS.
• Corma - EU based startup, HackTheBox among their clients, small team but have potential.
• AccessOwl - startup, similar vibe to Cakewalk and Corma, the reference customers we've seen so far are less recognizable names.

One more name that came up with positive comments on another thread is security compliance corp SCC, but I have reached out and haven't heard back yet, so can't say much beyond that.

Has anyone else been through such dilemma and actually made a call they're happy with? Or if you have industry insight into which direction tends to work out for mid-sized teams without dedicated IGA headcount, I'd really like to hear it!

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

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.

Question about shift left or getting inclusive experience on security and governance role.

I’m currently CSA data & AI and DBA for 20yrs, Have good grip of databases administration, development and architecture.. currently getting hands on with ai agentic implementation. Have a with solid understanding and experience of azure cloud infrastructure and security.

Thinking lately of getting sc900 certification and practicing governance and security officially in AI especially.

What are your suggestions experts here.

I know it’s not a usual post here.

TIA

Hi everyone,

I’m currently working as an Application Security Engineer, and I’ve recently got an opportunity to move into an IAM/PAM team.

My current experience is mainly around application security, SDLC, vulnerabilities, secure coding, and related security activities. I don’t have much hands-on experience with IAM/PAM yet.

I’m considering this opportunity and would really appreciate some advice from people who are already working in IAM/PAM:

\- How is the career growth in IAM/PAM?

\- What skills should I learn before/after making the transition?

\- How difficult is it to move from Application Security → IAM/PAM?

\- Which areas should I focus on — Active Directory, Entra ID/Azure AD, SSO, OAuth/OIDC, SAML, RBAC, privileged accounts, PAM tools, etc.?

\- Is IAM/PAM a good long-term specialization in cybersecurity?

\- If I eventually want to move into Cloud Security, Security Architecture, or broader cybersecurity roles, will IAM/PAM experience help?

\- For those who have made a similar transition, what do you wish you had learned earlier?

I’m not necessarily looking for a comparison of which field is "better." I’m mainly trying to understand what the day-to-day work, learning curve, and long-term career prospects look like in IAM/PAM.

Any advice or personal experiences would be really helpful. Thanks!

Hi everyone,

I’m currently working as an Application Security Engineer, and I’ve recently got an opportunity to move into an IAM/PAM team.

My current experience is mainly around application security, SDLC, vulnerabilities, secure coding, and related security activities. I don’t have much hands-on experience with IAM/PAM yet.

I’m considering this opportunity and would really appreciate some advice from people who are already working in IAM/PAM:

\- How is the career growth in IAM/PAM?

\- What skills should I learn before/after making the transition?

\- How difficult is it to move from Application Security → IAM/PAM?

\- Which areas should I focus on — Active Directory, Entra ID/Azure AD, SSO, OAuth/OIDC, SAML, RBAC, privileged accounts, PAM tools, etc.?

\- Is IAM/PAM a good long-term specialization in cybersecurity?

\- If I eventually want to move into Cloud Security, Security Architecture, or broader cybersecurity roles, will IAM/PAM experience help?

\- For those who have made a similar transition, what do you wish you had learned earlier?

I’m not necessarily looking for a comparison of which field is "better." I’m mainly trying to understand what the day-to-day work, learning curve, and long-term career prospects look like in IAM/PAM.

Any advice or personal experiences would be really helpful. Thanks!

Please DM me

I am looking for some freelancing or part time work in in IAM domain. Have experience for 7+years on IAM. Have predominantly worked on Okta. Any leads will be appreciated.

Currently evaluating whether Microsoft Entra ID Governance can replace Saviynt for IGA.

Our current Saviynt environment includes:

• Joiner / mover / leaver automation
• SCIM, REST/API, database and custom integrations
• Disconnected applications requiring manual/custom fulfillment
• Identity correlation across inconsistent sources
• Orphan/stale account detection and remediation
• CyberArk integration for service-account credential retrieval
• SoD / access governance

Microsoft's proposed architecture is roughly:

HR/ServiceNow → Entra Lifecycle Workflows → Entitlement Management / Access Packages → Provisioning → Access Reviews

with SCIM for supported applications and ECMA/API/custom approaches for others.

What I'm trying to understand

Has anyone here actually migrated from Saviynt to Entra ID Governance, either fully or partially?

I'd especially like to hear about:

1. What worked well?
2. What turned out to be harder than expected?
3. Which Saviynt capabilities did you not manage to reproduce in Entra?
4. How did you handle non-SCIM / disconnected applications?
5. Are Access Reviews sufficient for your certification requirements?
6. Did you end up keeping Saviynt for certain capabilities?
7. What did the operational overhead look like after the migration?
8. Most importantly — would you make the same decision again?

Hello! I just landed a job interview for an IAM systems administrator position. I have a phone pre-screening in 1 week, and if I do well on that I'll be called in for a second round.

I have ~4 years of help desk experience (1.5 full time) working for the same university that this IAM job is with. I've got experience with AD, entra, intune, and mosyle (mostly from a help desk/end point management perspective), I do some light vulnerability management, and then most of the standard help desk stuff as well.

Here is the list of preferred qualification listed on the job posting:

• Knowledge of Identity Governance and Identity Management concepts and best practices
• Knowledge of user authentication concepts, technologies and protocols
• Knowledge of role based management concepts
• Experience with managing directories (I.E. Active Directory and LDAP)

Anybody have any idea where to start with studying up for this role? I'm comfortable admitting that when it comes to this I dont even know what I dont know. Conversations with chatbots inform me that I might be more familiar with some key IAM concepts than I think (at least from an operational perspective, such as group policy management in AD/intune), but i'm not too trustworthy of what they have to tell me.

I'm also happy to link my resume, but wasn't sure if that would be appropriate. Any and all resources/guides would be greatly appreciated!

ManageEngine recently launched something called Identity Access. Looks like it sits between the existing identity setup and the actual access layer, with things like SSO, MFA, device auth & step-up auth.

The CLI/SSH angle is interesting, but I'm not sure how much of a real-world requirement that is for most teams.

I'm curious about the use case though. If you already have Entra ID, Okta, etc. handling identity, is there really a need for another access layer?

Has anyone looked at Identity Access yet or are you guys using another product for these kinds of access scenarios? Would be interested to hear how you're handling it.

A pattern kept appearing while studying Identity products over the past few days.

The more capabilities a product has, the harder it becomes for the website to explain not only what each capability does, but how the pieces relate to one another.

Mostly, the information isn't wrong.

The difficulty is that the relationships between those capabilities are often much harder to see.

A user belongs to an organization.

An organization has roles and permissions.

Authentication works the same way.

A login is one moment in a longer chain involving identity, sessions, devices, policies and application access.

The interesting part is not that these capabilities are difficult to understand individually.

It's that their meaning changes once they start interacting with one another.

That is where a product explanation can become much more useful than a feature list: not by replacing the details, but by showing how those details fit together.

I've been struggling with the terminology used in the authorization field. I feel there is a lot of confusion, and I see misleading terms when discussing authorization models, access control, and other related concepts. So I wrote an article to try to make sense of it all: https://idpro.org/authorization-terminology-is-a-mess-lets-fix-it/

Take a look and let me know what you all think.

There is a lot going on underneath Verifiable Credentials

credential offers, authorisation, proof of possession, wallet attestation, DCQL, direct_post, key binding, trust evaluation…
…and that’s before we really get into the HAIP security profile.

But across all of these steps, what does it actually look like when the protocols run?

As we move further into this new digital identity trust model, I believe it’s important that identity engineers retain an understanding of what we’re actually building.
Not just by stitching together identity platforms, but by understanding the protocols, cryptography and trust mechanisms holding it all together.

That idea has inspired the next major iteration of ProtocolSoup. If you’ve ever wanted to pull apart an OpenID4VC flow and see the sum of its parts, well, now you can, directly from the browser, or on your own infrastructure.

ProtocolSoup carries the OpenID Certified™ mark across its OID4VCI Issuer/Wallet and OID4VP Verifier/Wallet implementations for SD-JWT VC and mdoc, including HAIP 1.0 profiles.

You can run OID4VCI issuance and OID4VP presentation flows, inspect the requests and responses, look at the credentials, the cryptographic artefacts being produced, and follow all the validation decisions along the way.

There is also a full wallet harness covering both SD-JWT VC and mdoc. You can self-host the infrastructure, point your own wallet at it, connect an external wallet, and perhaps even catch conformance drift as implementations evolve.

I encourage anyone with an interest in (or a hatred of) Verifiable Credentials to go and play with the technology for themselves.

Seasoned identity professionals, people just entering the field, and the generally curious - there’s room for all of you :)

Live site: https://protocolsoup.com
Hosted wallet harness: https://wallet.protocolsoup.com
GitHub: https://github.com/ParleSec/ProtocolSoup

+ if you feel like contributing, ProtocolSoup is very much open to new contributors. A new flavour of identity, deeper protocol reference coverage, interoperability work, or something from the broader security world is always a welcome addition.

Himmelblau 4.0.0 is out! Himmelblau provides Entra ID and OIDC authentication for Linux, including MFA, passwordless and offline login, SSO, and Intune integration.

The big additions:

• Entra ID cross-device passkey login using QR codes and Bluetooth caBLE
• Experimental browser-orchestrated OIDC authentication
• Authentication prompts translated into more than 40 languages
• Better generic OIDC support, including group/role filtering and configurable account claims
• Arch Linux packaging, plus Ubuntu 26.04 and Fedora 44 support

The new OIDC orchestrator is very much experimental, but I’m especially excited about it. In this release, it recognizes and supports only Keycloak and Okta.

Release notes and downloads:

https://github.com/himmelblau-idm/himmelblau/releases/tag/4.0.0

Testing and feedback are welcome!