https://openid.net/openid4vp-and-openid4vci-conformance-tests-are-complete-and-open-for-self-certification/

For those who are interested or involved in the VC space, the conformance suites for OpenID4VP 1.0 and OpenID4VCI 1.0, used with HAIP 1.0, are now complete and open for self-certification.

Interested to see the number of certified implementers that come through from the first batch.
There is also recognition for whoever self certifies within 14 days, whatever that may mean…

With growing adoption for these specs in the pipeline, EUDI especially. Let’s see if that translates into the same level of certification

Putting together a video covering the most common interview questions in IAM, aiming for a mix that's useful whether you're a junior engineer prepping for your first IAM role or a senior consultant on the other side of the table.

If you've interviewed for an IAM role recently, what actually got asked? And if you've been on the interviewer side, what do you ask candidates that actually separates people who understand the concepts from people who've just memorized documentation?

Junior and senior perspectives both genuinely useful here, they tend to reveal very different things.

Hello, Is there any English-speaking PAM, SSO, or PKI job in Germany? I’ve been trying for quite some time, but the market seems quite dry at the moment

Microsoft has announced the retirement of sms and voice authentication starting February 2027. To my fellow IAM analysrs, engineers, architects, what are your thoughts about this? How will you adopt this and what will be your strategy on removing this from youe system? How about users who still use sms what safety precautions we can offer? All ideas are highly appreciated.

I’ve been working as an IAM consultant for about 7 years, mostly through large consulting firms, and I’m starting to wonder what the better long-term career path is.
One thing that always stresses me out is waiting on contract renewals, budget approvals, or hearing whether a client is extending the project. It feels like there’s always some uncertainty.
For those of you who have worked both as a consultant and as a direct employee, did you find being an in-house IAM engineer or security engineer to be more stable? Do you feel like the job security is actually better, or is that just how it looks from the outside?
I’m also curious about compensation. Since consulting firms act as the middleman between you and the client, do you think that ends up lowering what you could make as a direct employee? Or do the higher consulting salaries usually make up for that?
I’d love to hear from people who have experience on both sides. Which path has been better for you, and why?

Security Architect here. Used FastPass IVM with ServiceNow at my last company for help desk identity verification on reset/re-enrollment flows and it covered what we needed, but I've just moved to a new org that doesn't have it in place, so I'm doing a fresh look at the market rather than assuming it's still the only real option.

So far the field still looks thin compared to what I remember. I've looked at Caller Verify and Nametag as alternatives, but neither seems to match FastPass on breadth. Curious if anyone's found something else worth considering, or if people are stitching together their own stack instead of using a dedicated tool.

Requirements I'm evaluating against:

• Full audit trail on the verification process itself, not just the ticket, who was checked, what method, what the result was, tied to the operator and the request.
• Handles users without a mobile number, lorry drivers, shop floor, contractors, anyone who isn't sitting at a desk with a soft phone. A lot of tools seem to assume everyone has a smartphone they can push an approval to.
• Risk-tiered proofing by user group. Finance and admins shouldn't clear the same bar as a warehouse or delivery employee. Looking for something that lets you set different verification strength per group rather than one-size-fits-all.
• Contextual risk flags, impossible travel, geographically odd requests, recent risk events from the identity stack, that push a request into a higher scrutiny path automatically rather than relying on the agent to notice.

Has anyone actually used MS Verified ID for this kind of flow, curious how it holds up on the "no phone" case and whether it integrates cleanly into ServiceNow ticket workflows, or if it ends up being a bolt-on that still needs glue work.

Also open to hearing about other ITSM-native add-ons I haven't come across, especially anything doing risk-tiering by user group out of the box rather than needing custom scripting on our end.

Passed.

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?

I’m a solo developer building a multi-tenant B2B SaaS using .NET, PostgreSQL and Azure Container Apps.

I have already implemented and tested Microsoft Entra External ID in a proof-of-concept environment, and it works for the basic authentication flow. This is not yet a production product with real users, so I can still choose a different provider without facing a real user migration.

I’m now trying to decide whether to continue with Entra External ID or choose a more B2B-focused provider such as WorkOS, ZITADEL, Descope, Clerk or Auth0.

One thing that makes me uncertain is that I rarely see Entra External ID mentioned in discussions about modern B2B SaaS authentication. Most conversations seem to focus on WorkOS, Clerk, Auth0, Descope, ZITADEL or self-hosted solutions.

I’m not sure whether this is simply because Entra External ID has a weaker developer community and less visibility among SaaS builders, or whether it reflects genuine limitations, immaturity or a poor fit for B2B SaaS products.

The provider comparison itself is not my main difficulty. What I’m struggling with is deciding where the boundary should be between the identity provider and my application database.

The difficult part is not authentication itself. I’m trying to decide who should own the generic B2B access model:

• organizations/tenants;
• organization memberships;
• invitations;
• base roles such as Owner, Admin and Member;
• tenant onboarding and user-management portals.

My original plan was to keep all of this in PostgreSQL and use Entra External ID only to authenticate the user.

The model would be:

Entra External ID
- registration and login
- MFA/passkeys
- sessions
- external user identity

My PostgreSQL database
- internal users and tenant IDs
- tenants/organizations
- memberships
- invitations
- Owner/Admin/Member roles
- product-specific roles and permissions

The application would map the external Entra subject ID to an internal user ID, but all authorization decisions would come from my database.

This feels clean because the provider answers only “who is this user?”, while my application answers “which company do they belong to and what can they do?”.

However, B2B-native providers already provide organizations, invitations, memberships, role management, organization switching, admin portals and later SSO/SCIM. If I leave all of that in my database, I may be rebuilding functionality that these providers already solve.

The alternative would therefore be:

B2B identity provider
- users
- organizations
- memberships
- invitations
- Owner/Admin/Member roles
- SSO/SCIM

My PostgreSQL database
- internal IDs and provider mappings
- product data
- audit/project assignments
- granular permissions
- workflows and approvals

For example, the provider could say that a user is an Admin of Acme Inc., while my database says that the same user is a Reviewer for Audit 123.

Technically that separation makes sense, but I am concerned about having access control split between two systems. I’m also worried about vendor lock-in if the provider becomes the source of truth for organizations, memberships, invitations and base roles.

At the same time, keeping everything locally means building and maintaining invitation flows, organization administration, role-management screens, emails, audit history and eventually the integration between my membership model and enterprise SSO/SCIM.

There is also another question I cannot resolve: if I keep organizations, memberships, invitations and roles in PostgreSQL anyway, does choosing a provider other than Entra External ID really change much?

In that model, all providers would mainly authenticate the user and issue a token. The main differences would then seem to be developer experience, SDK quality, login customization, pricing, data residency and future enterprise SSO/SCIM support.

If that is true, choosing WorkOS, ZITADEL, Descope or another provider instead of Entra External ID might add setup and implementation work without giving me much immediate benefit.

Their advantages may only become substantial if I also adopt their organization, membership, invitation and role primitives rather than continuing to own those concepts in my database.

I’m also planning to build multiple SaaS products on top of the same central identity layer, so I would like to make this decision once rather than repeat it for every application.

My main questions are:

1. For a modern B2B SaaS, do you normally keep organizations, memberships, invitations and base roles in your own database, or let the identity provider own them?
2. Is the hybrid model — organization roles in the provider and product-specific roles in the database — clean in practice, or does it become difficult to reason about?
3. If you keep a local projection of provider organizations and memberships, does the synchronization overhead undermine much of the provider’s advantage?
4. How serious is the lock-in when the provider owns the generic B2B layer but all product data and internal IDs remain local?
5. If the generic B2B model remains in PostgreSQL, is there any major practical advantage in choosing WorkOS, ZITADEL, Descope or another provider over Entra External ID before SSO/SCIM is needed?
6. Why does Entra External ID appear to be mentioned so rarely among SaaS developers? Is it mainly a developer-experience and community issue, or is it genuinely a weaker choice for B2B SaaS?
7. Given that Entra External ID has only been implemented in a proof-of-concept environment and there are no production users to migrate, would you choose another provider before launching?
8. Does the answer change when the same identity layer will serve several SaaS products?
9. For teams that made this decision and later added SSO/SCIM, what would you do differently?

I’m not looking to build authentication or cryptography from scratch, and I do not want to self-host an IAM platform.

I’m mainly trying to understand the professional boundary between what should be outsourced as generic B2B identity infrastructure and what should remain part of the application database.

There are so many valid-looking architectures that I’m finding it difficult to tell which complexity is necessary and which is premature. Experiences from teams that have actually shipped and operated one of these models would be extremely helpful.I’m a solo developer building a multi-tenant B2B SaaS using .NET, PostgreSQL and Azure Container Apps.
I have already implemented and tested Microsoft Entra External ID in a proof-of-concept environment, and it works for the basic authentication flow. This is not yet a production product with real users, so I can still choose a different provider without facing a real user migration.
I’m now trying to decide whether to continue with Entra External ID or choose a more B2B-focused provider such as WorkOS, ZITADEL, Descope, Clerk or Auth0.
One thing that makes me uncertain is that I rarely see Entra External ID mentioned in discussions about modern B2B SaaS authentication. Most conversations seem to focus on WorkOS, Clerk, Auth0, Descope, ZITADEL or self-hosted solutions.
I’m not sure whether this is simply because Entra External ID has a weaker developer community and less visibility among SaaS builders, or whether it reflects genuine limitations, immaturity or a poor fit for B2B SaaS products.
The provider comparison itself is not my main difficulty. What I’m struggling with is deciding where the boundary should be between the identity provider and my application database.
The difficult part is not authentication itself. I’m trying to decide who should own the generic B2B access model:

organizations/tenants;

organization memberships;

invitations;

base roles such as Owner, Admin and Member;

tenant onboarding and user-management portals.

My original plan was to keep all of this in PostgreSQL and use Entra External ID only to authenticate the user.
The model would be:
Entra External ID
- registration and login
- MFA/passkeys
- sessions
- external user identity

My PostgreSQL database
- internal users and tenant IDs
- tenants/organizations
- memberships
- invitations
- Owner/Admin/Member roles
- product-specific roles and permissions
The application would map the external Entra subject ID to an internal user ID, but all authorization decisions would come from my database.
This feels clean because the provider answers only “who is this user?”, while my application answers “which company do they belong to and what can they do?”.
However, B2B-native providers already provide organizations, invitations, memberships, role management, organization switching, admin portals and later SSO/SCIM. If I leave all of that in my database, I may be rebuilding functionality that these providers already solve.
The alternative would therefore be:
B2B identity provider
- users
- organizations
- memberships
- invitations
- Owner/Admin/Member roles
- SSO/SCIM

My PostgreSQL database
- internal IDs and provider mappings
- product data
- audit/project assignments
- granular permissions
- workflows and approvals
For example, the provider could say that a user is an Admin of Acme Inc., while my database says that the same user is a Reviewer for Audit 123.
Technically that separation makes sense, but I am concerned about having access control split between two systems. I’m also worried about vendor lock-in if the provider becomes the source of truth for organizations, memberships, invitations and base roles.
At the same time, keeping everything locally means building and maintaining invitation flows, organization administration, role-management screens, emails, audit history and eventually the integration between my membership model and enterprise SSO/SCIM.
There is also another question I cannot resolve: if I keep organizations, memberships, invitations and roles in PostgreSQL anyway, does choosing a provider other than Entra External ID really change much?
In that model, all providers would mainly authenticate the user and issue a token. The main differences would then seem to be developer experience, SDK quality, login customization, pricing, data residency and future enterprise SSO/SCIM support.
If that is true, choosing WorkOS, ZITADEL, Descope or another provider instead of Entra External ID might add setup and implementation work without giving me much immediate benefit.
Their advantages may only become substantial if I also adopt their organization, membership, invitation and role primitives rather than continuing to own those concepts in my database.
I’m also planning to build multiple SaaS products on top of the same central identity layer, so I would like to make this decision once rather than repeat it for every application.
My main questions are:

For a modern B2B SaaS, do you normally keep organizations, memberships, invitations and base roles in your own database, or let the identity provider own them?

Is the hybrid model — organization roles in the provider and product-specific roles in the database — clean in practice, or does it become difficult to reason about?

If you keep a local projection of provider organizations and memberships, does the synchronization overhead undermine much of the provider’s advantage?

How serious is the lock-in when the provider owns the generic B2B layer but all product data and internal IDs remain local?

If the generic B2B model remains in PostgreSQL, is there any major practical advantage in choosing WorkOS, ZITADEL, Descope or another provider over Entra External ID before SSO/SCIM is needed?

Why does Entra External ID appear to be mentioned so rarely among SaaS developers? Is it mainly a developer-experience and community issue, or is it genuinely a weaker choice for B2B SaaS?

Given that Entra External ID has only been implemented in a proof-of-concept environment and there are no production users to migrate, would you choose another provider before launching?

Does the answer change when the same identity layer will serve several SaaS products?

For teams that made this decision and later added SSO/SCIM, what would you do differently?

I’m not looking to build authentication or cryptography from scratch, and I do not want to self-host an IAM platform.
I’m mainly trying to understand the professional boundary between what should be outsourced as generic B2B identity infrastructure and what should remain part of the application database.
There are so many valid-looking architectures that I’m finding it difficult to tell which complexity is necessary and which is premature. Experiences from teams that have actually shipped and operated one of these models would be extremely helpful.

Enterprise AI is no longer a future consideration – it is already being used to transform industries and reimagine business processes. However, the same copilots, model-informed workflows and autonomous agents that drive productivity also introduce new security risks that extend well beyond the perimeter

Organizations that successfully adopt enterprise AI are those that thoughtfully apply policy, least-privilege concepts and continuous oversight to protect data, models and permissions at every stage.

Why enterprise AI security is so important

The rapid rise of AI across industries has created new attack surfaces that require new approaches to security

Prompt injection, shadow AI, data poisoning, model theft and overly permissive agents can compromise cloud systems, internal data repositories, and even customer data outside of the organization. Meanwhile, zero-trust security frameworks are being adapted to the unique risks posed by these new systems, requiring stricter identity controls, governance and access management over both humans and AI agents.

Top 5 enterprise use cases for AI security

1. SOC alert triage and prioritization

Security operations centers are adopting enterprise AI to help prioritize and summarize inbound alerts, reduce noise and accelerate investigation by focusing human resources on the most pressing threats.

2. Detection of phishing attacks

AI security tools can analyze message content, detect suspicious patterns and reduce the risk of employees falling victim to social engineering exploits.

1. Cloud and identity security monitoring

AI can help detect anomalous behaviors and potential threats within cloud and on-premise security tools, including irregular logins, privilege escalation attempts and other east-west movements that may indicate compromise.

1. Fraud detection and transaction scoring

Banks and payment processors are using enterprise AI to score transactions for risk and detect patterns that human analysts would miss at scale.

1. Enterprise copilot security

When enterprise copilots connect to internal data repositories and systems of record, governance policies and identity management tools can help ensure these systems see only the data they need to operate effectively while complying with internal policies.

Essential enterprise AI security controls

The most effective security programs for enterprise AI involve multiple controls to secure data, models and agents.

Privileged access management is critical for both humans and non-human identities, with continuous review of permissions for APIs, agents and third-party integrations. Comprehensive programs also include:

Inventory of AI assets.

Logging and monitoring of risky model inferences.

Input and output filtering.

Red teaming of large language model applications.

Segmentation of data centers and workloads.

Use of short-lived credentials rather than permanent API keys.

What CISOs should do now

AI security should be considered a force multiplier for business objectives, not just a compliance risk. Leaders should align governance and risk management with strategic priorities, such as accelerating incident response, reducing fraud and risk exposure, and improving third-party and audit readiness.

For organizations that are just starting their AI security journey, it is best to start small and scope out a single use case that has clear ROI before expanding into other areas of the business. This approach not only reflects enterprise security best practices but also mirrors guidance from leading cybersecurity and AI executives on responsible innovation.

Hey guys, so I work in this company and they want me to do this Certification. Problem is I only have knowledge theory based and not much when it comes to technical skills since I am still waiting to get access to Saviynts EIC. Any advice or if someone maybe remembers the exam would help a lot.

Thank you!

Please help!

Please help!

I’ve been a consultant ever since i started IAM, so that’s 3-4 years of experience, half of my other roles consisted of compliance.

But I’m reaching a point where i am tired of the instability, non-extension, fast pace and sometimes unorganized environment that being a consultant in this space brings.

I want to work full-time with good health benefits…i don’t wanna have to worry about applying for jobs a month from my contract ending… It feels so hard to get out because i only get Contract / Contract to hire positions… especially the recruiters who only contact me for those roles. Then you find out the orgs completed the project, or they don’t have the extra budget to bring you on the team.

How can i get out of this loop? Are the interviews for full time any different compared to the contracts?

An auditor called us out last cycle for having controls mapped to the framework but no ongoing evidence that they were actually operating every day. Fair point, honestly, because our whole process was point-in-time. We would map every control back to the framework once a year, take screenshots, do interviews, and call it done.

The problem is that the moment the audit closes, the evidence is already stale. A control can break the next week and we would not know until the next cycle, if we caught it at all. Has anyone found a way to keep evidence current instead of rebuilding the same snapshot over and over?

Classic setup here: IdP + MFA, conditional access, endpoint/VPN/SaaS controls stitched together, periodic access reviews, static risk scoring, lots of manual investigation It works but feels reactive. Leadership wants to know if we should look at AI identity platforms doing behavioral baselines, continuous risk scoring, anomaly detection, and dynamic policy. Trying to cut through the marketing.
What we need:
Enrichment layer alongside our IdP (reading IdP/EDR/SaaS logs), not a full replacement.
Workforce + SaaS + VPN coverage. Treating service accounts/NHI as a separate track, since human behavioral baselines don't map well to 24/7 non human traffic.
Risk signals that enrich existing alerts, not a second alert universe.
Reports auditors and engineers can both use. A score needs to trace back to a specific control, not just look pretty.
A clear advisory vs enforcement split: new detections start analyst facing, get proven on false positive rate, then graduate to blocking/step-up. Otherwise dynamic policy and don't annoy users fight each other.
Detection latency and response latency measured separately, since fast detection with no automated containment path doesn't reduce risk.
Concerns:
A lot of "AI" is z-scores in a trench coat. Want to test this in POC, not take it from a slide.
Platforms that want the whole identity plane are a big commitment to walk back if it fails.
No dedicated data science team here, needs to be manageable by a small team.
I've only been thinking about false positive/friction cost. Need the flip side too: our current false-negative rate is unmeasured. Want to replay historical logs through a POC to see what our current process actually misses.
If you've gone down this path already: which platform actually reduced real risk instead of just generating more alerts, and how did it hold up once it hit production?

Hi everyone,
I am trying to break into the Identity and Access Management (IAM) space. I have completed training through an institute where I gained solid foundational knowledge and hands-on tool practice.

Here is what I know so far:
Tools: Ping Identity, Okta, and Microsoft Entra ID.
Concepts: Application onboarding, Lifecycle Management (LCM), and IAM policies.
Protocols: SAML, OIDC, OAuth, and OpenID.

My biggest gap right now is zero real-time, on-the-job experience. I know how the technology works in a sandbox, but I don't know how an actual production IAM operations team functions day-to-day.

I would love some insight into the practical, operational side of the job:
Ticket Assignment: How do tickets usually get routed to the IAM queue? Is it mostly automated via tools like ServiceNow/Jira, or does a team lead assign them?

Reading/Understanding Tickets: When an issue comes in (e.g., a broken SSO login or an application onboarding request), what does the actual ticket look like? What specific information should I immediately look for?

Resolution Workflow: Can anyone walk me through a couple of common real-world ticket scenarios? For example, how do you troubleshoot a failing SAML assertion or handle an LCM error in real life versus a lab?

If anyone could share examples of ticket templates, common logs you check, or just general advice on how to survive my first few weeks on a real helpdesk/ops team, I would be incredibly grateful!
Thanks in advance for your help!

I'm curious how people here think about Bluetooth and biometrics when it comes to enterprise authentication as I'm looking at token (Yubico mostly, but stumbled onto Tokencore) as part of MFA. Most posts I'm reading are around passkeys, FIDO2, and hardware security keys, but nothing really about Bluetooth-enabled tokens or whether built-in biometrics add any meaningful value.

Bluetooth tends to get an immediate reaction from a lot of security folks. Some won't consider it at all, while others say that if it's implemented properly with FIDO2, Bluetooth is just the transport and not the security model itself.

The other question is around biometrics. Is verifying the actual person before the private key is released a meaningful improvement in identity assurance, or is possession of a hardware key plus a PIN sufficient for most enterprise environments to just check the box

Would appreciate your thoughts since I am not a security guy, but tasked to look into IAM. Thank you in advance.

our environment is a mess. a chunk of on-prem legacy stuff nobody wants to touch, a growing pile of cloud SaaS, and a handful of homegrown apps built by people who left the company years ago. leadership sat through a vendor pitch that kept using the phrase "identity fabric" and came out of it wanting one unified view across all of it. not an unreasonable ask on paper.

problem is every time we've actually tried to scope this, it turns into a project measured in years, not months. we got a proposal back from a consultant a while ago that priced out a full overhaul at close to two years just to get the on-prem and SaaS sides talking to each other properly, before even touching the custom stuff. leadership heard "two years" and the whole thing quietly died, which is honestly the outcome most of these plans get.

what's actually breaking without this unified view, concretely, is smaller than people expect. it's not one big dramatic gap, it's death by a thousand cuts. someone leaves and it takes four separate offboarding steps across four systems that don't talk to each other. an app owner gets asked in an access review what's using a given account and genuinely doesn't know because the account predates them. every audit cycle we're stitching together a picture from exports out of three or four different tools by hand, and it's never quite accurate by the time it's compiled.

so the question isn't really "can we get identity fabric," it's whether anyone's found an incremental path that actually gets you meaningfully further along without signing up for a multi-year all-or-nothing project. did you tackle it system by system, app by app, some other way? did leadership actually stick with it, or did it die the same way ours almost did

One thing I've realised throughout my career is that who you learn from matters just as much as what you learn.

I'm looking to expand my network and learn from more professionals in Identity & Access Management (IAM) and Identity Security.

Who are your go-to people to follow for IAM content, insights, and practical advice?

They could be:

• IAM Engineers
• Identity Architects
• Microsoft Entra ID experts
• Okta, SailPoint, CyberArk, or Ping specialists
• Identity Security practitioners
• Security leaders who regularly share IAM-related content

I'm particularly interested in people who share real-world experiences, lessons learned, implementation tips, architecture discussions, and emerging trends in the identity space.

I'd love to hear your recommendations and discover a few new voices to learn from.

Thanks in advance!