Microsoft Entra OIDC authentication
Implemented for active, pre-mapped CardIQ Identity users where the company integration is deployed and configured.
Enterprise identity documentation
Enterprise SSO, Entra and SCIM status
CardIQ Identity separates authentication, provisioning and employee lifecycle control. Availability depends on deployed code, tenant entitlement and configuration.
Current status
Last reviewed: 2026-09-05. Repository implementation is not the same as production deployment. Where stated, staging or tenant validation is still required.
Entra sign-in policy enforcement
Implemented in the v209 code path. A company can use an optional or required Entra sign-in policy where the supporting release is deployed and readiness checks are satisfied. Existing sessions are not automatically revoked.
SAML login
Not currently active. Stored SAML metadata is configuration foundation only and must not be described as working SAML login.
SCIM 2.0 Users
Implemented in the develop codebase for Enterprise tenant-scoped provisioning with bearer-token authentication, User discovery, create/update/deactivate/reactivate flows, filtering and audit controls. Real staging interoperability validation is still required before a general production-support claim.
SCIM Groups and Bulk
Not currently supported.
Just-in-Time login-user creation
Not currently supported. Entra authentication signs in an existing mapped user; it does not create a new CardIQ Identity login user automatically.
Native Okta integration
No native Okta provisioning or tested generic SAML/OIDC compatibility claim is currently made.
Authentication and provisioning are different
Authentication
Microsoft Entra OIDC verifies the configured sign-in path for an existing mapped CardIQ Identity user. Enforced Entra sign-in is a tenant policy when the v209 path is deployed and enabled.
Provisioning
Provisioning creates, updates, deactivates or reactivates employee identity records. CardIQ Identity provides a Microsoft Graph-based controlled Entra synchronization workflow, and separately contains a SCIM 2.0 Users implementation in develop.
Lifecycle controls
Offboarding and deactivation remain subject to company policy and safeguards. Missing membership in a selected Entra group is not treated as proof that an identity was deleted from Entra.
SCIM implementation boundary
The current implementation is intentionally scoped to Users and conservative lifecycle behavior.
Supported in the current Users implementation
ServiceProviderConfig, ResourceTypes, Schemas, Users list/read/create, PUT/PATCH updates, active=false deactivation, reactivation, userName/externalId equality filters, pagination, tenant-scoped tokens, token revocation/rotation support, rate limiting and audit logging.
Not in scope yet
Groups, Bulk, SAML login, JIT login-user creation and a claim of broad third-party interoperability certification.
Production wording
Until a real Enterprise staging pilot is completed, public wording should say that SCIM Users is implemented and under interoperability validation, not that CardIQ Identity provides generally available production SCIM.
Deployment and readiness
Code availability is not deployment
A capability present in develop or main must still be released to the target environment before it is available to a tenant.
Tenant configuration still matters
Microsoft tenant settings, permissions, selected groups, CardIQ Identity entitlement, mapping and policy configuration must be complete before Entra features can be used safely.
Validate before expanding claims
For SCIM, validate one Enterprise tenant end-to-end: connect, provision one user, update attributes, deactivate, verify public identity is inactive, reactivate with the same mapping, then rotate and revoke the token.
Control how employees represent your company externally
Explore the CardIQ Identity platform or review the workflow from verification through identity deactivation.
See how CardIQ Identity works View pricing