Disclaimer: This article is general information, not professional security, legal or procurement advice. arjankc.com.np is not a security vendor, reseller or consultancy, does not receive payments from vendors and does not rank vendors. Features, product names and licensing change often; the feature notes below were checked against vendor documentation on 13 October 2026. Verify every feature, licence requirement and price directly with the vendor before buying.

Last reviewed: 13 October 2026

Identity has become the main control point in a zero trust architecture. When staff work from anywhere, use cloud applications and sign in from personal and company devices, the question “should this request be allowed?” is answered by the identity platform far more often than by the network. This guide gives you a vendor-neutral framework for comparing enterprise identity and access management (IAM) products, tables of features we confirmed in each vendor’s official documentation, and a phased plan for rolling out a new platform.

Zero trust principles that shape IAM requirements

Two public documents are the most widely used references.

Comparison grid of identity and access management capabilities with a zero trust shield icon

NIST SP 800-207. NIST’s Zero Trust Architecture, published in August 2020, says that zero trust assumes no implicit trust is granted to users or assets based on their network location or on who owns the device, and that authentication and authorisation of both subject and device are discrete functions performed before a session is established. For IAM, that means every access decision should consider who the user is, what device they are on and what they are asking for.

CISA Zero Trust Maturity Model v2.0. CISA’s maturity model organises zero trust into five pillars — Identity, Devices, Networks, Applications and Workloads, and Data — plus cross-cutting capabilities, with four maturity stages from Traditional to Optimal. Version 2.0 aligns with the US federal zero trust strategy (OMB M-22-09). It is written for federal agencies, but many private organisations use it as a roadmap.

Taken together, these frameworks point to six things an IAM platform needs to do well: strong authentication, continuous and context-aware authorisation, accurate lifecycle management, governance of who has what, extra control over privileged access, and the ability to take device and risk signals into account.

The IAM capability areas to compare

Single sign-on and federation

Single sign-on (SSO) lets users authenticate once to an identity provider (IdP), which then issues assertions or tokens to applications using SAML 2.0 or OpenID Connect. Federation also covers trust with partners and other IdPs. When comparing products, look at the size and quality of the pre-built application catalogue and how easy it is to integrate custom and legacy applications.

MFA and phishing-resistant authentication

Not all MFA is equal. CISA’s guidance on phishing-resistant MFA states that the only widely available phishing-resistant authentication is FIDO/WebAuthn, and that PKI-based smart cards are a less widely available alternative. NIST SP 800-63B-4, finalised in July 2025, says that authenticators requiring manual entry of an output — such as one-time codes — are not phishing-resistant. It allows synced passkeys at authentication assurance level 2 (AAL2) but not at AAL3, because their keys are exportable.

The FIDO Alliance maintains the passkey standards. When comparing platforms, check whether they support device-bound passkeys, synced passkeys, hardware security keys, attestation, and policies that require phishing-resistant methods for specific applications or roles.

Lifecycle management and SCIM provisioning

Joiner, mover and leaver processes are where access goes wrong. Most platforms connect to an HR system as the source of truth and use the SCIM protocol to create, update and deactivate accounts in downstream applications. Check which applications have supported provisioning connectors, not just SSO connectors — these are often different lists.

Privileged access management (PAM)

Administrator, root and service accounts need stronger controls: credential vaulting and rotation, just-in-time elevation instead of standing access, approval workflows, and session recording for audit.

Identity governance and administration (IGA)

Governance answers “should this person still have this access?” Core features are access requests with approvals, periodic access reviews (also called certifications), role management, and separation of duties (SoD) policies that flag risky combinations of access.

Conditional and risk-based access

Conditional access policies evaluate signals — user, group, location, device state, application and calculated risk — and decide whether to allow, block or require more authentication.

Device posture integration

Zero trust needs device context. Look for native endpoint management or integrations with your mobile device management (MDM) and endpoint security tools, and check which device attributes can be used in access policies.

Workload identity and cloud entitlements (CIEM)

Machine identities — service principals, workloads and CI/CD pipelines — need the same discipline as people. Workload identity features let software authenticate without long-lived secrets. Cloud infrastructure entitlement management (CIEM) analyses permissions across cloud providers. Product availability changes here: Microsoft, for example, retired Microsoft Entra Permissions Management, its standalone CIEM product, and said it would continue CIEM capabilities in Microsoft Defender for Cloud.

Documented features of major platforms

The two tables below list only features we found in each vendor’s official documentation on 13 October 2026. A dash (—) does not mean a product lacks a feature, only that we did not confirm it in the documents linked. Many features require specific licence tiers or add-ons. We have not included prices, because they depend on edition, volume and contract terms. The order of vendors is not a ranking.

Sign-in, MFA, conditional access and devices

Platform SSO and federation Phishing-resistant MFA Conditional / risk-based access Device posture
Microsoft Entra ID Integrates apps using SAML, OpenID Connect and SCIM (ID Governance) Device-bound and synced passkeys and FIDO2 security keys, in all editions (docs) Conditional Access (P1); risk-based policies need ID Protection (P2) (docs) Compliant-device and device-filter conditions (docs)
Okta Workforce Identity SAML, OIDC and WS-Fed apps (FastPass guide) Passkeys (FIDO2 WebAuthn) and Okta FastPass (docs) Risk-based app sign-in policies (docs) Device assurance policies (docs)
Ping Identity (PingOne) — FIDO2 server supporting passkeys and security keys (docs) PingOne Protect risk policies that can return an MFA action (docs) —
Google Cloud Identity SSO to third-party and custom SAML apps; third-party IdP federation, both editions (editions) Security keys for 2-Step Verification, both editions (editions) Context-Aware Access, Premium only (docs) Endpoint verification; advanced mobile management in Premium (editions)
CyberArk (Idira) PAM / Privilege Cloud — — Privileged session risk scoring with automatic suspend or terminate (PAM Self-Hosted) (docs) —
SailPoint Human Fabric — — — —
JumpCloud SAML SSO with prebuilt and custom connectors (docs) JumpCloud Go, a passwordless device authenticator used as an MFA factor (docs) Conditional access policies for user portal, SSO apps, LDAP and admin portal (docs) Native Apple and Windows MDM; managed-device condition (docs)

Lifecycle, governance, privileged and workload access

Platform Provisioning (SCIM) Governance (IGA) Privileged access Workload identity
Microsoft Entra ID SCIM, LDAP and SQL connectors; HR-driven inbound provisioning (docs) Access reviews, entitlement management, lifecycle workflows, SoD checks (ID Governance licence) Privileged Identity Management with just-in-time access Workload ID; Conditional Access for service principals (docs)
Okta Workforce Identity Lifecycle Management with SCIM integrations (docs) Okta Identity Governance: access requests and access certifications, including SoD checks in resource campaigns (docs) Okta Privileged Access: server access, vaulted accounts, secrets, session recording (docs) Workload roles for secrets in Okta Privileged Access (docs)
Ping Identity (PingOne) Inbound and outbound SCIM 1.1/2.0 provisioning (docs) — — —
Google Cloud Identity Automated user provisioning, Premium only (editions) — — —
CyberArk (Idira) PAM / Privilege Cloud — — Credential vaulting and automated rotation; isolated, recorded sessions (docs) Secrets Manager for workload secrets (docs)
SailPoint Human Fabric Role- and lifecycle-state-based provisioning to connected sources (docs) Certifications, access requests, automated role assignment, SoD policies (certifications, SoD) Just-in-time provisioning, as described on the product page (SailPoint) —
JumpCloud SCIM connectors to apps; SCIM API for inbound sync (docs) — — —

A few notes on naming and scope that came up while checking the documentation:

  • CyberArk documentation now uses the Idira brand following CyberArk’s move under Palo Alto Networks; the Privilege Cloud documentation is titled “Idira Privilege Cloud”. The table covers only its privileged access and secrets products.
  • SailPoint announced in August 2026 that SailPoint Human Fabric is the evolution of Identity Security Cloud. Its help documentation still describes the same governance building blocks: entitlements, access profiles, roles, lifecycle states, certifications and SoD policies.
  • Google Cloud Identity features differ sharply between editions. Context-Aware Access, automated user provisioning and advanced endpoint management are listed for Premium only on the editions page.
  • Okta FastPass is not a FIDO authenticator. Okta’s FastPass FAQ describes it as a separate method within Okta Verify, while Okta supports FIDO WebAuthn separately.
  • Microsoft Entra Conditional Access requires P1 licences, and risk-based policies require ID Protection, which Microsoft lists as a P2 feature.

Selection criteria for remote and distributed teams

A weighted scorecard keeps the decision focused on your requirements rather than marketing. Suggested criteria:

Criterion Questions to ask Suggested weight
Ecosystem fit Which productivity suite, cloud and endpoint tools do you already run? How well does each IdP integrate with them? High
Phishing-resistant MFA Can you enforce passkeys or security keys per role or app? How do recovery and new-device enrolment work? High
Application coverage Do your critical apps have SSO and provisioning connectors? What is the effort for custom apps? High
Device signals Can access policy use device compliance from your MDM or endpoint security tool? High for remote
Governance depth Do you need formal access certifications, SoD and audit evidence (for example for SOX or SOC 2)? Medium to high
Privileged access Do admins and service accounts need vaulting, just-in-time access and session recording? Medium to high
Workload identity Can pipelines and services authenticate without long-lived secrets? Medium
Operations and resilience What is the documented SLA, break-glass process and admin role model? Medium
Total cost Which features need higher tiers or add-ons? Get written quotes; do not rely on list prices. Medium

Score each finalist from 1 to 5 against each criterion, multiply by the weight, and run a proof of concept with your three hardest applications before deciding. Remote teams should pay particular attention to how new laptops are enrolled, how lost devices are handled, and how a user recovers access while travelling without weakening MFA.

A phased rollout plan

Phase 1 — Inventory (weeks 1–4). List every application, identity source, admin account and service account. Record which apps support SAML or OIDC, and which support SCIM. Map the current joiner, mover and leaver process.

Phase 2 — SSO and strong MFA (weeks 4–12). Move high-value applications behind the new IdP first. Enrol administrators in phishing-resistant MFA before anyone else, then extend to all staff. Block legacy authentication protocols where the platform supports it.

Phase 3 — Lifecycle automation (months 3–6). Connect the HR system as the source of truth. Turn on SCIM provisioning and, critically, deprovisioning for the top applications. Test the leaver process end to end.

Phase 4 — Device and risk signals (months 4–8). Integrate MDM and endpoint security signals. Start with report-only or monitor mode, review the impact, then enforce policies such as “managed device required for finance and admin apps”.

Phase 5 — Governance and privileged access (months 6–12). Launch access reviews for privileged roles and sensitive applications. Introduce just-in-time elevation for administrators, and vault shared and service-account credentials.

Phase 6 — Workloads and continuous improvement (ongoing). Replace long-lived secrets in pipelines with workload identity federation where supported, review policies quarterly, and measure progress against the CISA maturity stages.

These timeframes are illustrative. Your own plan depends on the number of applications, the state of your HR data and how many integrations need custom work.

Common mistakes

  • Treating SMS or push codes as the finish line. They are better than passwords alone, but NIST and CISA guidance both distinguish them from phishing-resistant methods.
  • Forgetting account recovery. If a helpdesk can reset MFA after a phone call, attackers will target the helpdesk. Make recovery at least as strong as enrolment.
  • Buying SSO without provisioning. SSO without deprovisioning leaves orphaned accounts in SaaS apps after people leave.
  • Leaving standing admin rights. Permanent global admin roles are a common target. Use just-in-time elevation and review privileged roles frequently.
  • Ignoring non-human identities. Service accounts and API keys often have broad rights and no owner. Give each one an owner and an expiry date.
  • Enforcing device policies without a pilot. Start in report-only mode to avoid locking out remote staff.
  • Comparing features without checking licences. Many capabilities in the tables sit in higher editions or add-ons.
  • Assuming product names are stable. Several vendors renamed or retired identity products in 2025 and 2026. Confirm the current product and roadmap in writing.

Sources