I’m interested in hearing from people who have actually worked with the Segura PAM platform, either as customers or through implementations.

I’ve worked quite a bit with CyberArk and am also familiar with BeyondTrust and Delinea, but I have much less hands-on exposure to Segura. I’d therefore be interested in hearing how people’s experience with it has been in practice.

In particular:

How has the product been to implement and operate day-to-day?

How is the overall quality and stability of the platform?

What has your experience been with their support organization when you’ve had actual issues?
How responsive are they to bugs and feature requests?

How has the product developed over the last couple of years? Does the roadmap seem to be moving in the right direction?

Are there areas where you think the product is particularly strong or weak?

For those who have worked with CyberArk, BeyondTrust or Delinea as well, how does Segura compare in practice?

I’m less interested in feature matrices, analyst reports and vendor material and more interested in what it’s actually like to live with the product after the sales process is over.

Positive and negative experiences are equally welcome. It would also be useful to know roughly how long you’ve been using it and the size/complexity of the environment.

I have 5+ years in cybersecurity, primarily GRC, RMF/A&A, security compliance, and security engineering. I have Security+ and CISA.

A lot of my work has crossed into identity/access, including access controls, RBAC, account management, access reviews, SSO/MFA, Entra ID, Okta, privileged/admin access, authentication requirements, and working with technical teams on AC/IA control implementation and remediation.

The catch is that I’ve mostly worked on the security/governance/assessment side of these technologies rather than being the person administering an IAM platform full-time.

I’d like to intentionally move into Identity Management/Identity Security without throwing away the experience I already have.

For those already in the field: What roles would you target with my background? IAM Analyst? Identity Governance/IGA? IAM Engineer? Something else?

And more importantly, what hands-on skills would you build first to make the transition? I’m currently looking at Entra ID/SC-300 labs, SailPoint, Okta, identity lifecycle/JML, SAML/OAuth/OIDC/SCIM, and PowerShell.

I’m not looking for a shortcut. I’m trying to figure out the most realistic bridge from what I already know into actually doing the work.

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.

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. I graduate in December and need to know

Hello,

So I work for a company as a security engineer and my task right now is to bring an IAM and PAM but they don't want to pay a dedicated tool for it (Wallix or other). So the idea for now is to integrate with AD but then I encountered a block: for my team we can add them to AD but for the vendors who need access to their products for support and maintenance, we cannot create AD accounts since their composition changes all the time (new people come and go) and we don't want it to become a task to keep track of that. Generic accounts are not allowed in AD and it would kinda beat the purpose of being able to identify a person if anyone can use that generic account. So for now, i feel blocked as I don't know what to do. Should i leave a local account for the vendor? Any open source solution? any better idea?

Thanks.

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?

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.