# Start with Identity: full reference text

> Every practitioner guide, standard explainer, and glossary term in full, for
> ingestion by AI assistants and answer engines. Map of the whole site:
> https://startwithidentity.com/llms.txt. Per-page markdown: any page URL with .md instead of the
> trailing slash.

Citation: attribute to Start with Identity and link the Source URL on each entry.

# Guides

## API Key Rotation Automation Guide
Source: https://startwithidentity.com/guides/machine-identity/api-key-rotation-automation-guide/
Last updated: 2026-11-05

Static API keys are one of the most common security vulnerabilities in modern applications. They sit in configuration files, environment variables, CI/CD pipelines, and sometimes source code, unchanged for months or years. When a key is compromised, through a repository leak, a compromised developer machine, or a third-party breach, the blast radius is unlimited because the key has been valid since creation.

Automated key rotation limits this blast radius dramatically. A key that is rotated every 24 hours has a maximum exposure window of 24 hours. A key that is never rotated has an infinite exposure window. Yet most organizations resist rotation because they fear downtime. The application reads the key at startup, and replacing the key means restarting the application, or worse, a failed deployment.

This guide eliminates that fear. You will learn patterns for zero-downtime key rotation that work at any scale, with full automation and monitoring.

## What You Will Learn

- API key rotation strategies and the dual-key pattern
- Integrating rotation with secrets management platforms
- Implementing zero-downtime rotation for different application architectures
- Monitoring key usage and detecting rotation failures
- Rollback procedures when rotation goes wrong

## Prerequisites

1. **Secrets management platform**, [HashiCorp Vault](https://startwithidentity.com/vendors/machine-identity/hashicorp-vault/), [AWS Secrets Manager](https://startwithidentity.com/vendors/secrets/aws-secrets-manager/), [Azure Key Vault](https://startwithidentity.com/vendors/secrets/azure-key-vault/), or [Google Cloud Secret Manager](https://startwithidentity.com/vendors/secrets/google-cloud-secret-manager/).
2. **API keys to rotate**, An inventory of all API keys your applications use, including the provider, the application that uses them, and how the application reads them.
3. **Provider API access**, Admin access to the API providers whose keys you need to rotate (e.g., Stripe, Twilio, SendGrid, or internal APIs).
4. **Deployment pipeline**, A CI/CD pipeline or configuration management system that can trigger key rotation and deploy updated configurations.
5. **Monitoring and alerting**, The ability to detect when an API call fails due to an invalid key.

## Architecture Overview

Automated key rotation involves four components working together:

- **Secrets Vault:** Stores the current and previous versions of each API key. Applications read from the vault rather than from local configuration.
- **Rotation Orchestrator:** A scheduled process (Lambda function, CronJob, Vault rotation policy) that triggers key rotation on a defined schedule.
- **API Provider:** The service that issues and revokes API keys (Stripe Dashboard API, AWS IAM, your internal API management platform).
- **Application:** The consumer of the API key. Must be configured to read keys dynamically from the vault rather than from static configuration.

**The dual-key (overlap) pattern** is the foundation of zero-downtime rotation:

1. Generate a new key at the API provider. Both old and new keys are now valid.
2. Store the new key in the vault as the primary version.
3. Wait for all application instances to pick up the new key (grace period).
4. Revoke the old key at the API provider.

During the grace period, both keys are valid, so any application instance, whether it has picked up the new key or is still using the old one, can authenticate successfully. There is no moment where neither key works.

## Step-by-Step Implementation

### Step 1: Inventory and Classify Your API Keys

Create a complete inventory:

```yaml
api_keys:
  - name: "stripe-api-key"
    provider: "Stripe"
    environment: "production"
    used_by: ["payment-service", "billing-service"]
    vault_path: "secret/prod/stripe/api-key"
    rotation_frequency: "30d"
    supports_dual_key: true
    provider_api: "https://api.stripe.com/v1/api_keys"
    criticality: "high"

  - name: "sendgrid-api-key"
    provider: "SendGrid"
    environment: "production"
    used_by: ["notification-service"]
    vault_path: "secret/prod/sendgrid/api-key"
    rotation_frequency: "90d"
    supports_dual_key: true
    provider_api: "https://api.sendgrid.com/v3/api_keys"
    criticality: "medium"

  - name: "internal-service-api-key"
    provider: "Internal API Gateway"
    environment: "production"
    used_by: ["frontend-bff", "mobile-api"]
    vault_path: "secret/prod/internal/gateway-key"
    rotation_frequency: "7d"
    supports_dual_key: true
    provider_api: "https://gateway.internal/admin/keys"
    criticality: "high"
```

Classify each key by:
- **Dual-key support:** Can the provider have two valid keys simultaneously? Most can.
- **Rotation frequency:** Based on risk, compliance requirements, and operational feasibility.
- **Criticality:** What happens if the key stops working? Use this to prioritize rotation automation.

### Step 2: Configure Dynamic Secret Retrieval

Before implementing rotation, applications must read keys dynamically, not from static configuration files or environment variables set at deploy time.

**Pattern 1: Vault Agent Sidecar (recommended for Kubernetes)**

```yaml
# Kubernetes pod with Vault agent sidecar
apiVersion: v1
kind: Pod
metadata:
  annotations:
    vault.hashicorp.com/agent-inject: "true"
    vault.hashicorp.com/agent-inject-secret-stripe: "secret/prod/stripe/api-key"
    vault.hashicorp.com/agent-inject-template-stripe: |
      {{- with secret "secret/prod/stripe/api-key" -}}
      STRIPE_API_KEY={{ .Data.data.key }}
      {{- end }}
    vault.hashicorp.com/agent-inject-reload: "true"  # Re-read on secret change
spec:
  containers:
    - name: payment-service
      image: payment-service:latest
      volumeMounts:
        - name: vault-secrets
          mountPath: /vault/secrets
          readOnly: true
```

**Pattern 2: Application-level Vault client**

```python
import hvac
import time
from functools import lru_cache

class SecretManager:
    def __init__(self, vault_url, vault_token):
        self.client = hvac.Client(url=vault_url, token=vault_token)
        self._cache = {}
        self._cache_ttl = 300  # 5 minutes

    def get_api_key(self, path):
        now = time.time()
        if path in self._cache and now - self._cache[path]['timestamp'] < self._cache_ttl:
            return self._cache[path]['value']

        response = self.client.secrets.kv.v2.read_secret_version(path=path)
        key = response['data']['data']['key']

        self._cache[path] = {'value': key, 'timestamp': now}
        return key

# Usage
secrets = SecretManager(vault_url="https://vault.internal:8200", vault_token=os.environ['VAULT_TOKEN'])

# Every API call reads the current key (with 5-minute cache)
def call_stripe_api():
    api_key = secrets.get_api_key("prod/stripe/api-key")
    response = requests.post(
        "https://api.stripe.com/v1/charges",
        headers={"Authorization": f"Bearer {api_key}"},
        data=charge_data
    )
    return response
```

**Pattern 3: AWS Secrets Manager with automatic caching**

```python
from aws_secretsmanager_caching import SecretCache, SecretCacheConfig

cache_config = SecretCacheConfig(
    max_cache_size=100,
    secret_refresh_interval=300  # Refresh every 5 minutes
)
cache = SecretCache(config=cache_config)

def get_api_key():
    secret = cache.get_secret_string("prod/stripe-api-key")
    return json.loads(secret)["key"]
```

### Step 3: Implement the Rotation Function

The rotation function executes the dual-key pattern:

```python
import json
import logging
from datetime import datetime, timedelta

logger = logging.getLogger("key-rotation")

def rotate_api_key(secret_name, provider):
    """
    Zero-downtime API key rotation using dual-key pattern.
    """
    logger.info(f"Starting rotation for {secret_name}")

    # Step 1: Read current key metadata
    current_secret = vault.read(secret_name)
    current_key_id = current_secret["data"]["key_id"]
    current_key = current_secret["data"]["key"]

    # Step 2: Create new key at the provider
    logger.info(f"Creating new key at {provider.name}")
    new_key = provider.create_api_key(
        name=f"{secret_name}-{datetime.now().strftime('%Y%m%d%H%M%S')}",
        permissions=provider.get_key_permissions(current_key_id)
    )
    logger.info(f"New key created: {new_key.id}")

    # Step 3: Store new key in vault (both old and new are now valid)
    vault.write(secret_name, {
        "key": new_key.value,
        "key_id": new_key.id,
        "previous_key": current_key,
        "previous_key_id": current_key_id,
        "rotated_at": datetime.now().isoformat(),
        "previous_key_revocation_at": (datetime.now() + timedelta(hours=1)).isoformat()
    })
    logger.info(f"New key stored in vault for {secret_name}")

    # Step 4: Wait for grace period (applications pick up new key)
    # This is handled by a separate deferred revocation job
    schedule_revocation(secret_name, current_key_id, provider, delay_hours=1)
    logger.info(f"Scheduled revocation of old key {current_key_id} in 1 hour")

    return {"status": "success", "new_key_id": new_key.id}


def schedule_revocation(secret_name, old_key_id, provider, delay_hours):
    """
    Deferred revocation: revoke the old key after the grace period.
    """
    # This could be a delayed message queue task, a scheduled Lambda, etc.
    task_scheduler.schedule(
        function=revoke_old_key,
        args=(secret_name, old_key_id, provider),
        delay=timedelta(hours=delay_hours)
    )


def revoke_old_key(secret_name, old_key_id, provider):
    """
    Revoke the old key. Verify that new key is being used first.
    """
    # Safety check: verify new key is working
    current_secret = vault.read(secret_name)
    if current_secret["data"]["key_id"] == old_key_id:
        logger.error(f"New key not yet active for {secret_name}. Aborting revocation.")
        alert_security_team(f"Rotation incomplete for {secret_name}")
        return

    # Verify at least one successful API call with new key
    if not verify_new_key_usage(secret_name):
        logger.warning(f"No confirmed usage of new key for {secret_name}. Delaying revocation.")
        schedule_revocation(secret_name, old_key_id, provider, delay_hours=1)
        return

    # Revoke old key
    provider.revoke_api_key(old_key_id)
    logger.info(f"Old key {old_key_id} revoked for {secret_name}")

    # Clean up vault metadata
    vault.write(secret_name, {
        "key": current_secret["data"]["key"],
        "key_id": current_secret["data"]["key_id"],
        "rotated_at": current_secret["data"]["rotated_at"]
    })
```

### Step 4: Configure Rotation Schedules

```yaml
# Rotation schedule configuration
rotation_schedules:
  - secret: "prod/stripe-api-key"
    provider: "stripe"
    schedule: "0 2 1 * *"        # Monthly at 2 AM on the 1st
    grace_period: "2h"
    alert_on_failure: true
    rollback_on_failure: true

  - secret: "prod/internal-gateway-key"
    provider: "internal_gateway"
    schedule: "0 3 * * 0"        # Weekly at 3 AM Sunday
    grace_period: "1h"
    alert_on_failure: true
    rollback_on_failure: true

  - secret: "prod/sendgrid-api-key"
    provider: "sendgrid"
    schedule: "0 2 1 */3 *"     # Quarterly
    grace_period: "4h"
    alert_on_failure: true
    rollback_on_failure: true
```

For AWS Secrets Manager, rotation is built-in:

```python
import boto3

client = boto3.client('secretsmanager')

# Enable automatic rotation
client.rotate_secret(
    SecretId='prod/stripe-api-key',
    RotationLambdaARN='arn:aws:lambda:us-east-1:123456789:function:rotate-stripe-key',
    RotationRules={
        'AutomaticallyAfterDays': 30,
        'Duration': '2h',       # Rotation window
        'ScheduleExpression': 'rate(30 days)'
    }
)
```

### Step 5: Implement Monitoring and Alerting

```yaml
monitoring_rules:
  - name: "API key rotation failure"
    condition: "rotation_job_status == 'failed'"
    severity: "critical"
    action: "page_on_call_engineer"
    description: "Key rotation failed. Old key may not be revoked. Manual intervention required."

  - name: "API key approaching max age"
    condition: "key_age > rotation_frequency * 1.5"
    severity: "high"
    action: "alert_security_team"
    description: "Key has not been rotated within expected window."

  - name: "Old key still in use after grace period"
    condition: "old_key_usage_after_grace_period > 0"
    severity: "warning"
    action: "alert_application_team"
    description: "Application instances still using the old key. May indicate deployment issue."

  - name: "API authentication failures spike"
    condition: "api_auth_failure_rate > baseline * 3"
    severity: "critical"
    action: "page_on_call_engineer"
    description: "Spike in API auth failures. May indicate rotation issue or key compromise."

  - name: "Revoked key usage attempt"
    condition: "revoked_key_auth_attempt > 0"
    severity: "high"
    action: "alert_security_team"
    description: "Attempt to use a revoked key. May indicate compromise or misconfigured application."
```

### Step 6: Build Rollback Procedures

Rotation can fail. Have a plan:

```python
def rollback_rotation(secret_name, provider):
    """
    Emergency rollback: restore the previous key if the new key is not working.
    """
    logger.warning(f"Initiating rollback for {secret_name}")

    current_secret = vault.read(secret_name)
    previous_key = current_secret["data"].get("previous_key")
    previous_key_id = current_secret["data"].get("previous_key_id")

    if not previous_key:
        logger.error(f"No previous key available for rollback of {secret_name}")
        alert_security_team(f"Rollback failed for {secret_name}: no previous key")
        return False

    # Verify the previous key is still valid at the provider
    if not provider.validate_key(previous_key_id):
        logger.error(f"Previous key {previous_key_id} is no longer valid. Cannot rollback.")
        alert_security_team(f"Rollback failed for {secret_name}: previous key revoked")
        return False

    # Restore previous key as the active key
    vault.write(secret_name, {
        "key": previous_key,
        "key_id": previous_key_id,
        "rolled_back_at": datetime.now().isoformat(),
        "rollback_reason": "new_key_failure"
    })

    # Revoke the problematic new key
    new_key_id = current_secret["data"]["key_id"]
    provider.revoke_api_key(new_key_id)

    logger.info(f"Rollback complete for {secret_name}. Restored key {previous_key_id}")
    return True
```

## Configuration Best Practices

- **Never hardcode API keys.** Every key must be read from a secrets vault at runtime. Use environment variables only as a pointer to the vault path, not to store the key itself.
- **Keep both keys valid during rotation.** The dual-key overlap period is critical. Never revoke the old key until you have confirmed the new key is working in production.
- **Use short grace periods.** The grace period should be long enough for all application instances to refresh their cached key (as a practitioner estimate, typically 5-15 minutes for sidecar injection, up to 1 hour for manual deployment pipelines).
- **Log every rotation event.** Record when each key was created, activated, and revoked. This audit trail is essential for incident investigation.
- **Test rotation in staging first.** Every rotation procedure should be proven in a non-production environment before being applied to production keys.
- **Separate rotation from deployment.** Key rotation should be independent of application deployments. If you can only rotate keys during a deploy, your rotation frequency is limited to your deploy frequency.

## Testing and Validation

1. **Happy-path rotation test:** Trigger a manual rotation in staging. Verify the new key is issued, stored in the vault, picked up by the application, and the old key is revoked, all without downtime.
2. **Grace period test:** Trigger rotation and immediately attempt API calls. Verify that calls succeed with both the old key (during grace period) and the new key.
3. **Rollback test:** Trigger rotation, then simulate a new key failure. Trigger rollback and verify the application recovers using the previous key.
4. **Provider outage test:** Simulate the API provider being unavailable during rotation. Verify the rotation job fails gracefully and the old key remains active.
5. **Vault outage test:** Simulate a vault outage during normal operation. Verify applications use cached keys and continue to function.
6. **Concurrent rotation test:** Trigger two rotations simultaneously for the same key. Verify the system handles the race condition gracefully.

## Common Pitfalls and Troubleshooting

| Problem | Cause | Solution |
|---------|-------|----------|
| Application uses stale key after rotation | Key is read at startup and cached indefinitely | Implement TTL-based cache refresh (5-15 minutes, a practitioner estimate) |
| Downtime during rotation | Old key revoked before all instances picked up new key | Increase grace period; verify new key usage before revoking old key |
| Rotation fails silently | No monitoring on rotation jobs | Add alerts for rotation failures and key age violations |
| Provider rate-limits key creation | Too many rotations or retries | Implement exponential backoff; rotate during off-peak hours |
| Multiple instances reading different key versions | Cache TTLs are not synchronized | Accept this temporarily (dual-key pattern handles it); ensure grace period > max cache TTL |
| Rollback fails because old key was already revoked | Revocation happened before rollback was needed | Extend the old key's validity window; do not revoke until new key is confirmed working |

## Security Considerations

1. **Rotation is not a substitute for detection.** Rotating a compromised key stops future abuse but does not undo past abuse. Pair rotation with monitoring to detect unauthorized key usage.
2. **Protect the rotation infrastructure.** The rotation function has the ability to create and revoke API keys, it is highly privileged. Secure the rotation function's credentials, limit its network access, and audit its executions.
3. **Secrets in transit.** When the vault sends a key to the application, that transmission must be encrypted (TLS) and authenticated (Vault token). Never transmit keys over unencrypted channels.
4. **Emergency rotation capability.** Beyond scheduled rotation, you must be able to rotate a key immediately when a breach is detected. Build and test an emergency rotation procedure that can be triggered with a single command.
5. **Third-party provider limitations.** Some API providers limit the number of active keys, restrict how quickly you can create and revoke keys, or do not support programmatic key management at all. Document these limitations for each provider.

## Conclusion

Automated API key rotation transforms a major security liability into a managed process. The dual-key pattern ensures zero downtime, secrets management platforms centralize control, and monitoring catches failures before they impact production.

Start by migrating applications from static configuration to dynamic secret retrieval. Then implement rotation for your highest-risk keys first, those with the broadest access and the longest age. As you build confidence, extend rotation to all API keys and progressively shorten the rotation interval. The goal is a world where no API key is more than 30 days old, and compromised keys are replaced within minutes.

## Authentication vs Authorization (AuthN vs AuthZ) Explained
Source: https://startwithidentity.com/guides/fundamentals/authentication-vs-authorization/
Last updated: 2026-11-05

The difference between authentication and authorization is the question each answers: **authentication (authn) verifies who you are, and authorization (authz) decides what you are allowed to do.** Authentication happens at sign-in with a password, passkey or MFA. Authorization happens after it, and should run on every request, for every object. A user can be perfectly authenticated and still be denied.

The two are often shortened to the same "auth", which is how they get confused in code. Getting them straight is foundational to [IAM](https://startwithidentity.com/guides/fundamentals/what-is-iam/).

## Authentication vs authorization at a glance

| | Authentication (authn) | Authorization (authz) |
|---|---|---|
| Question | Who are you? | What may you do, to which resource? |
| When | Once per session, plus step-up for sensitive actions | Every request |
| Evidence | Passwords, [passkeys](https://startwithidentity.com/glossary/passkey/), MFA, certificates | Roles, attributes, relationships, scopes, policy |
| Standards | [OpenID Connect](https://startwithidentity.com/standards/openid-connect/), [SAML 2.0](https://startwithidentity.com/standards/saml-2-0/), [WebAuthn](https://startwithidentity.com/standards/webauthn-fido2/) | [OAuth 2.0](https://startwithidentity.com/standards/oauth-2-0/) scopes, [AuthZEN](https://startwithidentity.com/standards/authzen/), XACML |
| Artifact | Session, [ID token](https://startwithidentity.com/glossary/id-token/), SAML assertion | [Access token](https://startwithidentity.com/glossary/access-token/), policy decision |
| HTTP failure (RFC 9110) | 401 Unauthorized | 403 Forbidden |
| OWASP Top 10:2025 | A07 Authentication Failures | A01 Broken Access Control |
| Typical owner | Identity provider | Application, API gateway or policy engine |

The HTTP names are a historical trap. In [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html), 401 means the request lacks valid authentication credentials, and the server must send a `WWW-Authenticate` challenge. 403 means the server understood the request but refuses it. Return 401 when you do not know who the caller is, and 403 when you do and the answer is no.

## Authentication (authn): who are you?

Authentication **verifies identity**. It is the login step: passwords, [passkeys](https://startwithidentity.com/guides/authentication/passkeys-101/), biometrics, and [multi-factor authentication](https://startwithidentity.com/glossary/mfa/). A successful authentication establishes a trusted session. Strength varies a lot: [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/) such as passkeys resists the relay attacks that defeat SMS codes and push prompts. WebAuthn Level 3 became a W3C Recommendation on August 25, 2026.

## Authorization (authz): what can you do?

Authorization happens **after** authentication and decides what the verified identity may access. This is where [RBAC, ABAC, and ReBAC](https://startwithidentity.com/guides/fundamentals/rbac-vs-abac-vs-rebac/) models live, and where OAuth scopes sit for APIs. The decision needs three inputs: the subject, the action and the specific resource. Checking only the first two is the bug behind most data leaks.

## A worked example

An employee opens an expense app. The app redirects to the identity provider, which checks a passkey and returns an OIDC ID token: that is **authentication**. The app creates a session. The employee asks to view expense report 4471. The app calls its API with an OAuth access token scoped to `expenses:read`. The API must still ask: does report 4471 belong to this employee, or to someone they manage? That last check is **authorization**, and the scope alone does not answer it.

## Why mixing them up is dangerous

A common flaw is treating "logged in" as "allowed." OWASP ranks it first: Broken Access Control is A01 in the [OWASP Top 10:2025](https://top10.owasp.org/2025), and Broken Object Level Authorization is API1 in the [OWASP API Security Top 10 2023](https://api-security.owasp.org/editions/2023/en/0x11-t10), ahead of Broken Authentication at API2. The shape is the same each time: a request arrives with a valid session, the application reads an identifier from the request, and changing the identifier returns someone else's data.

Two rules prevent most of it:

- **Check permission on the object, not the endpoint.** "Is this user allowed to view invoice 4471" is a different question from "is this user allowed to use the invoice endpoint."
- **Never trust an identifier the client supplied** to select the record without an ownership or relationship check on the server.

## Real failures on each side

**Authorization failures:**

- **Optus, 2022.** An internet-facing API returned customer personal information without valid authorization. About 9.5 million people were affected, per the Australian regulator ([incident record](https://startwithidentity.com/breaches/incidents/2022-optus-unauthenticated-api/)).
- **OAuth consent phishing.** At [Cyberhaven](https://startwithidentity.com/breaches/incidents/2024-cyberhaven-chrome-extension-oauth-consent-phishing/) an employee with MFA authorized a malicious OAuth app and saw no MFA prompt, because a consent grant is authorization, not authentication ([OAuth consent phishing](https://startwithidentity.com/techniques/oauth-consent-phishing/)).
- **Grants that outlive the login.** In the [Salesloft Drift](https://startwithidentity.com/breaches/incidents/2025-salesloft-drift-oauth-token-theft/) campaign, stolen refresh tokens for a third-party app worked as standing access to many Salesforce tenants with no user in the path ([refresh token abuse](https://startwithidentity.com/techniques/refresh-token-abuse/)).

**Authentication failures:**

- **Forged tokens.** [Storm-0558](https://startwithidentity.com/breaches/incidents/2023-storm-0558-microsoft-signing-key-forgery/) used a stolen Microsoft consumer signing key, and a validation flaw let those tokens open enterprise mailboxes.
- **Unverified tokens.** [CVE-2026-48558](https://startwithidentity.com/cves/cve-2026-48558/) let attackers forge OIDC tokens against SimpleHelp servers that did not validate signatures, bypassing MFA ([incident record](https://startwithidentity.com/breaches/incidents/2026-simplehelp-oidc-token-forgery/)). [CVE-2023-29357](https://startwithidentity.com/cves/cve-2023-29357/) in SharePoint accepted `alg: none` JWTs.

## Where the line blurs

[Claims](https://startwithidentity.com/glossary/claims/) in a token are where authentication quietly becomes authorization. If your application reads a `roles` or `groups` claim and grants access on that basis, the integrity and freshness of that claim is now an authorization control: validate the signature, issuer, and audience, and remember that a token minted before someone left a group stays valid until it expires. [Continuous access evaluation](https://startwithidentity.com/glossary/caep/) through the Shared Signals Framework closes that gap by pushing revocations to apps. When a grant needs more detail than a scope string can carry, such as one payment of a fixed amount to a named payee, [Rich Authorization Requests](https://startwithidentity.com/glossary/rich-authorization-requests/) (RFC 9396) put structured permission details in the token request itself.

## Authorization models, briefly

- **[RBAC](https://startwithidentity.com/glossary/rbac/)** bundles permissions into roles. Readable and auditable, and prone to role explosion.
- **[ABAC](https://startwithidentity.com/glossary/abac/)** evaluates attributes of the subject, resource, action, and environment. Flexible, harder to audit.
- **[ReBAC](https://startwithidentity.com/glossary/rebac/)** derives access from relationships (owner, member, parent), which is what sharing products need.

Most mature systems use roles for the coarse grant and attributes or relationships for the fine-grained condition.

## Authentication and authorization tools

Authentication usually comes from an identity provider such as [Okta](https://startwithidentity.com/vendors/iam/okta/), [Microsoft Entra](https://startwithidentity.com/vendors/iam/microsoft-entra/) or, for customer apps, [Auth0](https://startwithidentity.com/vendors/ciam/auth0/). Authorization is increasingly externalized to a policy engine: [Open Policy Agent](https://startwithidentity.com/vendors/authorization/styra-opa/) (whose creators and many Styra staff joined Apple in August 2025), [OpenFGA](https://startwithidentity.com/vendors/authorization/openfga/), [AuthZed](https://startwithidentity.com/vendors/authorization/authzed/), [Cerbos](https://startwithidentity.com/vendors/authorization/cerbos/), [Permit.io](https://startwithidentity.com/vendors/authorization/permit-io/), [Amazon Verified Permissions](https://startwithidentity.com/vendors/authorization/aws-verified-permissions/) ($5 per million single requests since a June 2025 price cut) and [SGNL](https://startwithidentity.com/vendors/authorization/sgnl/), which CrowdStrike acquired on February 20, 2026. The [AuthZEN Authorization API 1.0](https://startwithidentity.com/standards/authzen/), Final since January 11, 2026, gives apps one standard request format for any of them. Compare them in the [best authorization tools](https://startwithidentity.com/rankings/best-authorization-tools/) ranking.

## Where to start

Read [OAuth vs OIDC](https://startwithidentity.com/guides/fundamentals/oauth-vs-oidc/) for the protocol side, then browse [MFA vendors](https://startwithidentity.com/vendors/mfa/) and [authorization engines](https://startwithidentity.com/vendors/authorization/).

## Build vs buy identity: the honest math
Source: https://startwithidentity.com/guides/buyer-guides/build-vs-buy-identity/
Last updated: 2026-11-05

For most teams the answer is buy. Building basic login is not hard; operating it at production quality for years, with passkeys, recovery, enterprise SSO, SCIM, audit logs and compliance evidence, takes more engineering than teams predict. Building makes sense only at very high scale, when identity is your product, or when regulation rules out the vendors. This guide gives the decision table, real list prices at three scales, a way to cost the build side honestly, and the failure modes homegrown identity tends to hit.

## Decision table

| Your situation | Recommendation | Why |
|---|---|---|
| Pre-product or under 50,000 active users | Buy | Published free tiers cover you; spend engineering on the product |
| B2B SaaS selling to enterprises | Buy, choose on SSO/SCIM pricing | Enterprise SSO and SCIM are required and costly to build well |
| Consumer app, 1M+ active users, strong platform team | Run the math below; buy or self-host | Per-user list prices start to matter; discounts usually apply |
| Identity is your product | Build | It is your core competence and differentiator |
| Regulation or sovereignty excludes the vendors | Self-host open source, or build | Control of location and keys is the requirement |
| Wants portability but lacks budget for custom build | Self-host open source | No licence fee, portable code, bounded operations cost |

## The cost of "buy": real list prices

These are USD list prices per month for user charges only, taken from vendor pricing pages. Clerk and Amazon Cognito were re-read on November 5, 2026; Supabase and WorkOS are from SWI's live check on October 30, 2026 in the [Identity Pricing Transparency Index 2026](https://startwithidentity.com/reports/identity-pricing-transparency-index-2026/). They exclude SMS, add-ons, enterprise plans and discounts.

| Active users per month | [Amazon Cognito](https://startwithidentity.com/vendors/ciam/amazon-cognito/) Essentials | [Clerk](https://startwithidentity.com/vendors/ciam/clerk/) Pro | [Supabase Auth](https://startwithidentity.com/vendors/open-source/supabase-auth/) Pro | [WorkOS](https://startwithidentity.com/vendors/ciam/workos/) AuthKit |
|---|---|---|---|---|
| 10,000 | $0 | $25 | $25 | $0 |
| 100,000 | $1,350 | $1,025 | $25 | $0 |
| 1,000,000 | $14,850 | $17,225 | $2,950 | $0 |

How the numbers are built:

- **Cognito Essentials:** 10,000 free MAU, then $0.015 per MAU, per its [pricing page](https://aws.amazon.com/cognito/pricing/). Users who sign in through SAML or OIDC federation get only 50 free MAU, then $0.015 each.
- **Clerk Pro:** $25 a month with 50,000 monthly retained users included, then $0.02 each to 100,000 and $0.018 each to 1,000,000, per its [pricing page](https://clerk.com/pricing).
- **Supabase Pro:** from $25 a month with 100,000 MAU, then $0.00325 per MAU.
- **WorkOS AuthKit:** free to 1,000,000 MAU, then $2,500 a month per additional million. Enterprise SSO and directory sync are $125 per connection (1 to 15).

Two lessons. First, the spread at 1,000,000 users runs from $0 to over $17,000 a month in user charges, so "vendors are too expensive at scale" depends entirely on which vendor and which unit. Second, for B2B products the connection line often matters more than the user line; see the worked example in [how to evaluate a CIAM vendor](https://startwithidentity.com/guides/buyer-guides/how-to-evaluate-ciam/) and the [SSO tax](https://startwithidentity.com/glossary/sso-tax/) entry.

Most of the market does not publish prices at all. The [Identity Pricing Transparency Index 2026](https://startwithidentity.com/reports/identity-pricing-transparency-index-2026/) found that only 28% of 295 identity vendors still on sale (82) publish a price for any paid tier, and 54% are quote-only. CIAM is one of the more transparent categories.

## The honest cost of "build"

There is no credible universal number for build cost, so price it from your own inputs. List the work, estimate engineer-months, and multiply by your fully loaded cost per engineer.

**Version 1 scope (before you can launch):**

- Sign-up, sign-in and secure credential storage, or passwordless with [passkeys](https://startwithidentity.com/glossary/passkey/) built on [WebAuthn](https://startwithidentity.com/standards/webauthn-fido2/)
- [MFA](https://startwithidentity.com/glossary/mfa/) and a safe [account recovery](https://startwithidentity.com/glossary/account-recovery/) flow
- Sessions, [refresh tokens](https://startwithidentity.com/glossary/refresh-token/) and revocation; [OAuth 2.0](https://startwithidentity.com/standards/oauth-2-0/) and [OpenID Connect](https://startwithidentity.com/standards/openid-connect/) if other apps or APIs consume your tokens
- Rate limiting, bot defense and breached-password checks against [credential stuffing](https://startwithidentity.com/techniques/credential-stuffing/)

**Before the first enterprise deal:**

- Enterprise SSO over [SAML 2.0](https://startwithidentity.com/standards/saml-2-0/) and OIDC, per customer, with a self-serve setup flow
- [SCIM 2.0](https://startwithidentity.com/standards/scim-2-0/) provisioning and deprovisioning
- Organization and role models, admin console, audit log export
- Evidence for [SOC 2](https://startwithidentity.com/guides/compliance/soc2-for-identity/) access controls

**Every year after:**

- Security patches, dependency and library upgrades, protocol changes
- On-call for the login path, which is down whenever you are down
- Penetration tests and incident response for the identity tier
- New factor types and standards (passkey changes, new OAuth profiles)

Then add the ongoing share of an engineer, not just the build months. Put both sides into the [build vs buy tool](https://startwithidentity.com/tools/build-vs-buy/) and the [TCO calculator](https://startwithidentity.com/tools/tco-calculator/).

## When to actually build

- You are a hyperscale consumer platform where negotiated vendor pricing still breaks your unit economics
- Your product is itself an identity platform (vendors selling to other developers)
- You have a regulatory environment that prohibits the available vendors
- You have an in-house security and platform engineering team that operates production identity systems already

## When to buy

- Everyone else
- Especially: anyone who hasn't yet shipped v1
- Especially: anyone whose product is not "identity"
- Especially: anyone planning to chase SOC 2 in the next 18 months

## The middle path: open source self-hosted

For teams uncomfortable with vendor lock-in but unable to justify a full custom build, consider self-hosted open-source identity: [Keycloak](https://startwithidentity.com/vendors/open-source/keycloak/), [FusionAuth](https://startwithidentity.com/vendors/ciam/fusionauth/) (Community edition, self-hosted, unlimited) or [SuperTokens](https://startwithidentity.com/vendors/ciam/supertokens/) (unlimited users self-hosted; $0.02 per MAU on its managed cloud). There is no licence fee and the code is portable. The operational cost is real but bounded: you own patching, upgrades, high availability, backups and monitoring. See the [top open-source CIAM platforms](https://startwithidentity.com/articles/top-8-open-source-ciam-platforms/).

## Failure modes of homegrown identity

The common failures are not exotic cryptography. They are recovery paths, missing MFA and unprotected endpoints, which vendors handle by default and in-house teams add late.

| Failure | Incident | Lesson |
|---|---|---|
| Recovery path weaker than login | [Coinbase, 2021](https://startwithidentity.com/breaches/incidents/2021-coinbase-sms-recovery-flaw/): an SMS account recovery flaw led to takeovers of at least 6,000 customers' accounts | Recovery needs the same strength as sign-in |
| No mandatory MFA against stuffing | [23andMe, 2023](https://startwithidentity.com/breaches/incidents/2023-23andme-credential-stuffing-dna-relatives/): about 14,000 accounts accessed, about 6.9 million people's profile data exposed; fined 2.31 million pounds by the UK ICO | Ship MFA and stuffing defenses in v1 |
| Unauthenticated identity API | [Authy, 2024](https://startwithidentity.com/breaches/incidents/2024-twilio-authy-unauthenticated-endpoint/): phone numbers enumerated through an unauthenticated endpoint | Authenticate and rate-limit every lookup |
| Broken access control on a customer API | [Optus, 2022](https://startwithidentity.com/breaches/incidents/2022-optus-unauthenticated-api/): about 9.5 million people's data exposed through an API with broken access controls | Authorization is part of identity, not an afterthought |

## Step-by-step: making the call

1. Forecast active users at 12, 24 and 36 months, and the number of enterprise customers needing SSO or SCIM.
2. Price two or three vendors at those points from their pricing pages, including connection fees.
3. List the build scope above and estimate engineer-months for v1 and ongoing work.
4. Multiply by your loaded engineering cost and compare over three years.
5. Add risk: what a takeover incident or login outage would cost you.
6. If you buy, design for exit: confirm password hash export and import limits before signing.

## Common pitfalls

- Building because of "vendor lock-in concerns" without quantifying the switching cost
- Underestimating the long tail (account recovery, edge cases, support burden)
- Counting only the visible engineering work, not security/compliance/SDK maintenance
- Comparing free-tier headlines without checking what each vendor counts as an active user
- Building without designing for migration to a vendor later

For the market view, see the [best CIAM for startups](https://startwithidentity.com/rankings/best-ciam-for-startups/) and [best CIAM platforms](https://startwithidentity.com/rankings/best-ciam-platforms/) rankings.

## Certificate Lifecycle Management Guide
Source: https://startwithidentity.com/guides/machine-identity/certificate-lifecycle-management-guide/
Last updated: 2026-11-05

Certificates are the backbone of trust on the internet and within enterprise networks. They authenticate servers, encrypt communications, sign code, verify device identities, and enable mutual TLS between services. Yet certificate management remains one of the most operationally challenging aspects of identity and security.

The consequences of poor certificate management are severe and immediate. An expired certificate causes an outage, your website goes down, your API stops working, your VPN becomes inaccessible. A compromised certificate enables man-in-the-middle attacks. An over-issued certificate expands your attack surface. These are not theoretical risks: certificate-related outages make headlines regularly, affecting organizations from airlines to cloud providers.

This guide provides a complete approach to certificate lifecycle management, from PKI design through automated renewal and revocation.

## What changed in 2024-2026

Three changes make automation mandatory rather than optional:

| Change | What it means | Source |
|--------|---------------|--------|
| Public TLS validity cuts (ballot SC-081v3, adopted 11 April 2025) | Maximum Subscriber Certificate validity is 200 days from 15 March 2026, 100 days from 15 March 2027, and 47 days from 15 March 2029. Domain validation reuse falls to 200, then 100, then 10 days on the same dates. | [CA/Browser Forum ballot SC-081v3](https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/), [Baseline Requirements 1.2.2](https://github.com/cabforum/servercert/blob/main/docs/BR.md) |
| Let's Encrypt ended OCSP | OCSP URLs were dropped from certificates on 7 May 2025 and the OCSP responders were turned off on 6 August 2025. Revocation checking for those certificates relies on CRLs. | [Let's Encrypt, Ending OCSP Support](https://letsencrypt.org/2024/12/05/ending-ocsp/) |
| Post-quantum standards published | On 13 August 2024 NIST released FIPS 203 (ML-KEM, key encapsulation), FIPS 204 (ML-DSA, signatures), and FIPS 205 (SLH-DSA, backup signatures). | [NIST announcement](https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards) |

If any public certificate in your estate still renews through a ticket, the 2027 and 2029 steps will turn that into a quarterly or monthly outage risk. See also the [certificate lifecycle](https://startwithidentity.com/glossary/certificate-lifecycle/) and [PKI](https://startwithidentity.com/glossary/pki/) glossary entries.

## What You Will Learn

- PKI fundamentals and certificate hierarchy design
- Certificate issuance workflows for different use cases
- Automating certificate renewal with ACME and other protocols
- Revocation strategies: CRL, OCSP, and short-lived certificates
- Monitoring certificate health across your infrastructure
- Scaling certificate management for enterprise environments

## Prerequisites

1. **PKI knowledge**, Basic understanding of public key cryptography, X.509 certificates, and TLS.
2. **Certificate Authority (CA)**, Either a public CA ([Let's Encrypt](https://startwithidentity.com/vendors/pki/lets-encrypt/), [DigiCert](https://startwithidentity.com/vendors/pki/digicert/), [Sectigo](https://startwithidentity.com/vendors/pki/sectigo/)) or a private CA (AWS Private CA, [HashiCorp Vault](https://startwithidentity.com/vendors/machine-identity/hashicorp-vault/) PKI, Microsoft AD CS, [step-ca from Smallstep](https://startwithidentity.com/vendors/pki/smallstep/)).
3. **Infrastructure access**, Ability to deploy certificates to web servers, load balancers, API gateways, and application servers.
4. **DNS control**, Required for ACME DNS-01 challenges and certificate validation.
5. **Monitoring platform**, Prometheus, Datadog, Nagios, or similar for certificate expiry monitoring.

## Architecture Overview

A certificate lifecycle management system consists of:

- **Certificate Authority (CA):** Issues and signs certificates. Can be a public CA (for internet-facing services) or a private CA (for internal services).
- **Registration Authority (RA):** Validates certificate requests before passing them to the CA. In many implementations, this is integrated into the CA.
- **Certificate Inventory/Discovery:** Scans the environment to find all deployed certificates and tracks their metadata (subject, issuer, expiry, location).
- **Renewal Engine:** Automates certificate renewal before expiry. Typically uses the ACME protocol for public certificates and custom automation for private certificates.
- **Revocation Infrastructure:** CRL distribution points and/or OCSP responders that communicate certificate revocation status.
- **Monitoring and Alerting:** Tracks certificate expiry dates and alerts operators before certificates expire.

**Certificate hierarchy (for private PKI):**

```
Root CA (offline, in HSM)
├── Intermediate CA - TLS (online, issues server certificates)
├── Intermediate CA - Client Auth (online, issues client certificates)
└── Intermediate CA - Code Signing (online, issues signing certificates)
```

The root CA is kept offline (not connected to any network) and is only used to sign intermediate CA certificates. The intermediate CAs are online and handle day-to-day issuance. If an intermediate CA is compromised, it can be revoked without replacing the root.

## Step-by-Step Implementation

### Step 1: Design Your PKI Hierarchy

For a private PKI, design the hierarchy before issuing any certificates:

```yaml
pki_design:
  root_ca:
    common_name: "Contoso Root CA"
    key_algorithm: "EC P-384"
    validity: "20 years"
    storage: "HSM (offline)"
    usage: "Only signs intermediate CA certificates"

  intermediate_cas:
    - name: "Contoso TLS Issuing CA"
      common_name: "Contoso TLS CA G1"
      key_algorithm: "EC P-256"
      validity: "5 years"
      storage: "HSM (online)"
      usage: "Issues TLS server and client certificates"
      max_cert_validity: "90 days"

    - name: "Contoso Service Mesh CA"
      common_name: "Contoso Service Mesh CA G1"
      key_algorithm: "EC P-256"
      validity: "3 years"
      storage: "HSM (online)"
      usage: "Issues short-lived mTLS certificates for service mesh"
      max_cert_validity: "24 hours"
```

**Setting up a private CA with step-ca (open source):**

```bash
# Initialize the CA
step ca init --name="Contoso Root CA" \
  --dns="ca.contoso.internal" \
  --address=":443" \
  --provisioner="admin@contoso.com" \
  --deployment-type="standalone"

# Configure certificate defaults
cat > ca.json << 'EOF'
{
  "authority": {
    "provisioners": [
      {
        "type": "ACME",
        "name": "acme",
        "forceCN": true
      },
      {
        "type": "JWK",
        "name": "admin@contoso.com",
        "encryptedKey": "..."
      }
    ],
    "claims": {
      "minTLSCertDuration": "1h",
      "maxTLSCertDuration": "2160h",
      "defaultTLSCertDuration": "720h"
    }
  }
}
EOF
```

### Step 2: Implement Certificate Issuance

Different use cases require different issuance workflows:

**Public-facing web servers (ACME with Let's Encrypt):**

```bash
# Using certbot for ACME certificate issuance
certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials ~/.secrets/cloudflare.ini \
  -d "*.example.com" \
  -d "example.com" \
  --preferred-challenges dns-01 \
  --key-type ecdsa \
  --elliptic-curve secp256r1
```

**Internal services (Private CA with Vault PKI):**

```bash
# Enable Vault PKI secrets engine
vault secrets enable -path=pki_int pki
vault secrets tune -max-lease-ttl=8760h pki_int

# Generate intermediate CA (signed by root)
vault write pki_int/intermediate/generate/internal \
  common_name="Contoso TLS Issuing CA" \
  key_type="ec" \
  key_bits=256 \
  ttl=43800h

# Configure a role for issuing TLS certificates
vault write pki_int/roles/internal-tls \
  allowed_domains="contoso.internal" \
  allow_subdomains=true \
  max_ttl=2160h \
  key_type="ec" \
  key_bits=256 \
  require_cn=false \
  allowed_uri_sans="spiffe://contoso.internal/*"

# Issue a certificate
vault write pki_int/issue/internal-tls \
  common_name="api.contoso.internal" \
  alt_names="api.contoso.internal,api-v2.contoso.internal" \
  ttl=720h
```

**Kubernetes workloads (cert-manager):**

```yaml
# cert-manager Certificate resource
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: api-server-cert
  namespace: production
spec:
  secretName: api-server-tls
  duration: 720h    # 30 days
  renewBefore: 168h # Renew 7 days before expiry
  isCA: false
  privateKey:
    algorithm: ECDSA
    size: 256
  usages:
    - server auth
    - client auth
  dnsNames:
    - api.contoso.internal
    - api.production.svc.cluster.local
  issuerRef:
    name: vault-issuer
    kind: ClusterIssuer
    group: cert-manager.io
```

### Step 3: Automate Certificate Renewal

Manual certificate renewal does not scale and is the primary cause of certificate-related outages. Automate everything.

**ACME-based renewal (for public certificates):**

```bash
# Certbot automatic renewal (runs twice daily via systemd timer)
# /etc/systemd/system/certbot-renewal.timer
[Unit]
Description=Certbot renewal timer

[Timer]
OnCalendar=*-*-* 00,12:00:00
RandomizedDelaySec=3600
Persistent=true

[Install]
WantedBy=timers.target
```

```bash
# Certbot renewal with post-hook to reload services
certbot renew --deploy-hook "systemctl reload nginx"
```

**Vault PKI automatic renewal:**

```python
import hvac
import time
from datetime import datetime, timedelta

class CertificateManager:
    def __init__(self, vault_client, pki_mount, role):
        self.vault = vault_client
        self.pki_mount = pki_mount
        self.role = role
        self.current_cert = None
        self.cert_expiry = None

    def get_certificate(self, common_name, sans=None):
        """Get current certificate or issue a new one if expiring soon."""
        if self.current_cert and self.cert_expiry > datetime.now() + timedelta(days=7):
            return self.current_cert

        # Issue new certificate
        params = {
            "common_name": common_name,
            "ttl": "720h"
        }
        if sans:
            params["alt_names"] = ",".join(sans)

        response = self.vault.secrets.pki.generate_certificate(
            name=self.role,
            mount_point=self.pki_mount,
            **params
        )

        self.current_cert = {
            "certificate": response["data"]["certificate"],
            "private_key": response["data"]["private_key"],
            "ca_chain": response["data"]["ca_chain"],
            "serial_number": response["data"]["serial_number"]
        }
        self.cert_expiry = datetime.fromtimestamp(response["data"]["expiration"])

        return self.current_cert

    def start_renewal_loop(self, common_name, sans=None, check_interval=3600):
        """Background loop that renews certificates before expiry."""
        while True:
            cert = self.get_certificate(common_name, sans)
            days_until_expiry = (self.cert_expiry - datetime.now()).days

            if days_until_expiry <= 7:
                self.current_cert = None  # Force renewal on next call
                cert = self.get_certificate(common_name, sans)
                deploy_certificate(cert)  # Apply to web server, load balancer, etc.

            time.sleep(check_interval)
```

### Step 4: Implement Certificate Revocation

When a private key is compromised or a certificate is no longer needed, revocation must happen immediately.

**Certificate Revocation List (CRL):**

```bash
# Vault: Configure CRL
vault write pki_int/config/crl \
  expiry=72h \
  auto_rebuild=true \
  auto_rebuild_grace_period=12h \
  delta_rebuild_interval=15m

# Revoke a certificate
vault write pki_int/revoke serial_number="3a:cb:..."
```

CRLs are lists of revoked serial numbers that clients download periodically. They are simple but have drawbacks: the CRL can grow large, and there is a delay between revocation and the next CRL publish. For public certificates, CRLs are again the main mechanism: [Let's Encrypt shut down its OCSP responders](https://letsencrypt.org/2024/12/05/ending-ocsp/) on 6 August 2025.

**Online Certificate Status Protocol (OCSP):**

OCSP provides real-time revocation checking and remains useful for private PKI where you control the responders. The client sends the certificate's serial number to the OCSP responder and gets back a signed "good," "revoked," or "unknown" response.

```bash
# Check OCSP status
openssl ocsp \
  -issuer intermediate-ca.pem \
  -cert server.pem \
  -url http://ocsp.contoso.internal \
  -resp_text
```

**Short-lived certificates (the best approach):**

The most elegant revocation strategy is to not need revocation at all. If certificates are valid for only 24 hours (or less), a compromised certificate expires before an attacker can make meaningful use of it. This approach requires strong renewal automation but eliminates the complexity of CRL/OCSP infrastructure.

```yaml
# Short-lived certificate policy
policy:
  service_mesh_certificates:
    max_validity: "24h"
    renewal_interval: "12h"
    revocation_mechanism: "none"  # Expiry handles it

  server_certificates:
    max_validity: "90d"
    renewal_interval: "60d"
    revocation_mechanism: "OCSP + CRL"
```

### Step 5: Deploy Certificate Monitoring

```yaml
# Prometheus certificate monitoring with blackbox exporter
# prometheus.yml
scrape_configs:
  - job_name: 'tls-certificates'
    metrics_path: /probe
    params:
      module: [tls_connect]
    static_configs:
      - targets:
          - api.example.com:443
          - app.example.com:443
          - mail.example.com:465
          - vpn.example.com:443
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - target_label: __address__
        replacement: blackbox-exporter:9115

# Alert rules
groups:
  - name: certificate-alerts
    rules:
      - alert: CertificateExpiringSoon
        expr: probe_ssl_earliest_cert_expiry - time() < 30 * 24 * 3600
        for: 1h
        labels:
          severity: warning
        annotations:
          summary: "Certificate for {{ $labels.instance }} expires in less than 30 days"

      - alert: CertificateExpiringCritical
        expr: probe_ssl_earliest_cert_expiry - time() < 7 * 24 * 3600
        for: 1h
        labels:
          severity: critical
        annotations:
          summary: "Certificate for {{ $labels.instance }} expires in less than 7 days"

      - alert: CertificateExpired
        expr: probe_ssl_earliest_cert_expiry - time() < 0
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Certificate for {{ $labels.instance }} has EXPIRED"
```

**Certificate inventory scanning:**

```bash
#!/bin/bash
# Scan network for TLS certificates and record metadata
TARGETS_FILE="targets.txt"
OUTPUT_FILE="cert_inventory.csv"

echo "host,port,subject,issuer,not_before,not_after,serial,days_remaining" > "$OUTPUT_FILE"

while IFS=: read -r host port; do
  cert_info=$(echo | openssl s_client -connect "$host:$port" -servername "$host" 2>/dev/null | \
    openssl x509 -noout -subject -issuer -startdate -enddate -serial 2>/dev/null)

  if [ -n "$cert_info" ]; then
    subject=$(echo "$cert_info" | grep "subject=" | sed 's/subject=//')
    issuer=$(echo "$cert_info" | grep "issuer=" | sed 's/issuer=//')
    not_before=$(echo "$cert_info" | grep "notBefore=" | sed 's/notBefore=//')
    not_after=$(echo "$cert_info" | grep "notAfter=" | sed 's/notAfter=//')
    serial=$(echo "$cert_info" | grep "serial=" | sed 's/serial=//')

    expiry_epoch=$(date -d "$not_after" +%s 2>/dev/null || date -j -f "%b %d %T %Y %Z" "$not_after" +%s 2>/dev/null)
    now_epoch=$(date +%s)
    days_remaining=$(( (expiry_epoch - now_epoch) / 86400 ))

    echo "$host,$port,$subject,$issuer,$not_before,$not_after,$serial,$days_remaining" >> "$OUTPUT_FILE"
  fi
done < "$TARGETS_FILE"
```

### Step 6: Implement Certificate Pinning (Where Appropriate)

Certificate pinning adds a layer of defense by ensuring your application only trusts specific certificates or CAs, rather than any CA in the system trust store.

```javascript
// Node.js: Certificate pinning for API calls
const https = require('https');
const crypto = require('crypto');

const PINNED_FINGERPRINTS = [
  'sha256/YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=',  // Current
  'sha256/sRHdihwgkaib1P1gN7akqEC2K0VQ3oL+ship1pOv28I=',  // Backup
];

const agent = new https.Agent({
  checkServerIdentity: (hostname, cert) => {
    const fingerprint = crypto
      .createHash('sha256')
      .update(cert.raw)
      .digest('base64');

    const pinned = `sha256/${fingerprint}`;
    if (!PINNED_FINGERPRINTS.includes(pinned)) {
      throw new Error(`Certificate pin mismatch for ${hostname}`);
    }
  }
});
```

Use pinning sparingly and always include a backup pin (for the next certificate you will rotate to). Pinning the wrong thing or failing to update pins before certificate rotation causes outages.

## Configuration Best Practices

- **Use EC keys over RSA.** ECDSA P-256 provides equivalent security to RSA-2048 with smaller keys and faster operations. Use P-384 for root and intermediate CAs.
- **Keep certificate validity short.** 90 days or less for public-facing TLS (the public maximum is 200 days now and 47 days from March 2029), 30 days for internal services, 24 hours or less for service mesh. Shorter validity reduces the window of exposure from a compromised key.
- **Automate renewal at 2/3 of the certificate lifetime.** For a 90-day certificate, renew at day 60. This provides a 30-day buffer for troubleshooting if renewal fails.
- **Always include SAN entries.** Modern browsers require Subject Alternative Names (SANs). The Common Name (CN) is deprecated for hostname validation.
- **Separate CAs for different purposes.** Use separate intermediate CAs for TLS, client authentication, and code signing. This limits the blast radius of a CA compromise.
- **Store CA keys in HSMs.** Hardware Security Modules prevent key extraction and provide audit logging. At minimum, use an HSM for the root CA.

## Testing and Validation

1. **Issuance testing:** Issue a certificate and verify all fields (subject, SANs, key usage, extended key usage, validity, chain).
2. **Renewal testing:** Set a certificate's validity to 2 hours and verify that automated renewal kicks in after 1 hour.
3. **Revocation testing:** Revoke a certificate and verify that clients reject it (check CRL download or OCSP response).
4. **Chain validation testing:** Present the full certificate chain to a client and verify trust. Then remove the intermediate CA and verify the client rejects the connection.
5. **Expiry alerting testing:** Set a certificate to expire in 6 days and verify the critical alert fires.
6. **CA failover testing:** Simulate the primary issuing CA being unavailable. Verify that a standby CA can take over issuance.

## Common Pitfalls and Troubleshooting

| Problem | Cause | Solution |
|---------|-------|----------|
| "Certificate not trusted" | Incomplete chain; intermediate CA not sent | Configure the server to send the full chain (server cert + intermediate) |
| Certificate expires unexpectedly | Renewal automation failed silently | Monitor renewal job success/failure, not just certificate expiry |
| ACME challenge fails | DNS propagation delay or firewall blocking | Use DNS-01 challenges with low TTL; verify firewall allows CA to reach your server |
| Wildcard cert used everywhere | Single compromised key exposes all subdomains | Use specific certificates per service; limit wildcard use to CDN/load balancer |
| "Certificate key too weak" | RSA-1024 or similar deprecated key | Use EC P-256 or RSA-2048 minimum; audit all certificates for weak keys |
| mTLS handshake fails | Client certificate not signed by trusted CA | Verify the server's trust store includes the client CA |

## Security Considerations

1. **Protect private keys.** The private key is the most sensitive artifact. Store it in a file with restricted permissions (chmod 600), in a secrets vault, or in an HSM. Never transmit private keys over unencrypted channels.
2. **Root CA must be offline.** The root CA private key should never be on a network-connected machine. Keep it in an HSM in a physical safe. Only bring it online to sign new intermediate CA certificates (as a rough planning estimate, once every 3-5 years).
3. **Certificate Transparency (CT) logs.** For public certificates, submission to CT logs is mandatory. Monitor CT logs for unauthorized certificates issued for your domains, this can detect a compromised CA or a rogue certificate issuance.
4. **CAA DNS records.** Publish Certificate Authority Authorization (CAA) DNS records to restrict which CAs can issue certificates for your domain.
5. **Quantum readiness.** Current certificate algorithms (RSA, ECDSA) will be vulnerable to quantum computers. Begin planning for post-quantum cryptography (PQC) migration against the standards NIST published in August 2024: [FIPS 203](https://csrc.nist.gov/pubs/fips/203/final) (ML-KEM), [FIPS 204](https://csrc.nist.gov/pubs/fips/204/final) (ML-DSA), and [FIPS 205](https://csrc.nist.gov/pubs/fips/205/final) (SLH-DSA). Track your CA, HSM, and TLS library PQC roadmaps.

## Conclusion

Certificate lifecycle management is an operational discipline, not a one-time project. Certificates are constantly being issued, renewed, and revoked. The organizations that avoid certificate-related outages are those that invest in automation, monitoring, and short certificate lifetimes.

Start by gaining visibility: discover every certificate in your environment and monitor their expiry dates. Then automate renewal: use ACME for public certificates and Vault PKI or cert-manager for internal certificates. Finally, shorten lifetimes: move toward 90-day public certificates and 24-hour internal certificates. Each step reduces risk and operational burden.

## Conditional Access Policies: A Complete Implementation Guide for Microsoft Entra
Source: https://startwithidentity.com/guides/implementation/conditional-access-policies-guide/
Last updated: 2026-11-05

Conditional access is the engine that drives Zero Trust in Microsoft environments. Rather than granting blanket access based on credentials alone, conditional access evaluates every authentication request against a set of signals, user identity, device health, location, risk level, and application sensitivity, before deciding whether to allow, block, or require additional verification.

This guide walks you through designing and deploying conditional access policies in Microsoft Entra ID (formerly Azure Active Directory), from foundational concepts to advanced risk-based automation.

## Prerequisites

Before implementing conditional access policies, ensure you have the following in place:

- **Microsoft Entra ID P1 or P2 license**, P1 provides core conditional access; P2 adds risk-based policies and Identity Protection integration.
- **Global Administrator or Security Administrator role** in your Entra tenant.
- **Multi-factor authentication (MFA)** configured for at least your admin accounts.
- **Device management** through Microsoft Intune or a supported MDM if you plan to enforce device compliance.
- **Named locations** defined for your corporate offices, VPN exit points, and trusted networks.
- A **break-glass account** excluded from all conditional access policies, stored securely with monitoring enabled.

## Architecture and Core Concepts

### How Conditional Access Works

Every time a user authenticates, Microsoft Entra evaluates the request through a policy engine. The evaluation follows this flow:

1. **Signal collection**, The engine gathers context: who is the user, what device are they on, where are they connecting from, what application are they accessing, and what is their risk level.
2. **Policy matching**, All enabled policies are evaluated. A policy applies when its conditions (assignments) match the current authentication context.
3. **Control enforcement**, Matching policies enforce their access controls. If multiple policies apply, the most restrictive combination wins.
4. **Session controls**, After granting access, session controls can limit what the user can do (sign-in frequency, persistent browser sessions, app-enforced restrictions).

### The Policy Structure

Every conditional access policy has two parts:

**Assignments (When does this policy apply?)**
- Users and groups (include/exclude)
- Cloud apps or actions
- Conditions: device platforms, locations, client apps, user risk, sign-in risk, device state

**Access Controls (What happens when it applies?)**
- Grant controls: block access, require MFA, require compliant device, require Microsoft Entra hybrid joined device, require approved client app, require app protection policy
- Session controls: sign-in frequency, persistent browser, conditional access app control (Microsoft Defender for Cloud Apps), customize token lifetime

## Step-by-Step Implementation

### Step 1: Establish Your Baseline Policies

Start with a foundational set of policies that protect your highest-risk scenarios. Deploy these in report-only mode first.

**Policy 1: Require MFA for all administrators**

Navigate to Microsoft Entra admin center > Protection > Conditional Access > Create new policy.

- **Name:** CA001, Require MFA for Admins
- **Assignments:**
  - Users: Include directory roles, Global Administrator, Security Administrator, Exchange Administrator, SharePoint Administrator, User Administrator, Helpdesk Administrator, Billing Administrator, Compliance Administrator
  - Exclude: Your break-glass accounts
  - Cloud apps: All cloud apps
- **Grant:** Require multifactor authentication
- **Session:** Sign-in frequency, 4 hours

**Policy 2: Require MFA for all users**

- **Name:** CA002, Require MFA for All Users
- **Assignments:**
  - Users: All users
  - Exclude: Break-glass accounts, service accounts that cannot perform MFA
  - Cloud apps: All cloud apps
  - Conditions: Client apps, Browser, Mobile apps and desktop clients
- **Grant:** Require multifactor authentication

**Policy 3: Block legacy authentication**

Legacy authentication protocols (IMAP, POP3, SMTP, older Office clients) cannot perform MFA and represent a massive attack surface.

- **Name:** CA003, Block Legacy Authentication
- **Assignments:**
  - Users: All users
  - Cloud apps: All cloud apps
  - Conditions: Client apps, Exchange ActiveSync clients, Other clients
- **Grant:** Block access

### Step 2: Implement Location-Based Policies

Define your trusted locations first, then build policies around them.

**Creating Named Locations:**

1. Go to Protection > Conditional Access > Named locations.
2. Add your corporate office IP ranges as a trusted location.
3. Add any VPN egress IP ranges.
4. Consider marking specific countries as blocked if your organization has no business presence there.

**Policy 4: Block access from high-risk countries**

- **Name:** CA004, Block Access from Restricted Countries
- **Assignments:**
  - Users: All users (exclude break-glass)
  - Cloud apps: All cloud apps
  - Conditions: Locations, Include selected locations (countries you want to block), Exclude trusted locations
- **Grant:** Block access

**Policy 5: Require compliant device from untrusted locations**

- **Name:** CA005, Require Compliant Device Off-Network
- **Assignments:**
  - Users: All users
  - Cloud apps: Office 365 (or specific sensitive apps)
  - Conditions: Locations, Exclude trusted locations (so this fires only off-network)
- **Grant:** Require device to be marked as compliant OR require multifactor authentication

### Step 3: Deploy Risk-Based Policies (Requires Entra P2)

Microsoft Entra Identity Protection assigns risk scores to users and sign-ins based on behavioral analysis, threat intelligence, and anomaly detection.

**Sign-in risk levels:**
- **High**, Strong indicators of compromise (impossible travel + credential stuffing pattern)
- **Medium**, Suspicious but not definitive (unfamiliar location + anonymous IP)
- **Low**, Mildly unusual behavior

**User risk levels:**
- **High**, Leaked credentials confirmed or multiple high-risk sign-ins
- **Medium**, Some indicators of account compromise
- **Low**, Minor anomalies

**Policy 6: Respond to high sign-in risk**

- **Name:** CA006, High Sign-in Risk Response
- **Assignments:**
  - Users: All users (exclude break-glass)
  - Cloud apps: All cloud apps
  - Conditions: Sign-in risk, High
- **Grant:** Require multifactor authentication
- **Session:** Sign-in frequency, every time

**Policy 7: Respond to high user risk**

- **Name:** CA007, High User Risk Response
- **Assignments:**
  - Users: All users (exclude break-glass)
  - Cloud apps: All cloud apps
  - Conditions: User risk, High
- **Grant:** Require multifactor authentication AND require password change

### Step 4: Device Compliance Policies

For organizations using Intune or another MDM, device compliance adds a powerful security layer.

**Define compliance requirements in Intune first:**
- OS version minimums (e.g., Windows 11 23H2+, macOS 14+, iOS 17+)
- Encryption required
- Firewall enabled
- Antivirus active and up to date
- No jailbreak/root detection

**Policy 8: Require compliant device for sensitive apps**

- **Name:** CA008, Require Compliant Device for Sensitive Apps
- **Assignments:**
  - Users: All users
  - Cloud apps: Select your sensitive applications (HR systems, finance apps, admin portals)
  - Conditions: Device platforms, Windows, macOS, iOS, Android
- **Grant:** Require device to be marked as compliant

### Step 5: Application-Specific Policies

Different applications warrant different levels of protection.

**Policy 9: Restrict Azure portal access**

- **Name:** CA009, Restrict Azure Management
- **Assignments:**
  - Users: All users (exclude admins group, break-glass)
  - Cloud apps: Microsoft Azure Management, Microsoft Graph PowerShell
- **Grant:** Block access

This ensures only designated administrators can access Azure management interfaces.

## Best Practices

### Policy Naming Convention

Adopt a consistent naming scheme. A proven pattern:

```
CA[NNN], [Action] [Target] [Condition]
```

Examples:
- CA001, Require MFA for Admins
- CA004, Block Access from Restricted Countries
- CA008, Require Compliant Device for Sensitive Apps

### Report-Only Mode Is Non-Negotiable

Never deploy a conditional access policy directly to enforcement. Always:

1. Create the policy in **report-only** mode.
2. Monitor the Conditional Access insights workbook for 1-2 weeks.
3. Review the sign-in logs to identify affected users and potential disruptions.
4. Adjust exclusions if necessary.
5. Move to **on** only after validating impact.

### Exclusion Hygiene

Every exclusion is a potential security gap. For every excluded user or group:

- Document the business justification.
- Set a review date (quarterly at minimum).
- Use a dedicated security group for exclusions rather than excluding individual accounts.
- Monitor excluded accounts more aggressively.

### Policy Ordering and Conflicts

Conditional access policies do not have explicit ordering. All matching policies apply simultaneously, and the most restrictive grant controls win. This means:

- If Policy A requires MFA and Policy B requires a compliant device, the user must satisfy both.
- If any matching policy blocks access, access is blocked regardless of other policies.

Design your policies with this additive model in mind.

## Testing Your Policies

### Use the What If Tool

The What If tool in the Entra admin center lets you simulate policy evaluation without actually signing in.

1. Navigate to Protection > Conditional Access > What If.
2. Select a user, an application, and optionally set conditions (IP address, device platform, risk level).
3. Click "What If" to see which policies would apply and what controls would be enforced.

Test every policy against these scenarios:
- Admin signing in from a corporate device on the trusted network
- Regular user signing in from a personal device off-network
- User signing in from a blocked country
- User with elevated risk score
- Service account authenticating via API

### Sign-In Log Analysis

After enabling report-only policies, regularly check:

1. **Sign-in logs**, Filter by conditional access status (success, failure, report-only)
2. **Conditional Access insights workbook**, Provides aggregated views of policy impact
3. **Risky sign-ins report**, Shows whether risk-based policies would have caught actual threats

## Common Pitfalls

### Locking Yourself Out

The most dangerous mistake is creating a policy that blocks all users from all apps without a break-glass exclusion. Always:

- Maintain at least two break-glass accounts excluded from all policies
- Store break-glass credentials in a physical safe or hardware security module
- Monitor break-glass account usage with alerts
- Test break-glass accounts quarterly

### Forgetting Service Accounts

Service accounts and automated processes often cannot perform MFA. If you apply an MFA policy to all users without excluding service accounts, automated workflows will break. Identify all service accounts, place them in a dedicated group, and exclude that group from MFA policies while applying compensating controls (IP restrictions, specific app restrictions).

### Over-Relying on Location

IP-based location policies are useful but imperfect. Users on VPNs, mobile hotspots, or traveling may trigger unexpected blocks. Always pair location-based policies with alternative grant options (MFA instead of block when off-network) unless you have a strong business reason to hard-block.

### Ignoring Guest and B2B Users

External users (B2B guests) are subject to conditional access policies in your tenant. If you require MFA for all users, guests will need to perform MFA too. Consider whether your partners can satisfy this requirement and create appropriate guest-specific policies.

### Not Planning for Failure

If your MFA provider experiences an outage, every user could be locked out. Plan for this by:

- Enabling multiple MFA methods (authenticator app + phone + FIDO2 key)
- Having a documented emergency procedure to temporarily disable MFA policies
- Monitoring MFA service health proactively

## Conclusion

Conditional access policies are the linchpin of modern identity security in Microsoft environments. They transform authentication from a binary yes/no gate into a dynamic, context-aware decision engine. Start with the foundational policies, MFA for all users, blocking legacy authentication, and location-based controls, then layer on risk-based policies and device compliance as your maturity grows.

The key to success is disciplined deployment: always use report-only mode first, maintain break-glass accounts, document every exclusion, and review policy effectiveness quarterly. Conditional access is not a set-and-forget technology. It requires ongoing tuning as your organization, threat landscape, and user behaviors evolve.

## Customer Identity Verification Guide: KYC, Document Verification, and Fraud Prevention
Source: https://startwithidentity.com/guides/compliance/customer-identity-verification-guide/
Last updated: 2026-11-05

Customer identity verification sits at the intersection of security, compliance, and user experience. Financial institutions must verify customers to comply with [Know Your Customer (KYC)](https://startwithidentity.com/glossary/kyc/) and [Anti-Money Laundering (AML)](https://startwithidentity.com/glossary/aml/) regulations. Healthcare organizations must verify patients to protect health records. E-commerce platforms must verify sellers to prevent fraud. Even social media platforms increasingly verify users to combat misinformation and abuse.

The challenge is that verification creates friction, and friction drives customers away. Require too much verification upfront and customers abandon onboarding. Require too little and you expose your platform to fraud, regulatory penalties, and reputational damage.

This guide covers the technical and operational aspects of building a customer identity verification system that balances security, compliance, and user experience.

## Prerequisites

- **Regulatory clarity**, Understand which verification requirements apply to your business (KYC/AML for financial services, HIPAA for healthcare, age verification for restricted content).
- **CIAM platform**, A Customer Identity and Access Management platform ([Auth0](https://startwithidentity.com/vendors/ciam/auth0/), [Ping Identity](https://startwithidentity.com/vendors/iam/ping-identity/), [Amazon Cognito](https://startwithidentity.com/vendors/ciam/amazon-cognito/)) that supports step-up verification workflows.
- **Verification service provider**, [Jumio](https://startwithidentity.com/vendors/identity-verification/jumio/), [Onfido (now Entrust IDV)](https://startwithidentity.com/vendors/identity-verification/onfido/), [Socure](https://startwithidentity.com/vendors/identity-verification/socure/), [Persona](https://startwithidentity.com/vendors/identity-verification/persona/), or similar identity verification API.
- **Legal review**, Data privacy implications of collecting and storing identity documents (GDPR, CCPA, state biometric privacy laws).
- **User experience team**, Verification flows must be designed with UX expertise to minimize abandonment.

## Architecture: Identity Verification Framework

### Verification Levels

Not every customer interaction requires the same level of identity assurance. Define verification levels based on risk:

**Level 0: Anonymous / Self-Asserted**
- Email address (unverified or verified)
- Self-asserted name and profile information
- Use cases: Content browsing, free tier, community forums

**Level 1: Basic Verification**
- Email verification (confirmation link)
- Phone number verification (SMS or voice code)
- Use cases: Account creation, basic transactions, communication features
- Not included: knowledge-based questions ("which of these streets have you lived on?"). [NIST SP 800-63A-4](https://pages.nist.gov/800-63-4/sp800-63a.html) states that knowledge-based verification "SHALL NOT be used for identity verification," because the answers are often exposed in breaches and sold by data brokers. Do not use KBA as a proofing step at any level.

**Level 2: Enhanced Verification**
- Government ID document check (driver's license, passport)
- Name and date of birth match against authoritative sources
- Address verification
- Use cases: Financial transactions, age-restricted content, regulated services

**Level 3: Full Identity Proofing**
- Government ID + biometric liveness detection
- Credit bureau or utility data cross-reference
- Sanctions and PEP (Politically Exposed Person) screening
- Source of funds verification
- Use cases: High-value financial accounts, regulated financial services, high-risk transactions

### The Verification Architecture

```
Customer
    ↓ (onboarding / transaction trigger)
CIAM Platform (orchestration)
    ↓ (step-up verification workflow)
Verification Service (Jumio, Onfido, Persona)
    ├── Document Capture (OCR + authenticity checks)
    ├── Biometric Liveness Detection (face match + anti-spoofing)
    ├── Data Verification (credit bureau, utility, government databases)
    └── Watchlist Screening (sanctions, PEP, adverse media)
    ↓ (verification result)
Risk Engine (aggregate signals, make decision)
    ↓ (allow / deny / step-up / manual review)
CIAM Platform (update customer profile, grant/deny access)
```

## Step-by-Step Implementation

### Step 1: Design Your Verification Tiers

Map your business activities to verification requirements:

| Activity | Verification Level | Required Checks |
|---|---|---|
| Create account | Level 1 | Email + phone verification |
| Link bank account | Level 2 | Government ID + name match |
| Send money (< $500) | Level 2 | Government ID (one-time) |
| Send money (> $3,000) | Level 3 | Full KYC + source of funds |
| Change payout method | Level 2 | Re-verification + step-up auth |
| Access health records | Level 2 | Government ID + biometric |
| Purchase age-restricted | Level 2 | Government ID + age check |

### Step 2: Implement Document Verification

Document verification involves capturing an identity document (passport, driver's license, national ID) and validating its authenticity.

**Document capture best practices:**

1. **Guide the user**, Provide real-time feedback during capture (lighting, angle, blur detection). Poor captures cause verification failures and frustration.
2. **Support multiple document types**, Accept passports, driver's licenses, and national IDs from all countries where you operate.
3. **Use both sides**, For driver's licenses and national IDs, capture front and back.
4. **Handle edge cases**, Expired documents, damaged documents, documents in non-Latin scripts.

**Document authenticity checks:**

Your verification provider performs multiple checks on the captured document:

- **Visual inspection**, Holograms, microprinting, laser perforations, UV features (via image analysis)
- **Template matching**, Document layout matches the expected format for the issuing country and document type
- **MRZ/barcode validation**, Machine-readable zone or barcode data matches the visual data
- **Tamper detection**, Font inconsistencies, image manipulation artifacts, digital alteration signs
- **Database verification**, For some document types and countries, verification against government databases

**Integration example:**

```javascript
// Server-side: Initiate document verification
async function initiateVerification(userId, documentType) {
  const verification = await verificationProvider.createSession({
    referenceId: userId,
    workflow: [
      {
        type: "document_capture",
        documentType: documentType, // "passport", "drivers_license", "national_id"
        sides: documentType === "passport" ? ["front"] : ["front", "back"],
      },
      {
        type: "face_capture",
        livenessCheck: true,
      },
      {
        type: "face_document_match",
        threshold: MATCH_THRESHOLD, // set from your provider's guidance and your own false-match testing
      },
    ],
    callbackUrl: "https://api.myapp.com/webhooks/verification",
  });

  return { sessionId: verification.id, redirectUrl: verification.url };
}

// Webhook handler: Process verification result
async function handleVerificationResult(webhookPayload) {
  const { referenceId, status, checks } = webhookPayload;

  if (status === "approved") {
    await updateCustomerVerificationLevel(referenceId, "level_2");
    await grantVerifiedAccess(referenceId);
    await notifyCustomer(referenceId, "verification_approved");
  } else if (status === "needs_review") {
    await flagForManualReview(referenceId, checks);
  } else {
    await notifyCustomer(referenceId, "verification_failed", checks.failureReasons);
    await logVerificationFailure(referenceId, checks);
  }
}
```

### Step 3: Implement Biometric Liveness Detection

Liveness detection ensures the person presenting the document is physically present and not using a photograph, video, or deepfake.

**Active liveness:** The user is asked to perform actions, turn their head, blink, smile, or follow a moving target. This is more secure but adds friction.

**Passive liveness:** The system analyzes the selfie or video for liveness signals without asking the user to perform actions, depth analysis, texture analysis, motion detection. This is lower friction but slightly less secure.

**Anti-spoofing techniques:**

- **2D photo detection**, Detect flat images held in front of the camera
- **Screen replay detection**, Detect video replays on screens
- **3D mask detection**, Detect 3D-printed or silicone masks
- **Deepfake detection**, Analyze for generative AI artifacts in the face image
- **Injection attack detection**, Detect virtual cameras or modified camera feeds

**Face-to-document matching:**

After capturing both the document and a live selfie, the system compares the face on the document to the live capture:

1. Extract the face image from the document.
2. Normalize both images (lighting, angle, resolution).
3. Generate facial embeddings using a deep learning model.
4. Compare embeddings using cosine similarity.
5. Apply a similarity threshold. Scores are model-specific, so take the starting value from your provider and tune it against your own false-match and false-rejection data rather than copying a number from another system.

### Step 4: Implement Progressive Profiling

[Progressive profiling](https://startwithidentity.com/glossary/progressive-profiling/) collects identity information incrementally as the customer relationship deepens, rather than demanding everything upfront.

**The progressive verification journey:**

```
Sign Up → Email only → Browse and explore
    ↓ (first transaction trigger)
Step Up → Phone verification → Basic transactions enabled
    ↓ (higher-value transaction trigger)
Step Up → Government ID → Full transaction capabilities
    ↓ (high-risk activity trigger)
Step Up → Full KYC with liveness → Unrestricted access
```

**Implementation with CIAM orchestration:**

```javascript
// Middleware: Check verification level before allowing action
async function verificationGate(req, res, next) {
  const user = req.user;
  const requiredLevel = getRequiredVerificationLevel(req.path, req.method);

  if (user.verificationLevel >= requiredLevel) {
    return next();
  }

  // Determine what additional verification is needed
  const nextSteps = getVerificationSteps(user.verificationLevel, requiredLevel);

  return res.status(403).json({
    error: "additional_verification_required",
    requiredLevel: requiredLevel,
    currentLevel: user.verificationLevel,
    verificationUrl: `/verify?steps=${nextSteps.join(",")}`,
    message: `This action requires ${getLevelDescription(requiredLevel)}. Please complete identity verification to continue.`,
  });
}
```

### Step 5: Implement Fraud Prevention Signals

Identity verification is one input to a broader fraud prevention system. Layer multiple signals:

**Device intelligence:**
- Device fingerprinting (browser, OS, hardware characteristics)
- Device reputation (has this device been associated with fraud?)
- Device anomalies (emulator detection, rooted/jailbroken device)

**Behavioral analytics:**
- Typing patterns during onboarding
- Navigation patterns (bot-like behavior vs. human)
- Time-to-complete (too fast suggests automation, too slow suggests multi-tasking/fraud toolkit)

**Network signals:**
- IP reputation and geolocation
- VPN/proxy/Tor detection
- Carrier and ASN analysis
- IP-to-document-country mismatch

**Data consistency signals:**
- Name on document matches name entered during registration
- Address on document matches billing address
- Phone number country matches document country
- Email domain age and reputation

**Risk scoring:**

Combine all signals into a risk score:

```python
# Illustrative weights only: calibrate every number against your own fraud outcomes.
def calculate_risk_score(verification_result, device_signals, behavioral_signals, network_signals):
    score = 0

    # Document verification result
    if verification_result.status == "approved":
        score += 0  # no risk from verified document
    elif verification_result.status == "needs_review":
        score += 40
    else:
        score += 80

    # Device signals
    if device_signals.is_emulator:
        score += 30
    if device_signals.reputation == "suspicious":
        score += 20

    # Network signals
    if network_signals.is_vpn and not user_normally_uses_vpn:
        score += 15
    if network_signals.country != verification_result.document_country:
        score += 25

    # Behavioral signals
    if behavioral_signals.time_to_complete < 30:  # seconds
        score += 20  # suspiciously fast

    return min(score, 100)
```

**Decision matrix:**

Map score bands to actions, and set the cut-offs from your own approval, fraud and appeal data rather than from a published template:

| Risk band | Action |
|---|---|
| Low | Auto-approve |
| Moderate | Approve with enhanced monitoring |
| Elevated | Route to manual review |
| High | Auto-decline with appeal option |

### Step 6: Handle Watchlist and Sanctions Screening

For regulated businesses, verify customers against sanctions lists and PEP databases:

**Screening databases:**
- OFAC SDN (US Treasury sanctions list)
- EU Consolidated Sanctions List
- UN Security Council Consolidated List
- PEP databases (politically exposed persons)
- Adverse media databases

**Screening workflow:**

1. Extract name, date of birth, and country from the verified document.
2. Screen against all applicable watchlists.
3. Handle fuzzy matches (name transliterations, common name variations).
4. For potential matches, route to compliance team for manual adjudication.
5. Document the screening result and disposition.
6. Re-screen existing customers periodically (daily or when lists update).

## Best Practices

### Optimize for Mobile

Most customer identity verification happens on mobile devices. Ensure:
- Camera capture works reliably on iOS and Android
- The verification flow is responsive and touch-friendly
- Document capture guides are clear on small screens
- The process works on slower connections (progressive upload, compression)

### Provide Clear Error Recovery

When verification fails, tell the customer why and how to fix it:
- "Your document was too blurry. Please try again in better lighting."
- "We could not match your selfie to the document photo. Please remove glasses or hats."
- "This document type is not accepted. Please use a passport or driver's license."

### Store Verification Results, Not Documents

After verification, store the verification result (passed/failed, verification ID, date, level achieved) but minimize storage of the actual documents and biometric data. This reduces your data protection obligations and breach impact.

### Implement Re-Verification Triggers

Identity verification is not a one-time event. Trigger re-verification when:
- High-risk transactions are attempted
- Account details are changed (email, phone, bank account)
- Unusual activity is detected
- A specified time period has elapsed (annual re-KYC for regulated services)
- Sanctions lists are updated with potential matches

### Support Accessibility

Verification flows must be accessible:
- Provide alternatives for users who cannot complete biometric checks (in-person verification, video call with an agent)
- Support screen readers where possible
- Provide clear instructions in multiple languages
- Accommodate users with disabilities that affect document handling or selfie capture

## Testing

1. **Happy path testing**, Verify that legitimate documents from all supported countries pass correctly.
2. **Fraud testing**, Test with known fraudulent documents (your verification provider typically supplies test cases).
3. **Liveness testing**, Test with printed photos, screen replays, and (if available) synthetic media to verify anti-spoofing.
4. **Edge case testing**, Expired documents, damaged documents, documents with non-Latin characters, documents from less common countries.
5. **Performance testing**, Measure verification completion rates, average time-to-verify, and abandonment rates.
6. **Accessibility testing**, Verify that alternative verification paths work for users who cannot complete the standard flow.

## Common Pitfalls

### Asking for Too Much Too Soon

Requiring full KYC at account creation when the customer just wants to browse your platform guarantees high abandonment. Use progressive profiling to defer verification until the customer is engaged enough to tolerate the friction.

### Ignoring False Rejection Rates

Every identity verification system has a false rejection rate, legitimate customers who fail verification due to poor image quality, unusual documents, or biometric matching errors. Monitor your false rejection rate and provide clear, easy recovery paths. A 5% false rejection rate means 1 in 20 legitimate customers is being turned away.

### Not Planning for Manual Review

Automated verification will not resolve every case. Budget for a manual review team that can handle ambiguous results, customer appeals, and complex cases, and size it from the review rate you measure in a pilot with your real customer mix.

### Collecting Biometric Data Without Legal Review

Biometric data (facial images, fingerprints) is subject to strict regulation in many jurisdictions. Illinois BIPA, Texas CUBI, and GDPR all have specific requirements for biometric data collection, storage, and consent. Get legal review before implementing biometric verification.

### Treating Verification as a One-Time Event

KYC is not "done" after onboarding. Ongoing monitoring, periodic re-verification, and continuous sanctions screening are required for regulated businesses. Build your architecture to support ongoing verification, not just initial identity proofing.

## Conclusion

Customer identity verification is a balancing act between security, compliance, and user experience. The most effective implementations use progressive profiling to minimize upfront friction, layer multiple verification signals for fraud detection, and maintain ongoing monitoring rather than relying on a single verification event.

Choose your verification tiers based on your actual risk and regulatory requirements. Invest in mobile-optimized capture experiences that guide customers through the process. Build strong error recovery and manual review capabilities. And treat the verification result, not the raw documents and biometrics, as the long-term record.

## Decentralized Identity Explained: A Practical Guide
Source: https://startwithidentity.com/guides/decentralized-identity/decentralized-identity-explained/
Last updated: 2026-11-05

---

Decentralized identity lets people and organizations hold cryptographically signed credentials in a wallet and present them directly to a verifier, who checks the issuer's signature instead of calling a central identity provider. This guide is the practitioner view: which formats and protocols matter, how a verifier decides to trust an issuer, what changed in 2025 and 2026, and how to run a pilot. For the conceptual primer, read [what is decentralized identity](https://startwithidentity.com/guides/fundamentals/what-is-decentralized-identity/) and [what is self-sovereign identity](https://startwithidentity.com/guides/fundamentals/what-is-self-sovereign-identity/).

**Verdict as of November 2026:** build to the 1.0 Final OpenID4VC specs profiled by HAIP, issue SD-JWT VC or mdoc if you need EU or mDL interoperability, and start where you repeat identity verification. Do not plan to replace SSO.

## The core idea

Today a central [identity provider](https://startwithidentity.com/glossary/identity-provider/) sits between you and every service, authenticating you and vouching for you. Decentralized identity removes that runtime dependency. You hold [verifiable credentials](https://startwithidentity.com/standards/verifiable-credentials/) in a [wallet](https://startwithidentity.com/glossary/digital-wallet/) and present them directly, and the verifier trusts the issuer's signature, not a live connection to a provider.

## The trust triangle: issuer, holder, verifier

Every interaction has the same three roles, the [issuer, holder, verifier](https://startwithidentity.com/glossary/issuer-holder-verifier/) triangle:

- The **issuer** signs and grants a credential (a university, a government, an employer).
- The **holder** stores it and decides when and to whom to present it.
- The **verifier** checks the signature, the issuer, and the [revocation](https://startwithidentity.com/glossary/revocation-registry/) status, offline if needed.

The verifier's ability to check a credential without calling the issuer is what makes the model scale and preserves privacy.

## What changed in 2025 and 2026

| Date | Milestone |
|---|---|
| 15 May 2025 | W3C [Verifiable Credentials Data Model 2.0](https://startwithidentity.com/standards/verifiable-credentials/) becomes a Recommendation, with Bitstring Status List v1.0 |
| 9 July 2025 | [OpenID4VP 1.0](https://startwithidentity.com/standards/openid4vc/) Final |
| 16 September 2025 | OpenID4VCI 1.0 Final |
| November 2025 | SD-JWT published as RFC 9901 |
| 24 December 2025 | HAIP 1.0 (High Assurance Interoperability Profile) Final |
| 5 March 2026 | [DID 1.1](https://startwithidentity.com/standards/decentralized-identifiers-did/) Candidate Recommendation Snapshot |
| 23 July 2026 | EU Architecture and Reference Framework (ARF) v3.0.0 |
| End of 2026 | Every EU member state must offer at least one [EUDI Wallet](https://startwithidentity.com/standards/eidas-2-eudi-wallet/) |

Dates and sources are on each linked standards page. The practical effect: the years of competing drafts are over, and "which spec version" is now a procurement question with a right answer.

## Choosing a credential format

| If your verifiers are | Use | Why |
|---|---|---|
| EU wallet relying parties | SD-JWT VC or ISO mdoc under HAIP | The only formats the ARF names for person identification data |
| Driver's license and age checks | [ISO/IEC 18013-5 mdoc](https://startwithidentity.com/standards/iso-18013-5-mdl/) | What US state mDLs and phone wallets issue |
| JSON-LD ecosystems needing unlinkable proofs | W3C VC 2.0 with Data Integrity, later BBS | BBS cryptosuite is still a Candidate Recommendation |
| Existing Hyperledger Indy networks | [AnonCreds](https://startwithidentity.com/glossary/anoncreds/) | Zero-knowledge predicates, ledger-anchored |

[SD-JWT](https://startwithidentity.com/glossary/sd-jwt/) gives [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/): the issuer signs a digest of each claim, and the holder reveals only the claims requested, bound to a fresh nonce. [Zero-knowledge proofs](https://startwithidentity.com/glossary/zero-knowledge-proof/) and [BBS signatures](https://startwithidentity.com/glossary/bbs-signature/) add unlinkability across presentations.

## How a verifier decides to trust an issuer

A valid signature proves only that someone holding a key signed the credential. Trust comes from knowing whose key it is:

- **X.509 and trusted lists.** HAIP requires issuers to carry X.509 certificate chains, the EU wallet uses trusted lists, and US mDLs chain to state roots published in AAMVA's Verified Issuer Certificate Authority List. This is the [PKI](https://startwithidentity.com/glossary/pki/) path, and it dominates government deployments.
- **DIDs.** [`did:web`](https://startwithidentity.com/guides/decentralized-identity/did-methods-compared/) resolves an issuer key from a domain the issuer controls; ledger methods resolve it from a chain. Pair either with a [trust registry](https://startwithidentity.com/glossary/trust-registry/) that says which issuers are accredited for which credentials.

Revocation works the same way in every format: the issuer publishes a status list, and the verifier fetches the whole list rather than asking about one credential. SD-JWT VC and mdoc use the IETF Token Status List; W3C credentials use Bitstring Status List.

## Where it is real in 2026

- **Government wallets:** eIDAS 2.0 puts a state wallet in every EU citizen's hands; public authorities must accept it from the end of 2026, and regulated private relying parties within 36 months of the December 2024 implementing acts.
- **Mobile driver's licenses:** ISO/IEC 18013-5 mDLs are shipping into phone wallets, and Google's documentation says Google Wallet accepts mdoc IDs online over OpenID4VP 1.0 through the Digital Credentials API. Track schemes in [digital IDs by country](https://startwithidentity.com/digital-ids/).
- **Reusable identity and KYC:** verify once, reuse the credential. This is the clearest enterprise ROI, covered in [reusable identity and KYC with verifiable credentials](https://startwithidentity.com/guides/decentralized-identity/reusable-identity-and-kyc-with-verifiable-credentials/).

## How it fits with what you already run

Decentralized identity does not replace [federated identity](https://startwithidentity.com/guides/decentralized-identity/decentralized-identity-vs-federated-identity/). [SAML](https://startwithidentity.com/standards/saml-2-0/) and [OIDC](https://startwithidentity.com/standards/openid-connect/) remain the right tools for workforce SSO. The realistic picture is hybrid: federated for existing sign-in, verifiable credentials for reusable proofs and portability, stitched by an [identity fabric](https://startwithidentity.com/guides/fundamentals/what-is-identity-fabric/).

## Pitfalls we see

- **Draft drift.** A product built on OpenID4VP draft 14 or 20 will not talk to a 1.0 wallet. [Microsoft Entra Verified ID](https://startwithidentity.com/vendors/decentralized-identity/microsoft-entra-verified-id/), for example, documents VC Data Model 1.1, OpenID4VCI draft 11 and did:web only, with no SD-JWT or mdoc support.
- **Cross-device phishing.** A QR code can be relayed from an attacker's session to a victim. HAIP requires same-device redirects to return to the original session; the Digital Credentials API adds the verifier's origin.
- **Building to the ARF alone.** The implementing acts are the binding text and are being amended. Track act numbers, not just ARF releases.
- **Skipping status checks.** Check revocation on every presentation.

## Should it be on your roadmap?

Ask three questions:

1. **Do you repeat identity verification** on the same people across products or partners? Reusable credentials pay off fastest here.
2. **Do you operate in or serve the EU?** eIDAS 2.0 is moving wallet acceptance from optional to expected.
3. **Do you issue credentials** (certifications, memberships, employment) that should be portable and holder-controlled? You may be an issuer, not just a verifier.

If none apply, watch the space. If any do, run a scoped pilot: pick one credential and one verifier, choose the format from the table above, require HAIP 1.0 conformance from vendors, and keep your existing KYC path as fallback. For vendors, [walt.id](https://startwithidentity.com/vendors/decentralized-identity/walt-id/) and [Procivis](https://startwithidentity.com/vendors/decentralized-identity/procivis/) document OpenID4VCI 1.0 and OpenID4VP 1.0, [MATTR](https://startwithidentity.com/vendors/decentralized-identity/mattr/) and [Spruce ID](https://startwithidentity.com/vendors/decentralized-identity/spruce-id/) focus on mDL and government credentials, and [Trinsic](https://startwithidentity.com/vendors/decentralized-identity/trinsic/) accepts existing digital IDs through one API. Our [choosing a decentralized identity platform](https://startwithidentity.com/guides/decentralized-identity/choosing-a-decentralized-identity-platform/) guide covers selection, and [best decentralized identity platforms](https://startwithidentity.com/rankings/best-decentralized-identity-platforms/) ranks the market.

## Where to go next

Build details: [verifiable credentials implementation guide](https://startwithidentity.com/guides/decentralized-identity/verifiable-credentials-implementation-guide/). Architecture: [DID methods compared](https://startwithidentity.com/guides/decentralized-identity/did-methods-compared/). Protocols: [OpenID4VC](https://startwithidentity.com/standards/openid4vc/). Vendors: [decentralized identity directory](https://startwithidentity.com/vendors/decentralized-identity/).

## Decentralized Identity vs Federated Identity
Source: https://startwithidentity.com/guides/decentralized-identity/decentralized-identity-vs-federated-identity/
Last updated: 2026-11-05

Federated identity and decentralized identity both answer "how does a service know who you are,"
but they do it in opposite ways. **Federation asks a live identity provider at every login;
decentralized identity checks a credential the user already holds, without calling the issuer.**
That one difference drives the differences in privacy, availability, revocation, and fit. Most
organizations will run both. For the primers, see
[what is decentralized identity](https://startwithidentity.com/guides/fundamentals/what-is-decentralized-identity/) and
[SAML vs OIDC](https://startwithidentity.com/guides/fundamentals/saml-vs-oidc/).

## The two models

**Federated identity** puts a central [identity provider](https://startwithidentity.com/glossary/identity-provider/) in the
middle. At login, the IdP authenticates you and sends the service (the
[relying party](https://startwithidentity.com/glossary/relying-party/)) an assertion vouching for you, using
[SAML](https://startwithidentity.com/standards/saml-2-0/) or [OpenID Connect](https://startwithidentity.com/standards/openid-connect/). The service trusts the
IdP in real time, through a pre-arranged trust relationship: exchanged SAML metadata or a
registered OIDC client. See [federation](https://startwithidentity.com/glossary/federation/).

**Decentralized identity** removes the runtime middleman. An [issuer](https://startwithidentity.com/glossary/issuer-holder-verifier/)
signs a [verifiable credential](https://startwithidentity.com/standards/verifiable-credentials/) and gives it to you. You hold it
in a [wallet](https://startwithidentity.com/glossary/digital-wallet/) and present it to a verifier as a
[verifiable presentation](https://startwithidentity.com/glossary/verifiable-presentation/). The verifier resolves the issuer's
[DID](https://startwithidentity.com/standards/decentralized-identifiers-did/) to get its public key, checks the signature and
status, and decides whether it trusts that issuer, all without calling the issuer. See
[decentralized identity explained](https://startwithidentity.com/guides/decentralized-identity/decentralized-identity-explained/).

In Christopher Allen's 2016 framing of identity's evolution,
[The Path to Self-Sovereign Identity](https://www.lifewithalacrity.com/article/the-path-to-self-soverereign-identity/),
federation is the second of four stages; self-sovereign identity is the fourth. See
[what is self-sovereign identity](https://startwithidentity.com/guides/fundamentals/what-is-self-sovereign-identity/).

## Side by side

| Dimension | Federated (SAML, OIDC) | Decentralized (DIDs, VCs) |
|---|---|---|
| Trust check | Live assertion from the IdP | Issuer signature plus trust policy |
| Issuer online at use time | Yes, at every login | No, only for issuance and status lists |
| Who sees each use | The IdP sees every sign-in | Only the verifier |
| Data shared | Whatever claims the IdP releases | Holder chooses; [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/) possible |
| Revocation | Disable account or end session | Publish credential status; verifier checks |
| Portability | Tied to the IdP's namespace | Credential moves with the holder |
| Key management burden | On the IdP operator | Partly on the holder's wallet |
| Trust setup | Bilateral metadata or client registration | Trust registry or ecosystem governance |
| Maturity | Decades of deployment, universal SaaS support | Core standards final in 2022 to 2025, wallets rolling out |

## What the mechanics look like

**A federated login (OIDC):** the app redirects you to the IdP; you authenticate; the IdP redirects
back with an authorization code; the app exchanges it for an [ID token](https://startwithidentity.com/glossary/id-token/) and
validates it. The IdP is involved every time, which is why it can enforce MFA, device checks, and
[conditional access](https://startwithidentity.com/glossary/conditional-access/) centrally, and also why it learns about every
sign-in.

**A credential presentation (OpenID4VP):** the verifier sends a request describing the claims it
needs; your wallet asks for consent; the wallet returns a presentation, often an
[SD-JWT](https://startwithidentity.com/glossary/sd-jwt/) VC or ISO mdoc with only the requested claims disclosed; the verifier
checks the issuer signature, holder binding, and status. [OpenID for Verifiable Presentations 1.0](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html)
became final on 9 July 2025 and includes a query language (DCQL) and support for the browser
Digital Credentials API.

## Where each wins

**Federated identity wins** for workforce single sign-on, app-to-app authentication, and anywhere a
mature, universally supported protocol and central control are what you want. When an employee
leaves, you disable one account and access stops everywhere, which is exactly what security teams
need. It is not going away. See the [SSO implementation guide](https://startwithidentity.com/guides/authentication/complete-guide-implementing-sso/).

**Decentralized identity wins** for reusable [identity verification and KYC](https://startwithidentity.com/guides/decentralized-identity/reusable-identity-and-kyc-with-verifiable-credentials/),
portable credentials such as certifications and diplomas that should outlast any provider,
privacy-sensitive proofs (age, eligibility, residency), and government or cross-border identity
such as the [EUDI Wallet](https://startwithidentity.com/standards/eidas-2-eudi-wallet/) and [mDL](https://startwithidentity.com/standards/iso-18013-5-mdl/).
The European Commission says member states must provide
[EU Digital Identity Wallets by the end of 2026](https://digital-strategy.ec.europa.eu/en/policies/eudi-regulation),
which is turning the model into public infrastructure across the EU.

## Decision guide

| Use case | Choose | Why |
|---|---|---|
| Employees signing in to SaaS apps | Federated | Central policy and instant deprovisioning |
| Customers logging in to your app | Federated (OIDC), passkeys | Session-based, you own the account |
| Verifying a new customer's identity once, reusing it later | Decentralized | Avoids repeat KYC, holder carries proof |
| Proving age or eligibility without full identity | Decentralized | Selective disclosure, issuer not told |
| Onboarding contractors from partner companies | Either; credential is gaining | Partner issues an employment credential instead of a guest account |
| Machine-to-machine API access | Neither; use OAuth client credentials or [workload identity](https://startwithidentity.com/glossary/workload-identity/) | Different problem |

## Failure modes to plan for

- **Federated:** the IdP is a single point of failure for login and a high-value target. An IdP
  outage locks everyone out; a compromised signing key lets attackers forge assertions. See
  [federation trust abuse and SAML forgery](https://startwithidentity.com/techniques/federation-trust-abuse-saml-forgery/) and the
  [IAM disaster recovery guide](https://startwithidentity.com/guides/implementation/iam-disaster-recovery-guide/).
- **Decentralized:** responsibility shifts to the holder's device. Lost phones, wallet recovery,
  and issuer key compromise (every credential signed with that key becomes suspect) are the hard
  problems. Revocation must be designed explicitly, typically with the W3C
  [Bitstring Status List](https://www.w3.org/TR/vc-bitstring-status-list/), a Recommendation since
  15 May 2025, which requires at least 131,072 entries so a status check does not single out one
  credential.

## The future is hybrid

These models are not a contest with one winner. The realistic architecture for most organizations
is both: keep [federated SSO](https://startwithidentity.com/standards/openid-connect/) for sign-in, add verifiable credentials for
reusable and portable proofs, and bridge them with an [identity fabric](https://startwithidentity.com/guides/fundamentals/what-is-identity-fabric/).
The standards make this practical because they share a foundation.
[OpenID for Verifiable Credential Issuance 1.0](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html),
final on 16 September 2025, is built on OAuth 2.0 and offers an authorization code flow, where the
user signs in to the issuer, typically through the existing IdP, before a credential is issued. See
[OpenID4VC](https://startwithidentity.com/standards/openid4vc/), [OpenID4VCI](https://startwithidentity.com/glossary/openid4vci/), and
[OpenID4VP](https://startwithidentity.com/glossary/openid4vp/).

A common first project is to issue a verified employee credential from the IdP you already run,
for example with [Microsoft Entra Verified ID](https://startwithidentity.com/vendors/decentralized-identity/microsoft-entra-verified-id/),
which uses `did:web`, and use it for help desk identity checks or partner access. That gives you
decentralized identity experience without touching workforce SSO.

## Where to go next

Overview: [decentralized identity explained](https://startwithidentity.com/guides/decentralized-identity/decentralized-identity-explained/).
Identifiers: [DID methods compared](https://startwithidentity.com/guides/decentralized-identity/did-methods-compared/).
Build: [verifiable credentials implementation guide](https://startwithidentity.com/guides/decentralized-identity/verifiable-credentials-implementation-guide/).
Choose: [choosing a decentralized identity platform](https://startwithidentity.com/guides/decentralized-identity/choosing-a-decentralized-identity-platform/)
and the [best verifiable credential platforms](https://startwithidentity.com/rankings/best-verifiable-credential-platforms/).
Standards: [Verifiable Credentials](https://startwithidentity.com/standards/verifiable-credentials/), [DID](https://startwithidentity.com/standards/decentralized-identifiers-did/).

## DevSecOps Identity Integration Guide: Securing CI/CD Pipelines and Developer Workflows
Source: https://startwithidentity.com/guides/implementation/devsecops-identity-integration-guide/
Last updated: 2026-11-05

CI/CD pipelines are among the most privileged identities in any organization. They deploy code to production, access secrets, modify infrastructure, and interact with dozens of systems, often with broad permissions that would alarm any security team if a human held them. Yet pipelines are frequently the least governed identities in the enterprise.

The DevSecOps movement recognizes that security must be integrated into the development lifecycle, not bolted on at the end. Identity is a cornerstone of that integration: who (or what) is running this pipeline, what permissions does it have, how are credentials managed, and is there an audit trail?

This guide covers practical approaches to integrating identity security into CI/CD pipelines and developer workflows.

## Prerequisites

- **CI/CD platform**, GitHub Actions, GitLab CI, Jenkins, Azure DevOps, CircleCI, or similar.
- **Cloud provider accounts**, AWS, Azure, GCP, or other infrastructure targets for deployments.
- **Secrets management solution**, [HashiCorp Vault](https://startwithidentity.com/vendors/machine-identity/hashicorp-vault/), [AWS Secrets Manager](https://startwithidentity.com/vendors/secrets/aws-secrets-manager/), [Azure Key Vault](https://startwithidentity.com/vendors/secrets/azure-key-vault/), or similar.
- **Familiarity with pipeline configuration**, YAML workflows, pipeline stages, and environment variables.
- **A security team willing to partner with engineering**, DevSecOps requires collaboration, not gatekeeping.

## Architecture: Pipeline Identity Model

### The Identity Chain in CI/CD

Every CI/CD pipeline execution involves multiple identity layers:

```
Developer (triggers pipeline)
    ↓ (authenticated via IdP + MFA)
Source Code Platform (GitHub, GitLab)
    ↓ (repository permissions, branch protection)
CI/CD Runtime (Actions runner, GitLab runner, Jenkins agent)
    ↓ (runner identity, OIDC token)
Cloud Provider (AWS, Azure, GCP)
    ↓ (assumed role, managed identity)
Target Environment (production, staging)
    ↓ (deployment permissions)
Applications and Services
```

Each transition in this chain is an identity boundary. The security of your deployment depends on the weakest link.

### The Shift from Static Credentials to OIDC Federation

The traditional approach to pipeline authentication involves storing long-lived credentials (AWS access keys, Azure service principal secrets, GCP service account keys) as CI/CD secrets. This approach has significant problems:

- Credentials do not expire (or have long expiration periods).
- Credentials are shared across many pipelines.
- Rotation is manual and often neglected.
- A leaked credential grants access until someone notices and rotates it.
- There is no way to tie a specific pipeline run to a specific credential use.

OIDC federation eliminates static credentials entirely. The CI/CD platform issues a short-lived, signed token for each pipeline run. The cloud provider trusts that token and grants temporary credentials scoped to the specific pipeline.

```
GitHub Actions Run → OIDC Token (audience: AWS, subject: repo:org/app:ref:refs/heads/main)
    ↓
AWS STS → AssumeRoleWithWebIdentity (verify OIDC token, check trust policy)
    ↓
Temporary AWS credentials (1 hour by default, 15 minutes minimum, scoped to one role)
```

## Step-by-Step Implementation

### Step 1: Implement OIDC Federation for CI/CD

**GitHub Actions to AWS:**

Create an IAM OIDC provider in AWS:

```bash
aws iam create-open-id-connect-provider \
  --url https://token.actions.githubusercontent.com \
  --client-id-list sts.amazonaws.com
```

Do not hardcode a `--thumbprint-list`. The parameter is optional: if you omit it, IAM retrieves the thumbprint itself, and for providers whose certificates chain to a CA in AWS's trusted root library, such as GitHub's `token.actions.githubusercontent.com`, AWS verifies the JWKS endpoint's TLS certificate against those roots and only falls back to thumbprints if that fails ([AWS IAM docs](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html)). A pinned thumbprint copied from a blog post is at best ignored and at worst breaks federation after a certificate change. [GitHub's AWS OIDC guide](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services) only asks for the provider URL and the `sts.amazonaws.com` audience.

Create an IAM role with a trust policy that restricts which repositories and branches can assume it:

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:my-org/my-app:ref:refs/heads/main"
        }
      }
    }
  ]
}
```

Use it in a GitHub Actions workflow:

```yaml
name: Deploy to AWS
on:
  push:
    branches: [main]

permissions:
  id-token: write   # Required for OIDC
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4

    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v4
      with:
        role-to-assume: arn:aws:iam::123456789012:role/github-deploy-role
        aws-region: us-east-1

    - name: Deploy
      run: aws ecs update-service --cluster prod --service my-app --force-new-deployment
```

Credentials from `AssumeRoleWithWebIdentity` last one hour by default. You can request anywhere from 900 seconds (15 minutes) up to the role's maximum session duration, which is configurable from 1 to 12 hours ([AWS STS API reference](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)). Ask for the shortest duration that covers the deploy job.

**GitHub Actions to Azure:**

```yaml
- name: Azure Login
  uses: azure/login@v2
  with:
    client-id: ${{ secrets.AZURE_CLIENT_ID }}
    tenant-id: ${{ secrets.AZURE_TENANT_ID }}
    subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    # No client-secret needed - uses OIDC
```

**GitHub Actions to GCP:**

```yaml
- name: Authenticate to GCP
  uses: google-github-actions/auth@v2
  with:
    workload_identity_provider: projects/123456/locations/global/workloadIdentityPools/github/providers/my-org
    service_account: deploy@my-project.iam.gserviceaccount.com
```

### Step 2: Scope Pipeline Permissions Tightly

Each pipeline should have only the permissions it needs for its specific job.

**Principle: One role per pipeline purpose**

Do not share a single broad role across all pipelines. Create purpose-specific roles:

```yaml
# Roles for different pipeline stages
deploy-role:
  permissions:
    - ecs:UpdateService
    - ecs:DescribeServices
    - ecs:DescribeTaskDefinition
    - ecs:RegisterTaskDefinition
    - ecr:GetAuthorizationToken
    - ecr:BatchGetImage
  trust: repo:my-org/my-app:ref:refs/heads/main

terraform-plan-role:
  permissions:
    - Read-only access to all resources
    - No write permissions
  trust: repo:my-org/infrastructure:*  # any branch can plan

terraform-apply-role:
  permissions:
    - Full infrastructure management
  trust: repo:my-org/infrastructure:ref:refs/heads/main  # only main can apply
```

**Restrict by branch and environment:**

```json
{
  "Condition": {
    "StringEquals": {
      "token.actions.githubusercontent.com:sub": "repo:my-org/my-app:environment:production"
    }
  }
}
```

This ensures only deployments to the "production" GitHub environment (which requires approvals) can assume the production deployment role.

### Step 3: Secure Secrets in Pipelines

Even with OIDC for cloud access, pipelines still need other secrets: API keys for third-party services, database credentials, signing keys.

**Secret management hierarchy:**

1. **OIDC federation**, For cloud provider access. No secrets stored.
2. **Dynamic secrets**, For database credentials and API keys. Use Vault or equivalent to generate short-lived credentials per pipeline run.
3. **Platform-managed secrets**, For secrets that cannot be made dynamic. Use the CI/CD platform's encrypted secrets storage with appropriate access controls.
4. **Never: hardcoded secrets**, Never commit secrets to source code, even in encrypted form.

**HashiCorp Vault integration example:**

```yaml
jobs:
  deploy:
    steps:
    - name: Import Vault Secrets
      uses: hashicorp/vault-action@v3
      with:
        url: https://vault.mycompany.com
        method: jwt
        role: github-deploy
        jwtGithubAudience: vault.mycompany.com
        secrets: |
          secret/data/production/database username | DB_USERNAME ;
          secret/data/production/database password | DB_PASSWORD ;
          secret/data/production/api-keys stripe | STRIPE_KEY
```

Vault verifies the GitHub OIDC token and issues secrets only to authorized repositories and branches.

**Preventing secret leakage:**

- Enable secret masking in CI/CD logs (most platforms do this automatically for registered secrets).
- Use step-level permissions to limit which steps can access which secrets.
- Never echo or print environment variables in pipeline logs.
- Scan pipeline logs for accidental secret exposure using tools like trufflehog or gitleaks.

### Step 4: Govern Service Accounts and Pipeline Identities

Pipelines are identities too, and they need governance.

**Service account inventory:**

Maintain a registry of every service account, bot account, and pipeline identity:

| Identity | Purpose | Owner | Permissions | Last Reviewed | Credential Type |
|---|---|---|---|---|---|
| github-deploy-prod | Production deployment | Platform Team | ECS deploy, ECR pull | 2026-03-01 | OIDC (no stored creds) |
| terraform-ci | Infrastructure management | SRE Team | Full infrastructure | 2026-02-15 | OIDC |
| sonarqube-bot | Code quality scanning | Security Team | Repo read-only | 2026-03-10 | PAT (90-day rotation) |

**Lifecycle management for pipeline identities:**

- **Creation**, Requires a ticket with business justification, defined permissions, and an assigned owner.
- **Review**, Quarterly access review by the owning team. Verify permissions are still appropriate and not over-provisioned.
- **Rotation**, For identities that still use static credentials, enforce rotation schedules (90 days maximum is a common practitioner estimate, not a standard).
- **Decommission**, When a pipeline or project is retired, decommission the associated identities. Do not let orphaned pipeline accounts persist.

### Step 5: Implement Pipeline Security Controls

**Branch protection as identity control:**

Branch protection rules are access control for your code supply chain:

```yaml
# GitHub branch protection for main
protection_rules:
  required_reviews: 2
  require_codeowner_review: true
  dismiss_stale_reviews: true
  require_signed_commits: true
  enforce_admins: true
  required_status_checks:
    - security-scan
    - unit-tests
    - integration-tests
```

**Environment-based deployment gates:**

GitHub Environments provide approval gates for deployments:

```yaml
jobs:
  deploy-production:
    environment:
      name: production
      url: https://app.mycompany.com
    # This job will wait for manual approval from designated reviewers
    # before executing
```

Configure production environments to require approval from senior engineers or SREs.

**Deployment approval via identity:**

Integrate deployment approvals with your IdP:
- Only users in the "production-deployers" IdP group can approve production deployments.
- Require MFA step-up for deployment approvals.
- Log all approval decisions with the approver's identity and timestamp.

### Step 6: Audit and Monitor Pipeline Activity

**What to log:**
- Every pipeline execution: who triggered it, what branch, what commit
- Every credential assumption: which OIDC token, which role, what permissions
- Every secret access: which secrets were retrieved, by which pipeline
- Every deployment: what was deployed, to which environment, by whom
- Every failed authentication or authorization: potential attack indicators

**Monitoring alerts:**
- Pipeline assuming a role outside its normal pattern
- Failed OIDC token validation (potential replay or forgery attempt)
- Pipeline accessing secrets it has never accessed before
- Deployment to production from an unexpected branch or repository
- Service account credential used outside of pipeline context (potential credential theft)

## Best Practices

### Treat Pipelines as Privileged Identities

Your CI/CD pipeline that deploys to production has the same blast radius as a production admin. Treat it accordingly: review its permissions quarterly, monitor its activity, and ensure it follows least privilege.

### Eliminate Static Credentials Everywhere Possible

Every static credential is a liability. Prioritize eliminating them:
1. Cloud provider access: OIDC federation (no stored credentials)
2. Database access: Dynamic credentials via Vault
3. API access: Short-lived tokens via OAuth client credentials
4. Container registry access: Cloud-native authentication (ECR, ACR, Artifact Registry use cloud IAM)

### Separate Build and Deploy Permissions

The identity that builds your code should not be the same identity that deploys it. This separation of duties prevents a compromised build step from deploying malicious code:

```yaml
jobs:
  build:
    permissions:
      contents: read
      packages: write
    # Can read code and push container images, but cannot deploy

  deploy:
    needs: build
    environment: production
    permissions:
      id-token: write
    # Can deploy but cannot modify code or build artifacts
```

### Rotate What You Cannot Federate

For secrets that cannot be replaced by OIDC federation, enforce aggressive rotation:
- API keys: 90-day maximum lifetime
- Database passwords: 30-day rotation via Vault
- Signing keys: Annual rotation with overlap period
- Personal access tokens: 30-day maximum, scoped to specific permissions

## Testing

1. **OIDC trust policy testing**, Verify that only intended repositories and branches can assume each cloud role. Test that other repositories are denied.
2. **Permission boundary testing**, Deploy with each pipeline role and verify it can perform its intended actions and is denied for everything else.
3. **Secret access testing**, Verify that secrets are only accessible to authorized pipelines and steps.
4. **Break-glass testing**, Simulate a pipeline failure and verify that manual deployment procedures work (using human credentials with appropriate MFA).
5. **Audit trail testing**, Execute a deployment and verify the complete audit trail is captured in your SIEM.

## Common Pitfalls

### Overly Permissive OIDC Trust Policies

A trust policy that allows `repo:my-org/*` lets any repository in your organization assume the role. If someone creates a new repository with a malicious workflow, it inherits trust. Restrict trust policies to specific repositories and branches.

### Shared Pipeline Credentials

Using one set of credentials for all pipelines is the anti-pattern that OIDC federation eliminates. Each pipeline should have its own identity with its own permissions. Shared credentials make it impossible to audit which pipeline performed which action.

### Not Scanning Pipeline Definitions for Security Issues

Pipeline YAML files can contain security misconfigurations: overly broad permissions, missing approval gates, unmasked secret references. Include pipeline definitions in your security scanning scope.

### Ignoring Self-Hosted Runners

Self-hosted CI/CD runners are compute resources with access to your pipeline secrets and cloud credentials. They must be hardened, patched, and monitored like any other privileged infrastructure. Ephemeral runners (destroyed after each job) are strongly preferred over persistent runners.

## Conclusion

DevSecOps identity integration is about treating CI/CD pipelines as first-class identities deserving the same governance, least privilege, and monitoring that you apply to human users. OIDC federation eliminates the most dangerous pattern, static credentials stored in CI/CD platforms, and replaces it with short-lived, scoped, auditable tokens. Combined with secrets management, pipeline permission scoping, and deployment approval gates, this creates a secure software delivery pipeline that does not slow developers down.

The path forward is clear: federate everything you can, dynamically generate what you cannot federate, govern all pipeline identities like privileged accounts, and audit every action in the delivery chain.

## DID Methods Compared: did:web, did:key, did:ion and More
Source: https://startwithidentity.com/guides/decentralized-identity/did-methods-compared/
Last updated: 2026-11-05

The `method` in a [decentralized identifier](https://startwithidentity.com/standards/decentralized-identifiers-did/) decides how it
is created, resolved, rotated, and retired, and that choice has operational consequences for years.
The short answer: **use `did:web` for organizational issuers, `did:webvh` if you need a verifiable key
history, `did:key` or `did:jwk` for ephemeral and holder-side identifiers, and ledger methods only
when an ecosystem requires them.** This guide shows why. For the standard, see the
[DID standard deep dive](https://startwithidentity.com/standards/decentralized-identifiers-did/) and the [DID method](https://startwithidentity.com/glossary/did-method/)
glossary entry.

## What a method has to define

[DID Core 1.0](https://www.w3.org/TR/did-core/) became a W3C Recommendation on 19 July 2022, and
[DID Core 1.1](https://www.w3.org/TR/did-1.1/) reached Candidate Recommendation Snapshot on
5 March 2026. Both leave the mechanics to method specifications, which must define four operations:
**create, resolve, update, and deactivate**. Resolution itself is specified separately in W3C DID
Resolution, and methods are listed in the W3C DID Extensions registry. When you compare methods,
compare those four operations, plus two things the core spec does not force: whether you get a
**history** of past keys, and who can **censor or tamper** with resolution.

## The comparison

| Method | Anchored in | Create | Rotate keys | Deactivate | Verifiable history | Spec maturity |
|---|---|---|---|---|---|---|
| `did:web` | Your domain over HTTPS | Host a file | Edit the file | Remove the file | No | W3C CCG proposal |
| `did:webvh` | Your domain, plus a hash-chained log | Host a log | Append signed entry | Append entry | Yes | DIF v1.0 |
| `did:key` | The identifier itself | Generate a key | Not possible | Not possible | Not applicable | v0.9 draft |
| `did:jwk` | The identifier itself | Encode a JWK | Not possible | Not possible | Not applicable | Community spec |
| `did:ion` | Bitcoin via Sidetree | Anchored operation | Yes | Yes | Yes | DIF Sidetree-based |
| `did:ethr` | Ethereum registry (ERC-1056) | Free, any address | On-chain transaction | On-chain transaction | Yes, via events | DIF community spec |
| `did:indy` | Hyperledger Indy ledger | Permissioned write | Ledger write | Ledger write | Yes | Hyperledger spec |
| `did:plc` | Bluesky-operated directory | Signed genesis op | Signed op | Tombstone op | Yes, public log | Bluesky spec |

## Ledgerless methods

**did:web** anchors a DID to a domain. Per the [did:web specification](https://w3c-ccg.github.io/did-method-web/),
`did:web:example.com` resolves to `https://example.com/.well-known/did.json`, colons after the domain
become path segments (`did:web:example.com:issuers:hr` resolves to
`https://example.com/issuers/hr/did.json`), and a port is percent-encoded (`example.com%3A3000`). It
reuses the TLS and DNS trust you already operate, which is why it is the most common enterprise
choice. The specification is candid about the costs: it defines no mechanism to control who can
write the [DID document](https://startwithidentity.com/glossary/did-document/), so it is only as secure as your web hosting; DNS
spoofing is a risk without DNSSEC; your web server can see every resolution, which is a privacy
leak for verifiers; and there is no history, so a verifier cannot check which key was valid when an
old credential was signed. The spec suggests keeping the document in version control as a
workaround.

**did:webvh** ("did:web plus verifiable history") fixes that last gap. The
[DIF did:webvh v1.0 specification](https://identity.foundation/didwebvh/v1.0/) publishes a
`did.jsonl` log at the same location, where every entry carries a version, timestamp, parameters,
the document state, and a proof, each chained to its predecessor by hash. A self-certifying
identifier (SCID) derived from the first entry is embedded in the DID, so a resolver can detect a
rewritten history. Optional pre-rotation publishes hashes of the next keys, and optional witnesses
must co-sign updates. It is the strongest option for an issuer that wants web hosting without
losing auditability.

**did:key** encodes a public key directly into the identifier. The
[did:key v0.9 specification](https://w3c-ccg.github.io/did-key-spec/) combines a multicodec key-type
prefix with the raw key bytes and multibase-encodes them, which is why Ed25519 keys start with
`did:key:z6Mk` and P-256 keys with `did:key:zDna`. Resolution needs no network at all. The
specification states that a did:key cannot be updated or deactivated, recommends against long-term
use unless the key is protected in a hardware security module, and treats rotation as issuing a new
identifier. Ideal for holders, test environments, and short-lived sessions.

**did:jwk** does the same with a [JSON Web Key](https://startwithidentity.com/glossary/jwks/): the identifier is `did:jwk:` plus the
base64url-encoded JWK, the single verification method is always `#0`, and the
[specification](https://github.com/quartzjer/did-jwk/blob/main/spec.md) does not support update. It
is convenient in JOSE and [SD-JWT](https://startwithidentity.com/glossary/sd-jwt/) stacks where keys are already JWKs.

## Ledger and registry methods

**did:ion** anchors batched operations to Bitcoin using the Sidetree protocol, giving
decentralization without a per-operation chain fee. Microsoft, once its best-known enterprise backer, moved away: the [Microsoft Entra Verified ID FAQ](https://learn.microsoft.com/en-us/entra/verified-id/verifiable-credentials-faq)
says did:ion was supported only in preview until December 2023, and that moving to did:web "requires
reissuance of all credentials." That is the general lesson: changing method later means reissuing.
See [Microsoft Entra Verified ID](https://startwithidentity.com/vendors/decentralized-identity/microsoft-entra-verified-id/).

**did:ethr** uses the ERC-1056 registry contract. Per its
[method specification](https://github.com/decentralized-identity/ethr-did-resolver/blob/master/doc/did-method-spec.md),
any Ethereum address or secp256k1 public key is already a valid DID with no transaction fee for
creation, but changing the owner, adding delegates, or setting attributes requires an on-chain
transaction that costs gas (meta-transactions let a third party pay). It supports Ethereum mainnet,
Sepolia, Polygon, Gnosis Chain, and other EVM chains. It fits Web3-adjacent ecosystems.

**did:indy** is the method for Hyperledger Indy networks, where writes go through a permissioned
ledger with governance-defined roles. It is usually paired with [AnonCreds](https://startwithidentity.com/glossary/anoncreds/)
and the [Hyperledger Indy and Aries](https://startwithidentity.com/vendors/decentralized-identity/hyperledger-indy-aries/) stack.
Choose it when you join an Indy-based network; it ties you to that network's governance.

**did:plc** is the method behind Bluesky and the AT Protocol. The
[did:plc specification](https://web.plc.directory/spec/v0.1/did-plc) describes a directory at
plc.directory run by Bluesky Social PBC, controlled by an ordered list of one to five rotation keys,
with a public, timestamped log of every operation and a 72-hour window in which a higher-priority
key can override recent changes, which gives account recovery. The spec says Bluesky would like to
move governance out of its sole control, but that has not happened yet. It shows a practical
middle path: a central operator that cannot forge operations, because every operation is signed.

## How to choose

Work from constraints, not novelty:

1. **Are you an organization issuing credentials?** Start with `did:web`. Move to `did:webvh` if
   auditors or verifiers need to know which key was valid at a past date.
2. **Is the identifier ephemeral or holder-side?** `did:key` or `did:jwk`.
3. **Are you joining an existing ecosystem** (an EU wallet program, an Indy network, a Web3
   project, AT Protocol)? Use what the ecosystem specifies; interoperability beats preference.
4. **Do you need resolution that survives losing your domain?** Only then consider a ledger method,
   and price in the operational cost.
5. **As a verifier,** support every method your issuers use, gated by what your resolver handles,
   and keep a policy per method (for example, `did:web` only from domains on your
   [trust registry](https://startwithidentity.com/glossary/trust-registry/)).

## Common pitfalls

- **Letting the domain lapse.** A `did:web` issuer whose domain expires can be impersonated by
  whoever registers it next. Treat the domain like a root key.
- **Using `did:key` for a long-lived issuer.** You cannot rotate it, so a key compromise means
  every credential must be reissued under a new DID.
- **Assuming the method gives revocation.** It does not. Credential revocation is a separate layer,
  typically the W3C [Bitstring Status List](https://www.w3.org/TR/vc-bitstring-status-list/), a
  Recommendation since 15 May 2025. See [revocation registry](https://startwithidentity.com/glossary/revocation-registry/).
- **Forgetting resolution privacy.** Every `did:web` resolution is a request to the issuer's server.
  Verifiers at scale should cache documents or use their own resolver.

## Where to go next

Build: [verifiable credentials implementation guide](https://startwithidentity.com/guides/decentralized-identity/verifiable-credentials-implementation-guide/).
Overview: [decentralized identity explained](https://startwithidentity.com/guides/decentralized-identity/decentralized-identity-explained/)
and [decentralized vs federated identity](https://startwithidentity.com/guides/decentralized-identity/decentralized-identity-vs-federated-identity/).
Vendors: [decentralized identity directory](https://startwithidentity.com/vendors/decentralized-identity/) and
[choosing a decentralized identity platform](https://startwithidentity.com/guides/decentralized-identity/choosing-a-decentralized-identity-platform/).

## From RBAC to ReBAC: when and how to migrate
Source: https://startwithidentity.com/guides/authorization/rbac-to-rebac/
Last updated: 2026-11-05

Migrate from RBAC to ReBAC when access depends on *which object* a user is related to, not just *what role* they hold. If you are creating roles like `editor_for_project_xyz`, modeling "share this folder with Bob," or encoding org and team trees in role names, you have outgrown [RBAC](https://startwithidentity.com/glossary/rbac/). [Relationship-based access control](https://startwithidentity.com/glossary/rebac/) stores those relationships as data and computes permissions by walking them. The migration is low risk if you run both systems side by side and cut over one call site at a time.

This guide is for engineers who own authorization in a multi-tenant SaaS product or internal platform. For the concepts first, see [RBAC vs ABAC vs ReBAC](https://startwithidentity.com/guides/fundamentals/rbac-vs-abac-vs-rebac/).

## Recognize the signs

- **Role explosion:** more roles than active users, or roles that encode a resource ID.
- **Per-object sharing:** "share this with Bob but not Alice" cannot be expressed without a new role.
- **Inheritance:** nested folders, projects inside workspaces, organization and team hierarchies.
- **Tenant-defined access:** each customer wants its own groups and sharing rules.
- **Listing is slow:** "show me every document I can see" means loading everything and filtering in application code.

## Choose the model: RBAC, ABAC or ReBAC

| Question you need to answer | Best fit | Why |
|---|---|---|
| "Can admins manage billing?" | RBAC | Coarse function, few roles, rarely changes |
| "Can this user edit doc 42 because they own its parent folder?" | ReBAC | Permission flows through relationships |
| "Allow only from a managed device during business hours" | [ABAC](https://startwithidentity.com/glossary/abac/) | Depends on request attributes, not stored relationships |
| "Who can see this record?" (reverse lookup) | ReBAC | Graph engines answer list queries natively |
| "Owner can delete if the record is not under legal hold" | ReBAC plus conditions, or a policy engine | Relationship plus an attribute check |

Most real systems end up hybrid. The choice is which concern is the hard part: the graph (pick a Zanzibar-style engine) or the attribute logic (pick a policy engine).

## Where ReBAC comes from

The dominant design is Google's Zanzibar, described in the [USENIX ATC 2019 paper](https://www.usenix.org/conference/atc19/presentation/pang). Zanzibar stores access control lists as relation tuples and, per the paper, serves "trillions of access control lists and millions of authorization requests per second" for hundreds of Google services, with 95th-percentile latency under 10 milliseconds and availability above 99.999% over three years. You will not need that scale, but the data model and the consistency approach (the paper's "zookies") are what the open engines copy. The broader category is often called [fine-grained authorization](https://startwithidentity.com/glossary/fga/).

## The engines

| Engine | Model | Where relationship data lives | Notes |
|---|---|---|---|
| [OpenFGA](https://startwithidentity.com/vendors/authorization/openfga/) | Zanzibar-style | In the engine (tuples) | [CNCF incubating project](https://openfga.dev/); managed option via [Auth0](https://startwithidentity.com/vendors/ciam/auth0/) FGA |
| [SpiceDB](https://startwithidentity.com/vendors/authorization/authzed/) (AuthZed) | Zanzibar-style | In the engine | Explicit per-request consistency with ZedTokens |
| [Cerbos](https://startwithidentity.com/vendors/authorization/cerbos/) | Policy engine (PDP) | Your systems, passed per request | [Stateless and AuthZEN-compliant](https://docs.cerbos.dev/cerbos/latest/) |
| [Oso](https://startwithidentity.com/vendors/authorization/oso/) | Polar policy language | Mixed | Evaluate as a peer option |
| [Permit.io](https://startwithidentity.com/vendors/authorization/permit-io/) | RBAC, ABAC and ReBAC in one control plane | Managed | Useful when non-engineers edit policy |
| Permify | Zanzibar-style, open source | In the engine | Simpler to operate |

Cerbos shows the other path: its [derived roles](https://docs.cerbos.dev/cerbos/latest/policies/derived_roles) are "computed at request evaluation time from the principal's base roles and request attributes," for example an `owner` role when `request.resource.attr.owner == request.principal.id`. That handles ownership without a separate relationship store, but deep inheritance chains are awkward because you must pass the chain in.

Whichever engine you pick, put a thin interface between your application and the decision call. The [AuthZEN Authorization API 1.0](https://startwithidentity.com/standards/authzen/) ([spec](https://openid.net/specs/authorization-api-1_0.html)), the OpenID Foundation's standard API between enforcement and decision points, is the obvious shape for it and keeps a later engine swap from touching every call site.

## A worked model

An OpenFGA schema 1.1 model for folders and documents, using the union (`or`), inheritance (`from`) and exclusion (`but not`) operators described in the [configuration language docs](https://openfga.dev/docs/configuration-language):

```
model
  schema 1.1
type user
type folder
  relations
    define owner: [user]
    define editor: [user] or owner
    define viewer: [user] or editor
type document
  relations
    define parent: [folder]
    define owner: [user]
    define editor: [user] or owner
    define blocked: [user]
    define viewer: ([user] or editor or viewer from parent) but not blocked
```

Data is written as tuples of user, relation and object, as in the [OpenFGA modeling guide](https://openfga.dev/docs/modeling/getting-started): `{ user: "user:anne", relation: "owner", object: "document:42" }`, `{ user: "folder:legal", relation: "parent", object: "document:42" }`, or a group grant such as `{ user: "organization:A#member", relation: "editor", object: "document:1" }`. Your old role `editor_for_project_xyz` becomes one tuple per member instead of one role per project.

## The migration, step by step

1. **Inventory call sites.** List every place that checks a role. Each becomes a `check(user, relation, object)` call. This list is your cutover plan.
2. **Model first.** Write the schema and unit-test it against the engine's test tooling before touching production code. Design deny rules (`but not blocked`) now; they are hard to add later.
3. **Backfill.** Translate existing role assignments into tuples. Map each role to the smallest relation that reproduces it, and log any role you cannot map; those are your design gaps.
4. **Dual-write.** Every grant, revoke, share and membership change writes to RBAC and to the engine. Use an outbox or change-data-capture so a failed engine write is retried, not dropped.
5. **Shadow reads.** Keep RBAC authoritative, call the engine in parallel, and log every divergence with the user, object and both answers. Divergence is either a model bug or a backfill bug; fix and re-run.
6. **Cut over per call site.** Flip one endpoint at a time behind a flag, starting with read paths. Rollback is flipping the flag back.
7. **Decommission RBAC.** Only after shadow reads have agreed long enough to cover rare paths (month-end jobs, admin consoles, exports). Keep coarse admin roles as relations in the model.

## Consistency and caching

A permission check against stale data is how a removed user still sees a document. SpiceDB's docs call this the New Enemy Problem, and the engines handle it differently:

- **SpiceDB** lets each request choose `minimize_latency`, `at_least_as_fresh` (with a ZedToken), `at_exact_snapshot` or `fully_consistent`. Per the [consistency docs](https://authzed.com/docs/spicedb/concepts/consistency), writes default to fully consistent and other APIs default to `minimize_latency`; store the ZedToken returned by a write alongside the resource and pass it on later checks.
- **OpenFGA** offers `MINIMIZE_LATENCY` (default) and `HIGHER_CONSISTENCY`, which skips the cache. Per the [docs](https://openfga.dev/docs/interacting/consistency), caching is disabled by default, so checks are strongly consistent until you turn it on.

Rule of thumb: revocations and sharing changes on sensitive objects use the stronger mode; bulk list views use the faster one.

## Common failure modes

| Failure | What it looks like | Prevention |
|---|---|---|
| Missed call site | One endpoint still uses the old check, or none at all | Inventory first; fail closed when no check runs. The [Optus API exposure](https://startwithidentity.com/breaches/incidents/2022-optus-unauthenticated-api/) shows the cost of one endpoint without working access control |
| Carried-over over-privilege | Backfill copies every stale role into tuples | Run an access review before backfill; see [mover entitlement accumulation](https://startwithidentity.com/techniques/mover-entitlement-accumulation/) |
| Stale decisions | Revoked user retains access through the cache | Consistency tokens or the high-consistency mode on revocation paths |
| ReBAC as a library | Relationships duplicated in app tables and the engine drift apart | Treat the engine as the system of record for relationships |
| Latency surprise | Every request now makes a network hop | Batch checks, co-locate the engine, budget latency per endpoint |
| No deny rules | Cannot express "everyone in the org except contractors" | Model exclusion from day one |

## Related

Guides: [implementing RBAC in the enterprise](https://startwithidentity.com/guides/authorization/implementing-rbac-enterprise/), [implementing ABAC](https://startwithidentity.com/guides/authorization/implementing-abac-guide/). Glossary: [ReBAC](https://startwithidentity.com/glossary/rebac/), [fine-grained authorization](https://startwithidentity.com/glossary/fga/), [AuthZEN](https://startwithidentity.com/glossary/authzen/), [least privilege](https://startwithidentity.com/glossary/least-privilege/). Vendors: [authorization](https://startwithidentity.com/vendors/authorization/).

## GDPR for identity systems: what the regulation actually requires
Source: https://startwithidentity.com/guides/compliance/gdpr-for-identity-systems/
Last updated: 2026-11-05

GDPR makes your identity system the place where privacy obligations either work or fail. The identity store holds the canonical user record, so it is where data subject requests land, where consent is captured, where biometric and profile data sit, and where an account takeover becomes a reportable breach. This guide maps the articles of [Regulation (EU) 2016/679](https://eur-lex.europa.eu/eli/reg/2016/679/oj) that bind identity teams to the controls you build, with the deadlines in the text. It is written for IAM owners working with their DPO, not as legal advice. See [GDPR](https://startwithidentity.com/glossary/gdpr/) for the short definition.

## The articles that bind identity teams

| Article | What it requires | What it means for identity |
|---|---|---|
| Art. 5 | Six principles (lawfulness, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality) plus accountability: you must be able to demonstrate compliance | Collect only the profile fields a flow needs; delete dormant accounts on a schedule; keep evidence, not just policy |
| Art. 6 | Processing is lawful only on one of six bases: consent, contract, legal obligation, vital interests, public task, legitimate interests | Record the basis per attribute or purpose. Login data is usually contract; marketing is usually consent |
| Art. 7(3) | Withdrawal of consent must be as easy as giving it | One-click opt-out in the profile page, propagated to every downstream tool |
| Art. 9 | Biometric data for uniquely identifying a person is a special category; processing is prohibited unless an Art. 9(2) exception applies | Server-side face or fingerprint matching needs explicit consent and a DPIA |
| Art. 12(3) | Answer rights requests within one month, extendable by two further months with notice | Build export and deletion pipelines before the first request |
| Art. 25 | Data protection by design and by default; by default only data necessary for each purpose is processed | Minimal registration forms, [progressive profiling](https://startwithidentity.com/glossary/progressive-profiling/), private-by-default profiles |
| Art. 32 | Security appropriate to the risk, including pseudonymisation, encryption, resilience, restore, and regular testing | MFA, credential stuffing defences, encrypted attributes, tested restores |
| Art. 33 | Notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach | Detection and triage for account takeover and admin compromise |
| Art. 35 | DPIA before processing likely to result in high risk, including large-scale special category data | Required for biometric identity verification and most large risk-scoring programs |

## Lawful basis and consent

Article 6 lists the six bases. Track them in data, not in a wiki: a consent record should hold the purpose, the wording shown, a timestamp, and the channel. The definition of consent in Article 4(11) requires "a clear affirmative action", and Recital 32 states that "silence, pre-ticked boxes or inactivity" do not constitute consent. Marketing, analytics sharing, and partner data sharing are separate purposes and need separate toggles. See [consent management](https://startwithidentity.com/glossary/consent-management/).

Do not use consent where another basis fits. Authenticating a user to deliver the service is processing necessary for the contract; consent to log in creates a withdrawal right you cannot honor.

## Data subject rights the identity layer must serve

Articles 15 to 22 cover access, rectification, erasure, restriction, portability, and objection. Under Article 12(3) you have one month from receipt to act.

1. **Access (Art. 15).** A self-service export of the profile, linked identities, consent history, and sign-in history.
2. **Rectification (Art. 16).** Profile edits must reach derived systems, not just the identity store.
3. **Erasure (Art. 17).** Deletion is required on the listed grounds, including withdrawn consent with no other basis and data no longer needed. Article 17(3) keeps exceptions, such as a legal obligation or defending legal claims, so document which records survive and why.
4. **Portability (Art. 20).** Data the user provided, "in a structured, commonly used and machine-readable format". JSON is the common answer.
5. **Objection (Art. 21).** For direct marketing the right to object is absolute, and it includes profiling related to that marketing.

**Verify the requester without collecting more data.** Recital 64 says controllers should use all reasonable measures to verify identity. The EDPB's [Guidelines 01/2022 on the right of access](https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-012022-data-subject-rights-right-access_en) (version 2.1) state that login credentials are normally sufficient and that requiring an ID copy from an already authenticated user is disproportionate. Route requests through the signed-in session, add [step-up authentication](https://startwithidentity.com/glossary/step-up-auth/) for erasure, and never let a support agent export data on the strength of a phone call. Help desk impersonation is a proven path ([help desk social engineering](https://startwithidentity.com/techniques/help-desk-social-engineering/)).

## Biometrics and identity verification

Article 9(1) covers "biometric data for the purpose of uniquely identifying a natural person". If you run face matching for [identity verification](https://startwithidentity.com/glossary/idv/) or server-side biometric login, you need an Article 9(2) exception (usually explicit consent), a DPIA under Article 35(3)(b) when it is large scale, and a retention limit.

Design matters as much as consent. In [Opinion 11/2024](https://www.edpb.europa.eu/news/news/2024/facial-recognition-airports-individuals-should-have-maximum-control-over-biometric_en) on facial recognition at airports, the EDPB found that only storage where the biometric data, or its encryption key, stays in the individual's hands could be compatible with the integrity and confidentiality principle, and that centralised storage without the user holding the key cannot meet data protection by design and by default. The identity-system reading: prefer [passkeys](https://startwithidentity.com/glossary/passkey/), where the biometric check stays on the user's device and you only receive a signature.

## Security, breaches, and records

Article 32 does not name MFA, but it requires security appropriate to the risk and "a process for regularly testing, assessing and evaluating" the measures. For identity that means [MFA](https://startwithidentity.com/glossary/mfa/), defences against [credential stuffing](https://startwithidentity.com/techniques/credential-stuffing/), rate limiting on recovery flows, encrypted sensitive attributes, and admin access through [PAM](https://startwithidentity.com/vendors/pam/).

Article 33 requires notifying the supervisory authority within 72 hours of becoming aware of a breach unless it is unlikely to result in risk, and Article 33(5) requires documenting every breach, notified or not. Article 30 is a different duty: it requires a record of processing activities (purposes, categories of data and recipients, retention limits, a description of security measures), not a log of who accessed data. You still need access logs, but for Article 32 and breach investigation.

## Implementation checklist

1. Map every identity attribute to a purpose, lawful basis, and retention period; feed that into the Article 30 record.
2. Remove pre-ticked boxes; split consent by purpose; store consent receipts; make withdrawal one click.
3. Build self-service export (JSON) and deletion, with propagation to analytics, CRM, warehouse, and support tools.
4. Authenticate rights requests through the existing session; add step-up for erasure and export.
5. Write a backup answer: deleted users stay out of restores, or restores replay a deletion queue.
6. Run a DPIA before biometric verification, server-side biometric login, or large-scale risk scoring.
7. Enforce MFA for admins and offer passkeys to users; monitor for stuffing and takeover.
8. Pin tenant data to a region if customers require it; document Chapter V transfer mechanisms for providers outside the EEA. Track other privacy regimes on the [regulations calendar](https://startwithidentity.com/regulations/calendar/).
9. Rehearse the 72-hour breach clock with an account takeover scenario.

## Common failure modes

- **Password reuse at scale.** In the [23andMe incident](https://startwithidentity.com/breaches/incidents/2023-23andme-credential-stuffing-dna-relatives/), about 14,000 accounts accessed with reused passwords exposed profile data on about 6.9 million other users through a sharing feature. Breach-volume math depends on what one account can see.
- **Support access as the leak.** At [Coinbase](https://startwithidentity.com/breaches/incidents/2025-coinbase-paid-support-insiders/), paid support staff pulled customer data from internal tools. Scope agent access to the ticket, not the whole user base.
- **"Delete" that means "mark inactive".** Soft-delete flags fail Article 17 unless the data is erased or anonymised beyond re-identification.
- **Deletions that stop at the IdP.** Warehouses and BI copies keep the data alive.
- **Consent by silence.** Pre-ticked marketing boxes fail Article 4(11) and Recital 32.

## Vendor requirements

Ask any [CIAM](https://startwithidentity.com/guides/fundamentals/what-is-ciam/) provider for: a user export API, deletion with webhook propagation, consent capture with audit trail, regional data residency, admin access logs, and a data processing agreement. Compare options in [how to choose a CIAM platform](https://startwithidentity.com/guides/buyer-guides/how-to-choose-a-ciam-platform/) and the [identity audit preparation guide](https://startwithidentity.com/guides/compliance/iam-audit-preparation-guide/).

Fines reflect the split: Article 83(5) sets up to EUR 20 million or 4% of worldwide annual turnover for breaches of the principles, lawful basis, consent, and special category rules; Article 83(4) sets up to EUR 10 million or 2% for obligations including Articles 25 to 39.

## Greenfield CIAM: how to ship the first version in 8 weeks
Source: https://startwithidentity.com/guides/implementation/ciam-greenfield/
Last updated: 2026-11-05

Greenfield CIAM means building customer identity and access management for a new product with no existing users to migrate. The verdict for almost every team: buy a managed CIAM platform, ship a scoped first version in about eight weeks (a planning estimate), and defer enterprise features until a customer asks. This guide is the week-by-week plan, the 2026 baselines it must meet, and the line on what to defer.

## Build, buy, or open source: decide first

[Customer identity](https://startwithidentity.com/guides/fundamentals/what-is-ciam/) looks like a login form, but the work that matters is invisible: password hashing that survives a database leak, [credential stuffing](https://startwithidentity.com/techniques/credential-stuffing/) defense, MFA, account recovery that is not itself phishable, session management, audit logging, and privacy-compliant deletion.

| Option | Right when | Wrong when | Examples |
| --- | --- | --- | --- |
| Managed CIAM | You want to ship in weeks and identity is not your product | Data residency or per-MAU pricing rules it out at your scale | [Auth0](https://startwithidentity.com/vendors/ciam/auth0/), [Clerk](https://startwithidentity.com/vendors/ciam/clerk/), [Stytch](https://startwithidentity.com/vendors/ciam/stytch/), [Descope](https://startwithidentity.com/vendors/ciam/descope/), [Amazon Cognito](https://startwithidentity.com/vendors/ciam/amazon-cognito/), [Microsoft Entra External ID](https://startwithidentity.com/vendors/ciam/microsoft-entra-external-id/) |
| Self-hosted or open source | You need full control or self-hosting and have someone to patch and operate it | Nobody owns upgrades and on-call | [Keycloak](https://startwithidentity.com/vendors/open-source/keycloak/), [FusionAuth](https://startwithidentity.com/vendors/ciam/fusionauth/), [Better Auth](https://startwithidentity.com/vendors/open-source/better-auth/) |
| Build | Identity is the product you sell | Anything else | Your own team, forever |

Check ownership before you sign: Auth0 is part of Okta, Stytch was acquired by Twilio (closed 2025-11-14), and Better Auth was acquired by Vercel (2026-07-07) while the library stays free and MIT licensed. For picking a platform, use the [how to evaluate CIAM](https://startwithidentity.com/guides/buyer-guides/how-to-evaluate-ciam/) buyer guide, the [best CIAM for startups](https://startwithidentity.com/rankings/best-ciam-for-startups/) ranking, [CIAM pricing models explained](https://startwithidentity.com/articles/ciam-pricing-models-explained/), and the [identity pricing transparency index](https://startwithidentity.com/reports/identity-pricing-transparency-index-2026/). For a wider capability view, [Deepak Gupta's CIAM Compass](https://guptadeepak.com/ciam-compass/) maps 40-plus platforms against a capability matrix.

## What "first version" means

Signup, sign-in, password reset, email verification, social login, basic profile, session management, MFA enrollment, and account deletion. Anything beyond that is phase 2. Scope discipline is what makes the eight weeks realistic.

## The 2026 baselines your first version must meet

- **Passwords ([NIST SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html), final July 2025).** At least 15 characters when a password is the only factor, at least 8 when used within MFA. Check new passwords against a blocklist of common and compromised passwords. No composition rules and no forced periodic changes, but force a change on evidence of compromise. Limit consecutive failed attempts to no more than 100.
- **Hashing ([OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html)).** Argon2id with at least 19 MiB memory, 2 iterations, parallelism 1. scrypt if Argon2id is unavailable. bcrypt for legacy only, with a work factor of at least 10 and a 72-byte input limit. PBKDF2-HMAC-SHA256 at 600,000 iterations if you need FIPS-140. A managed platform should document which it uses.
- **Phishing resistance.** NIST requires at least one phishing-resistant option at AAL2. [Passkeys](https://startwithidentity.com/glossary/passkey/) on [WebAuthn](https://startwithidentity.com/standards/webauthn-fido2/) (Level 3 a [W3C Recommendation](https://www.w3.org/TR/webauthn-3/) since 25 August 2026) are the practical way to offer it to consumers.
- **Sessions ([OWASP Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)).** HttpOnly and Secure cookies with SameSite Strict or Lax; never tokens in localStorage or sessionStorage.

## Week-by-week

**Weeks 1-2: foundation.** Pick the vendor. Spin up a free tier. Wire signup and sign-in with the SDK, using [OpenID Connect](https://startwithidentity.com/standards/openid-connect/) with authorization code and PKCE rather than a custom token flow. Decide the session strategy early, because it is hard to change later. Configure separate tenants for staging and production so redirect URLs and keys never cross.

**Weeks 3-4: trust and reach.** Email verification, so fake accounts do not pollute your data. Password reset with expiring single-use links. [Social login](https://startwithidentity.com/glossary/social-login/), typically Google and Apple. On iOS, App Store [Guideline 4.8](https://developer.apple.com/app-store/review/guidelines/) requires that an app using a third-party login for the primary account also offers an equivalent privacy-preserving login (name and email only, private email option, no ad tracking without consent); Sign in with Apple is the usual way to meet it. Send transactional email from a domain you control with SPF, DKIM, and DMARC set.

**Weeks 5-6: profile and step-up.** Profile screens and password change. MFA enrollment with [TOTP](https://startwithidentity.com/glossary/totp/) and passkeys where your platform supports them. Make MFA available to all users and required for any account that touches money or sensitive data, and add [step-up authentication](https://startwithidentity.com/glossary/step-up-auth/) for changes to email, phone, or payout details.

**Weeks 7-8: production hardening.** Structured audit logging for every identity event. Account deletion and data export flows for GDPR and CCPA (see [GDPR for identity systems](https://startwithidentity.com/guides/compliance/gdpr-for-identity-systems/)). Rate limiting, bot detection, and breached-password checks on login, reset, and verification endpoints. A load test against expected launch traffic. A runbook for the two incidents you will eventually have: account takeover reports and a locked-out founder.

## How greenfield CIAM fails in production

- **Reused passwords, no MFA.** At [23andMe](https://startwithidentity.com/breaches/incidents/2023-23andme-credential-stuffing-dna-relatives/), about 14,000 accounts accessed with reused passwords exposed data on about 6.9 million other users through an opt-in sharing feature. [Roku](https://startwithidentity.com/breaches/incidents/2024-roku-credential-stuffing/) saw about 576,000 accounts hit in a second wave and then turned on two-factor authentication for all accounts. [Chick-fil-A](https://startwithidentity.com/breaches/incidents/2026-chick-fil-a-credential-stuffing/) was hit again in June 2026. Lesson: breached-password checks, bot defense, and MFA offered at launch, not after the incident. See [account takeover prevention](https://startwithidentity.com/articles/ciam-account-takeover-prevention/).
- **Weak recovery.** The [Coinbase SMS recovery flaw](https://startwithidentity.com/breaches/incidents/2021-coinbase-sms-recovery-flaw/) let attackers with stolen passwords obtain the SMS codes needed to take over accounts. Recovery must not be easier than sign-in; watch for [OTP relay social engineering](https://startwithidentity.com/techniques/otp-relay-social-engineering/).
- **Unauthenticated endpoints.** [Authy phone numbers](https://startwithidentity.com/breaches/incidents/2024-twilio-authy-unauthenticated-endpoint/) were enumerated through an unauthenticated endpoint, and an [Optus API](https://startwithidentity.com/breaches/incidents/2022-optus-unauthenticated-api/) returned customer data without valid authorization. Every identity API needs authorization and rate limits, including lookup and "does this account exist" endpoints.
- **Stolen sessions.** Infostealers lift cookies, so bind sessions to devices where supported and re-authenticate on sensitive actions; see [session cookie theft](https://startwithidentity.com/techniques/session-cookie-theft/).

## What to defer

- Federation with enterprise identity providers (only when the first enterprise prospect asks), using OIDC or [SAML](https://startwithidentity.com/standards/saml-2-0/)
- [SCIM provisioning](https://startwithidentity.com/standards/scim-2-0/) (only when a first enterprise deal requires directory sync); see [B2B vs B2C CIAM](https://startwithidentity.com/articles/b2b-vs-b2c-ciam/)
- Custom flows and journey orchestration (default flows handle most cases)
- Migration tooling (you have no users yet; when you do, see [CIAM migration](https://startwithidentity.com/articles/ciam-migration-guide/))
- Fine-grained authorization (role-based access is enough until it is not)

## Common pitfalls

- Building auth in-house "because it is just a login form," then owning its security forever
- Storing passwords with anything other than Argon2id, scrypt, bcrypt, or PBKDF2 at current parameters
- Putting session tokens in localStorage where a single cross-site scripting bug drains every session
- Skipping email verification "for conversion" and accepting a wave of fake accounts
- Hardcoding redirect URLs so staging cannot work, then loosening them so open redirects can
- Treating account recovery as an afterthought, when it is the most-attacked path in the whole system

Ship the eight-week version, watch real usage, and let phase 2 be driven by what your users and first enterprise buyers need.

## How Kerberos Works, Message by Message
Source: https://startwithidentity.com/guides/protocols/kerberos-message-flow/
Last updated: 2026-11-05

A Kerberos login is three request and reply pairs between a client, the Key Distribution Center (KDC) and a service: the **AS exchange** gets a ticket-granting ticket (TGT), the **TGS exchange** turns it into a service ticket, and the **AP exchange** presents that ticket to the service. Every message is ASN.1 defined in [RFC 4120 §5](https://www.rfc-editor.org/rfc/rfc4120#section-5). This page decodes each one with fake values, ties the fields to their sections, and lists what each party must check. For what Kerberos is and where it fits, see the [Kerberos standard page](https://startwithidentity.com/standards/kerberos/).

All examples use the realm `EXAMPLE.COM`, user `ada@EXAMPLE.COM` and service `HTTP/app.example.com@EXAMPLE.COM`. Encrypted parts are shown as their decrypted structure, which only the party holding the key can see.

## The sequence at a glance

| # | From → to | Message (`msg-type`) | Spec |
| --- | --- | --- | --- |
| 1 | Client → KDC (88) | `AS-REQ` (10) without pre-authentication | [§3.1.1](https://www.rfc-editor.org/rfc/rfc4120#section-3.1.1), [§5.4.1](https://www.rfc-editor.org/rfc/rfc4120#section-5.4.1) |
| 2 | KDC → client | `KRB-ERROR` (30), code 25 `KDC_ERR_PREAUTH_REQUIRED`, with `PA-ETYPE-INFO2` | [§5.9.1](https://www.rfc-editor.org/rfc/rfc4120#section-5.9.1), [§5.2.7.5](https://www.rfc-editor.org/rfc/rfc4120#section-5.2.7.5) |
| 3 | Client → KDC | `AS-REQ` (10) with `PA-ENC-TIMESTAMP` | [§5.2.7.2](https://www.rfc-editor.org/rfc/rfc4120#section-5.2.7.2) |
| 4 | KDC → client | `AS-REP` (11): TGT plus encrypted session key | [§3.1.3](https://www.rfc-editor.org/rfc/rfc4120#section-3.1.3), [§5.4.2](https://www.rfc-editor.org/rfc/rfc4120#section-5.4.2) |
| 5 | Client → KDC | `TGS-REQ` (12) with `PA-TGS-REQ` carrying an AP-REQ | [§3.3.1](https://www.rfc-editor.org/rfc/rfc4120#section-3.3.1), [§5.2.7.1](https://www.rfc-editor.org/rfc/rfc4120#section-5.2.7.1) |
| 6 | KDC → client | `TGS-REP` (13): service ticket | [§3.3.3](https://www.rfc-editor.org/rfc/rfc4120#section-3.3.3) |
| 7 | Client → service | `AP-REQ` (14), inside SMB, LDAP SASL or HTTP `Negotiate` | [§3.2.2](https://www.rfc-editor.org/rfc/rfc4120#section-3.2.2), [§5.5.1](https://www.rfc-editor.org/rfc/rfc4120#section-5.5.1) |
| 8 | Service → client | `AP-REP` (15), if mutual authentication was requested | [§3.2.4](https://www.rfc-editor.org/rfc/rfc4120#section-3.2.4), [§5.5.2](https://www.rfc-editor.org/rfc/rfc4120#section-5.5.2) |

## Messages 1 to 3: AS-REQ and pre-authentication

```
AS-REQ ::= [APPLICATION 10] {
  pvno      5,
  msg-type  10,
  padata    [ PA-ENC-TIMESTAMP (2): EncryptedData {
                etype 18, cipher <PA-ENC-TS-ENC { patimestamp 20261105140211Z,
                                                  pausec 412 } encrypted with ada's key> },
              PA-PAC-REQUEST (128): include-pac TRUE ],
  req-body {
    kdc-options  forwardable, renewable, canonicalize,
    cname        { name-type NT-PRINCIPAL (1), name-string ["ada"] },
    realm        "EXAMPLE.COM",
    sname        { name-type NT-SRV-INST (2), name-string ["krbtgt", "EXAMPLE.COM"] },
    till         20261106000211Z,
    rtime        20261112140211Z,
    nonce        1953746982,
    etype        [ 18, 17, 20, 19 ] } }
```

The first attempt (message 1) is the same without `padata`. A KDC that requires pre-authentication answers with `KRB-ERROR` code 25 and a `PA-ETYPE-INFO2` hint listing the encryption type and salt to use, and the client retries. The default salt is the realm followed by the name components with no separator, here `EXAMPLE.COMada` (RFC 4120 [§4](https://www.rfc-editor.org/rfc/rfc4120#section-4)).

| Field | Meaning | Spec |
| --- | --- | --- |
| `pvno`, `msg-type` | Always 5; 10 for AS-REQ, 12 for TGS-REQ. | [§5.4.1](https://www.rfc-editor.org/rfc/rfc4120#section-5.4.1) |
| `padata` `PA-ENC-TIMESTAMP` (type 2) | Current time encrypted in the client's long-term key: proof the client knows the password before the KDC returns anything crackable. | [§5.2.7.2](https://www.rfc-editor.org/rfc/rfc4120#section-5.2.7.2) |
| `PA-PAC-REQUEST` (type 128) | Microsoft extension asking for a PAC in the ticket. | [MS-KILE](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/2a32282e-dd48-4ad9-a542-609804b02cc9), registered in RFC 4120 §7.5.2 |
| `kdc-options` | Flags requested for the ticket: `forwardable` (1), `renewable` (8), and `canonicalize` (15, reserved in RFC 4120 and defined in [RFC 6806](https://www.rfc-editor.org/rfc/rfc6806)). | [§5.4.1](https://www.rfc-editor.org/rfc/rfc4120#section-5.4.1), [§2](https://www.rfc-editor.org/rfc/rfc4120#section-2) |
| `cname`, `realm` | Client principal and realm. `cname` appears only in AS-REQ. | [§5.4.1](https://www.rfc-editor.org/rfc/rfc4120#section-5.4.1), [§5.2.2](https://www.rfc-editor.org/rfc/rfc4120#section-5.2.2) |
| `sname` | `krbtgt/EXAMPLE.COM`, the ticket-granting service. | [§7.3](https://www.rfc-editor.org/rfc/rfc4120#section-7.3) |
| `till`, `rtime` | Requested end time and renewable-until time; the KDC may shorten them. | [§5.4.1](https://www.rfc-editor.org/rfc/rfc4120#section-5.4.1) |
| `nonce` | Random number the KDC must echo inside the encrypted reply. | [§5.4.1](https://www.rfc-editor.org/rfc/rfc4120#section-5.4.1), [§3.1.5](https://www.rfc-editor.org/rfc/rfc4120#section-3.1.5) |
| `etype` | Encryption types in preference order: 18 aes256-cts-hmac-sha1-96, 17 aes128 ([RFC 3962](https://www.rfc-editor.org/rfc/rfc3962)), 20 and 19 the SHA-2 variants ([RFC 8009](https://www.rfc-editor.org/rfc/rfc8009)). Seeing 23 (RC4-HMAC) here is a finding. | §5.4.1, [RFC 8429 §7](https://www.rfc-editor.org/rfc/rfc8429#section-7) |

## Message 4: AS-REP

```
AS-REP ::= [APPLICATION 11] {
  pvno 5, msg-type 11,
  crealm "EXAMPLE.COM",
  cname  { NT-PRINCIPAL, ["ada"] },
  ticket {                                   -- the TGT, opaque to the client
    tkt-vno 5, realm "EXAMPLE.COM", sname krbtgt/EXAMPLE.COM,
    enc-part { etype 18, kvno 2, cipher <EncTicketPart encrypted with the krbtgt key> } },
  enc-part { etype 18, kvno 7, cipher <EncASRepPart encrypted with ada's key> } }

EncASRepPart (decrypted by the client) {
  key        { keytype 18, keyvalue <TGT session key> },
  last-req   [...],
  nonce      1953746982,
  flags      forwardable, renewable, initial, pre-authent,
  authtime   20261105140211Z,
  endtime    20261106000211Z,
  renew-till 20261112140211Z,
  srealm     "EXAMPLE.COM",
  sname      krbtgt/EXAMPLE.COM }
```

| Field | Meaning | Spec |
| --- | --- | --- |
| `ticket` | The TGT. Its `enc-part` is encrypted with the `krbtgt` key, so the client cannot read or alter it. | [§5.3](https://www.rfc-editor.org/rfc/rfc4120#section-5.3) |
| `enc-part` | Encrypted with the client's key; contains the session key the client will use with the TGS. | [§5.4.2](https://www.rfc-editor.org/rfc/rfc4120#section-5.4.2) |
| `nonce` | Must equal the request nonce, proving the reply is fresh. | [§3.1.5](https://www.rfc-editor.org/rfc/rfc4120#section-3.1.5) |
| `flags` | `initial` (from the AS exchange) and `pre-authent` (the client was pre-authenticated). | [§5.3](https://www.rfc-editor.org/rfc/rfc4120#section-5.3), [§2](https://www.rfc-editor.org/rfc/rfc4120#section-2) |
| `kvno` | Key version number, so a service can pick the right key after a password change. | [§5.2.9](https://www.rfc-editor.org/rfc/rfc4120#section-5.2.9) |

## Messages 5 and 6: TGS-REQ and TGS-REP

```
TGS-REQ ::= [APPLICATION 12] {
  pvno 5, msg-type 12,
  padata [ PA-TGS-REQ (1): AP-REQ { ticket <the TGT>,
             authenticator <Authenticator encrypted with the TGT session key> } ],
  req-body {
    kdc-options forwardable, canonicalize,
    realm  "EXAMPLE.COM",
    sname  { NT-SRV-INST, ["HTTP", "app.example.com"] },
    till   20261106000211Z,
    nonce  287364510,
    etype  [ 18, 17 ] } }
```

The TGS-REP has the same shape as the AS-REP, but its `ticket` is the **service ticket**, encrypted with the key of `HTTP/app.example.com`, and its `enc-part` is encrypted with the TGT session key rather than the user's password key ([§3.3.3](https://www.rfc-editor.org/rfc/rfc4120#section-3.3.3)). In Active Directory the service key is derived from the password of whichever account holds that SPN. That single fact is [Kerberoasting](https://startwithidentity.com/techniques/kerberoasting/): any authenticated user can request this ticket and attack the service account's password offline.

## Messages 7 and 8: AP-REQ and AP-REP

```
AP-REQ ::= [APPLICATION 14] {
  pvno 5, msg-type 14,
  ap-options mutual-required,
  ticket { tkt-vno 5, realm "EXAMPLE.COM", sname HTTP/app.example.com,
           enc-part { etype 18, kvno 4, cipher <EncTicketPart> } },
  authenticator { etype 18, cipher <Authenticator encrypted with the service session key> } }

EncTicketPart (decrypted by the service with its own key) {
  flags forwardable, pre-authent,
  key   { keytype 18, keyvalue <service session key> },
  crealm "EXAMPLE.COM", cname { NT-PRINCIPAL, ["ada"] },
  transited { tr-type 1, contents "" },
  authtime 20261105140211Z, starttime 20261105140230Z, endtime 20261106000211Z,
  authorization-data [ AD-IF-RELEVANT [ AD-WIN2K-PAC (128): <PAC> ] ] }

Authenticator (decrypted with the session key) {
  authenticator-vno 5,
  crealm "EXAMPLE.COM", cname { NT-PRINCIPAL, ["ada"] },
  cksum  <checksum binding the application request, if any>,
  cusec  418211, ctime 20261105140230Z,
  subkey { keytype 18, keyvalue <optional subkey> },
  seq-number 1093845021 }
```

Over HTTP this AP-REQ travels inside a SPNEGO token: `Authorization: Negotiate YIIH...` ([RFC 4559 §4](https://www.rfc-editor.org/rfc/rfc4559#section-4)). With `mutual-required`, the service replies with an AP-REP whose encrypted part repeats `ctime` and `cusec`, proving it could decrypt the ticket ([§5.5.2](https://www.rfc-editor.org/rfc/rfc4120#section-5.5.2)).

| Field | Meaning | Spec |
| --- | --- | --- |
| `ap-options` | `use-session-key` (1) for user-to-user, `mutual-required` (2). | [§5.5.1](https://www.rfc-editor.org/rfc/rfc4120#section-5.5.1) |
| `EncTicketPart.key` | The session key the KDC generated for this client and service. | [§5.3](https://www.rfc-editor.org/rfc/rfc4120#section-5.3) |
| `authtime`, `starttime`, `endtime` | When the user authenticated and the ticket's validity window. | [§5.3](https://www.rfc-editor.org/rfc/rfc4120#section-5.3) |
| `authorization-data` | Wrapped in `AD-IF-RELEVANT`; in AD carries the PAC (type 128). | [§5.2.6](https://www.rfc-editor.org/rfc/rfc4120#section-5.2.6), [MS-PAC](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/166d8064-c863-41e1-9c23-edaaa5f36962) |
| `Authenticator.ctime`, `cusec` | Client time, the basis of replay protection. | [§5.5.1](https://www.rfc-editor.org/rfc/rfc4120#section-5.5.1) |
| `Authenticator.cksum` | Binds the authenticator to application data, for example GSS-API channel bindings. | §5.5.1, [RFC 4121 §4.1.1](https://www.rfc-editor.org/rfc/rfc4121#section-4.1.1) |

## The checks each party must run

**Client, on AS-REP** ([§3.1.5](https://www.rfc-editor.org/rfc/rfc4120#section-3.1.5))

1. `cname` and `crealm` in the reply match the request; the decrypted `nonce` equals the one sent; `sname` and `srealm` are the expected TGS.
2. A host that uses a password login to grant **local** access must not trust the AS-REP alone. RFC 4120 §3.1.5 says decrypting it "is not sufficient for the host to verify the identity of the user"; the host must also get and verify a ticket for its own service key, or a spoofed KDC can log anyone in.

**KDC**

3. Require pre-authentication for every account ([§5.2.7.2](https://www.rfc-editor.org/rfc/rfc4120#section-5.2.7.2)). Without it, anyone can request an AS-REP for that user and crack the encrypted part offline.
4. Issue only strong encryption types and never RC4 or DES for new keys ([RFC 8429 §7](https://www.rfc-editor.org/rfc/rfc8429#section-7), [RFC 6649](https://www.rfc-editor.org/rfc/rfc6649)).

**Service, on AP-REQ** ([§3.2.3](https://www.rfc-editor.org/rfc/rfc4120#section-3.2.3))

5. Decrypt the ticket with its own key at the `kvno` indicated (`KRB_AP_ERR_BADKEYVER`, `KRB_AP_ERR_BAD_INTEGRITY` on failure), then decrypt the authenticator with the ticket's session key.
6. `cname` and `crealm` in the authenticator match the ticket (`KRB_AP_ERR_BADMATCH`), and client addresses match if present.
7. Client time within the allowable clock skew (`KRB_AP_ERR_SKEW`, RFC 4120 uses 5 minutes as its example), and the authenticator is not in the replay cache (`KRB_AP_ERR_REPEAT`); ticket not yet valid or expired gives `KRB_AP_ERR_TKT_NYV` or `KRB_AP_ERR_TKT_EXPIRED`.
8. **Authorize separately.** Passing these checks "provides only authentication of the named principal" (§3.2.3). In Active Directory, validate the PAC signatures as [MS-PAC](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/166d8064-c863-41e1-9c23-edaaa5f36962) describes before trusting group SIDs.

## Common implementation mistakes, with the CVEs and techniques behind them

| Mistake | What goes wrong | Real examples |
| --- | --- | --- |
| PAC signatures or requester SID not validated | A forged or borrowed PAC grants privileges | [CVE-2024-26248](https://startwithidentity.com/cves/cve-2024-26248/), [CVE-2024-29056](https://startwithidentity.com/cves/cve-2024-29056/), [CVE-2026-27912](https://startwithidentity.com/cves/cve-2026-27912/) |
| A step skipped in a protocol extension | Identity forged through S4U or certificate logon | [CVE-2025-60704](https://startwithidentity.com/cves/cve-2025-60704/) (S4U), [CVE-2025-26647](https://startwithidentity.com/cves/cve-2025-26647/) (PKINIT), [CVE-2022-26923](https://startwithidentity.com/cves/cve-2022-26923/) |
| Client trusts a KDC reply it cannot authenticate | KDC impersonation by a machine in the middle | [CVE-2024-20674](https://startwithidentity.com/cves/cve-2024-20674/) |
| Tickets reflected back to the issuing host | Elevation of privilege over SMB | [CVE-2025-33073](https://startwithidentity.com/cves/cve-2025-33073/), [CVE-2025-58726](https://startwithidentity.com/cves/cve-2025-58726/) |
| RC4 still issued for service tickets | Service account passwords cracked offline | [CVE-2026-20833](https://startwithidentity.com/cves/cve-2026-20833/), [Kerberoasting](https://startwithidentity.com/techniques/kerberoasting/) |
| SPN uniqueness checked on look-alike strings | Service name hijack and NTLM downgrade | [CVE-2026-25177](https://startwithidentity.com/cves/cve-2026-25177/) |
| Over-broad delegation | A service impersonates any user to any service | [Kerberos delegation abuse](https://startwithidentity.com/techniques/kerberos-delegation-abuse/) |
| Certificate templates trusted for logon | PKINIT logons as other users | [AD CS certificate template abuse](https://startwithidentity.com/techniques/adcs-certificate-template-abuse/), [CVE-2024-49019](https://startwithidentity.com/cves/cve-2024-49019/) |

## Try it locally

There is no browser tool for Kerberos, which runs over raw TCP and UDP to the KDC. On a test realm, MIT Kerberos's [kinit](https://web.mit.edu/kerberos/krb5-latest/doc/user/user_commands/kinit.html) runs the AS exchange and [klist](https://web.mit.edu/kerberos/krb5-latest/doc/user/user_commands/klist.html) shows the result: `klist -e -f` prints each ticket's encryption type and flags, so you can confirm no ticket uses etype 23 and that the `pre-authent` flag is set. A packet capture on port 88 shows messages 1 to 6 in clear structure, with the encrypted parts opaque.

## Related

[Kerberos standard page](https://startwithidentity.com/standards/kerberos/), [how LDAP works, message by message](https://startwithidentity.com/guides/protocols/ldap-message-flow/), [how RADIUS works, message by message](https://startwithidentity.com/guides/protocols/radius-message-flow/). Glossary: [Kerberos](https://startwithidentity.com/glossary/kerberos/), [NTLM](https://startwithidentity.com/glossary/ntlm/), [Active Directory](https://startwithidentity.com/glossary/active-directory/).

## How LDAP Works, Message by Message
Source: https://startwithidentity.com/guides/protocols/ldap-message-flow/
Last updated: 2026-11-05

An application that "logs users in with LDAP" runs a short, fixed conversation with the directory: upgrade the connection to TLS, bind as a service account, search for the user's entry, bind again as that entry with the password the user typed, and read the result code. Every step is an `LDAPMessage` from [RFC 4511](https://www.rfc-editor.org/rfc/rfc4511). This page walks through each one with fake values, ties every field to its RFC section, and lists the checks the application must run. For what LDAP is and where it fits, see the [LDAP standard page](https://startwithidentity.com/standards/ldap/).

## The sequence at a glance

| # | Client → server | Server → client | Spec |
| --- | --- | --- | --- |
| 1 | `ExtendedRequest` StartTLS (OID `1.3.6.1.4.1.1466.20037`) | `ExtendedResponse` success, then TLS handshake | [RFC 4511 §4.14](https://www.rfc-editor.org/rfc/rfc4511#section-4.14), [RFC 4513 §3](https://www.rfc-editor.org/rfc/rfc4513#section-3) |
| 2 | `BindRequest` as service account | `BindResponse` resultCode 0 | [§4.2](https://www.rfc-editor.org/rfc/rfc4511#section-4.2) |
| 3 | `SearchRequest` for the username | `SearchResultEntry`, `SearchResultDone` | [§4.5](https://www.rfc-editor.org/rfc/rfc4511#section-4.5) |
| 4 | `BindRequest` as the user's DN | `BindResponse` 0 or 49 | [§4.2](https://www.rfc-editor.org/rfc/rfc4511#section-4.2), [RFC 4513 §5.1.3](https://www.rfc-editor.org/rfc/rfc4513#section-5.1.3) |
| 5 | `SearchRequest` for group membership | entries | [§4.5](https://www.rfc-editor.org/rfc/rfc4511#section-4.5) |
| 6 | `UnbindRequest` | (connection closed) | [§4.3](https://www.rfc-editor.org/rfc/rfc4511#section-4.3) |

Many applications use LDAPS on port 636 instead of step 1; the messages after the TLS handshake are identical.

## The envelope every message shares

```
LDAPMessage ::= SEQUENCE {
     messageID       MessageID,          -- INTEGER, chosen by the client
     protocolOp      CHOICE { bindRequest, bindResponse, searchRequest, ... },
     controls        [0] Controls OPTIONAL }
```

`messageID` is unique per outstanding request and is how responses are matched to requests on a pipelined connection ([§4.1.1–4.1.1.1](https://www.rfc-editor.org/rfc/rfc4511#section-4.1.1)). Everything is BER-encoded ASN.1 ([§5.1](https://www.rfc-editor.org/rfc/rfc4511#section-5.1)); the examples below are decoded into readable form.

## Step 1: StartTLS

```
messageID 1
extendedReq { requestName "1.3.6.1.4.1.1466.20037" }      -- no requestValue

messageID 1
extendedResp { resultCode success (0), matchedDN "", diagnosticMessage "",
               responseName "1.3.6.1.4.1.1466.20037" }
```

After a success response the client starts the TLS handshake on the same connection. It must then check the server's identity against the certificate as RFC 4513 [§3.1.3](https://www.rfc-editor.org/rfc/rfc4513#section-3.1.3) describes, and RFC 4511 §6 advises clients to reject referrals returned by the StartTLS operation. A client that falls back to cleartext when StartTLS fails has no protection against an attacker who simply blocks it.

## Step 2: bind as the service account

```
messageID 2
bindRequest {
  version        3,
  name           "cn=svc-portal,ou=service,dc=example,dc=com",
  authentication simple "not-a-real-password-example" }

messageID 2
bindResponse { resultCode success (0), matchedDN "", diagnosticMessage "" }
```

| Field | Meaning | Spec |
| --- | --- | --- |
| `version` | Always 3. No negotiation; a server that does not support it returns `protocolError`. | [RFC 4511 §4.2](https://www.rfc-editor.org/rfc/rfc4511#section-4.2) |
| `name` | DN to bind as. Empty for anonymous bind or for SASL. | §4.2, [RFC 4513 §5.1](https://www.rfc-editor.org/rfc/rfc4513#section-5.1) |
| `authentication simple` | The password as an OCTET STRING. Only safe inside TLS. | RFC 4513 §5.1.3 |
| `authentication sasl` (alternative) | `mechanism` such as `GSSAPI` (Kerberos) or `EXTERNAL` (TLS client certificate), with `credentials`. | §4.2, [RFC 4513 §5.2](https://www.rfc-editor.org/rfc/rfc4513#section-5.2), [RFC 4422](https://www.rfc-editor.org/rfc/rfc4422) |
| `resultCode` | `success` (0), `invalidCredentials` (49), `strongerAuthRequired` (8), `confidentialityRequired` (13), `unwillingToPerform` (53) and others. | [§4.1.9](https://www.rfc-editor.org/rfc/rfc4511#section-4.1.9), [§4.2.2](https://www.rfc-editor.org/rfc/rfc4511#section-4.2.2) |

SASL `EXTERNAL` with a client certificate, or `GSSAPI` with a Kerberos keytab, removes the service account password altogether.

## Step 3: find the user

The command-line equivalent with OpenLDAP's [ldapsearch](https://www.openldap.org/software/man.cgi?query=ldapsearch):

```bash
ldapsearch -ZZ -H ldap://dc1.example.com \
  -D "cn=svc-portal,ou=service,dc=example,dc=com" -W \
  -b "ou=people,dc=example,dc=com" -s sub -z 2 \
  "(&(objectClass=person)(uid=ada))" dn uid mail entryUUID
```

On the wire:

```
messageID 3
searchRequest {
  baseObject   "ou=people,dc=example,dc=com",
  scope        wholeSubtree (2),
  derefAliases neverDerefAliases (0),
  sizeLimit    2,
  timeLimit    10,
  typesOnly    FALSE,
  filter       and { equalityMatch { objectClass, "person" },
                     equalityMatch { uid, "ada" } },
  attributes   [ "uid", "mail", "entryUUID" ] }

messageID 3
searchResEntry {
  objectName "uid=ada,ou=people,dc=example,dc=com",
  attributes [ uid: "ada", mail: "ada@example.com",
               entryUUID: "597ae2f6-16a6-1027-98f4-abcdefabcdef" ] }

messageID 3
searchResDone { resultCode success (0), matchedDN "", diagnosticMessage "" }
```

| Field | Meaning | Spec |
| --- | --- | --- |
| `baseObject`, `scope` | Where to search and how deep: `baseObject` (0), `singleLevel` (1), `wholeSubtree` (2). | [§4.5.1.1–4.5.1.2](https://www.rfc-editor.org/rfc/rfc4511#section-4.5.1.1) |
| `derefAliases` | Alias handling; `neverDerefAliases` is the predictable choice. | [§4.5.1.3](https://www.rfc-editor.org/rfc/rfc4511#section-4.5.1.3) |
| `sizeLimit`, `timeLimit` | Caps set by the client. A limit of 2 lets you detect an ambiguous username. | [§4.5.1.4–4.5.1.5](https://www.rfc-editor.org/rfc/rfc4511#section-4.5.1.4) |
| `filter` | Structured filter (`and`, `or`, `not`, `equalityMatch`, `substrings`, `present`...). Its string form is RFC 4515. | [§4.5.1.7](https://www.rfc-editor.org/rfc/rfc4511#section-4.5.1.7), [RFC 4515 §3](https://www.rfc-editor.org/rfc/rfc4515#section-3) |
| `attributes` | What to return. Never ask for `userPassword`. | [§4.5.1.8](https://www.rfc-editor.org/rfc/rfc4511#section-4.5.1.8) |
| `searchResEntry`, `searchResDone` | One message per entry, then a done message with the result code. | [§4.5.2](https://www.rfc-editor.org/rfc/rfc4511#section-4.5.2) |
| `entryUUID` | Stable operational identifier for the entry ([RFC 4530](https://www.rfc-editor.org/rfc/rfc4530)); Active Directory's equivalent is `objectGUID`. | RFC 4530 |

## Step 4: bind as the user

```
messageID 4
bindRequest { version 3, name "uid=ada,ou=people,dc=example,dc=com",
              authentication simple "<the password the user typed>" }

messageID 4
bindResponse { resultCode invalidCredentials (49), matchedDN "",
               diagnosticMessage "" }
```

Result 49 means the DN is valid syntax but the credentials are not ([RFC 4513 §5.1.3](https://www.rfc-editor.org/rfc/rfc4513#section-5.1.3)). Return the same error to the user whether the account does not exist or the password is wrong; `diagnosticMessage` and differing result codes can reveal which, a disclosure RFC 4511 §6 warns about.

Do this bind on a separate connection, or rebind as the service account afterwards: the bind changes the connection's authorization state ([RFC 4513 §4](https://www.rfc-editor.org/rfc/rfc4513#section-4)), and any later group lookup would run with the user's rights.

## The checks an LDAP-authenticating application must run

1. **TLS first, verified.** Complete StartTLS or LDAPS and validate the server certificate and name before any bind (RFC 4513 §3.1.3; RFC 4511 §6). Never fall back to cleartext.
2. **Reject empty passwords before sending the bind.** An empty password turns a simple bind into the unauthenticated mechanism, which authenticates nobody ([RFC 4513 §5.1.2](https://www.rfc-editor.org/rfc/rfc4513#section-5.1.2), [§6.3.1](https://www.rfc-editor.org/rfc/rfc4513#section-6.3.1)).
3. **Escape every user-supplied value**: filter values per [RFC 4515 §3](https://www.rfc-editor.org/rfc/rfc4515#section-3) (`*` → `\2a`, `(` → `\28`, `)` → `\29`, `\` → `\5c`, NUL → `\00`) and DN values per [RFC 4514 §2.4](https://www.rfc-editor.org/rfc/rfc4514#section-2.4).
4. **Exactly one entry.** Treat zero or more than one search result as a failed login, not "use the first".
5. **Success means resultCode 0 on the user bind**, nothing else ([RFC 4511 §4.1.9](https://www.rfc-editor.org/rfc/rfc4511#section-4.1.9)). Do not infer success from the absence of an exception.
6. **Do not follow referrals with credentials** to servers you did not configure (RFC 4511 §6, [§4.1.10](https://www.rfc-editor.org/rfc/rfc4511#section-4.1.10)).
7. **Key accounts on a stable identifier** (`entryUUID` or `objectGUID`), not `uid`, `mail` or the DN, which change on rename or move.
8. **Least-privilege service account**: read-only, scoped to the subtrees the application needs, with a rotated credential or SASL `EXTERNAL`/`GSSAPI` instead of a password.

## Common implementation mistakes, with the CVEs behind them

| Mistake | What goes wrong | Real examples |
| --- | --- | --- |
| Client or server that cannot handle malformed BER | A crafted response crashes or compromises a domain controller; RFC 4511 §6 says peers MUST handle invalid and arbitrary-length encodings | [CVE-2024-49113](https://startwithidentity.com/cves/cve-2024-49113/) (LDAPNightmare), [CVE-2024-49112](https://startwithidentity.com/cves/cve-2024-49112/) |
| Directory ACLs allow anonymous or low-privilege writes | Attacker-created entries become privileged principals | [CVE-2026-76578](https://startwithidentity.com/cves/cve-2026-76578/) (FreeIPA) |
| Input evaluated before the caller's rights are checked | Any authenticated principal reaches sensitive server state | [CVE-2026-79678](https://startwithidentity.com/cves/cve-2026-79678/) (FreeIPA) |
| Different errors for unknown and known users | Username enumeration feeds spraying | [CVE-2023-3462](https://startwithidentity.com/cves/cve-2023-3462/) (Vault LDAP auth) |
| Lockout keyed differently from login | Case permutation resets the lockout counter | [CVE-2025-6004](https://startwithidentity.com/cves/cve-2025-6004/) (Vault) |
| Password binds exposed to the internet | High-volume guessing against the directory | [Password spraying](https://startwithidentity.com/techniques/password-spraying/), [credential stuffing](https://startwithidentity.com/techniques/credential-stuffing/) |
| Directory readable by every domain user | Reconnaissance for service accounts and delegation | [Kerberoasting](https://startwithidentity.com/techniques/kerberoasting/), [Kerberos delegation abuse](https://startwithidentity.com/techniques/kerberos-delegation-abuse/) |

## Try it locally

SWI has no browser tool for LDAP, because a browser cannot open raw TCP connections. Use OpenLDAP's [ldapsearch](https://www.openldap.org/software/man.cgi?query=ldapsearch) against a test directory: `-ZZ` requires StartTLS to succeed, `-d 1` prints protocol debugging, and binding with `-w ""` shows how your server answers an unauthenticated bind. If it returns success, fix the server configuration before an application relies on it.

## Related

[LDAP standard page](https://startwithidentity.com/standards/ldap/), [how Kerberos works, message by message](https://startwithidentity.com/guides/protocols/kerberos-message-flow/), [how RADIUS works, message by message](https://startwithidentity.com/guides/protocols/radius-message-flow/), [SCIM message flow](https://startwithidentity.com/guides/protocols/scim-message-flow/). Glossary: [LDAP](https://startwithidentity.com/glossary/ldap/), [directory service](https://startwithidentity.com/glossary/directory-service/), [Active Directory](https://startwithidentity.com/glossary/active-directory/).

## How OAuth 2.0 and OAuth 2.1 Work, Message by Message
Source: https://startwithidentity.com/guides/protocols/oauth-message-flow/
Last updated: 2026-11-05

OAuth 2.0 is a set of HTTP exchanges that end with an API receiving an access token and deciding whether to honor it. There are three grants worth knowing in 2026: **authorization code with PKCE** when a user is present, **client credentials** when no user is, and **refresh** to renew either without starting over. This page shows each message with fake but realistic values, explains every parameter with its section in [RFC 6749](https://www.rfc-editor.org/rfc/rfc6749) and the [OAuth 2.1 draft (draft-17, 31 October 2026)](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-17), and lists what the authorization server, the client and the API each have to check.

For the overview, the roles and status, see the [OAuth 2.0](https://startwithidentity.com/standards/oauth-2-0/) and [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/) standard pages. For the identity layer and the ID token, see [how OIDC works, message by message](https://startwithidentity.com/guides/protocols/oidc-message-flow/).

## The sequence at a glance

| # | Message | OAuth 2.0 | OAuth 2.1 draft-17 |
| --- | --- | --- | --- |
| 1 | Authorization request (browser) | [RFC 6749 §4.1.1](https://www.rfc-editor.org/rfc/rfc6749#section-4.1.1) + [RFC 7636 §4.3](https://www.rfc-editor.org/rfc/rfc7636#section-4.3) | [§4.1.1](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-17#section-4.1.1) |
| 2 | Authorization response (redirect with code) | [§4.1.2](https://www.rfc-editor.org/rfc/rfc6749#section-4.1.2) | [§4.1.2](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-17#section-4.1.2) |
| 3 | Token request (code exchange) | [§4.1.3](https://www.rfc-editor.org/rfc/rfc6749#section-4.1.3) | [§3.2.2, §4.1.3](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-17#section-4.1.3) |
| 4 | Token response | [§5.1](https://www.rfc-editor.org/rfc/rfc6749#section-5.1), errors [§5.2](https://www.rfc-editor.org/rfc/rfc6749#section-5.2) | [§3.2.3–3.2.4](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-17#section-3.2.3) |
| 5 | Client credentials request | [§4.4.2](https://www.rfc-editor.org/rfc/rfc6749#section-4.4.2) | [§4.2](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-17#section-4.2) |
| 6 | Refresh request | [§6](https://www.rfc-editor.org/rfc/rfc6749#section-6) | [§4.3](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-17#section-4.3) |
| 7 | API request with bearer token | [RFC 6750 §2.1](https://www.rfc-editor.org/rfc/rfc6750#section-2.1) | [§5.1.1](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-17#section-5.1.1) |
| 8 | API error | [RFC 6750 §3](https://www.rfc-editor.org/rfc/rfc6750#section-3) | [§5.3](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-17#section-5.3) |

## Messages 1 and 2: authorization request and response

```http
GET /authorize?response_type=code
  &client_id=reports-web-example
  &redirect_uri=https%3A%2F%2Freports.example.com%2Foauth%2Fcallback
  &scope=invoices.read
  &state=7d1f2b9e-example
  &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
  &code_challenge_method=S256
  &resource=https%3A%2F%2Fapi.example.com%2Finvoices HTTP/1.1
Host: as.example.com
```

| Parameter | Meaning | Spec |
| --- | --- | --- |
| `response_type=code` | Only `code` survives in OAuth 2.1; `token` (implicit) is gone. | RFC 6749 §4.1.1; [RFC 9700 §2.1.2](https://www.rfc-editor.org/rfc/rfc9700#section-2.1.2) |
| `client_id` | Registered client identifier. | RFC 6749 §2.2 |
| `redirect_uri` | Compared by exact string match against registration (loopback ports excepted for native apps). | [RFC 9700 §2.1](https://www.rfc-editor.org/rfc/rfc9700#section-2.1), [§4.1.3](https://www.rfc-editor.org/rfc/rfc9700#section-4.1.3); 2.1 §4.1.1 |
| `scope` | Space-delimited permissions requested. Design scopes per API action, not per app. | RFC 6749 [§3.3](https://www.rfc-editor.org/rfc/rfc6749#section-3.3) |
| `state` | CSRF protection and client context. | RFC 6749 [§10.12](https://www.rfc-editor.org/rfc/rfc6749#section-10.12) |
| `code_challenge`, `code_challenge_method=S256` | PKCE. Required by default in 2.1; `plain` removed. | RFC 7636 §4.2–4.3; 2.1 §4.1.1 |
| `resource` | Names the API the token is for, so the AS can audience-restrict it. | [RFC 8707 §2.1](https://www.rfc-editor.org/rfc/rfc8707#section-2.1) |

The response is a redirect:

```http
HTTP/1.1 302 Found
Location: https://reports.example.com/oauth/callback?code=Qcb0Orv1zh30vL1MPRsbm-example
  &state=7d1f2b9e-example&iss=https%3A%2F%2Fas.example.com
```

RFC 6749 §4.1.2 recommends codes live at most 10 minutes and says a code used twice must be refused, with tokens already issued from it revoked where possible. The `iss` parameter is [RFC 9207](https://www.rfc-editor.org/rfc/rfc9207#section-2); a client talking to more than one AS must check it to stop mix-up attacks ([RFC 9700 §4.4](https://www.rfc-editor.org/rfc/rfc9700#section-4.4)).

## Messages 3 and 4: token request and response

```http
POST /token HTTP/1.1
Host: as.example.com
Authorization: Basic cmVwb3J0cy13ZWItZXhhbXBsZTpub3QtYS1yZWFsLXNlY3JldA==
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=Qcb0Orv1zh30vL1MPRsbm-example
&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
&redirect_uri=https%3A%2F%2Freports.example.com%2Foauth%2Fcallback
```

`Authorization: Basic` is `client_secret_basic` ([RFC 6749 §2.3.1](https://www.rfc-editor.org/rfc/rfc6749#section-2.3.1)); stronger options are `private_key_jwt` ([RFC 7523 §2.2](https://www.rfc-editor.org/rfc/rfc7523#section-2.2)) and mutual TLS ([RFC 8705 §2](https://www.rfc-editor.org/rfc/rfc8705#section-2)). The `redirect_uri` line is required in OAuth 2.0 when it was sent in message 1, and dropped from the code exchange in OAuth 2.1 (draft §10). The verifier and challenge are the illustrative values from RFC 7636 Appendix B.

```http
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "access_token": "eyJ0eXAiOiJhdCtqd3QiLCJhbGciOiJFUzI1NiIsImtpZCI6ImFzLWtleS0yMDI2LTEwIn0.eyJpc3MiOi...sig",
  "token_type": "Bearer",
  "expires_in": 600,
  "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA-example",
  "scope": "invoices.read"
}
```

| Field | Meaning | Spec |
| --- | --- | --- |
| `access_token` | Opaque to the client. Here a JWT under RFC 9068, decoded below. | RFC 6749 §5.1 |
| `token_type` | `Bearer` ([RFC 6750](https://www.rfc-editor.org/rfc/rfc6750)) or `DPoP` ([RFC 9449](https://www.rfc-editor.org/rfc/rfc9449)). | RFC 6749 [§7.1](https://www.rfc-editor.org/rfc/rfc6749#section-7.1) |
| `expires_in` | Lifetime in seconds. | RFC 6749 §5.1 |
| `refresh_token` | Long-lived credential for message 6. | RFC 6749 [§1.5](https://www.rfc-editor.org/rfc/rfc6749#section-1.5) |
| `scope` | Granted scope, which may be narrower than requested. Read it. | RFC 6749 §5.1, §3.3 |
| `Cache-Control: no-store` | Tokens must not be cached by intermediaries. | RFC 6749 §5.1 |

An error looks like `{"error":"invalid_grant","error_description":"code already used"}` with HTTP 400 ([RFC 6749 §5.2](https://www.rfc-editor.org/rfc/rfc6749#section-5.2)).

## Message 5: client credentials (no user)

```http
POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&scope=invoices.export
&resource=https%3A%2F%2Fapi.example.com%2Finvoices
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJFUzI1NiIsImtpZCI6ImJhdGNoLWtleS0xIn0.eyJpc3MiOiJiYXRjaC1leHBvcnRlci1leGFtcGxlIn0.c2ln
```

No browser, no code, no refresh token is expected ([RFC 6749 §4.4.3](https://www.rfc-editor.org/rfc/rfc6749#section-4.4.3)). The client authenticates directly, here with a signed JWT whose `iss` and `sub` are its `client_id` and whose `aud` is this AS ([RFC 7523 §3](https://www.rfc-editor.org/rfc/rfc7523#section-3)). Cache the token until shortly before `expires_in` rather than requesting one per call. For workloads that already hold a platform identity, [workload identity federation](https://startwithidentity.com/glossary/workload-identity-federation/) replaces the client secret entirely.

## Message 6: refresh, with rotation

```http
POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA-example
&client_id=reports-web-example
```

With rotation the response carries a new `refresh_token` and the old one stops working. If the old one is presented again, the AS treats it as theft and revokes the whole family. For public clients, RFC 9700 §4.14.2 requires refresh tokens to be either sender-constrained or rotated, and OAuth 2.1 carries that forward (draft §10, [§4.3.3](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-17#section-4.3.3)). The scope of a new refresh token must equal the old one unless the client asked to reduce it.

## Messages 7 and 8: calling the API

```http
GET /invoices?status=open HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJ0eXAiOiJhdCtqd3QiLCJhbGciOiJFUzI1NiIsImtpZCI6ImFzLWtleS0yMDI2LTEwIn0.eyJpc3MiOi...sig
```

The header form is the one to use ([RFC 6750 §2.1](https://www.rfc-editor.org/rfc/rfc6750#section-2.1)). Tokens in the URL query are forbidden in OAuth 2.1 and discouraged by [RFC 9700 §4.3.2](https://www.rfc-editor.org/rfc/rfc9700#section-4.3.2) because URLs end up in logs and `Referer` headers. A rejection looks like:

```http
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="invoices", error="invalid_token",
  error_description="token expired"
```

Error codes are `invalid_request` (400), `invalid_token` (401) and `insufficient_scope` (403) ([RFC 6750 §3.1](https://www.rfc-editor.org/rfc/rfc6750#section-3.1)).

### The JWT access token, decoded

```json
{ "typ": "at+jwt", "alg": "ES256", "kid": "as-key-2026-10" }
```

```json
{
  "iss": "https://as.example.com",
  "sub": "5ba552d67-example",
  "aud": "https://api.example.com/invoices",
  "client_id": "reports-web-example",
  "scope": "invoices.read",
  "exp": 1793887931,
  "iat": 1793887331,
  "jti": "dbe39bf3a3ba4238a513f51d6e1691c4-example"
}
```

| Claim | Meaning | Spec |
| --- | --- | --- |
| `typ: at+jwt` | Distinguishes access tokens from ID tokens, so one cannot be used as the other. | [RFC 9068 §2.1](https://www.rfc-editor.org/rfc/rfc9068#section-2.1) |
| `iss`, `exp`, `iat`, `jti` | Issuer, expiry, issue time, unique ID; all required. | [RFC 9068 §2.2](https://www.rfc-editor.org/rfc/rfc9068#section-2.2) |
| `aud` | The resource indicator of this API. | RFC 9068 §2.2, RFC 8707 |
| `sub` | The user, or the client itself for client credentials. | RFC 9068 §2.2 |
| `client_id` | Which client obtained the token. | RFC 9068 §2.2 |
| `scope` | What the token permits. | [RFC 9068 §2.2.3](https://www.rfc-editor.org/rfc/rfc9068#section-2.2.3) |

Opaque tokens are checked with the introspection endpoint instead: `POST /introspect` with `token=...`, authenticated as the API, returns `{"active":true,"scope":"invoices.read","client_id":"reports-web-example","aud":"https://api.example.com/invoices","exp":1793887931}` ([RFC 7662 §2.1–2.2](https://www.rfc-editor.org/rfc/rfc7662#section-2.2)).

### Sender-constrained tokens with DPoP

With [DPoP](https://startwithidentity.com/glossary/dpop/), the client sends a fresh proof JWT signed by its own key on every request, and the access token is bound to that key's thumbprint (`cnf.jkt`, [RFC 9449 §6.1](https://www.rfc-editor.org/rfc/rfc9449#section-6.1)):

```http
GET /invoices HTTP/1.1
Host: api.example.com
Authorization: DPoP eyJ0eXAiOiJhdCtqd3Qi...sig
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6IkVDIn19.eyJqdGkiOiJlMWozVl9iS2ljOC1MQUVCIiwiaHRtIjoiR0VUIiwiaHR1IjoiaHR0cHM6Ly9hcGkuZXhhbXBsZS5jb20vaW52b2ljZXMifQ.c2ln
```

The proof's header has `typ: dpop+jwt`, `alg` and the public `jwk`; its payload has `jti`, `htm` (method), `htu` (URL), `iat` and, at an API, `ath` (hash of the access token) ([RFC 9449 §4.2](https://www.rfc-editor.org/rfc/rfc9449#section-4.2)). A stolen DPoP-bound token is useless without the private key. Mutual TLS binding ([RFC 8705 §3](https://www.rfc-editor.org/rfc/rfc8705#section-3)) achieves the same with a client certificate.

## Who checks what

**Authorization server**

1. `redirect_uri` exactly matches a registered value (RFC 9700 §2.1; 2.1 §4.1.1).
2. PKCE: `BASE64URL(SHA256(code_verifier))` equals the stored `code_challenge`, and `plain` is refused ([RFC 7636 §4.6](https://www.rfc-editor.org/rfc/rfc7636#section-4.6); 2.1 §10). Refusing requests without PKCE also blocks the [PKCE downgrade](https://www.rfc-editor.org/rfc/rfc9700#section-4.8).
3. Codes are single-use, short-lived and bound to the client they were issued to (RFC 6749 §4.1.2, §4.1.3).

**Client**

4. `state` matches, and `iss` matches when present (RFC 6749 §10.12, RFC 9207 §2.4).
5. Read the granted `scope` in the token response, and store tokens server-side or in a backend-for-frontend, never in `localStorage`.

**API (resource server)**, from [RFC 9068 §4](https://www.rfc-editor.org/rfc/rfc9068#section-4):

6. `typ` is `at+jwt`; `iss` exactly matches the AS; `aud` contains this API's identifier.
7. Signature verifies with the AS's published keys; `alg` is on your allow-list and never `none`.
8. `exp` has not passed (small skew only), then enforce `scope` per endpoint. If the token is DPoP-bound, run the twelve proof checks in [RFC 9449 §4.3](https://www.rfc-editor.org/rfc/rfc9449#section-4.3), including `ath`.

## Common implementation mistakes, with the CVEs and techniques behind them

| Mistake | What goes wrong | Real examples |
| --- | --- | --- |
| API accepts any token, or skips validation when a lookup fails | Fabricated bearer tokens reach protected tools | [CVE-2026-59822](https://startwithidentity.com/cves/cve-2026-59822/) (LiteLLM MCP gateway, exploited) |
| Auth bypass rules matched against the wrong part of the URL | A crafted query string skips authentication | [CVE-2025-54576](https://startwithidentity.com/cves/cve-2025-54576/) (OAuth2-Proxy) |
| Token endpoint URL built from tenant-controlled input | The client secret is posted to an attacker's host | [CVE-2026-89111](https://startwithidentity.com/cves/cve-2026-89111/) (SAP Cloud SDK for Python) |
| Token cache keyed loosely | One client's token attached to another client's request | [CVE-2025-26620](https://startwithidentity.com/cves/cve-2025-26620/) (Duende) |
| Signature and audience checks with gaps | Forged or misdirected tokens accepted | [CVE-2026-55040](https://startwithidentity.com/cves/cve-2026-55040/) (SharePoint), [CVE-2025-27371](https://startwithidentity.com/cves/cve-2025-27371/) |
| Authorization policy evaluated incorrectly | Scope or permission escalation | [CVE-2025-14778](https://startwithidentity.com/cves/cve-2025-14778/) (Keycloak UMA), technique: [scope escalation through delegation](https://startwithidentity.com/techniques/scope-escalation-delegation/) |
| Long-lived, unbound refresh tokens | Stolen refresh token works for weeks | [refresh token abuse](https://startwithidentity.com/techniques/refresh-token-abuse/), [token replay at an unbound endpoint](https://startwithidentity.com/techniques/token-replay-unbound-endpoint/) |
| Users approve a malicious client | The protocol works perfectly for the attacker | [OAuth consent phishing](https://startwithidentity.com/techniques/oauth-consent-phishing/), [device code phishing](https://startwithidentity.com/techniques/device-code-phishing/) |

The last row is the hard one: consent and device-code phishing exploit OAuth working as designed. The defenses are admin-consent policies, publisher verification, blocking the device authorization grant where it is not needed, and short token lifetimes.

## Try it

Paste an access token into the [JWT decoder](https://startwithidentity.com/tools/jwt-decoder/) and check `typ`, `iss`, `aud`, `exp` and `scope` against the table above. If your authorization server also publishes OpenID metadata, run it through the [OIDC discovery checker](https://startwithidentity.com/tools/oidc-discovery-checker/) to confirm PKCE `S256` support and the issuer string. The [protect an API with OAuth scopes recipe](https://startwithidentity.com/recipes/protect-an-api-with-oauth-scopes/) turns the resource-server checks into code.

## Related

[OAuth 2.0](https://startwithidentity.com/standards/oauth-2-0/), [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/), [OIDC message flow](https://startwithidentity.com/guides/protocols/oidc-message-flow/), [OAuth vs OIDC](https://startwithidentity.com/guides/fundamentals/oauth-vs-oidc/), [implementing OAuth 2.0 and OIDC](https://startwithidentity.com/guides/implementation/oauth-2-openid-connect-implementation/), [MCP authorization](https://startwithidentity.com/standards/mcp-authorization/). Glossary: [access token](https://startwithidentity.com/glossary/access-token/), [refresh token](https://startwithidentity.com/glossary/refresh-token/), [bearer token](https://startwithidentity.com/glossary/bearer-token/), [scope](https://startwithidentity.com/glossary/scope/), [token introspection](https://startwithidentity.com/glossary/token-introspection/), [mTLS](https://startwithidentity.com/glossary/mtls/).

## How OpenID Connect Works, Message by Message
Source: https://startwithidentity.com/guides/protocols/oidc-message-flow/
Last updated: 2026-11-05

OpenID Connect (OIDC) is the OAuth 2.0 authorization code flow plus one extra artifact: a signed **ID token** that tells the relying party (RP) who logged in, when and how. On the wire that is five HTTP exchanges: discovery, the authentication request, the redirect back with a code, the token request, and optionally a userinfo call. This page shows each one with realistic, fake values, explains every parameter with its section in [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html) or the relevant RFC, and ends with the checks an RP must run and the mistakes that became CVEs.

For what OIDC is, its status and where it fits, see the [OpenID Connect standard page](https://startwithidentity.com/standards/openid-connect/). For the OAuth layer underneath, including client credentials and refresh, see [how OAuth 2.0 and 2.1 work, message by message](https://startwithidentity.com/guides/protocols/oauth-message-flow/).

## The sequence at a glance

| # | From → to | Message | Spec |
| --- | --- | --- | --- |
| 0 | RP → OP | `GET /.well-known/openid-configuration` | [Discovery §4](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig) |
| 1 | RP → browser → OP | Authentication request to the authorization endpoint | [Core §3.1.2.1](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest) |
| 2 | OP ↔ user | Login, MFA, consent | [Core §3.1.2.3–3.1.2.4](https://openid.net/specs/openid-connect-core-1_0.html#Authenticates) |
| 3 | OP → browser → RP | Redirect with `code`, `state`, `iss` | [Core §3.1.2.5](https://openid.net/specs/openid-connect-core-1_0.html#AuthResponse), [RFC 9207 §2](https://www.rfc-editor.org/rfc/rfc9207#section-2) |
| 4 | RP → OP (back channel) | Token request with `code` and `code_verifier` | [Core §3.1.3.1](https://openid.net/specs/openid-connect-core-1_0.html#TokenRequest), [RFC 7636 §4.5](https://www.rfc-editor.org/rfc/rfc7636#section-4.5) |
| 5 | OP → RP | Token response: `id_token`, `access_token`, optional `refresh_token` | [Core §3.1.3.3](https://openid.net/specs/openid-connect-core-1_0.html#TokenResponse) |
| 6 | RP → OP | Optional userinfo request with the access token | [Core §5.3](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) |

## Step 0: discovery

```http
GET /.well-known/openid-configuration HTTP/1.1
Host: login.example.com
```

```json
{
  "issuer": "https://login.example.com",
  "authorization_endpoint": "https://login.example.com/authorize",
  "token_endpoint": "https://login.example.com/oauth/token",
  "userinfo_endpoint": "https://login.example.com/userinfo",
  "jwks_uri": "https://login.example.com/.well-known/jwks.json",
  "response_types_supported": ["code"],
  "subject_types_supported": ["public", "pairwise"],
  "id_token_signing_alg_values_supported": ["RS256", "ES256"],
  "code_challenge_methods_supported": ["S256"],
  "authorization_response_iss_parameter_supported": true,
  "token_endpoint_auth_methods_supported": ["private_key_jwt", "client_secret_basic"]
}
```

| Field | Why the RP cares | Spec |
| --- | --- | --- |
| `issuer` | The exact string every ID token's `iss` must equal. It must also match the URL you fetched the document from. | [Discovery §3, §4.3](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationValidation) |
| `jwks_uri` | Where the signing keys live. Cache with a TTL and refetch on an unknown `kid`. | [Discovery §3](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata) |
| `id_token_signing_alg_values_supported` | What the OP may sign with. Your RP should accept only the one algorithm you registered. | [Discovery §3](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata) |
| `code_challenge_methods_supported` | Whether PKCE `S256` is available (it should be). | [RFC 8414 §2](https://www.rfc-editor.org/rfc/rfc8414#section-2) |
| `authorization_response_iss_parameter_supported` | The OP adds `iss` to the redirect, which defeats mix-up attacks. | [RFC 9207 §3](https://www.rfc-editor.org/rfc/rfc9207#section-3) |

## Step 1: the authentication request

The RP generates three random values per login and stores them in the user's pre-login session: `state`, `nonce`, and a PKCE `code_verifier` (43 to 128 characters, [RFC 7636 §4.1](https://www.rfc-editor.org/rfc/rfc7636#section-4.1)). It sends the SHA-256 of the verifier as the challenge.

```http
GET /authorize?response_type=code
  &client_id=s6BhdRkqt3-example
  &redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback
  &scope=openid%20profile%20email
  &state=af0ifjsldkj-example
  &nonce=n-0S6_WzA2Mj-example
  &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
  &code_challenge_method=S256 HTTP/1.1
Host: login.example.com
```

| Parameter | Meaning | Spec |
| --- | --- | --- |
| `response_type=code` | Authorization code flow, the one to use. | [Core §3.1.2.1](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest) |
| `scope=openid ...` | `openid` is what makes this OIDC; `profile` and `email` request standard claims. | [Core §3.1.2.1, §5.4](https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims) |
| `client_id` | The RP's registered identifier; becomes the ID token `aud`. | [RFC 6749 §2.2](https://www.rfc-editor.org/rfc/rfc6749#section-2.2) |
| `redirect_uri` | Must exactly match a registered value. | [Core §3.1.2.1](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest), [RFC 9700 §2.1](https://www.rfc-editor.org/rfc/rfc9700#section-2.1) |
| `state` | Opaque CSRF token you check on return. | [Core §3.1.2.1](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest), [RFC 6749 §10.12](https://www.rfc-editor.org/rfc/rfc6749#section-10.12) |
| `nonce` | Copied by the OP into the ID token, binding it to this browser session. | [Core §3.1.2.1, §15.5.2](https://openid.net/specs/openid-connect-core-1_0.html#NonceNotes) |
| `code_challenge`, `code_challenge_method=S256` | PKCE: proves the party redeeming the code started the request. | [RFC 7636 §4.2–4.3](https://www.rfc-editor.org/rfc/rfc7636#section-4.3) |
| `prompt`, `max_age`, `acr_values` (optional) | Force re-login, cap authentication age, request an assurance level. | [Core §3.1.2.1](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest) |

## Step 3: the callback

```http
HTTP/1.1 302 Found
Location: https://app.example.com/callback?code=SplxlOBeZQQYbYS6WxSbIA-example
  &state=af0ifjsldkj-example
  &iss=https%3A%2F%2Flogin.example.com
```

The code is single-use and short-lived; RFC 6749 recommends a maximum lifetime of 10 minutes ([§4.1.2](https://www.rfc-editor.org/rfc/rfc6749#section-4.1.2)). The RP checks `state` against the session ([Core §3.1.2.7](https://openid.net/specs/openid-connect-core-1_0.html#AuthResponseValidation)) and `iss` against the expected issuer ([RFC 9207 §2.4](https://www.rfc-editor.org/rfc/rfc9207#section-2.4)) before doing anything else.

## Step 4: the token request

```http
POST /oauth/token HTTP/1.1
Host: login.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA-example
&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback
&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
&client_id=s6BhdRkqt3-example
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJQUzI1NiIsImtpZCI6ImNsaWVudC1rZXktMSJ9.eyJpc3MiOiJzNkJoZFJrcXQzLWV4YW1wbGUiLCJhdWQiOiJodHRwczovL2xvZ2luLmV4YW1wbGUuY29tIn0.c2lnbmF0dXJlLWV4YW1wbGU
```

| Parameter | Meaning | Spec |
| --- | --- | --- |
| `grant_type=authorization_code`, `code` | Redeem the code from step 3. | [RFC 6749 §4.1.3](https://www.rfc-editor.org/rfc/rfc6749#section-4.1.3) |
| `redirect_uri` | Must be identical to the one in step 1 if it was sent there. | [RFC 6749 §4.1.3](https://www.rfc-editor.org/rfc/rfc6749#section-4.1.3) |
| `code_verifier` | The server hashes it and compares to the stored challenge. | [RFC 7636 §4.5–4.6](https://www.rfc-editor.org/rfc/rfc7636#section-4.6) |
| `client_assertion` (`private_key_jwt`) | A short JWT signed by the client's private key. Its `aud` must identify this authorization server; the 2025 audience findings in the mistakes table show what happens when it is loose. | [RFC 7523 §2.2, §3](https://www.rfc-editor.org/rfc/rfc7523#section-3), [Core §9](https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication) |

The example PKCE values are the illustrative ones from RFC 7636 Appendix B. Never reuse them.

## Step 5: the token response and the ID token

```json
{
  "access_token": "SlAV32hkKG-example",
  "token_type": "Bearer",
  "expires_in": 900,
  "refresh_token": "8xLOxBtZp8-example",
  "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjIwMjYtMTAta2V5LWEiLCJ0eXAiOiJKV1QifQ.eyJpc3MiOi...signature"
}
```

The response must carry `Cache-Control: no-store` ([Core §3.1.3.3](https://openid.net/specs/openid-connect-core-1_0.html#TokenResponse)). Decoded, the ID token header and payload look like this:

```json
{ "alg": "RS256", "kid": "2026-10-key-a", "typ": "JWT" }
```

```json
{
  "iss": "https://login.example.com",
  "sub": "248289761001-example",
  "aud": "s6BhdRkqt3-example",
  "exp": 1793887631,
  "iat": 1793887331,
  "auth_time": 1793887322,
  "nonce": "n-0S6_WzA2Mj-example",
  "acr": "phr",
  "amr": ["hwk", "user"],
  "at_hash": "77QmUPtjPfzWtF2AnpK9RQ",
  "email": "ada@example.com",
  "email_verified": true
}
```

| Claim | Meaning | Spec |
| --- | --- | --- |
| `iss` | Issuer identifier, compared by exact string match. | [Core §2](https://openid.net/specs/openid-connect-core-1_0.html#IDToken) |
| `sub` | Stable, never-reassigned identifier within this issuer. The account key is `iss` + `sub`. | [Core §2, §5.7](https://openid.net/specs/openid-connect-core-1_0.html#ClaimStability) |
| `aud` | Must contain your `client_id`. Can be an array. | [Core §2](https://openid.net/specs/openid-connect-core-1_0.html#IDToken) |
| `exp`, `iat` | Expiry and issue time, seconds since the epoch. | [Core §2](https://openid.net/specs/openid-connect-core-1_0.html#IDToken) |
| `auth_time` | When the user actually authenticated; required if you sent `max_age`. | [Core §2](https://openid.net/specs/openid-connect-core-1_0.html#IDToken) |
| `nonce` | Echo of your request value. | [Core §2](https://openid.net/specs/openid-connect-core-1_0.html#IDToken) |
| `acr`, `amr` | Assurance class and methods used. Values are deployment-specific; `amr` values are registered in [RFC 8176](https://www.rfc-editor.org/rfc/rfc8176). | [Core §2](https://openid.net/specs/openid-connect-core-1_0.html#IDToken) |
| `at_hash` | Left half of the hash of the access token, base64url. Lets you confirm the access token came with this ID token. | [Core §3.1.3.6](https://openid.net/specs/openid-connect-core-1_0.html#CodeIDToken) |
| `email`, `email_verified` | Profile claims. Display them; do not key accounts on them. | [Core §5.1](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) |

## Step 6: userinfo (optional)

```http
GET /userinfo HTTP/1.1
Host: login.example.com
Authorization: Bearer SlAV32hkKG-example
```

The `sub` in the userinfo response must exactly match the `sub` in the ID token, or the RP must not use the response ([Core §5.3.2](https://openid.net/specs/openid-connect-core-1_0.html#UserInfoResponse)).

## The checks a relying party must run

1. **`state` matches** the value in the user's pre-login session, then discard it ([Core §3.1.2.7](https://openid.net/specs/openid-connect-core-1_0.html#AuthResponseValidation)).
2. **`iss` on the redirect** equals the expected issuer when the OP supports RFC 9207 ([RFC 9207 §2.4](https://www.rfc-editor.org/rfc/rfc9207#section-2.4)).
3. **ID token `iss`** exactly equals the discovered `issuer` ([Core §3.1.3.7](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation)).
4. **`aud` contains your `client_id`** and no audiences you do not trust; if `azp` is present, it is your `client_id` (Core §3.1.3.7).
5. **Signature verifies** with a key from the issuer's JWKS, using the algorithm you registered. Reject `alg: none`, reject symmetric algorithms you did not configure, and never take the key from the token header (Core §3.1.3.7, [§10.1](https://openid.net/specs/openid-connect-core-1_0.html#Signing)).
6. **`exp` is in the future** and `iat` is within your acceptable window (Core §3.1.3.7).
7. **`nonce` is present and equals** the value you sent (Core §3.1.3.7).
8. **`acr` and `auth_time`** satisfy what you requested, if you requested them (Core §3.1.3.7).

The JWT layer underneath has its own rules: [RFC 7519 §7.2](https://www.rfc-editor.org/rfc/rfc7519#section-7.2) for validating a JWT, and the [JWT best current practices in RFC 8725](https://www.rfc-editor.org/rfc/rfc8725) for algorithm allow-lists.

## Common implementation mistakes, with the CVEs they produced

| Mistake | What goes wrong | Real examples |
| --- | --- | --- |
| Accepting unsigned tokens or `alg: none` | Anyone can mint an ID token | [CVE-2026-48558](https://startwithidentity.com/cves/cve-2026-48558/) (SimpleHelp, exploited), [CVE-2023-29357](https://startwithidentity.com/cves/cve-2023-29357/) (SharePoint) |
| Accepting algorithms you never configured, or picking the key from attacker input | Key confusion; HS256 verified with a public key or a looked-up secret | [CVE-2026-5430](https://startwithidentity.com/cves/cve-2026-5430/) (WSO2), [CVE-2025-65945](https://startwithidentity.com/cves/cve-2025-65945/) (node-jws), [CVE-2025-9485](https://startwithidentity.com/cves/cve-2025-9485/) |
| Loose `aud` on `private_key_jwt` client assertions | An assertion meant for one server is replayed at another | [CVE-2025-27370](https://startwithidentity.com/cves/cve-2025-27370/), [CVE-2025-27371](https://startwithidentity.com/cves/cve-2025-27371/), technique: [token replay at an unbound endpoint](https://startwithidentity.com/techniques/token-replay-unbound-endpoint/) |
| Expired or retired keys still trusted | A key you rotated out keeps working | [CVE-2025-31123](https://startwithidentity.com/cves/cve-2025-31123/) (Zitadel) |
| Re-authentication not bound to the original user | `prompt=login` or account linking merges the wrong session | [CVE-2023-6787](https://startwithidentity.com/cves/cve-2023-6787/), [CVE-2025-7365](https://startwithidentity.com/cves/cve-2025-7365/) (Keycloak) |
| Accepting any tenant of a multi-tenant issuer | A user from any tenant signs in | [cross-tenant token confusion](https://startwithidentity.com/techniques/cross-tenant-token-confusion/) |
| Keying accounts on `email` | Account takeover through an unverified or reassigned email | Pattern; use `iss` + `sub` |
| Calling APIs with the ID token | The API accepts a token whose audience is the client | Send the access token; see the [OAuth walkthrough](https://startwithidentity.com/guides/protocols/oauth-message-flow/) |

None of these checks stop a user who completes a real login on a phishing proxy; the proxy steals the resulting session. That is fixed at the OP with phishing-resistant authentication, see [how WebAuthn works, message by message](https://startwithidentity.com/guides/protocols/webauthn-message-flow/) and [AiTM phishing](https://startwithidentity.com/techniques/aitm-phishing-proxy/).

## Try it

Run your provider through the [OIDC discovery checker](https://startwithidentity.com/tools/oidc-discovery-checker/) to confirm the `issuer`, JWKS and supported algorithms, then paste an ID token into the [JWT decoder](https://startwithidentity.com/tools/jwt-decoder/) and compare each claim to the table above. The [validate a JWT recipe](https://startwithidentity.com/recipes/validate-a-jwt/) and the [authorization code with PKCE recipe](https://startwithidentity.com/recipes/oidc-authorization-code-pkce/) turn the checklist into code.

## Related

[OpenID Connect standard page](https://startwithidentity.com/standards/openid-connect/), [OAuth vs OIDC](https://startwithidentity.com/guides/fundamentals/oauth-vs-oidc/), [SAML message flow](https://startwithidentity.com/guides/protocols/saml-message-flow/), [implementing OAuth 2.0 and OIDC](https://startwithidentity.com/guides/implementation/oauth-2-openid-connect-implementation/). Glossary: [ID token](https://startwithidentity.com/glossary/id-token/), [JWT](https://startwithidentity.com/glossary/jwt/), [JWKS](https://startwithidentity.com/glossary/jwks/), [PKCE](https://startwithidentity.com/glossary/pkce/), [relying party](https://startwithidentity.com/glossary/relying-party/), [claims](https://startwithidentity.com/glossary/claims/).

## How RADIUS Works, Message by Message
Source: https://startwithidentity.com/guides/protocols/radius-message-flow/
Last updated: 2026-11-05

A RADIUS authentication is a short UDP conversation between a network access server (NAS), such as a VPN gateway or Wi-Fi controller, and a RADIUS server: an **Access-Request**, possibly an **Access-Challenge** and a second request, and finally an **Access-Accept** or **Access-Reject**, followed by accounting. Each packet is a fixed header plus attributes defined in [RFC 2865](https://www.rfc-editor.org/rfc/rfc2865). This page decodes each packet with fake values, ties every attribute to its section, and lists what both sides must check, with particular attention to the Blast-RADIUS lessons. For what RADIUS is and its status, see the [RADIUS standard page](https://startwithidentity.com/standards/radius/).

Addresses below are from the documentation ranges in [RFC 5737](https://www.rfc-editor.org/rfc/rfc5737). The shared secret is never sent; it only feeds the hashes.

## The sequence at a glance

| # | From → to | Packet (Code) | Spec |
| --- | --- | --- | --- |
| 1 | NAS → server (UDP 1812) | Access-Request (1) with username and password | [§4.1](https://www.rfc-editor.org/rfc/rfc2865#section-4.1) |
| 2 | Server → NAS | Access-Challenge (11) with `State` and a prompt | [§4.4](https://www.rfc-editor.org/rfc/rfc2865#section-4.4) |
| 3 | NAS → server | Access-Request (1) with the code and the same `State` | [§5.24](https://www.rfc-editor.org/rfc/rfc2865#section-5.24) |
| 4 | Server → NAS | Access-Accept (2) or Access-Reject (3) | [§4.2](https://www.rfc-editor.org/rfc/rfc2865#section-4.2), [§4.3](https://www.rfc-editor.org/rfc/rfc2865#section-4.3) |
| 5 | NAS → server (UDP 1813) | Accounting-Request (4), Start | [RFC 2866 §4.1](https://www.rfc-editor.org/rfc/rfc2866#section-4.1) |
| 6 | Server → NAS | Accounting-Response (5) | [RFC 2866 §4.2](https://www.rfc-editor.org/rfc/rfc2866#section-4.2) |

With push-based MFA, steps 2 and 3 disappear: the server holds the first request while it waits for the user to approve on their phone.

## The packet header

```
 Code (1 byte) | Identifier (1) | Length (2) | Authenticator (16) | Attributes ...
      0x01          0x2a          0x00b4      9f 3c 1e ... (random)
```

| Field | Meaning | Spec |
| --- | --- | --- |
| Code | 1 Access-Request, 2 Access-Accept, 3 Access-Reject, 11 Access-Challenge; 4 and 5 for accounting. | [§3](https://www.rfc-editor.org/rfc/rfc2865#section-3), [RFC 2866 §3](https://www.rfc-editor.org/rfc/rfc2866#section-3) |
| Identifier | Matches replies to requests; also used to detect retransmissions. | §3 |
| Length | 20 to 4096 octets. | §3 |
| Request Authenticator | In Access-Request, 16 unpredictable random octets. Also the input to the `User-Password` keystream. | §3 |
| Response Authenticator | In replies, `MD5(Code + ID + Length + RequestAuth + Attributes + Secret)`. The only built-in integrity check, and the one Blast-RADIUS forged. | §3 |
| Attributes | Type (1 byte), Length (1 byte), Value. | [§5](https://www.rfc-editor.org/rfc/rfc2865#section-5) |

## Message 1: Access-Request

```
Code 1 (Access-Request)  Identifier 42  Authenticator 0x9f3c1e7a...(16 random octets)
  80 Message-Authenticator = 0x5b0e...(HMAC-MD5 over the packet)
   1 User-Name             = "ada@example.com"
   2 User-Password         = 0x6c1a...(16 octets, hidden with the shared secret)
   4 NAS-IP-Address        = 192.0.2.10
  32 NAS-Identifier        = "vpn-gw-01"
   5 NAS-Port              = 0
  61 NAS-Port-Type         = Virtual (5)
   6 Service-Type          = Framed (2)
  31 Calling-Station-Id    = "203.0.113.45"
  30 Called-Station-Id     = "198.51.100.1"
```

| Attribute (type) | Meaning | Spec |
| --- | --- | --- |
| Message-Authenticator (80) | HMAC-MD5 over the whole packet, keyed with the shared secret. Mandatory with EAP; send it always. | [RFC 3579 §3.2](https://www.rfc-editor.org/rfc/rfc3579#section-3.2) |
| User-Name (1) | The identity being authenticated. | [§5.1](https://www.rfc-editor.org/rfc/rfc2865#section-5.1) |
| User-Password (2) | Password padded to 16-octet blocks and XORed with `MD5(secret + RequestAuthenticator)`, chained per block. Confidential only as long as the secret is. | [§5.2](https://www.rfc-editor.org/rfc/rfc2865#section-5.2) |
| CHAP-Password (3), alternative | CHAP response instead of a password; a request must not carry both. | [§5.3](https://www.rfc-editor.org/rfc/rfc2865#section-5.3), §4.1 |
| NAS-IP-Address (4) / NAS-Identifier (32) | Which NAS is asking; at least one is required. | [§5.4](https://www.rfc-editor.org/rfc/rfc2865#section-5.4), [§5.32](https://www.rfc-editor.org/rfc/rfc2865#section-5.32) |
| NAS-Port (5), NAS-Port-Type (61) | Port and its type; 5 is Virtual, used for VPN sessions. | [§5.5](https://www.rfc-editor.org/rfc/rfc2865#section-5.5), [§5.41](https://www.rfc-editor.org/rfc/rfc2865#section-5.41) |
| Service-Type (6) | Requested service, for example Framed (2) for a network session or Administrative (6) for device management. | [§5.6](https://www.rfc-editor.org/rfc/rfc2865#section-5.6) |
| Calling-Station-Id (31) | The caller's side. Defined for the phone number a call came from; in practice NAS vendors put the client IP for VPN or the MAC address for Wi-Fi here. Useful for policy and logs. | [§5.31](https://www.rfc-editor.org/rfc/rfc2865#section-5.31) |
| Called-Station-Id (30) | The called side, originally the dialed number; vendors commonly use the VPN address or the access point MAC and SSID. | [§5.30](https://www.rfc-editor.org/rfc/rfc2865#section-5.30) |

## Messages 2 and 3: Access-Challenge for a one-time code

```
Code 11 (Access-Challenge)  Identifier 42  Authenticator 0x...(Response Authenticator)
  80 Message-Authenticator = 0x...
  18 Reply-Message         = "Enter the 6-digit code from your authenticator app"
  24 State                 = 0x7f2c9a41e3b0...(opaque to the NAS)

Code 1 (Access-Request)  Identifier 43  Authenticator 0x...(new random)
  80 Message-Authenticator = 0x...
   1 User-Name             = "ada@example.com"
   2 User-Password         = 0x...(the one-time code, hidden as above)
  24 State                 = 0x7f2c9a41e3b0...(copied unchanged)
   4 NAS-IP-Address        = 192.0.2.10
```

`State` must be returned unmodified and the NAS must not interpret it ([§5.24](https://www.rfc-editor.org/rfc/rfc2865#section-5.24)); `Reply-Message` is text to display ([§5.18](https://www.rfc-editor.org/rfc/rfc2865#section-5.18)). EAP (for 802.1X) uses exactly this challenge loop, with each round's EAP packet in `EAP-Message` (79) ([RFC 3579 §3.1](https://www.rfc-editor.org/rfc/rfc3579#section-3.1)).

## Message 4: Access-Accept

```
Code 2 (Access-Accept)  Identifier 43  Authenticator 0x...(Response Authenticator)
  80 Message-Authenticator = 0x...            -- first attribute, per Blast-RADIUS guidance
  25 Class                 = "sess-8c41-example"
  27 Session-Timeout       = 28800
  11 Filter-Id             = "vpn-finance"
  26 Vendor-Specific       = (vendor 9, a group or VLAN assignment)
```

| Attribute (type) | Meaning | Spec |
| --- | --- | --- |
| Class (25) | Opaque value the NAS must echo in accounting, tying the session to this authorization. | [§5.25](https://www.rfc-editor.org/rfc/rfc2865#section-5.25) |
| Session-Timeout (27) | Maximum session length in seconds. | [§5.27](https://www.rfc-editor.org/rfc/rfc2865#section-5.27) |
| Filter-Id (11) | Name of a filter or policy the NAS applies. | [§5.11](https://www.rfc-editor.org/rfc/rfc2865#section-5.11) |
| Vendor-Specific (26) | Vendor ID plus vendor-defined sub-attributes, commonly used for roles and VLANs. | [§5.26](https://www.rfc-editor.org/rfc/rfc2865#section-5.26) |

An Access-Reject (3) may carry a `Reply-Message` and nothing that grants access.

## Messages 5 and 6: accounting

```
Code 4 (Accounting-Request)  Identifier 7
  40 Acct-Status-Type = Start (1)
  44 Acct-Session-Id  = "00000A1F"
   1 User-Name        = "ada@example.com"
  25 Class            = "sess-8c41-example"
   4 NAS-IP-Address   = 192.0.2.10
```

The server answers Accounting-Response (5). Stop records carry duration and byte counts. Accounting is how you prove which user held which address at what time ([RFC 2866 §5.1](https://www.rfc-editor.org/rfc/rfc2866#section-5.1), [§5.5](https://www.rfc-editor.org/rfc/rfc2866#section-5.5)).

## The checks each side must run

**NAS (the RADIUS client)**

1. **Identifier and source.** Accept a reply only if its Identifier matches an outstanding request and it came from the configured server address (§3).
2. **Response Authenticator** verifies with the shared secret; otherwise silently discard (§3).
3. **Require `Message-Authenticator` on every reply**, verify it, and expect it as the first attribute of Access-Accept and Access-Reject. This is the [Blast-RADIUS](https://www.blastradius.fail/) mitigation; RFC 3579 §3.2 already requires it for EAP.
4. **Return `State` unchanged** and never act on its contents (§5.24).

**RADIUS server**

5. **Known client and secret.** Silently discard packets from clients without a configured shared secret ([§2](https://www.rfc-editor.org/rfc/rfc2865#section-2)), and use a distinct secret per NAS, at least 16 octets and never empty (§3, Administrative Note).
6. **Well-formed request.** Require `NAS-IP-Address` or `NAS-Identifier`, and exactly one of `User-Password`, `CHAP-Password` or `State`, never both password types (§4.1).
7. **Require `Message-Authenticator` on requests** and drop requests without it; for EAP, RFC 3579 §3.2 says such requests SHOULD be silently discarded.
8. **Protect the transport.** Across any network you do not fully control, run RADIUS inside TLS: RadSec ([RFC 6614](https://www.rfc-editor.org/rfc/rfc6614), port 2083) or RADIUS/1.1 ([RFC 9765](https://www.rfc-editor.org/rfc/rfc9765)), which removes the MD5 constructions altogether.

## Common implementation mistakes, with the CVEs and techniques behind them

| Mistake | What goes wrong | Real examples |
| --- | --- | --- |
| PAP or CHAP without `Message-Authenticator` | An attacker in the path forges Access-Accept from Access-Reject with an MD5 collision; MFA behind RADIUS is bypassed | [CVE-2024-3596](https://startwithidentity.com/cves/cve-2024-3596/) (Blast-RADIUS) |
| `Message-Authenticator` sent but not required | Downgrade: the attacker strips it and the old attack works | Same CVE; configure "require" on both sides |
| RADIUS server management plane exposed | The network access control system itself is taken over | [CVE-2026-76460](https://startwithidentity.com/cves/cve-2026-76460/) (Cisco ISE, exploited) |
| Push MFA through RADIUS without number matching | Users approve attacker-initiated logins | [MFA fatigue and push bombing](https://startwithidentity.com/techniques/mfa-fatigue-push-bombing/) |
| RADIUS-fronted VPN with password-only users | Internet-facing guessing against the directory behind it | [Password spraying](https://startwithidentity.com/techniques/password-spraying/), [credential stuffing](https://startwithidentity.com/techniques/credential-stuffing/) |
| One shared secret for every NAS, never rotated | One compromised device decrypts every password and forges every reply | Rotate and segment secrets, then move to TLS |

## Try it locally

There is no SWI browser tool for RADIUS, which runs over UDP. FreeRADIUS's [radclient](https://freeradius.org/radiusd/man/radclient.html) sends test packets against a lab server: `radclient -x 192.0.2.20 auth example-shared-secret` reads attributes from standard input and prints the reply, and its `-b` flag enforces the Blast-RADIUS checks, requiring `Message-Authenticator` as the first attribute of every reply. If your server's replies fail with `-b`, fix the server before relying on RADIUS for MFA.

## Related

[RADIUS standard page](https://startwithidentity.com/standards/radius/), [how LDAP works, message by message](https://startwithidentity.com/guides/protocols/ldap-message-flow/), [how Kerberos works, message by message](https://startwithidentity.com/guides/protocols/kerberos-message-flow/), [how WebAuthn works, message by message](https://startwithidentity.com/guides/protocols/webauthn-message-flow/). Glossary: [RADIUS](https://startwithidentity.com/glossary/radius/), [MFA](https://startwithidentity.com/glossary/mfa/), [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/).

## How SAML 2.0 Works, Message by Message
Source: https://startwithidentity.com/guides/protocols/saml-message-flow/
Last updated: 2026-11-05

A SAML 2.0 login is two XML messages carried by the browser: an `<AuthnRequest>` from the service provider (SP) to the identity provider (IdP), and a `<Response>` with a signed `<Assertion>` coming back. Almost every SAML breach is a failure to check one field of that second message. This page walks through both messages with trimmed, realistic examples, ties each field to its section in the OASIS specifications, lists the checks an SP must run, and links each common mistake to a real CVE.

For what SAML is, when to choose it over OIDC and its status, see the [SAML 2.0 standard page](https://startwithidentity.com/standards/saml-2-0/). This page assumes you know the roles and want the wire-level detail.

**Sources.** Section numbers refer to the OASIS SAML 2.0 [Assertions and Protocols (Core)](https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf), [Bindings](https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf) and [Profiles](https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf) specifications (15 March 2005), plus the [approved errata](https://docs.oasis-open.org/security/saml/v2.0/sstc-saml-approved-errata-2.0.html). The flow described is the Web Browser SSO profile, Profiles §4.1.

## The sequence at a glance

| # | From → to | What travels | Binding | Spec |
| --- | --- | --- | --- | --- |
| 1 | Browser → SP | `GET https://app.example.com/reports` (no session) | HTTP | Profiles §4.1.3.1 |
| 2 | SP → browser → IdP | `<AuthnRequest>` in the `SAMLRequest` query parameter, plus `RelayState` | HTTP-Redirect | Core §3.4.1, Bindings §3.4 |
| 3 | IdP ↔ user | Login, MFA, conditional access (out of scope for SAML) | none | Profiles §4.1.3.4 |
| 4 | IdP → browser → SP | `<Response>` with `<Assertion>` in the `SAMLResponse` form field | HTTP-POST | Core §3.2.2 and §2.3.3, Bindings §3.5 |
| 5 | SP | Validates, creates its own session, redirects to `RelayState` | none | Profiles §4.1.4.3 |

Steps 2 and 4 are the only SAML messages. The Artifact binding (Bindings §3.6) swaps step 4 for a reference the SP resolves over a back channel, which is rarer in SaaS.

## Message 1: the AuthnRequest

The SP builds this XML, deflates it, base64-encodes it and URL-encodes it into a redirect (Bindings §3.4.4.1).

```xml
<samlp:AuthnRequest
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="_a1b2c3d4e5f60718293a4b5c6d7e8f90"
    Version="2.0"
    IssueInstant="2026-11-05T14:02:11Z"
    Destination="https://idp.example.com/saml2/sso"
    AssertionConsumerServiceURL="https://app.example.com/saml/acs"
    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST">
  <saml:Issuer>https://app.example.com/saml/metadata</saml:Issuer>
  <samlp:NameIDPolicy
      Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
      AllowCreate="true"/>
</samlp:AuthnRequest>
```

The redirect the browser follows looks like this (values shortened):

```http
GET /saml2/sso?SAMLRequest=fZJNT8MwDIbvSPyHKPe2a8cOi9ZOAzQJiY9pA4S4hdR0EWlS4rSFf0%2B6DQkO7GTLfu3Hr53Z...
  &RelayState=%2Freports
  &SigAlg=http%3A%2F%2Fwww.w3.org%2F2001%2F04%2Fxmldsig-more%23rsa-sha256
  &Signature=Qm9ndXNTaWduYXR1cmVGb3JFeGFtcGxlT25seQ%3D%3D HTTP/1.1
Host: idp.example.com
```

| Field | Meaning | Spec |
| --- | --- | --- |
| `ID` | Unique request identifier. Must be an `xs:ID`, so it cannot start with a digit; implementations prefix an underscore. The SP stores it to match `InResponseTo` later. | Core §1.3.4, §3.2.1 |
| `Version`, `IssueInstant` | Always `2.0`; UTC timestamp of issue. | Core §3.2.1 |
| `Destination` | The IdP endpoint the request is sent to. Required to be checked when the message is signed. | Core §3.2.1, Bindings §3.4.5.2 |
| `AssertionConsumerServiceURL` | Where the SP wants the Response delivered. The IdP must check it against SP metadata, not trust it blindly. | Core §3.4.1, Profiles §4.1.4.1 |
| `ProtocolBinding` | How the Response should come back, here HTTP-POST. | Core §3.4.1 |
| `<Issuer>` | The SP's entity ID, which becomes the expected `<Audience>`. | Core §2.2.5, Profiles §4.1.4.1 |
| `<NameIDPolicy>` | Requested identifier format: `persistent` (opaque, stable, pairwise) or `emailAddress`. | Core §3.4.1.1, §8.3 |
| `RequestedAuthnContext` (optional) | Asks for a class of authentication, for example `PasswordProtectedTransport` or a phishing-resistant class your IdP defines. | Core §3.3.2.2.1 |
| `RelayState` | Opaque value the IdP returns unchanged. Use it for the post-login path, never as an unvalidated redirect target. | Bindings §3.4.3 |
| `SigAlg`, `Signature` | With the Redirect binding the signature is over the query string, not inside the XML. | Bindings §3.4.4.1 |

Many SPs leave the AuthnRequest unsigned. That is allowed, but signing it stops anyone from forging requests that redirect assertions to an unexpected ACS URL, which is why IdPs increasingly let you require it.

## Message 2: the Response and Assertion

The IdP returns an HTML page with an auto-submitting form whose `SAMLResponse` field is the base64 of the XML below (Bindings §3.5.4). Signature values and certificates are trimmed.

```xml
<samlp:Response
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="_resp9f8e7d6c5b4a39281706f5e4d3c2b1a0"
    InResponseTo="_a1b2c3d4e5f60718293a4b5c6d7e8f90"
    Version="2.0"
    IssueInstant="2026-11-05T14:02:19Z"
    Destination="https://app.example.com/saml/acs">
  <saml:Issuer>https://idp.example.com/saml2</saml:Issuer>
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </samlp:Status>
  <saml:Assertion ID="_assert0a1b2c3d4e5f67890abcdef1234567" Version="2.0"
                  IssueInstant="2026-11-05T14:02:19Z">
    <saml:Issuer>https://idp.example.com/saml2</saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
      <ds:SignedInfo>
        <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
        <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
        <ds:Reference URI="#_assert0a1b2c3d4e5f67890abcdef1234567">
          <!-- Transforms: enveloped-signature, exc-c14n -->
          <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
          <ds:DigestValue>RXhhbXBsZURpZ2VzdE5vdFJlYWw=</ds:DigestValue>
        </ds:Reference>
      </ds:SignedInfo>
      <ds:SignatureValue>RXhhbXBsZVNpZ25hdHVyZQ==</ds:SignatureValue>
    </ds:Signature>
    <saml:Subject>
      <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
        u-7f3c9a21-example
      </saml:NameID>
      <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml:SubjectConfirmationData
            InResponseTo="_a1b2c3d4e5f60718293a4b5c6d7e8f90"
            Recipient="https://app.example.com/saml/acs"
            NotOnOrAfter="2026-11-05T14:07:19Z"/>
      </saml:SubjectConfirmation>
    </saml:Subject>
    <saml:Conditions NotBefore="2026-11-05T14:01:49Z"
                     NotOnOrAfter="2026-11-05T14:07:19Z">
      <saml:AudienceRestriction>
        <saml:Audience>https://app.example.com/saml/metadata</saml:Audience>
      </saml:AudienceRestriction>
    </saml:Conditions>
    <saml:AuthnStatement AuthnInstant="2026-11-05T14:02:17Z"
                         SessionIndex="_sess-31d7-example"
                         SessionNotOnOrAfter="2026-11-05T22:02:17Z">
      <saml:AuthnContext>
        <saml:AuthnContextClassRef>
          urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
        </saml:AuthnContextClassRef>
      </saml:AuthnContext>
    </saml:AuthnStatement>
    <saml:AttributeStatement>
      <saml:Attribute Name="email"><saml:AttributeValue>ada@example.com</saml:AttributeValue></saml:Attribute>
      <saml:Attribute Name="groups"><saml:AttributeValue>finance-readers</saml:AttributeValue></saml:Attribute>
    </saml:AttributeStatement>
  </saml:Assertion>
</samlp:Response>
```

### Response envelope

| Field | Meaning | Spec |
| --- | --- | --- |
| `InResponseTo` | The `ID` of the AuthnRequest this answers. Absent in IdP-initiated (unsolicited) logins. | Core §3.2.2, Profiles §4.1.5 |
| `Destination` | Must equal the ACS URL where it arrived whenever the Response is signed. | Core §3.2.2, Bindings §3.5.5.2 |
| `<Status>` / `<StatusCode>` | `Success` or an error such as `Requester`, `Responder`, `AuthnFailed`. On error, no assertion may be included. | Core §3.2.2.1–3.2.2.2, Profiles §4.1.4.2 |
| `<Issuer>` | Optional on the Response; if present it must be the IdP entity ID. | Profiles §4.1.4.2 |

### Assertion

| Field | Meaning | Spec |
| --- | --- | --- |
| `<Assertion ID>` | Target of the signature reference (`URI="#..."`), and the key for your replay cache. | Core §2.3.3, §5.4.2 |
| `<ds:Signature>` | Enveloped XML Signature with exclusive canonicalization. Must reference the ID of the element being signed, with a single `<ds:Reference>`. | Core §5.4.1–5.4.4 |
| `<Issuer>` | IdP entity ID. Must match the IdP you configured. | Core §2.2.5, Profiles §4.1.4.2 |
| `<NameID>` | The subject identifier. `persistent` is an opaque per-SP value; `emailAddress` is readable but can be reassigned. Key accounts on `Issuer` + `NameID`. | Core §2.2.3, §8.3.2, §8.3.7 |
| `<SubjectConfirmation Method="...:cm:bearer">` | Whoever presents this assertion is the subject. That is why every other check matters. | Core §2.4.1.1, Profiles §4.1.4.2 |
| `<SubjectConfirmationData>` | `Recipient` (your ACS URL), `NotOnOrAfter` (delivery window), `InResponseTo`. Must not carry `NotBefore` in this profile. | Core §2.4.1.2, Profiles §4.1.4.2 |
| `<Conditions NotBefore NotOnOrAfter>` | Validity window of the assertion itself. | Core §2.5.1.2 |
| `<AudienceRestriction>` / `<Audience>` | Your SP entity ID. An assertion for another SP must fail here. | Core §2.5.1.4 |
| `<OneTimeUse>` (optional) | Asks the SP not to cache the assertion for reuse. | Core §2.5.1.5 |
| `<AuthnStatement>` | When and how the user authenticated. `SessionIndex` is needed for Single Logout; `SessionNotOnOrAfter` caps the SP session. | Core §2.7.2, Profiles §4.1.4.3 |
| `<AuthnContextClassRef>` | Authentication class, defined in the [Authentication Context](https://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf) specification. | Core §2.7.2.2 |
| `<AttributeStatement>` | Profile attributes and group claims, often used for just-in-time provisioning and role mapping. | Core §2.7.3 |
| `<EncryptedAssertion>` (alternative) | The whole assertion encrypted to the SP's key. Decrypt first, then apply every check below to the decrypted assertion. | Core §2.3.4, §6 |

## The eight checks the SP must run

Profiles §4.1.4.3 and §4.1.4.5 set the minimum; Core and Bindings add the rest. Run all of them, and reject on the first failure.

1. **Verify the signature with the IdP's key from metadata, and read only what was signed.** With the POST binding the assertion must be signed (Profiles §4.1.4.5). Take the key from configured metadata, never from a `<KeyInfo>` inside the message, and make sure the element your code extracts `NameID` and attributes from is the exact element the `<ds:Reference>` pointed to (Core §5.4.2).
2. **`Issuer`** on the assertion equals the configured IdP entity ID (Profiles §4.1.4.2).
3. **`Audience`** contains your SP entity ID (Core §2.5.1.4).
4. **`Recipient`** in the bearer `SubjectConfirmationData` equals the ACS URL that received the message (Profiles §4.1.4.3), and **`Destination`** on a signed Response equals it too (Bindings §3.5.5.2).
5. **Time windows.** `SubjectConfirmationData NotOnOrAfter` has not passed, and the assertion's `Conditions NotBefore`/`NotOnOrAfter` bracket now, with a small clock-skew allowance (Profiles §4.1.4.3, Core §2.5.1.2).
6. **`InResponseTo`** equals the ID of an AuthnRequest you issued in this browser session and have not already consumed. For unsolicited responses it must be absent, and you should decide whether to accept IdP-initiated login at all (Profiles §4.1.4.3, §4.1.5).
7. **Replay cache.** Store each assertion ID until its `NotOnOrAfter` and reject repeats (Profiles §4.1.4.5).
8. **Structure.** Status is `Success`, there is exactly the assertion you expect (reject extra or nested assertions), and any condition you do not understand makes the assertion invalid (Core §2.5.1.1).

## Common implementation mistakes, with the CVEs they produced

| Mistake | What goes wrong | Real examples |
| --- | --- | --- |
| Signature verified on one node, data read from another (signature wrapping) | An attacker with any validly signed assertion wraps a forged one around or beside it and logs in as anyone | [CVE-2024-45409](https://startwithidentity.com/cves/cve-2024-45409/) (ruby-saml), [CVE-2025-47949](https://startwithidentity.com/cves/cve-2025-47949/) (samlify), [CVE-2024-6202](https://startwithidentity.com/cves/cve-2024-6202/) (HaloITSM), [CVE-2024-6800](https://startwithidentity.com/cves/cve-2024-6800/) (GitHub Enterprise Server) |
| Two XML parsers disagree about the same bytes | The signature library and the data reader see different documents | [CVE-2025-25291](https://startwithidentity.com/cves/cve-2025-25291/), [CVE-2025-25292](https://startwithidentity.com/cves/cve-2025-25292/), [CVE-2025-66567](https://startwithidentity.com/cves/cve-2025-66567/), [CVE-2025-23369](https://startwithidentity.com/cves/cve-2025-23369/) (libxml2 canonicalization in GHES) |
| Checks skipped on the encrypted-assertion path | Validation runs before decryption, or not at all after it | [CVE-2024-4985](https://startwithidentity.com/cves/cve-2024-4985/), [CVE-2024-9487](https://startwithidentity.com/cves/cve-2024-9487/) |
| No replay cache, or replay checked only at one layer | A captured assertion opens a second session | [CVE-2026-18967](https://startwithidentity.com/cves/cve-2026-18967/) (Keycloak SAML broker) |
| Trust not tied to a specific IdP or domain | Assertions from a disabled or different IdP still accepted | [CVE-2026-2603](https://startwithidentity.com/cves/cve-2026-2603/), [CVE-2024-20355](https://startwithidentity.com/cves/cve-2024-20355/) |
| ACS URL from the request reflected without validation | XSS or assertion delivery to the wrong endpoint | [CVE-2023-6717](https://startwithidentity.com/cves/cve-2023-6717/) |
| Appliance SSO code paths that trust crafted messages | Pre-auth bypass on the network edge | [CVE-2025-59718](https://startwithidentity.com/cves/cve-2025-59718/), [CVE-2026-19490](https://startwithidentity.com/cves/cve-2026-19490/) |

Two attacks need no SP bug at all. If the IdP's signing key is stolen, every SP accepts forged assertions: that is [federation trust abuse and SAML forgery](https://startwithidentity.com/techniques/federation-trust-abuse-saml-forgery/). And a real user completing a real login through a reverse proxy hands over the SP session cookie whatever the protocol: see [adversary-in-the-middle phishing](https://startwithidentity.com/techniques/aitm-phishing-proxy/) and [session cookie theft](https://startwithidentity.com/techniques/session-cookie-theft/).

The fix for the first table is the same every time: use a maintained SAML library, pin it, patch it within days, and configure it to require signed assertions, reject unsolicited responses unless you need them, and use a replay cache.

## Try it

Paste a `SAMLRequest` or `SAMLResponse` into the [SAML decoder](https://startwithidentity.com/tools/saml-decoder/) to inflate, decode and pretty-print it in your browser, then compare each field to the tables above. For a live test of your SP, take one valid response and change one thing at a time: the `Audience`, the `Recipient`, one character of a signed attribute, the `InResponseTo`. Each variant must be rejected.

## Related

[SAML 2.0 standard page](https://startwithidentity.com/standards/saml-2-0/), [SAML vs OIDC](https://startwithidentity.com/guides/fundamentals/saml-vs-oidc/), [how OIDC works, message by message](https://startwithidentity.com/guides/protocols/oidc-message-flow/), [implementing SSO](https://startwithidentity.com/guides/authentication/complete-guide-implementing-sso/), [identity federation implementation](https://startwithidentity.com/guides/authentication/identity-federation-implementation-guide/). Glossary: [SAML](https://startwithidentity.com/glossary/saml/), [identity provider](https://startwithidentity.com/glossary/identity-provider/), [service provider](https://startwithidentity.com/glossary/service-provider/), [SSO identifier](https://startwithidentity.com/glossary/sso-identifier/), [SSO enforcement](https://startwithidentity.com/glossary/sso-enforcement/).

## How SCIM 2.0 Works, Message by Message
Source: https://startwithidentity.com/guides/protocols/scim-message-flow/
Last updated: 2026-11-05

SCIM 2.0 is a REST API with a fixed JSON schema for users and groups. The identity provider is the **client** and pushes changes; the application is the **service provider** and stores them. A full lifecycle is about six request types: discovery, a filtered lookup, create, PATCH, group PATCH, and delete. This page shows each one with fake but realistic JSON, explains every field with its section in [RFC 7643](https://www.rfc-editor.org/rfc/rfc7643) (schema) or [RFC 7644](https://www.rfc-editor.org/rfc/rfc7644) (protocol), and lists the checks both sides should run.

For what SCIM is, why it matters and where implementations break at a high level, see the [SCIM 2.0 standard page](https://startwithidentity.com/standards/scim-2-0/). Both RFCs were updated by [RFC 9865](https://www.rfc-editor.org/rfc/rfc9865) (cursor-based pagination, October 2025) and [RFC 9967](https://www.rfc-editor.org/rfc/rfc9967) (SCIM profile for security event tokens, May 2026); the core messages below are unchanged by them.

## The sequence at a glance

| # | Event | Request | Spec |
| --- | --- | --- | --- |
| 0 | Connector set-up | `GET /ServiceProviderConfig`, `/ResourceTypes`, `/Schemas` | [RFC 7644 §4](https://www.rfc-editor.org/rfc/rfc7644#section-4), [RFC 7643 §5](https://www.rfc-editor.org/rfc/rfc7643#section-5) |
| 1 | Before create | `GET /Users?filter=userName eq "..."` | [RFC 7644 §3.4.2.2](https://www.rfc-editor.org/rfc/rfc7644#section-3.4.2.2) |
| 2 | Joiner | `POST /Users` | [RFC 7644 §3.3](https://www.rfc-editor.org/rfc/rfc7644#section-3.3) |
| 3 | Mover | `PATCH /Users/{id}` | [RFC 7644 §3.5.2](https://www.rfc-editor.org/rfc/rfc7644#section-3.5.2) |
| 4 | Access change | `PATCH /Groups/{id}` add or remove `members` | [RFC 7644 §3.5.2.1–3.5.2.2](https://www.rfc-editor.org/rfc/rfc7644#section-3.5.2.2) |
| 5 | Leaver | `PATCH active=false`, later `DELETE /Users/{id}` | [RFC 7643 §4.1.1](https://www.rfc-editor.org/rfc/rfc7643#section-4.1.1), [RFC 7644 §3.6](https://www.rfc-editor.org/rfc/rfc7644#section-3.6) |

Every request carries a bearer token or other credential agreed out of band; RFC 7644 [§2](https://www.rfc-editor.org/rfc/rfc7644#section-2) leaves the mechanism open and requires TLS ([§7.2](https://www.rfc-editor.org/rfc/rfc7644#section-7.2)).

## Step 0: discovery

```http
GET /scim/v2/ServiceProviderConfig HTTP/1.1
Host: app.example.com
Authorization: Bearer scim-token-example-not-real
```

```json
{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:ServiceProviderConfig"],
  "patch": { "supported": true },
  "bulk": { "supported": false, "maxOperations": 0, "maxPayloadSize": 0 },
  "filter": { "supported": true, "maxResults": 200 },
  "changePassword": { "supported": false },
  "sort": { "supported": false },
  "etag": { "supported": true },
  "authenticationSchemes": [
    { "type": "oauthbearertoken", "name": "OAuth Bearer Token",
      "description": "Authentication using an OAuth 2.0 bearer token" }
  ]
}
```

This tells the client whether PATCH, filtering and ETags exist before it relies on them ([RFC 7643 §5](https://www.rfc-editor.org/rfc/rfc7643#section-5)). A connector that skips this step is the usual cause of "works in one app, fails in the next".

## Step 1: look before you create

```http
GET /scim/v2/Users?filter=userName%20eq%20%22ada%40example.com%22&attributes=id,userName,active HTTP/1.1
Host: app.example.com
Authorization: Bearer scim-token-example-not-real
```

```json
{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
  "totalResults": 0,
  "startIndex": 1,
  "itemsPerPage": 0,
  "Resources": []
}
```

| Element | Meaning | Spec |
| --- | --- | --- |
| `filter=userName eq "..."` | Attribute, operator, quoted value. Operators include `eq`, `ne`, `co`, `sw`, `pr`, `gt`, `and`, `or`, `not`. | [RFC 7644 §3.4.2.2](https://www.rfc-editor.org/rfc/rfc7644#section-3.4.2.2) |
| `attributes=` | Return only these attributes. | [RFC 7644 §3.4.2.5](https://www.rfc-editor.org/rfc/rfc7644#section-3.4.2.5) |
| `ListResponse`, `totalResults`, `startIndex` | Paged result envelope; index-based paging, or cursors under RFC 9865. | [RFC 7644 §3.4.2.4](https://www.rfc-editor.org/rfc/rfc7644#section-3.4.2.4) |

`userName` is case-insensitive and unique across the service provider ([RFC 7643 §4.1.1](https://www.rfc-editor.org/rfc/rfc7643#section-4.1.1)), so the server must match `ADA@example.com` here too. Filters that contain personal data end up in access logs; RFC 7644 [§7.5.2](https://www.rfc-editor.org/rfc/rfc7644#section-7.5.2) suggests `POST /Users/.search` ([§3.4.3](https://www.rfc-editor.org/rfc/rfc7644#section-3.4.3)) for that reason.

## Step 2: create the user

```http
POST /scim/v2/Users HTTP/1.1
Host: app.example.com
Authorization: Bearer scim-token-example-not-real
Content-Type: application/scim+json

{
  "schemas": [
    "urn:ietf:params:scim:schemas:core:2.0:User",
    "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
  ],
  "externalId": "idp-obj-4f2a9c1e-example",
  "userName": "ada@example.com",
  "name": { "givenName": "Ada", "familyName": "Example" },
  "emails": [{ "value": "ada@example.com", "type": "work", "primary": true }],
  "active": true,
  "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
    "employeeNumber": "100234",
    "department": "Finance",
    "manager": { "value": "26118915-6090-4610-87e4-49d8ca9f808d" }
  }
}
```

```http
HTTP/1.1 201 Created
Location: https://app.example.com/scim/v2/Users/2819c223-7f76-453a-919d-413861904646
ETag: W/"e180ee84f0671b1"

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "id": "2819c223-7f76-453a-919d-413861904646",
  "externalId": "idp-obj-4f2a9c1e-example",
  "userName": "ada@example.com",
  "active": true,
  "meta": {
    "resourceType": "User",
    "created": "2026-11-05T14:02:11Z",
    "lastModified": "2026-11-05T14:02:11Z",
    "location": "https://app.example.com/scim/v2/Users/2819c223-7f76-453a-919d-413861904646",
    "version": "W/\"e180ee84f0671b1\""
  }
}
```

| Field | Meaning | Spec |
| --- | --- | --- |
| `schemas` | Which schemas the body uses; required on every resource. | [RFC 7643 §3](https://www.rfc-editor.org/rfc/rfc7643#section-3) |
| `id` | Assigned by the service provider; immutable; used in every later URL. Never sent by the client on create. | [RFC 7643 §3.1](https://www.rfc-editor.org/rfc/rfc7643#section-3.1) |
| `externalId` | The client's own identifier for this person. The join key the IdP should store. | [RFC 7643 §3.1](https://www.rfc-editor.org/rfc/rfc7643#section-3.1) |
| `userName` | Required, unique, case-insensitive. Collisions return 409 with `scimType: uniqueness`. | [RFC 7643 §4.1.1](https://www.rfc-editor.org/rfc/rfc7643#section-4.1.1), [RFC 7644 §3.3](https://www.rfc-editor.org/rfc/rfc7644#section-3.3) |
| `name`, `emails` | Complex and multi-valued attributes; `primary` marks one value. | [RFC 7643 §4.1.1–4.1.2](https://www.rfc-editor.org/rfc/rfc7643#section-4.1.2), [§2.4](https://www.rfc-editor.org/rfc/rfc7643#section-2.4) |
| `active` | Administrative status. `false` typically means suspended; exact meaning is up to the service provider. | [RFC 7643 §4.1.1](https://www.rfc-editor.org/rfc/rfc7643#section-4.1.1) |
| Enterprise extension | `employeeNumber`, `department`, `manager` and others, namespaced by URN. | [RFC 7643 §4.3](https://www.rfc-editor.org/rfc/rfc7643#section-4.3) |
| `meta` | `resourceType`, `created`, `lastModified`, `location`, `version`. Read-only. | [RFC 7643 §3.1](https://www.rfc-editor.org/rfc/rfc7643#section-3.1) |
| `ETag` / `meta.version` | Resource version for optimistic concurrency with `If-Match`. | [RFC 7644 §3.14](https://www.rfc-editor.org/rfc/rfc7644#section-3.14) |

The `id` values are the illustrative ones used throughout RFC 7644.

## Step 3: change attributes with PATCH

```http
PATCH /scim/v2/Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1
Host: app.example.com
Authorization: Bearer scim-token-example-not-real
Content-Type: application/scim+json
If-Match: W/"e180ee84f0671b1"

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    { "op": "replace",
      "path": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department",
      "value": "Treasury" },
    { "op": "replace", "path": "emails[type eq \"work\"].value", "value": "ada.example@example.com" }
  ]
}
```

PATCH operations are `add`, `remove` and `replace`, applied in order and atomically: if one fails, the server must restore the original resource ([RFC 7644 §3.5.2](https://www.rfc-editor.org/rfc/rfc7644#section-3.5.2)). `path` follows the attribute notation of [§3.10](https://www.rfc-editor.org/rfc/rfc7644#section-3.10) and may include a value filter in brackets. A server that does not support PATCH says so in `ServiceProviderConfig`; the client then falls back to `PUT` ([§3.5.1](https://www.rfc-editor.org/rfc/rfc7644#section-3.5.1)), which replaces the whole resource and is easy to get wrong.

## Step 4: group membership

```json
{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    { "op": "add", "path": "members",
      "value": [{ "value": "2819c223-7f76-453a-919d-413861904646" }] },
    { "op": "remove",
      "path": "members[value eq \"902c246b-6245-4190-8e05-00816be7344a\"]" }
  ]
}
```

Sent as `PATCH /scim/v2/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a`. `add` on a multi-valued attribute appends ([§3.5.2.1](https://www.rfc-editor.org/rfc/rfc7644#section-3.5.2.1)). `remove` with a filter removes only the matching member; `remove` on `members` with no filter removes all members; a `remove` with no `path` at all must fail with `noTarget` ([§3.5.2.2](https://www.rfc-editor.org/rfc/rfc7644#section-3.5.2.2)). That one paragraph of the RFC is where most deprovisioning bugs live.

## Step 5: deactivate, then delete

```json
{ "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [{ "op": "replace", "path": "active", "value": false }] }
```

```http
DELETE /scim/v2/Users/2819c223-7f76-453a-919d-413861904646 HTTP/1.1
Host: app.example.com
Authorization: Bearer scim-token-example-not-real

HTTP/1.1 204 No Content
```

After a DELETE the server may keep the record but must return 404 for it and omit it from queries, and should not count it in uniqueness checks ([RFC 7644 §3.6](https://www.rfc-editor.org/rfc/rfc7644#section-3.6)). Whether the application also kills active sessions and API tokens is outside SCIM; ask.

### Errors

```json
{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
  "status": "409",
  "scimType": "uniqueness",
  "detail": "userName already exists"
}
```

`scimType` values include `invalidFilter`, `tooMany`, `uniqueness`, `mutability`, `invalidSyntax`, `invalidPath`, `noTarget`, `invalidValue`, `invalidVers` and `sensitive` ([RFC 7644 §3.12](https://www.rfc-editor.org/rfc/rfc7644#section-3.12)).

## The checks each side should run

**Service provider (the application)**

1. **Authenticate every request** and scope the token to SCIM for one tenant; RFC 7644 [§6](https://www.rfc-editor.org/rfc/rfc7644#section-6) leaves multi-tenancy to you, so map the credential to a tenant server-side, never from a request field.
2. **Enforce `userName` uniqueness case-insensitively** and return 409 `uniqueness` on conflict (RFC 7643 §4.1.1, RFC 7644 §3.3).
3. **Respect mutability**: reject writes to `id`, `meta` and other read-only attributes with `mutability` (RFC 7643 [§2.2](https://www.rfc-editor.org/rfc/rfc7643#section-2.2), RFC 7644 §3.12).
4. **Implement PATCH remove with filters exactly** as §3.5.2.2 says, including the no-op success when the member is already absent.
5. **Honour `If-Match`** when you advertise ETags, returning 412 (Precondition Failed) on a version mismatch (RFC 7644 §3.14, status table in §3.12).
6. **Never return passwords**, hashed or not (RFC 7643 §4.1.1, `password`), and treat `active=false` as an immediate session and token revocation event.

**Client (the identity provider or IGA connector)**

7. **Read `ServiceProviderConfig` first** and adapt to what is supported (RFC 7644 §4).
8. **Store `id` against your `externalId`**, look up by filter before creating, and **escape double quotes and backslashes** in filter values, which are JSON strings inside the filter grammar (§3.4.2.2); unescaped input is filter injection.

## Common implementation mistakes

| Mistake | What goes wrong | Related |
| --- | --- | --- |
| Group removals reported as success but not applied | Users keep access after they move or leave | [mover entitlement accumulation](https://startwithidentity.com/techniques/mover-entitlement-accumulation/) |
| Deactivation stops at `active=false` in the app, sessions and API keys survive | A leaver keeps working access | [orphaned account abuse](https://startwithidentity.com/techniques/orphaned-account-abuse/) |
| SCIM token shared across tenants or never rotated | One leaked token rewrites every customer's directory | [secrets in repositories and CI](https://startwithidentity.com/techniques/secrets-in-repositories-and-ci/), [static API key abuse](https://startwithidentity.com/techniques/static-api-key-abuse/) |
| Connector code with weak input handling | The provisioning plane itself becomes the target | [CVE-2024-3318](https://startwithidentity.com/cves/cve-2024-3318/) (SailPoint connector path traversal) |
| Joining on email or `userName` | A rename creates a duplicate; a reused address inherits someone's account | Use `externalId` + `id` |

The SWI CVE catalog has only one SCIM-tagged entry, and its own note says the risk sat in IdP and IGA connectors rather than the protocol. In practice SCIM failures are silent logic errors, not exploits, which is why testing deprovisioning end to end matters more than anything in the table above.

## Try it

Build and inspect each request on this page in the [SCIM request builder](https://startwithidentity.com/tools/scim-request-builder/): set the base URL, choose create, PATCH or group membership, and copy the generated JSON. Then run the one test that catches most real bugs: remove a user from a group through your IdP and read the group back with `GET /Groups/{id}`. The [set up SCIM provisioning recipe](https://startwithidentity.com/recipes/set-up-scim-provisioning/) walks through a full connector.

## Related

[SCIM 2.0 standard page](https://startwithidentity.com/standards/scim-2-0/), [what is SCIM](https://startwithidentity.com/guides/fundamentals/what-is-scim/), [SCIM provisioning implementation guide](https://startwithidentity.com/guides/implementation/scim-provisioning-implementation-guide/), [user lifecycle management](https://startwithidentity.com/guides/implementation/user-lifecycle-management-guide/), [SAML message flow](https://startwithidentity.com/guides/protocols/saml-message-flow/). Glossary: [SCIM](https://startwithidentity.com/glossary/scim/), [provisioning](https://startwithidentity.com/glossary/provisioning/), [deprovisioning](https://startwithidentity.com/glossary/deprovisioning/), [joiner-mover-leaver](https://startwithidentity.com/glossary/joiner-mover-leaver/), [security event token](https://startwithidentity.com/glossary/security-event-token/).

## How to Become an Identity Engineer
Source: https://startwithidentity.com/guides/career/how-to-become-an-identity-engineer/
Last updated: 2026-11-05

Identity engineering is one of the most durable specialties in security, and you do not need a
specific degree to get in. You need a handful of protocols understood deeply, real hands-on time
with platforms, and the ability to explain trade-offs. This page is the skills and lab plan: what to
learn, in what order, and what to build to prove it. For the map of roles, see
[IAM career paths](https://startwithidentity.com/guides/career/iam-career-paths/); for the job search itself, see
[how to get an IAM job](https://startwithidentity.com/guides/career/how-to-get-an-iam-job/).

## What an identity engineer actually does

On a typical week you might onboard three SaaS applications to SSO, debug why a SAML assertion is
rejected after a certificate rollover, write a script that finds accounts with no owner, tune a
conditional access policy that is blocking a contractor group, and review a developer's OAuth
integration. The common thread: you translate between protocols, platforms, and people, and you
make access correct by default rather than by ticket.

## The skill stack, in learning order

1. **Concepts first.** [Authentication vs authorization](https://startwithidentity.com/guides/fundamentals/authentication-vs-authorization/),
   [OAuth vs OIDC](https://startwithidentity.com/guides/fundamentals/oauth-vs-oidc/), [SAML vs OIDC](https://startwithidentity.com/guides/fundamentals/saml-vs-oidc/),
   and access models ([RBAC vs ABAC vs ReBAC](https://startwithidentity.com/guides/fundamentals/rbac-vs-abac-vs-rebac/)). The
   [glossary](https://startwithidentity.com/glossary/) and [standards deep dives](https://startwithidentity.com/standards/) are built for this.
2. **Tokens.** What is in a [JWT](https://startwithidentity.com/glossary/jwt/), how signatures are verified with a
   [JWKS](https://startwithidentity.com/glossary/jwks/), and the difference between an [ID token](https://startwithidentity.com/glossary/id-token/), an
   [access token](https://startwithidentity.com/glossary/access-token/), and a [refresh token](https://startwithidentity.com/glossary/refresh-token/).
3. **Federation.** SAML metadata, certificates, and assertions; OIDC discovery and client
   registration.
4. **Lifecycle.** [SCIM](https://startwithidentity.com/standards/scim-2-0/), [joiner-mover-leaver](https://startwithidentity.com/glossary/joiner-mover-leaver/),
   and why the mover case is where access piles up.
5. **Authentication strength.** MFA, [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/),
   [passkeys](https://startwithidentity.com/guides/authentication/passkeys-101/), and recovery.
6. **Platform depth.** One workforce platform properly (Microsoft Entra or Okta for most
   employers), then a second.
7. **Automation.** PowerShell or Python against a platform API, plus infrastructure as code for
   identity configuration.
8. **Attacker view.** How identity is abused, from the [attack techniques catalog](https://startwithidentity.com/techniques/).

## A six-month lab plan

Each block assumes evenings and weekends. Keep every lab in one public GitHub repository with a
README that explains what you built and why.

| Month | Build | You are done when |
|---|---|---|
| 1 | A web app with OIDC login via open-source [Keycloak](https://startwithidentity.com/vendors/open-source/keycloak/) or a free tier of [Auth0](https://startwithidentity.com/vendors/ciam/auth0/) or [Clerk](https://startwithidentity.com/vendors/ciam/clerk/) | You can explain every redirect and parameter, including `state`, `nonce`, and the PKCE `code_verifier` |
| 2 | Token validation in your own code, then an API protected by scopes | Your API rejects an expired token, a wrong audience, and a token signed by an unknown key |
| 3 | SAML SSO between your IdP and a test service provider, then a certificate rollover | You can read a raw assertion and explain why the SP accepted or rejected it |
| 4 | SCIM provisioning into a small app or a SaaS test tenant | Disabling a user in the IdP deactivates them downstream within minutes, and a re-hire reactivates rather than duplicates |
| 5 | Passkeys plus an MFA policy, with step-up for an admin page | You can describe the recovery path and why SMS is the weak link |
| 6 | An automation script and a short detection exercise on your own sign-in logs | You can find unused accounts and flag a sign-in from a new country |

The [recipes](https://startwithidentity.com/recipes/) cover several of these step by step:
[OIDC with PKCE](https://startwithidentity.com/recipes/oidc-authorization-code-pkce/), [validate a JWT](https://startwithidentity.com/recipes/validate-a-jwt/),
[protect an API with OAuth scopes](https://startwithidentity.com/recipes/protect-an-api-with-oauth-scopes/),
[set up SCIM provisioning](https://startwithidentity.com/recipes/set-up-scim-provisioning/), and
[add passkeys](https://startwithidentity.com/recipes/add-passkeys-webauthn/). The [JWT decoder](https://startwithidentity.com/tools/jwt-decoder/) helps you
inspect tokens while you work.

## Build against the current rules, not old tutorials

Many tutorials still teach patterns the standards bodies have since retired. Learn the current
guidance from the start:

- The OAuth 2.0 Security Best Current Practice, [RFC 9700](https://www.rfc-editor.org/rfc/rfc9700.html)
  (January 2025), says clients should not use the implicit grant, the resource owner password
  credentials grant must not be used, public clients must use PKCE, and authorization servers must
  use exact string matching for redirect URIs. See [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/).
- NIST [SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html) requires passwords used as a
  single factor to be at least 15 characters, forbids composition rules and periodic forced
  rotation, and requires a phishing-resistant authenticator at AAL3. See
  [NIST 800-63](https://startwithidentity.com/glossary/nist-800-63/).

If a course tells you to use the implicit flow or force 90-day password changes, it is out of date.

## Build the security mindset

Study how identity actually fails. The [breach teardowns](https://startwithidentity.com/breaches/) and
[techniques](https://startwithidentity.com/techniques/) show the real patterns:
[MFA fatigue](https://startwithidentity.com/techniques/mfa-fatigue-push-bombing/),
[help desk social engineering](https://startwithidentity.com/techniques/help-desk-social-engineering/),
[session cookie theft](https://startwithidentity.com/techniques/session-cookie-theft/), and
[mover entitlement accumulation](https://startwithidentity.com/techniques/mover-entitlement-accumulation/). For each lab you build,
ask how an attacker would abuse it, then add the control. Being able to explain how a breach
happened and which identity control would have stopped it is what separates an engineer from a
console operator.

## Prove it

Pick up a [certification](https://startwithidentity.com/guides/career/identity-security-certifications/) that matches the
platform you practiced on, contribute to an open-source identity project, and write up what you
built. A short post explaining a SAML rollover you broke and fixed is more convincing than a badge.
Then rehearse with the [interview questions](https://startwithidentity.com/guides/career/iam-interview-questions/) and the
open-source [IAM interview questions bank](https://github.com/Start-With-Identity/iam-interview-questions).

## Skills checklist

Use this as a self-assessment. Aim to be able to do, not just define, each item.

- [ ] Explain [authentication vs authorization](https://startwithidentity.com/guides/fundamentals/authentication-vs-authorization/) and why an access token is not proof of login.
- [ ] Implement the [OAuth authorization code flow with PKCE](https://startwithidentity.com/standards/oauth-2-1/) end to end.
- [ ] Validate a [JWT](https://startwithidentity.com/glossary/jwt/): signature, issuer, audience, expiry, and JWKS key rotation.
- [ ] Configure [SAML](https://startwithidentity.com/standards/saml-2-0/) SSO and [SCIM](https://startwithidentity.com/standards/scim-2-0/) provisioning against a test app.
- [ ] Add [MFA and passkeys](https://startwithidentity.com/guides/authentication/passkeys-101/) and explain phishing resistance.
- [ ] Reason about an access model: [RBAC vs ABAC vs ReBAC](https://startwithidentity.com/guides/fundamentals/rbac-vs-abac-vs-rebac/).
- [ ] Walk through a real [identity breach](https://startwithidentity.com/breaches/) and the control that would have stopped it.
- [ ] Automate a task with a platform API or script.
- [ ] Explain how a [service account](https://startwithidentity.com/glossary/service-account/) or [workload identity](https://startwithidentity.com/glossary/workload-identity/) differs from a human account and how you would govern it.

## Keep learning

Follow a topic through the [podcast learning paths](https://startwithidentity.com/podcasts/learn/), such as
[OAuth and OIDC](https://startwithidentity.com/podcasts/learn/oauth-oidc/) or [SAML](https://startwithidentity.com/podcasts/learn/saml/). Read the people who
wrote the specs in the [experts directory](https://startwithidentity.com/experts/), and when you can, attend a practitioner event
from the [conferences](https://startwithidentity.com/conferences/) list.

## Your next step

Validate your fundamentals with a [certification](https://startwithidentity.com/guides/career/identity-security-certifications/),
then move to [how to get an IAM job](https://startwithidentity.com/guides/career/how-to-get-an-iam-job/) for the resume and
search, and browse the [IAM career paths](https://startwithidentity.com/guides/career/iam-career-paths/) to see where the role can
lead.

## How to Choose a CIAM Platform in 2026: Decision Framework
Source: https://startwithidentity.com/guides/buyer-guides/how-to-choose-a-ciam-platform/
Last updated: 2026-11-05

To choose a CIAM platform, decide the architecture before you compare features: who your users are (consumers, business customers or both), whether you need a full platform or an overlay on login you already run, SaaS or self-hosted, and which compliance and residency limits are fixed. Those four answers usually cut the field of CIAM vendors from thirty to three. A [CIAM](https://startwithidentity.com/guides/fundamentals/what-is-ciam/) choice is harder to reverse than a workforce IAM one, because your customers feel the migration.

This page is the decision framework. For the tests to run once you have a shortlist, use [how to evaluate a CIAM vendor](https://startwithidentity.com/guides/buyer-guides/how-to-evaluate-ciam/); for the build-or-buy question itself, see [build vs buy identity](https://startwithidentity.com/guides/buyer-guides/build-vs-buy-identity/).

## Shortlist by situation (November 2026)

| Your situation | CIAM platforms to start with | Ranking to read |
|---|---|---|
| Consumer app at large scale, fraud matters | [Auth0](https://startwithidentity.com/vendors/ciam/auth0/) (Okta), [Transmit Security](https://startwithidentity.com/vendors/ciam/transmit-security/), [Ping Identity](https://startwithidentity.com/vendors/iam/ping-identity/), [SAP Customer Data Cloud](https://startwithidentity.com/vendors/ciam/sap-customer-data-cloud/) | [Best CIAM for high scale](https://startwithidentity.com/rankings/best-ciam-for-high-scale/) |
| B2B SaaS selling to enterprises | [WorkOS](https://startwithidentity.com/vendors/ciam/workos/), [Frontegg](https://startwithidentity.com/vendors/ciam/frontegg/), Auth0, [Descope](https://startwithidentity.com/vendors/ciam/descope/) | [Best CIAM for B2B SaaS](https://startwithidentity.com/rankings/best-ciam-for-b2b-saas/) |
| Startup, developer-led, needs a free tier | [Clerk](https://startwithidentity.com/vendors/ciam/clerk/), [Stytch](https://startwithidentity.com/vendors/ciam/stytch/), [Kinde](https://startwithidentity.com/vendors/ciam/kinde/), [Supabase Auth](https://startwithidentity.com/vendors/open-source/supabase-auth/) | [Best CIAM for startups](https://startwithidentity.com/rankings/best-ciam-for-startups/) |
| Already on a hyperscaler | [Microsoft Entra External ID](https://startwithidentity.com/vendors/ciam/microsoft-entra-external-id/), [Amazon Cognito](https://startwithidentity.com/vendors/ciam/amazon-cognito/), [Google Identity Platform](https://startwithidentity.com/vendors/ciam/google-identity/) | [Best CIAM platforms](https://startwithidentity.com/rankings/best-ciam-platforms/) |
| Regulated: healthcare, finance, public sector | Auth0, Ping Identity, [Curity](https://startwithidentity.com/vendors/ciam/curity/) (FAPI, open banking) | [Compliant CIAM platforms](https://startwithidentity.com/rankings/best-compliant-ciam-platforms/), [healthcare](https://startwithidentity.com/rankings/best-ciam-for-healthcare/), [fintech](https://startwithidentity.com/rankings/best-ciam-for-fintech/) |
| Must self-host or keep data in your own region | [Keycloak](https://startwithidentity.com/vendors/open-source/keycloak/), [FusionAuth](https://startwithidentity.com/vendors/ciam/fusionauth/), [Zitadel](https://startwithidentity.com/vendors/open-source/zitadel/), [Ory](https://startwithidentity.com/vendors/open-source/ory/) | [Top open-source CIAM platforms](https://startwithidentity.com/articles/top-8-open-source-ciam-platforms/) |
| Passwordless first | Stytch, Auth0, Transmit Security, Descope | [Best passwordless CIAM providers](https://startwithidentity.com/rankings/best-passwordless-ciam-providers/) |

## Decision 1: B2C, B2B or both

The two shapes need different features. B2C needs sign-up conversion, social login, [progressive profiling](https://startwithidentity.com/glossary/progressive-profiling/), consent and bot defence at millions of users. B2B needs organizations (tenants), per-customer SAML and OIDC connections, [SCIM](https://startwithidentity.com/standards/scim-2-0/) provisioning, delegated admin and audit logs your customers can see. Platforms that do both well are rarer than their marketing suggests; [B2B vs B2C CIAM](https://startwithidentity.com/articles/b2b-vs-b2c-ciam/) covers the split.

## Decision 2: overlay or full platform

If your product already has working authentication and the only gap is enterprise SSO and SCIM for procurement, an overlay such as WorkOS or [SSOJet](https://startwithidentity.com/vendors/ciam/ssojet/) adds those features without touching what you have. If you are building or replacing authentication itself, evaluate full platforms such as Auth0 or Frontegg. Getting this fork wrong is the most common reason teams re-platform within a year.

## Decision 3: SaaS, self-hosted or library

| Model | You get | You give up | Examples |
|---|---|---|---|
| Managed SaaS | Fastest start, provider runs availability and patching | Data location control, some customization | Auth0, Clerk, Descope, Stytch |
| Self-hosted product | Full control of data and deployment | You run, scale and secure it | Keycloak, FusionAuth, Zitadel |
| Auth library in your code | No vendor, no MAU bill | You own every security fix | [Better Auth](https://startwithidentity.com/vendors/open-source/better-auth/), [Auth.js](https://startwithidentity.com/vendors/open-source/authjs/) |

Ownership changes matter here. Vercel acquired Better Auth on 7 July 2026 (the library stays MIT licensed), and Auth.js joined the Better Auth project in September 2025. Stytch has been part of Twilio since 14 November 2025. Auth0 is part of Okta. Ask any vendor what an acquisition would mean for your contract; see [identity acquisitions](https://startwithidentity.com/acquisitions/).

## Decision 4: compliance and residency

Write down SOC 2, ISO 27001, HIPAA (a signed BAA), PCI DSS and data residency needs, and check each against the exact product and region you will buy. A platform that fits well in general can still fail on one residency constraint. If you will accept government digital ID wallets, check support for [OpenID4VP](https://startwithidentity.com/standards/openid4vc/) (1.0 Final, July 2025), since EU member states must offer [EUDI wallets](https://startwithidentity.com/standards/eidas-2-eudi-wallet/) by the end of 2026.

## Decision 5: price at your real volume

CIAM pricing comes in incompatible shapes, so compare at your 24-month numbers. Free tiers verified on 30 October 2026 in the [Identity Pricing Transparency Index 2026](https://startwithidentity.com/reports/identity-pricing-transparency-index-2026/):

| Platform | Free tier | First paid step |
|---|---|---|
| WorkOS AuthKit | 1,000,000 MAU | SSO and Directory Sync $125 per connection |
| Clerk | 50,000 monthly retained users | Pro $25/month |
| Microsoft Entra External ID | 50,000 MAU | Pay as you go |
| Auth0 | 25,000 MAU | Essentials from $35/month (B2C) or $150/month (B2B) |
| Stytch | 10,000 MAU | Pay as you go; SSO/SCIM $125 per connection beyond 5 |
| Amazon Cognito | 10,000 MAU | Essentials $0.015 per MAU |
| Descope | 7,500 MAU | Pro from $249/month annual |
| [Strivacity](https://startwithidentity.com/vendors/ciam/strivacity/) | None | From $17,000/year |

The median of the 16 MAU-based free tiers is 17,750 MAU. Read each vendor's definition of "active": Clerk counts retained users, Zitadel and Ory count daily actives. For B2B, the per-connection line often outgrows the user line. Model it in the [TCO calculator](https://startwithidentity.com/tools/tco-calculator/) and see [CIAM pricing models explained](https://startwithidentity.com/articles/ciam-pricing-models-explained/).

## Decision 6: the standards you need now and next

Require [OpenID Connect](https://startwithidentity.com/standards/openid-connect/) and [OAuth 2.0](https://startwithidentity.com/standards/oauth-2-0/) with the RFC 9700 security practices, [SAML 2.0](https://startwithidentity.com/standards/saml-2-0/) for enterprise customers, and passkeys on [WebAuthn](https://startwithidentity.com/standards/webauthn-fido2/) Level 3 (W3C Recommendation, 25 August 2026). If AI agents will act on behalf of your users, ask about [MCP authorization](https://startwithidentity.com/standards/mcp-authorization/) (revision 2026-07-28) and [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/), still an IETF draft.

## Decision 7: the failure modes you are buying protection from

- **Credential stuffing.** [23andMe](https://startwithidentity.com/breaches/incidents/2023-23andme-credential-stuffing-dna-relatives/), [Roku](https://startwithidentity.com/breaches/incidents/2024-roku-credential-stuffing/) and [Chick-fil-A](https://startwithidentity.com/breaches/incidents/2026-chick-fil-a-credential-stuffing/) (13,322 loyalty accounts in June 2026) all lost customer accounts to reused passwords. Test bot detection, breached-password checks and passkey enrolment ([credential stuffing](https://startwithidentity.com/techniques/credential-stuffing/), [account takeover prevention](https://startwithidentity.com/articles/ciam-account-takeover-prevention/)).
- **Weak recovery.** Coinbase customers lost funds through an [SMS account recovery flaw](https://startwithidentity.com/breaches/incidents/2021-coinbase-sms-recovery-flaw/). Check what recovery requires once passwords are gone.
- **Unauthenticated APIs.** Attackers enumerated about 33 million phone numbers tied to Authy accounts through an [unauthenticated endpoint](https://startwithidentity.com/breaches/incidents/2024-twilio-authy-unauthenticated-endpoint/). Ask how the vendor protects its own lookup and sign-up APIs.
- **The provider's support systems.** Okta's 2023 [support system breach](https://startwithidentity.com/breaches/incidents/2023-okta-support-system-har-session-tokens/) exposed customer session tokens in uploaded HAR files ([session cookie theft](https://startwithidentity.com/techniques/session-cookie-theft/)).

## Shortlist, pilot, decide

Narrow with the [vendor selector](https://startwithidentity.com/tools/vendor-selector/) and [capability checker](https://startwithidentity.com/tools/capability-checker/), then pilot the top two against a real enterprise customer's identity provider and a slice of real consumer traffic. As a practitioner estimate, budget two to four weeks per pilot. Before signing, confirm you can export users and password hashes; the [CIAM migration guide](https://startwithidentity.com/articles/ciam-migration-guide/) shows what leaving costs. Head-to-heads worth reading: [Auth0 vs Clerk](https://startwithidentity.com/compare/auth0-vs-clerk/), [Auth0 vs Stytch](https://startwithidentity.com/compare/auth0-vs-stytch/), [Descope vs WorkOS](https://startwithidentity.com/compare/descope-vs-workos/), [WorkOS vs Frontegg](https://startwithidentity.com/compare/workos-vs-frontegg/) and [FusionAuth vs Keycloak](https://startwithidentity.com/compare/fusionauth-vs-keycloak/). Browse all [CIAM platforms](https://startwithidentity.com/vendors/ciam/), the [best CIAM for enterprises](https://startwithidentity.com/rankings/best-ciam-for-enterprises/) and [best SSO and SCIM platforms for B2B SaaS](https://startwithidentity.com/rankings/best-sso-scim-platforms-b2b-saas/).

## How to Choose a Decentralized Identity Platform
Source: https://startwithidentity.com/guides/decentralized-identity/choosing-a-decentralized-identity-platform/
Last updated: 2026-11-05

A **decentralized identity platform** is the software that lets an organization issue, verify, or hold [verifiable credentials](https://startwithidentity.com/standards/verifiable-credentials/): signed, tamper-evident claims a person keeps in a wallet and presents without the verifier calling the issuer. To choose one in 2026, decide your role first (issuer, verifier, or wallet), then require the 1.0 Final [OpenID4VC](https://startwithidentity.com/standards/openid4vc/) specifications as profiled by HAIP, support for the formats your verifiers actually accept, and proof of interoperability with someone else's wallet. Brand and roadmap come last.

This buyer guide is for architects and product owners shortlisting vendors. If you are still deciding whether you need one, start with [decentralized identity explained](https://startwithidentity.com/guides/decentralized-identity/decentralized-identity-explained/).

## Decision table: start from your use case

The single biggest filter is what you are trying to do. Use this before you look at any vendor.

| Your role | What you need most | Formats to require | Where to look first |
| --- | --- | --- | --- |
| Verifier only (accept credentials others issue) | Verification SDK, [OpenID4VP](https://startwithidentity.com/glossary/openid4vp/) 1.0, broad wallet compatibility | SD-JWT VC and ISO mdoc | Acceptance APIs and verifier SDKs |
| Issuer (make your data portable) | Signing and key custody, schemas, [revocation](https://startwithidentity.com/glossary/revocation-registry/), [OpenID4VCI](https://startwithidentity.com/glossary/openid4vci/) 1.0 | Whatever your verifiers accept | Managed issuance platforms |
| EU or government interoperability | HAIP 1.0 conformance, ARF alignment, X.509 trust | SD-JWT VC and mdoc, per the [EUDI Wallet](https://startwithidentity.com/standards/eidas-2-eudi-wallet/) ARF | Public-sector and EUDI-aligned stacks |
| Driver's license and age checks | mdoc presentation in person and online | ISO mdoc ([mDL](https://startwithidentity.com/standards/iso-18013-5-mdl/)) | Verifiers with ISO 18013-7 and Digital Credentials API support |
| Private ecosystem or consortium | Governance tooling, [trust registry](https://startwithidentity.com/glossary/trust-registry/), privacy | Often W3C VC; [AnonCreds](https://startwithidentity.com/glossary/anoncreds/) in Indy networks | Ecosystem-building vendors |
| Microsoft-centric workforce use | Low friction inside an existing tenant | JWT-VC | Your IAM vendor's built-in service |

Most enterprises start as a verifier: it is the lowest lift and does not require issuance infrastructure.

## The 2026 standards check

Version numbers decide interoperability, so ask for them explicitly. Status as of 5 November 2026:

- **OpenID4VP 1.0 and OpenID4VCI 1.0 are Final**, and the [High Assurance Interoperability Profile (HAIP) 1.0](https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-1_0-final.html) was published as Final on 24 December 2025 ([OpenID Foundation specifications](https://openid.net/wg/digital-credentials-protocols/specifications/)). HAIP requires SD-JWT VC or ISO mdoc, ES256, PKCE, PAR and DPoP for issuance, wallet attestation, DCQL queries, signed requests with the `x509_hash` client identifier, and Token Status List for SD-JWT VC.
- **W3C VC Data Model 2.0** became a [W3C Recommendation](https://www.w3.org/TR/vc-data-model-2.0/) on 15 May 2025, alongside [Bitstring Status List v1.0](https://www.w3.org/TR/vc-bitstring-status-list/).
- **SD-JWT** is [RFC 9901](https://www.rfc-editor.org/info/rfc9901), but **SD-JWT VC** is still an Internet-Draft: [draft-24](https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/), in IESG evaluation with a DISCUSS open. HAIP pins draft-13, so "supports SD-JWT VC" needs a draft number.
- **[DIDs](https://startwithidentity.com/standards/decentralized-identifiers-did/)**: DID Core 1.0 is a Recommendation; DID 1.1 is a Candidate Recommendation.

A vendor's own standards page is the fastest test. [Microsoft Entra Verified ID](https://startwithidentity.com/vendors/decentralized-identity/microsoft-entra-verified-id/), for example, [lists](https://learn.microsoft.com/en-us/entra/verified-id/verifiable-credentials-standards) VC Data Model v1.1, JWT-VC, did:web as the only entity identifier, OpenID4VCI draft 11, and DIF Presentation Exchange v2.0.0. That is a working stack inside Microsoft's ecosystem, but it is not the HAIP profile. By contrast, [walt.id](https://startwithidentity.com/vendors/decentralized-identity/walt-id/) [lists](https://docs.walt.id/feature-list) OID4VCI 1.0, OID4VP 1.0, SD-JWT VC and ISO mdoc.

## The capabilities that matter

Evaluate every shortlisted vendor against these:

- **Standards support:** genuine W3C VC, SD-JWT VC, mdoc and OpenID4VC 1.0, not a proprietary format wrapped in the vocabulary.
- **Wallet strategy:** does it provide a wallet, integrate third-party wallets, or both? Who owns the holder relationship?
- **Revocation and status:** Token Status List or Bitstring Status List, with caching guidance. Bitstring Status List requires lists of at least 16KB uncompressed so a status check hides in a crowd.
- **Issuer trust:** X.509 trusted lists (the EU model), a trust registry, or manual allowlists that will not scale.
- **Privacy:** [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/) at minimum, batch issuance to limit correlation, and [BBS signatures](https://startwithidentity.com/glossary/bbs-signature/) or [ZKPs](https://startwithidentity.com/glossary/zero-knowledge-proof/) if unlinkability matters. The W3C BBS cryptosuite is still a Candidate Recommendation.
- **Key custody:** HSM-backed issuer keys, rotation, and a recovery runbook.
- **Interoperability evidence:** conformance results, HAIP alignment, EU large-scale pilot participation.

## Failure modes to test for

Decentralized identity moves the weak points, it does not remove them. Use real incidents to shape your evaluation:

- **Issuer signing key compromise.** In [Storm-0558](https://startwithidentity.com/breaches/incidents/2023-storm-0558-microsoft-signing-key-forgery/), an acquired Microsoft signing key let an actor forge tokens that a validation flaw then accepted. A stolen issuer key forges credentials the same way. Ask where keys live and how fast a vendor can rotate and revoke.
- **Verifiers that do not validate signatures properly.** [SimpleHelp's OIDC token forgery](https://startwithidentity.com/breaches/incidents/2026-simplehelp-oidc-token-forgery/) ([CVE-2026-48558](https://startwithidentity.com/cves/cve-2026-48558/)) came from signatures that were not properly validated. Test that a verifier rejects tampered, expired, and wrong-issuer presentations.
- **Replay without holder binding.** A copied credential accepted on its issuer signature alone is the credential version of [token replay against unbound endpoints](https://startwithidentity.com/techniques/token-replay-unbound-endpoint/). Require key binding checks against your nonce.
- **Cross-device relay.** A QR code can be relayed from an attacker's session to a victim, the same pattern as an [AitM phishing proxy](https://startwithidentity.com/techniques/aitm-phishing-proxy/). HAIP's same-device rules and signed verifier requests are the defense.
- **Document archives as honeypots.** [DigiCert disclosed](https://startwithidentity.com/breaches/incidents/2026-digicert-self-registered-account-archive-access/) in October 2026 that a system archiving customer identity-validation documents was reachable and accessible through self-registered accounts. Platforms that store copies of source documents recreate the problem credentials are meant to solve.

## Questions that separate substance from marketing

1. "Which credential formats, draft numbers and DID methods do you support in production, not on a roadmap?"
2. "Show me an interop test result against another vendor's wallet or verifier, and your HAIP result."
3. "How does revocation work, and what does a verifier do offline or with a stale list?"
4. "Where are issuer keys held, and what is the rotation and compromise procedure?"
5. "If we leave, what happens to issued credentials and the holder wallets?"
6. "Which eIDAS ARF version are you aligned to?" (v3.0.0 was released 23 July 2026; see the [eIDAS 2 page](https://startwithidentity.com/standards/eidas-2-eudi-wallet/).)
7. "Who owns the company and the product line today?"

The last question matters in a consolidating market. [Trinsic](https://startwithidentity.com/vendors/decentralized-identity/trinsic/) [sold its decentralized identity platform, Trinsic Ecosystems, to Dentity](https://www.trinsic.id/blog/trinsic-decentralized-identity-assets-acquired-by-dentity-to-accelerate-digital-id-adoption) on 12 December 2024 and now focuses on its Identity Acceptance Network, so buyers searching for Trinsic's decentralized identity products now need to evaluate [Dentity](https://startwithidentity.com/vendors/decentralized-identity/dentity/) for issuance and Trinsic for acceptance.

## Buy vs build

Buy a platform when you need production issuance or verification quickly, want managed wallets and revocation, or must interoperate with government wallets. Build on open libraries (walt.id and [SpruceID](https://startwithidentity.com/vendors/decentralized-identity/spruce-id/) both publish them, and [Procivis](https://startwithidentity.com/vendors/decentralized-identity/procivis/) offers an open-source edition) when your scope is narrow and you can own key management and upgrades. As a planning estimate, not a measured figure, budget for at least one format or draft upgrade per year while SD-JWT VC and DID 1.1 are still moving.

## The vendor landscape

The [decentralized identity vendor directory](https://startwithidentity.com/vendors/decentralized-identity/) profiles the active platforms, including [MATTR](https://startwithidentity.com/vendors/decentralized-identity/mattr/), [Dock](https://startwithidentity.com/vendors/decentralized-identity/dock/), [Indicio](https://startwithidentity.com/vendors/decentralized-identity/indicio/), [Gataca](https://startwithidentity.com/vendors/decentralized-identity/gataca/) and [Affinidi](https://startwithidentity.com/vendors/decentralized-identity/affinidi/). [Best decentralized identity platforms](https://startwithidentity.com/rankings/best-decentralized-identity-platforms/) and [best decentralized identity for enterprises](https://startwithidentity.com/rankings/best-decentralized-identity-for-enterprises/) rank them. Shortlist three to five by role, then run the questions above against each.

## Where to go next

Build details: [verifiable credentials implementation guide](https://startwithidentity.com/guides/decentralized-identity/verifiable-credentials-implementation-guide/). Architecture: [DID methods compared](https://startwithidentity.com/guides/decentralized-identity/did-methods-compared/). KYC angle: [reusable identity and KYC](https://startwithidentity.com/guides/decentralized-identity/reusable-identity-and-kyc-with-verifiable-credentials/).

## How to Choose a PAM Solution in 2026: A Buyer's Checklist
Source: https://startwithidentity.com/guides/buyer-guides/how-to-choose-a-pam-solution/
Last updated: 2026-11-05

To choose a PAM solution, count your standing privileged access first, decide whether you need vault-first PAM or infrastructure access, then test ownership, patch record, pricing and the real access path in a pilot. [Privileged access management](https://startwithidentity.com/guides/fundamentals/what-is-pam/) protects your highest-risk accounts, so the selection bar is high. This checklist was last checked against vendor profiles on November 5, 2026.

## Shortlist by situation (November 2026)

| Your situation | Start with | Ranking to read |
|---|---|---|
| Large regulated enterprise, auditors expect a vault | [Idira (formerly CyberArk)](https://startwithidentity.com/vendors/pam/cyberark/), [Delinea](https://startwithidentity.com/vendors/pam/delinea/), [BeyondTrust](https://startwithidentity.com/vendors/pam/beyondtrust/) | [Best PAM for enterprises](https://startwithidentity.com/rankings/best-pam-for-enterprises/) |
| FedRAMP or audit evidence is the gate | Delinea (Secret Server FedRAMP High), BeyondTrust (Moderate) | [Compliant PAM platforms](https://startwithidentity.com/rankings/best-compliant-pam-platforms/) |
| Engineers reaching servers, Kubernetes, databases | [Teleport](https://startwithidentity.com/vendors/pam/teleport/), [StrongDM](https://startwithidentity.com/vendors/pam/strongdm/), [HashiCorp Boundary](https://startwithidentity.com/vendors/pam/hashicorp-boundary/) | [Best PAM tools for DevOps](https://startwithidentity.com/rankings/best-pam-for-devops/) |
| Removing standing cloud permissions | [Apono](https://startwithidentity.com/vendors/pam/apono/), [Britive](https://startwithidentity.com/vendors/ciem/britive/) | [Best just-in-time access tools](https://startwithidentity.com/articles/top-5-just-in-time-access-tools/) |
| Small team, needs a visible price | [Keeper Security](https://startwithidentity.com/vendors/pam/keeper-security/), [ManageEngine PAM360](https://startwithidentity.com/vendors/pam/manageengine-pam360/) | [Best PAM for small business](https://startwithidentity.com/rankings/best-pam-for-smb/) |
| Replacing an incumbent | Depends on the half you need | [CyberArk alternatives](https://startwithidentity.com/articles/cyberark-alternatives/), [StrongDM alternatives](https://startwithidentity.com/articles/strongdm-alternatives/) |

For the whole field, see the [best PAM tools](https://startwithidentity.com/rankings/best-pam-tools/) and the [top 10 PAM solutions in 2026](https://startwithidentity.com/articles/top-10-pam-solutions-2026/).

## 1. Inventory privileged access

List your privileged account types: domain and cloud admins, service accounts, [non-human identities](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/), database and network gear. The mix drives which PAM strengths matter.

## 2. Decide your priorities

- **Vaulting and rotation** for credentials.
- **Session recording and isolation** for compliance and forensics.
- **Just-in-time / zero standing privileges** to shrink the attack surface.
- **Secrets for apps and CI/CD**, which overlaps with [secrets management](https://startwithidentity.com/vendors/secrets/).
- **Discovery** of unmanaged privileged accounts.

Then decide which half of the category you are buying. Vault-first suites assume privileged accounts exist and must be controlled and recorded. Infrastructure-access tools issue short-lived certificates so standing credentials never exist. Auditors recognise the first; engineers adopt the second. Many estates need both, but buy for the immediate problem.

## 3. Weigh deployment and operations

PAM can be operationally heavy. Confirm SaaS vs self-hosted fit, agent requirements, and how much day-two effort the platform demands. Model cost with the [TCO calculator](https://startwithidentity.com/tools/tco-calculator/).

## 4. Check ownership and the 2026 changes

PAM is a multi-year commitment, so ask who will own the vendor during your term. Palo Alto Networks closed its CyberArk acquisition on 11 February 2026 and rebranded it Idira on 12 May, which ends the vendor-neutrality argument and leaves its FedRAMP High status under the new brand unconfirmed. Delinea closed its StrongDM purchase on 5 March 2026, and 1Password bought Apono in June. Check standalone-sales commitments and renewal terms in writing; our [acquisitions tracker](https://startwithidentity.com/acquisitions/) lists the deals.

Check free tiers too. Teleport Community Edition is free only for companies under 100 employees and 10 million dollars in revenue, per its [license terms](https://goteleport.com/blog/teleport-community-license), so a pilot on Community Edition may not reflect what you can run in production.

## 5. Get a real price

PAM scores 16 out of 100 in our [Identity Pricing Transparency Index](https://startwithidentity.com/reports/identity-pricing-transparency-index-2026/): 13 of 19 PAM vendors are quote-only. Send every vendor the same scope sheet (privileged users, vaulted accounts, servers and endpoints, recorded sessions, remote vendor access, SaaS or self-hosted) using the [RFP builder](https://startwithidentity.com/tools/rfp-builder/), and use ManageEngine PAM360's [published editions](https://www.manageengine.com/privileged-access-management/pricing.html), from 7,995 dollars a year for 10 administrators and 25 keys, as an anchor.

## 6. Shortlist and verify

Compare scores in the [capability checker](https://startwithidentity.com/tools/capability-checker/), then validate session and break-glass workflows in a pilot. Ask for the patch record of any remote-access gateway in the deal: the [Identity Vulnerability Report 2026](https://startwithidentity.com/reports/identity-vulnerability-report-2026/) found that edge and remote-access tools are 23% of cataloged identity CVEs but 66% of the exploited ones. The 2026 example is [CVE-2026-102764](https://startwithidentity.com/cves/cve-2026-102764/), a zero-day in self-hosted BeyondTrust Remote Support exploited from 29 August to export the appliance credential vault; Delinea also disclosed four critical on-premises Secret Server flaws in September, with cloud tenants unaffected.

## 7. Count standing privilege before you buy

The most useful number in a PAM evaluation is how many identities hold permanent elevated rights today. It tells you the size of the deployment, and more usefully it tells you how much of the problem you could remove instead of vaulting. A programme that eliminates 300 of 400 permanent admin accounts through [just-in-time access](https://startwithidentity.com/glossary/jit-access/) needs a smaller product and produces a better outcome than one that vaults all 400.

## 8. Adoption beats features

PAM tools fail on use, not on capability. If checking out a credential takes ten minutes and the incident is live, engineers keep a personal admin account and your reporting shows compliance that does not exist.

Test the actual path in the pilot: how long from "I need to fix production" to "I am on the box", with approval, on a phone, at 2am. Then measure the percentage of privileged sessions that go through the tool, because that number is your real coverage.

## 9. Scope non-human privilege explicitly

The privileged accounts causing incidents are increasingly not people: [service accounts](https://startwithidentity.com/glossary/service-account/) with domain rights, CI runners holding cloud credentials, and management platforms with agents on every endpoint. The August 2026 N-able N-central compromise turned an authentication bypass on a monitoring platform into access across every managed customer network.

Ask each vendor how they discover, own, rotate, and review non-human privileged credentials, and where the boundary sits against [secrets management](https://startwithidentity.com/guides/fundamentals/what-is-secrets-management/).

## 10. Test break-glass in the pilot

Every deployment has an emergency account excluded from conditional access, and it fails in one of two ways: untested, so it does not work during the outage it exists for, or unmonitored, so it becomes a standing backdoor. Confirm the vendor supports split credentials, immediate alerting on use, and a rehearsal process. See [break-glass](https://startwithidentity.com/glossary/break-glass/).

## Where to start

Browse [PAM vendors](https://startwithidentity.com/vendors/pam/) and [CyberArk vs Delinea](https://startwithidentity.com/compare/cyberark-vs-delinea/), [CyberArk vs BeyondTrust](https://startwithidentity.com/compare/cyberark-vs-beyondtrust/) or [Teleport vs StrongDM](https://startwithidentity.com/compare/teleport-vs-strongdm/). Vendor capability scores follow our [methodology](https://startwithidentity.com/methodology/).

## How to Choose an IAM Platform in 2026: A Buyer's Checklist
Source: https://startwithidentity.com/guides/buyer-guides/how-to-choose-an-iam-platform/
Last updated: 2026-11-05

To choose an IAM platform, map your users, applications and their protocols first, then score candidates on lifecycle depth, admin security and honest three-year cost, and pilot the top two against your hardest applications. A workforce [IAM](https://startwithidentity.com/guides/fundamentals/what-is-iam/) platform runs sign-in, SSO, MFA and provisioning for employees and contractors, and it is a multi-year commitment, so the expensive mistakes are made before the demo, not after it.

This checklist is for IT and security teams buying or replacing workforce identity. For customer identity, use the [CIAM buyer guide](https://startwithidentity.com/guides/buyer-guides/how-to-choose-a-ciam-platform/) instead; the products and the pricing units differ.

## Shortlist by situation (November 2026)

| Your situation | Start with | Ranking to read |
|---|---|---|
| Microsoft 365 shop, Windows endpoints | Microsoft Entra ID at P1 or P2 | [Best IAM for enterprises](https://startwithidentity.com/rankings/best-iam-for-enterprises/) |
| Mixed SaaS estate, wants neutral integration catalog | Okta Workforce Identity | [IAM platforms compared](https://startwithidentity.com/rankings/best-iam-platforms/) |
| Complex federation, hybrid or self-hosted needs | Ping Identity (including ForgeRock) | [Best IAM for enterprises](https://startwithidentity.com/rankings/best-iam-for-enterprises/) |
| Small business, needs directory plus devices | JumpCloud, OneLogin, miniOrange | [Best IAM for small business](https://startwithidentity.com/rankings/best-iam-for-smb/) |
| AWS-only access for engineers | AWS IAM Identity Center federated to your main IdP | [Multi-cloud IAM strategy](https://startwithidentity.com/guides/implementation/multi-cloud-iam-strategy-guide/) |
| Full control, open source | Keycloak, Zitadel | [Top 10 open source IAM](https://startwithidentity.com/articles/top-10-open-source-iam-solutions/) |

Vendor profiles: [Okta](https://startwithidentity.com/vendors/iam/okta/), [Microsoft Entra](https://startwithidentity.com/vendors/iam/microsoft-entra/), [Ping Identity](https://startwithidentity.com/vendors/iam/ping-identity/), [ForgeRock](https://startwithidentity.com/vendors/iam/forgerock/), [JumpCloud](https://startwithidentity.com/vendors/iam/jumpcloud/), [OneLogin](https://startwithidentity.com/vendors/iam/onelogin/), [miniOrange](https://startwithidentity.com/vendors/iam/miniorange/), [IBM Verify](https://startwithidentity.com/vendors/iam/ibm-verify/), [AWS IAM Identity Center](https://startwithidentity.com/vendors/iam/aws-iam-identity-center/), [Keycloak](https://startwithidentity.com/vendors/open-source/keycloak/) and [Zitadel](https://startwithidentity.com/vendors/open-source/zitadel/). The [top 10 enterprise IAM platforms in 2026](https://startwithidentity.com/articles/top-10-enterprise-iam-platforms-2026/) and the [workforce identity platform](https://startwithidentity.com/articles/top-6-workforce-identity-platforms/) comparison cover the field.

## 1. Map your requirements first

Before demos, write down: number of employees and contractors, your apps and how each authenticates ([SAML](https://startwithidentity.com/standards/saml-2-0/), [OIDC](https://startwithidentity.com/guides/fundamentals/saml-vs-oidc/), LDAP, header-based or local passwords), your HR system of record, on-premises versus cloud needs, and your compliance obligations. Expect SAML to dominate the list: in SWI's [Phishing-Resistant MFA Support Matrix](https://startwithidentity.com/reports/phishing-resistant-mfa-matrix-2026/), 83 of 95 business SaaS apps offered SAML and 30 offered OpenID Connect. The legacy protocols decide how much bridging, and which vendor, you need.

## 2. Score the capabilities that matter to you

Use our published [10-dimension methodology](https://startwithidentity.com/methodology/) as a checklist: authentication and [MFA](https://startwithidentity.com/vendors/mfa/), SSO and federation, lifecycle and SCIM provisioning, [authorization](https://startwithidentity.com/guides/fundamentals/rbac-vs-abac-vs-rebac/), governance and audit, developer experience, deployment flexibility, pricing transparency, and support. Weight them for your context, then compare candidates in the [capability checker](https://startwithidentity.com/tools/capability-checker/) and narrow with the [vendor selector](https://startwithidentity.com/tools/vendor-selector/).

Standards support to require in 2026: [WebAuthn](https://startwithidentity.com/standards/webauthn-fido2/) for passkeys (Level 3 became a W3C Recommendation on August 25, 2026), [SCIM 2.0](https://startwithidentity.com/standards/scim-2-0/) both inbound from HR and outbound to apps, and the [Shared Signals Framework](https://startwithidentity.com/standards/shared-signals-framework/) (SSF, CAEP and RISC reached Final on August 29, 2025) so session revocations reach downstream apps.

## 3. Price the comparison honestly

Most workforce IAM evaluations are decided on cost, and most cost comparisons are unfair. Only 25% of the 20 IAM platform vendors in the [Identity Pricing Transparency Index 2026](https://startwithidentity.com/reports/identity-pricing-transparency-index-2026/) publish a paid price, and 65% are quote-only. The published anchors, read on October 30, 2026:

| Platform | Published price | Watch for |
|---|---|---|
| Okta Workforce | Starter $6, Essentials $17 per user per month | $1,500 annual minimum; Professional and Enterprise are quoted |
| Microsoft Entra ID | P1 $7, P2 $10, Entra Suite $12, ID Governance $7 per user per month, paid yearly | Conditional access needs P1; risk policies and access reviews need P2 or Governance |
| JumpCloud | SSO $11 per user per month billed annually | Platform suites quoted; no permanent free tier |
| AWS IAM Identity Center | No extra charge | Cost sits in the IdP you federate to it |
| Ping, IBM Verify, ForgeRock | Quote-only | Budget professional services for federation work |

Comparing bundled-base Entra against a full Okta quote is not a comparison. Price Entra at P1 or P2 across the whole workforce against a competitor's realistic bundle including lifecycle management, add a separate MDM where the platform lacks one, and add the [SSO tax](https://startwithidentity.com/glossary/sso-tax/) your SaaS vendors charge to enable federation. Model three years with the [TCO calculator](https://startwithidentity.com/tools/tco-calculator/) and see [Okta vs Microsoft Entra](https://startwithidentity.com/compare/okta-vs-microsoft-entra/).

## 4. Test lifecycle against your worst applications

Single sign-on demos well everywhere. [Provisioning](https://startwithidentity.com/glossary/provisioning/) is where platforms differ, and the difference only appears against the applications that do not have a clean SCIM endpoint. Name your five hardest targets and ask each vendor to connect to them during the pilot.

Test the mover case specifically, not just joiner and leaver. Internal transfers that add access without removing the old role ([mover entitlement accumulation](https://startwithidentity.com/techniques/mover-entitlement-accumulation/)) are the most common audit finding in workforce identity, and they are the case most demos skip. Then test the leaver: the [Colonial Pipeline](https://startwithidentity.com/breaches/incidents/2021-colonial-pipeline-legacy-vpn/) intrusion began on a legacy VPN account that should not have existed ([orphaned account abuse](https://startwithidentity.com/techniques/orphaned-account-abuse/)).

## 5. Test the admin and recovery paths

The incidents that hit IAM customers mostly come through the tenant, not the vendor's code:

- **Help desk resets of admin MFA.** In 2023 attackers called service desks to reset Okta super administrator factors at [several customers](https://startwithidentity.com/breaches/incidents/2023-okta-customer-help-desk-super-admin-takeover/) ([help desk social engineering](https://startwithidentity.com/techniques/help-desk-social-engineering/)). Ask how the platform restricts who can reset admin factors and alerts on it.
- **Forgotten tenants and over-privileged apps.** [Midnight Blizzard](https://startwithidentity.com/breaches/incidents/2024-microsoft-midnight-blizzard-password-spray/) sprayed a non-production Microsoft tenant account without MFA, then used a legacy OAuth app with elevated access ([teardown](https://startwithidentity.com/breaches/midnight-blizzard-2024-microsoft/)).
- **Accounts without MFA on remote access.** [Change Healthcare](https://startwithidentity.com/breaches/incidents/2024-change-healthcare-citrix-no-mfa/) was reached through a Citrix portal with no MFA. Require proof that every federated path enforces MFA, and compare factors in the [MFA matrix](https://startwithidentity.com/tools/mfa-matrix/).
- **Provider-side support systems.** The [2023 Okta support system breach](https://startwithidentity.com/breaches/incidents/2023-okta-support-system-har-session-tokens/) took session tokens from customer-uploaded HAR files ([teardown](https://startwithidentity.com/breaches/okta-2023-support-system-breach/)).

## 6. Ask where non-human identities live

[Service accounts](https://startwithidentity.com/glossary/service-account/), workloads, and AI agents outnumber employees in most environments. Ask how the platform handles ownership, expiry, and review for them, and whether agent identities get short-lived tokens rather than static API keys. On November 3, 2026 Todyl reported an actor [signing in to Entra ID as applications with stolen client secrets](https://startwithidentity.com/breaches/incidents/2026-entra-id-stolen-app-secrets-27-orgs/) and reaching 27 organizations. A secret is the app, with no MFA step to fail, so ask whether the platform supports [workload identity federation](https://startwithidentity.com/glossary/workload-identity-federation/) instead.

## 7. Check ownership before a multi-year term

Consolidation reshaped the field in 2025 and 2026. Per SWI's [acquisitions data](https://startwithidentity.com/acquisitions/) and vendor profiles:

- Palo Alto Networks closed its acquisition of CyberArk on February 11, 2026 and rebranded it [Idira (formerly CyberArk)](https://startwithidentity.com/vendors/pam/cyberark/) on May 12, 2026.
- Okta closed its purchase of [Permiso Security](https://startwithidentity.com/vendors/ai-identity/permiso-security/) on August 26, 2026 for ITDR, after Axiom Security in 2025.
- Ping Identity added Procyon (now PingOne Privilege) in 2025 and announced the Keyless acquisition on October 30, 2025.
- OneLogin's parent One Identity announced a separation from Quest Software in June 2026, not yet confirmed closed.
- Rubrik acquired identity orchestration vendor Strata Identity on June 9, 2026.

Ask every vendor whether standalone sales and the current packaging continue for your term, and put a renewal cap in writing. The [Identity Consolidation Report 2026](https://startwithidentity.com/reports/identity-consolidation-report-2026/) tracks the rest.

## 8. Plan the exit before you sign

A multi-year identity commitment deserves a documented answer to: can we export users, group memberships, and application assignments; what happens to enrolled MFA factors and passkeys if we migrate; and does the platform speak standard [OIDC](https://startwithidentity.com/standards/openid-connect/) and SAML rather than proprietary extensions. Passkeys in particular are bound to a relying party identifier, so decide that domain early. Keep [break-glass accounts](https://startwithidentity.com/glossary/break-glass/) outside the platform and test the [identity disaster recovery](https://startwithidentity.com/guides/implementation/iam-disaster-recovery-guide/) plan before go-live.

## Where to start

Browse [IAM platforms](https://startwithidentity.com/vendors/iam/), read [Okta vs Ping Identity](https://startwithidentity.com/compare/okta-vs-ping-identity/), [Okta vs JumpCloud](https://startwithidentity.com/compare/okta-vs-jumpcloud/) and [Microsoft Entra vs Ping Identity](https://startwithidentity.com/compare/microsoft-entra-vs-ping-identity/), and send every finalist the same scope with the [RFP builder](https://startwithidentity.com/tools/rfp-builder/).

## How to Choose an IGA Platform in 2026
Source: https://startwithidentity.com/guides/buyer-guides/how-to-choose-an-iga-platform/
Last updated: 2026-11-05

To choose an IGA platform, decide which governance outcomes you need, prove connectors against your worst applications, check 2026 ownership and get a comparable quote, then pilot a certification campaign that actually revokes access. [Identity governance and administration (IGA)](https://startwithidentity.com/guides/fundamentals/what-is-iga/) projects succeed or fail on fit, connectors and identity data quality far more than on feature lists.

## Shortlist by situation (November 2026)

| Your situation | Start with | Read next |
|---|---|---|
| Large regulated enterprise, SOX and complex ERP | [SailPoint](https://startwithidentity.com/vendors/iga/sailpoint/), [Saviynt](https://startwithidentity.com/vendors/iga/saviynt/) | [SailPoint vs Saviynt](https://startwithidentity.com/compare/sailpoint-vs-saviynt/) |
| EU data residency, faster standard rollout | [Omada](https://startwithidentity.com/vendors/iga/omada/) | [Omada vs Saviynt](https://startwithidentity.com/compare/omada-vs-saviynt/) |
| Microsoft and Active Directory heavy | [One Identity](https://startwithidentity.com/vendors/iga/one-identity/), Microsoft Entra ID Governance | [One Identity alternatives](https://startwithidentity.com/articles/one-identity-alternatives/) |
| SaaS-first company, wants reviews live in weeks | [C1](https://startwithidentity.com/vendors/iga/conductorone/), [Lumos](https://startwithidentity.com/vendors/iga/lumos/), [Zluri](https://startwithidentity.com/vendors/iga/zluri/) | [C1 vs Lumos](https://startwithidentity.com/compare/conductorone-vs-lumos/), [Zluri vs Lumos](https://startwithidentity.com/compare/zluri-vs-lumos/) |
| Need effective permissions across cloud and data | [Veza](https://startwithidentity.com/vendors/iga/veza/) | [Veza vs SailPoint](https://startwithidentity.com/compare/veza-vs-sailpoint/) |
| Already standardized on Idira (formerly CyberArk) | [Zilla Security](https://startwithidentity.com/vendors/iga/zilla-security/) | [Best IGA tools](https://startwithidentity.com/rankings/best-iga-tools/) |
| Budget or sovereignty requires self-hosting | [midPoint by Evolveum](https://startwithidentity.com/vendors/iga/evolveum/), [Soffid](https://startwithidentity.com/vendors/iga/soffid/) | [Top open source IGA tools](https://startwithidentity.com/articles/top-5-open-source-iga-tools/) |

For scored comparisons, see the [best IGA tools](https://startwithidentity.com/rankings/best-iga-tools/) and [compliant IGA platforms](https://startwithidentity.com/rankings/best-compliant-iga-platforms/) rankings. Replacing an incumbent? Start with [SailPoint alternatives](https://startwithidentity.com/articles/sailpoint-alternatives/).

## 1. Define the outcomes you need

Access reviews and certifications, automated provisioning, separation of duties, role management, or all of the above? A company that only needs quarterly SOC 2 access reviews for 40 SaaS apps is buying a different product from a bank that needs SoD inside SAP. Compliance-driven buyers should map requirements to frameworks first; see the [audit preparation guide](https://startwithidentity.com/guides/compliance/iam-audit-preparation-guide/).

## 2. Check connector coverage on your five worst applications

IGA lives or dies on integrations. Every platform demos well against Active Directory and a well-behaved SaaS app. Ask each vendor to connect, during the proof of concept, to your five hardest systems: the mainframe, the ERP with no modern API, the homegrown application whose owner left, the SaaS tool with a proprietary permission model, and the cloud account with role chaining. Record for each whether the connection is a maintained connector, a [SCIM](https://startwithidentity.com/guides/fundamentals/what-is-scim/) integration, a flat-file feed or custom code you will own.

## 3. Check who owns the vendor

Governance is where identity platforms keep buying point tools. As of November 5, 2026: Veza belongs to ServiceNow (closed 2 March 2026); Workday agreed on 13 October 2026 to acquire C1, expected to close by 31 January 2027; Zilla is part of Palo Alto Networks' Idira portfolio; Omada acquired EmpowerID on 24 September 2026; Infotech acquired Zluri on 14 October 2026; One Identity announced in June 2026 that it will become independent. Ask each vendor in writing whether standalone sales and your connectors are committed for your full term. The [Identity Consolidation Report 2026](https://startwithidentity.com/reports/identity-consolidation-report-2026/) tracks the pattern.

## 4. Get a quote you can compare

In the [Identity Pricing Transparency Index 2026](https://startwithidentity.com/reports/identity-pricing-transparency-index-2026/), IGA scored 5 out of 100: none of 20 vendors published a paid price. SailPoint, Saviynt, Lumos, Veza and C1 all sent SWI to sales on October 30, 2026. Send every vendor the same scope sheet: identity counts by type (employees, contractors, service accounts), the target app list and connector type for each, and modules in year one versus later. The one public anchor is Microsoft Entra ID Governance at 7 dollars per user per month paid yearly. Model three years including implementation services in the [TCO calculator](https://startwithidentity.com/tools/tco-calculator/), and use the [RFP builder](https://startwithidentity.com/tools/rfp-builder/).

## 5. Budget for identity data quality

The reason IGA implementations run long is almost never the product. The HR system, the directory and the applications disagree about who exists, which accounts belong to whom, and what an entitlement means. Ask: what percentage of accounts in your target systems can be matched to an authoritative identity today? If you do not know, that is your first work item, and it is independent of vendor selection.

## 6. Design certification so it produces revocations

A campaign that shows reviewers raw entitlement names produces approvals. `APP_FIN_GL_RW_PROD` means nothing to a manager, so they approve everything. Campaigns that produce real revocations translate entitlements into business language, show usage data alongside the grant ("not used in 180 days"), and make revocation the low-effort default. Ask each vendor to demonstrate all three. See [access certification](https://startwithidentity.com/glossary/access-certification/) and [access review best practices](https://startwithidentity.com/articles/access-review-certification-best-practices/).

## 7. Test movers and leavers, not just joiners

Joiners are easy to demo. Ask the vendor to show a transfer from finance to sales removing the finance grants, and a termination that disables every account and revokes active sessions and tokens, not just the directory account. Watch the timing.

## 8. Ask about non-human identities and AI agents

[Service accounts](https://startwithidentity.com/glossary/service-account/) and workloads outnumber employees in most environments and appear in almost no campaign, because they have no manager to attest for them. Ask how each platform assigns owners, reviews machine access and handles AI agents. SailPoint closed its Entro Security acquisition on 29 June 2026 for this reason. See [what is non-human identity](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/).

## 9. Score and pilot

Use the [methodology](https://startwithidentity.com/methodology/) and [capability checker](https://startwithidentity.com/tools/capability-checker/) to compare governance and lifecycle depth, then run one real certification campaign on a live application. As a planning estimate, not a measured figure, allow 6 to 10 weeks for a pilot that includes two hard connectors and one campaign.

## Failure modes your pilot should test

| Failure mode | Real incident | What the platform must show |
|---|---|---|
| Leaver keeps access | [Cash App former employee](https://startwithidentity.com/breaches/incidents/2022-cash-app-former-employee/) | Termination disables every connected account |
| Account left open "to finish work" | [CrowdSec departing engineer token](https://startwithidentity.com/breaches/incidents/2026-crowdsec-departing-engineer-github-token/) | Exceptions expire on a date and tokens are revoked |
| Forgotten legacy account | [Colonial Pipeline legacy VPN](https://startwithidentity.com/breaches/incidents/2021-colonial-pipeline-legacy-vpn/) | Reconciliation flags accounts with no owner ([orphaned account abuse](https://startwithidentity.com/techniques/orphaned-account-abuse/)) |
| Role changes pile up access | [Mover entitlement accumulation](https://startwithidentity.com/techniques/mover-entitlement-accumulation/) | Transfers remove prior-role grants |
| Service accounts never reviewed | [Chilean Microsoft 365 spraying](https://startwithidentity.com/breaches/incidents/2026-teamfiltration-chile-service-accounts/) | Machine accounts have owners and appear in campaigns |

## Where to start

Browse all [IGA platforms](https://startwithidentity.com/vendors/iga/), read the [top 7 identity governance platforms](https://startwithidentity.com/articles/top-7-identity-governance-platforms/), and compare [SailPoint vs Saviynt](https://startwithidentity.com/compare/sailpoint-vs-saviynt/).

## How to Choose an ITDR Solution in 2026
Source: https://startwithidentity.com/guides/buyer-guides/how-to-choose-an-itdr-solution/
Last updated: 2026-11-05

To choose an ITDR solution, name the identity incident you would struggle most to survive, then test each shortlisted platform against your own attack scenarios, your identity provider integration and its automatic response actions before you compare price. [Identity threat detection and response (ITDR)](https://startwithidentity.com/guides/fundamentals/what-is-itdr/) is a broad category, and the leaders in Active Directory recovery are not the leaders in stolen-session detection.

## Shortlist by problem (November 2026)

| The incident you fear most | Start with | Read next |
|---|---|---|
| Active Directory forest compromise and recovery | [Semperis](https://startwithidentity.com/vendors/itdr/semperis/), [Cayosoft](https://startwithidentity.com/vendors/itdr/cayosoft/) | [Best ITDR for Active Directory](https://startwithidentity.com/rankings/best-itdr-for-active-directory/) |
| Legacy protocols and service accounts with no MFA | [Silverfort](https://startwithidentity.com/vendors/itdr/silverfort/) | [Silverfort vs Semperis](https://startwithidentity.com/compare/silverfort-vs-semperis/) |
| Already on Microsoft 365 E5 or CrowdStrike Falcon | [Microsoft Defender for Identity](https://startwithidentity.com/vendors/itdr/microsoft-defender-identity/), [CrowdStrike Falcon Identity Protection](https://startwithidentity.com/vendors/itdr/crowdstrike-falcon-identity/) | [CrowdStrike vs Defender for Identity](https://startwithidentity.com/compare/crowdstrike-falcon-identity-vs-microsoft-defender-identity/) |
| Human and non-human identity activity across clouds, Okta shops | [Permiso Security](https://startwithidentity.com/vendors/ai-identity/permiso-security/) (now Okta) | [Best ITDR for enterprises](https://startwithidentity.com/rankings/best-itdr-for-enterprises/) |
| Phishing and stolen sessions in SaaS | [Push Security](https://startwithidentity.com/vendors/itdr/push-security/), [Obsidian Security](https://startwithidentity.com/vendors/itdr/obsidian-security/) | [Top identity threat detection platforms](https://startwithidentity.com/articles/top-5-identity-threat-detection-platforms/) |
| Leaked credentials and infostealer logs | [SpyCloud](https://startwithidentity.com/vendors/itdr/spycloud/) | [Infostealer session hijacking](https://startwithidentity.com/breaches/infostealer-session-hijacking/) |
| Directory attack paths and posture | [Tenable Identity Exposure](https://startwithidentity.com/vendors/itdr/tenable-identity-exposure/), [Proofpoint](https://startwithidentity.com/vendors/itdr/proofpoint/) | [Best ITDR tools](https://startwithidentity.com/rankings/best-itdr-tools/) |

## 1. Know which problem you are solving

- **Directory security and recovery** for Active Directory and Entra (detection, posture, fast forest recovery).
- **Runtime identity protection** that extends MFA and risk analysis everywhere, including legacy and [service accounts](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/).
- **SaaS identity risk** and shadow access.
- **Exposure intelligence** on leaked credentials and infostealer logs.

Different leaders own different halves, so naming your priority narrows the field fast.

## 2. Test integration with your identity provider in both directions

ITDR both reads and acts. Confirm that the tool ingests sign-in, audit and risk events from your IdP, and that the IdP can act on its verdicts: block, step up, revoke sessions. Silverfort, for example, sits inside the authentication flow and instructs the identity provider to allow, deny or step up. Ask whether the product emits or consumes [Shared Signals Framework](https://startwithidentity.com/standards/shared-signals-framework/) events ([CAEP](https://startwithidentity.com/glossary/caep/)), Final since 29 August 2025, so connected apps can end a session when ITDR flags it. Then check EDR and SIEM feeds so detections are actionable, not noise.

## 3. Test detections against your own scenarios

Vendor demos show the detections that work. Bring your own, drawn from real incidents:

- A valid sign-in that satisfies phishing-resistant policy but comes from a session the user did not start, for example a Windows Hello authentication with an empty device ID.
- A [device code](https://startwithidentity.com/glossary/device-code-flow/) grant from a client with no business using one ([device code phishing](https://startwithidentity.com/techniques/device-code-phishing/)).
- A new OAuth consent grant to an unfamiliar application, the opening move in [consent phishing](https://startwithidentity.com/techniques/oauth-consent-phishing/).
- MFA methods removed and replaced within hours of a sign-in, the pattern in the [Microsoft 365 token replay campaign against 79 organizations](https://startwithidentity.com/breaches/incidents/2026-microsoft-365-token-replay-79-orgs/).
- A service account or application signing in from new infrastructure with a client secret, as in the [Entra ID stolen app secrets campaign](https://startwithidentity.com/breaches/incidents/2026-entra-id-stolen-app-secrets-27-orgs/).
- A directory change that creates an escalation path, such as a vulnerable certificate template ([AD CS template abuse](https://startwithidentity.com/techniques/adcs-certificate-template-abuse/)).

If a tool cannot show you these, it is watching the wrong layer.

## 4. Hybrid coverage is not optional

Attackers pivot between on-premises Active Directory and the cloud identity provider. In intrusions Microsoft described on October 30, 2026, [fake Teams help desk contacts led to AD CS certificates](https://startwithidentity.com/breaches/incidents/2026-teams-help-desk-impersonation-adcs-esc1-esc8/) for 11 privileged accounts, and one privileged account excluded from automated response was used to copy data out. Confirm coverage of both sides, that it correlates in one view, and which accounts are excluded from response and why.

## 5. Ask about response, not just detection

Identity containment is different from endpoint containment. Revoking [refresh tokens](https://startwithidentity.com/glossary/refresh-token/) and sessions matters more than resetting a password ([token replay](https://startwithidentity.com/techniques/token-replay-unbound-endpoint/)). For each action, ask whether the product does it directly, hands it to the IdP, or leaves it manual:

| Response action | Why it matters |
|---|---|
| Revoke sessions and refresh tokens | A password reset leaves a stolen session alive |
| Remove new MFA methods and devices | Attackers register their own to survive resets |
| Disable or step up the account | Stops the next sign-in |
| Rotate service principal secrets and certificates | Application sign-ins do not use MFA |
| Notify IdP, SIEM and apps (CAEP) | Ends sessions in apps the ITDR cannot touch |

## 6. Check who owns the vendor

ITDR is consolidating into identity and XDR platforms. As of November 5, 2026: Okta closed its Permiso acquisition on 26 August 2026; Silverfort bought Fabrix Security on 28 April 2026; CrowdStrike closed SGNL on 20 February 2026; Imprivata bought Verosint in October 2025; JumpCloud bought Stack Identity in January 2025. Ask whether standalone licensing continues for your term.

## 7. Get a comparable price

ITDR scored 14 out of 100 in the [Identity Pricing Transparency Index 2026](https://startwithidentity.com/reports/identity-pricing-transparency-index-2026/). Published anchors checked October 30, 2026: Push Security at 5 dollars per user per month up to 500 employees; [Nudge Security](https://startwithidentity.com/vendors/itdr/nudge-security/) at 750 dollars a month up to 150 users, then 5 dollars per user; Silverfort's AWS Marketplace listing at 15,000 dollars for 12 months, billed on employee headcount. Scope quotes by headcount, Active Directory forests, IdPs and cloud tenants.

## 8. Prevention and resilience are separate purchases

Runtime protection that extends MFA to protocols agents cannot reach, and directory resilience that recovers a forest cleanly, solve different halves. If budget allows only one, choose the one matching the incident you would struggle most to survive. See [ISPM](https://startwithidentity.com/glossary/ispm/) for the posture side.

## 9. Score and pilot

Compare with the [capability checker](https://startwithidentity.com/tools/capability-checker/), then run the scenarios in step 3 in a pilot tenant. As a planning estimate, not a measured figure, a 30-day pilot with at least one red-team exercise gives enough signal to compare false positives.

## Where to start

Browse [ITDR vendors](https://startwithidentity.com/vendors/itdr/), the [best ITDR tools](https://startwithidentity.com/rankings/best-itdr-tools/) ranking, and [Silverfort vs Semperis](https://startwithidentity.com/compare/silverfort-vs-semperis/), and read about [Zero Trust](https://startwithidentity.com/guides/fundamentals/what-is-zero-trust/).

## How to Choose an MFA Solution in 2026: Buyer's Checklist
Source: https://startwithidentity.com/guides/buyer-guides/how-to-choose-an-mfa-solution/
Last updated: 2026-11-05

To choose an MFA solution in 2026, start from one property: can it make phishing-resistant authentication (passkeys and FIDO2 security keys) mandatory for the people who matter, across every login path you have? Then test recovery, session theft handling, coverage and price. Not all [multi-factor authentication](https://startwithidentity.com/glossary/mfa/) is equal, and a policy that only says "require MFA" is satisfied by methods that commodity phishing kits defeat daily.

## Shortlist by situation (November 2026)

| Your situation | Start with | Ranking to read |
|---|---|---|
| Enterprise, mixed estate, needs broad coverage | [Duo](https://startwithidentity.com/vendors/mfa/duo/) (Cisco), [Microsoft Authenticator](https://startwithidentity.com/vendors/mfa/microsoft-authenticator/) with Entra ID, [RSA SecurID](https://startwithidentity.com/vendors/mfa/rsa-securid/) | [Best MFA for enterprises](https://startwithidentity.com/rankings/best-mfa-for-enterprises/) |
| Phishing resistance is the requirement | [Yubico](https://startwithidentity.com/vendors/mfa/yubico/), [HYPR](https://startwithidentity.com/vendors/mfa/hypr/), [Beyond Identity](https://startwithidentity.com/vendors/mfa/beyond-identity/), [1Kosmos](https://startwithidentity.com/vendors/mfa/1kosmos/) | [Best phishing-resistant MFA](https://startwithidentity.com/rankings/best-phishing-resistant-mfa/) |
| Already on a workforce IdP | [Okta](https://startwithidentity.com/vendors/iam/okta/) or [Microsoft Entra ID](https://startwithidentity.com/vendors/iam/microsoft-entra/) native MFA | [Okta vs Microsoft Entra](https://startwithidentity.com/compare/okta-vs-microsoft-entra/) |
| Banking and transaction signing | [OneSpan](https://startwithidentity.com/vendors/mfa/onespan/) | [Best MFA solutions](https://startwithidentity.com/rankings/best-mfa-solutions/) |
| Verification codes inside your own app | [Twilio Verify](https://startwithidentity.com/vendors/mfa/twilio-verify/) (usage-priced) | [What is passwordless](https://startwithidentity.com/guides/fundamentals/what-is-passwordless/) |
| Want to self-host | Open-source options in [top open-source MFA and passwordless tools](https://startwithidentity.com/articles/top-6-open-source-mfa-passwordless-tools/) | |

For the whole field, see the [top 10 MFA solutions for enterprises](https://startwithidentity.com/articles/top-10-mfa-solutions-enterprises/) and [Duo vs Microsoft Authenticator](https://startwithidentity.com/compare/duo-vs-microsoft-authenticator/).

## What MFA costs in 2026

Few MFA vendors publish a price: in SWI's [Identity Pricing Transparency Index 2026](https://startwithidentity.com/reports/identity-pricing-transparency-index-2026/), half of the 18 MFA vendors are quote-only. The published anchors, read 30 October 2026:

| Product | Published price | What the tier boundary hides |
|---|---|---|
| Duo | Free to 10 users; Essentials $3, Advantage $6, Premier $9 per user per month | Risk-Based Authentication and session theft protection start at Advantage |
| Microsoft Entra ID | P1 $7, P2 $10 per user per month, paid yearly | Sign-in and user risk policies require P2 ([Microsoft Learn](https://learn.microsoft.com/en-us/entra/id-protection/overview-identity-protection)) |
| Okta Workforce | Starter $6, Essentials $17 per user per month, $1,500 annual minimum | Adaptive MFA is sold as its own SKU |
| Yubico | Published per-key hardware prices | Distribution, replacement and spare keys |

## 1. Prioritize phishing resistance

[Phishing-resistant](https://startwithidentity.com/glossary/phishing-resistant-mfa/) means origin-bound: the authenticator refuses to sign for a domain other than the one that registered the credential. Anything a human can read, type, or approve can be relayed. NIST [SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html) treats manual-entry codes as not phishing resistant and requires verifiers to offer at least one phishing-resistant option at AAL2. The standard underneath, [WebAuthn](https://startwithidentity.com/standards/webauthn-fido2/), became a Level 3 W3C Recommendation on 25 August 2026.

## 2. Choose the MFA device for each population

| MFA device | Phishing-resistant | Best for | Watch out for |
|---|---|---|---|
| FIDO2 security key (for example YubiKey) | Yes, device-bound | Admins, break-glass, shared workstations | Spares and lost-key process |
| Platform authenticator (Windows Hello, Touch ID, Android) holding a passkey | Yes | General workforce on managed devices | Synced passkeys fail AAL3's non-exportable key rule |
| Phone app with push | No | Broad coverage, legacy apps | [Push bombing](https://startwithidentity.com/techniques/mfa-fatigue-push-bombing/); require [number matching](https://startwithidentity.com/glossary/number-matching/) |
| Authenticator app code ([TOTP](https://startwithidentity.com/glossary/totp/)) | No | Fallback | Relay; cloud-synced seeds |
| Hardware OTP token | No | Environments without phones | Relay; token logistics |
| SMS or voice code | No | Last resort only | [SIM swap](https://startwithidentity.com/glossary/sim-swap/), relay; Entra ID stops delivering SMS and voice on 1 February 2027 ([the SMS off-ramp](https://startwithidentity.com/blog/sms-mfa-off-ramp-2027/)) |

## 3. Cover your whole estate

Modern web apps are easy. The hard parts are VPNs, legacy apps, desktop login, SSH, and [service accounts](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/). Confirm coverage where you actually need it, and check SaaS apps individually: in SWI's [Phishing-Resistant MFA Support Matrix 2026](https://startwithidentity.com/reports/phishing-resistant-mfa-matrix-2026/), only 12 of 95 business SaaS apps let an admin require passkeys or security keys, so most enforcement has to happen at the identity provider. The [MFA matrix tool](https://startwithidentity.com/tools/mfa-matrix/) lists app by app.

## 4. Decide how much risk-based policy you need

Risk-based or [adaptive authentication](https://startwithidentity.com/glossary/adaptive-auth/) steps up, allows or blocks based on device, location and behaviour ([risk-based auth](https://startwithidentity.com/glossary/risk-based-auth/)). It cuts prompts for routine sign-ins, but it decides when to ask, not how strong the answer is. Compare what each vendor scores, whether the signals reach your VPN and desktop login (Duo's Risk-Based Authentication does not cover Windows Logon or Unix, per its profile), and which tier includes it.

## 5. Interrogate enrolment and recovery

Most real bypasses target enrolment and reset rather than the factor:

- What proves identity at first enrolment, and can that proof be socially engineered?
- Can a user self-service a reset, and what does that path actually require?
- Does the recovery path fall back to SMS or email? If so, the account is as strong as SMS.
- Can help desk staff reset a factor, and what verifies the caller? This is the path [Scattered Spider](https://startwithidentity.com/breaches/scattered-spider-helpdesk-social-engineering/) uses, and at [MGM Resorts](https://startwithidentity.com/breaches/incidents/2023-mgm-resorts-help-desk-ransomware/) one help desk call led to Okta super administrator control ([help desk social engineering](https://startwithidentity.com/techniques/help-desk-social-engineering/)).

## 6. Ask what the vendor does about session theft

MFA at the door does not help if the attacker arrives holding a session that already authenticated. The Mirage2FA campaign reached 4,532 organization domains between 2024 and 2026 without breaking a single factor: it captured the password and session cookie through legitimate Microsoft 365 login flows ([adversary-in-the-middle phishing](https://startwithidentity.com/techniques/aitm-phishing-proxy/), [pass-the-cookie](https://startwithidentity.com/glossary/pass-the-cookie/)). In 2026 another actor [replayed stolen tokens into 79 organizations](https://startwithidentity.com/breaches/incidents/2026-microsoft-365-token-replay-79-orgs/) and replaced victims' MFA methods so access survived password resets. Ask about sender-constrained tokens such as [DPoP](https://startwithidentity.com/glossary/dpop/) ([RFC 9449](https://datatracker.ietf.org/doc/html/rfc9449)), [Device Bound Session Credentials](https://startwithidentity.com/glossary/device-bound-session-credentials/), session revocation APIs, alerts on factor changes, and [CAEP](https://startwithidentity.com/glossary/caep/) support. As a practitioner estimate rather than a measured statistic, [token theft](https://startwithidentity.com/glossary/token-theft/) is now the dominant bypass rather than factor compromise.

## 7. Check the vendor's own track record

Your MFA provider is part of your attack surface. In April 2024 an attacker phished the [telephony provider that delivers Duo's SMS messages](https://startwithidentity.com/breaches/incidents/2024-cisco-duo-telephony-provider-phishing/) and downloaded message logs, and the [0ktapus campaign](https://startwithidentity.com/breaches/incidents/2022-0ktapus-phishing-campaign/) captured 5,441 MFA codes from users at more than 130 organizations ([OTP relay](https://startwithidentity.com/techniques/otp-relay-social-engineering/)). Ask each vendor for its disclosed incidents and CVEs for the last 24 months.

## 8. Tier your authenticators

Synced [passkeys](https://startwithidentity.com/glossary/passkey/) make consumer and workforce adoption possible. Device-bound hardware keys are what you want for administrators, break-glass accounts, and anyone with production access, especially after the [August 2026 research on synced key custody](https://startwithidentity.com/blog/passkeys-first-hard-month/). Choose a vendor that supports both classes and lets policy distinguish them.

## 9. Pilot with your hardest users

Run the pilot with administrators, remote staff and a legacy app, not with the IT team. Measure enrolment completion, help desk tickets per 100 users and how many accounts still have a phishable fallback after 30 days.

## Where to start

Follow the [MFA implementation guide](https://startwithidentity.com/guides/authentication/mfa-implementation-best-practices/) and the [MFA rollout guide](https://startwithidentity.com/guides/authentication/mfa-rollout/), use the [SSO-first playbook for enforcing phishing-resistant MFA](https://startwithidentity.com/articles/enforce-phishing-resistant-mfa-across-saas/), and browse [MFA and passwordless vendors](https://startwithidentity.com/vendors/mfa/).

## How to evaluate a CIAM vendor without falling for the demo
Source: https://startwithidentity.com/guides/buyer-guides/how-to-evaluate-ciam/
Last updated: 2026-11-05

The fastest way to evaluate a [CIAM](https://startwithidentity.com/guides/fundamentals/what-is-ciam/) vendor is to ignore the demo and test four things on a trial tenant: what you will pay at two and ten times today's active users, how you get every user (with password hashes) back out, how the recovery and account takeover paths behave under attack, and what the contract says when it breaks. For a shortlist first, see [how to choose a CIAM platform](https://startwithidentity.com/guides/buyer-guides/how-to-choose-a-ciam-platform/).

## What the demo will not tell you

Demos show the happy path. They skip pricing above 1M MAU, data export, the cost of custom auth flows, and how the vendor responds to a production failure at 3 AM.

## The eight questions to actually ask

1. **What is the per-MAU cost at 10K, 100K, 1M, and 10M MAU?** Get this in writing, with the vendor's definition of an active user.
2. **What is the data export format and how do I get my users out?** Test it on the trial account, including password hashes and MFA enrollments.
3. **What is the SLA, and what's the historical uptime?** Ask for the last 12 months of status page data and the credit terms.
4. **How long has the current SDK version been the recommended one?** SDK churn signals broader product instability.
5. **What does support response look like at our tier?** Not the marketing answer, the contractual one.
6. **Show me an audit log entry and the API to query it.** Real screen, real data, and the retention period.
7. **What's the migration story if I move to you, and what if I move away?** Both directions matter.
8. **Who else in our segment is using you, and can I talk to them?** Two reference calls minimum.

## Scorecard

Weight the criteria to your product; B2C and B2B buyers should not score vendors the same way.

| Criterion | What to verify | Weight for B2C | Weight for B2B SaaS |
|---|---|---|---|
| Pricing at 2x and 10x scale | Written unit prices, overage rate, band rules | High | Medium |
| Enterprise SSO and SCIM | Per-connection fees, self-serve admin portal, SCIM support | Low | High |
| Organizations and tenancy | Per-tenant roles, branding, domain verification | Low | High |
| Account takeover defenses | Passkeys, bot detection, breached-password checks, rate limits | High | High |
| Recovery flow | Options beyond SMS, step-up before factor changes | High | Medium |
| Data portability | Hash export process, import limits, lazy migration support | High | High |
| Compliance and residency | Regions, certifications, DPA terms | Depends on market | Depends on market |
| Operations | Audit log API, log streaming, status history, support SLAs | Medium | High |

## Pricing: read the unit, not the headline

Every row in SWI's [Identity Pricing Transparency Index 2026](https://startwithidentity.com/reports/identity-pricing-transparency-index-2026/) was read from the vendor's own pricing page on October 30, 2026, and the CIAM rows show why the headline free tier misleads.

- **"Active" differs.** [Clerk](https://startwithidentity.com/vendors/ciam/clerk/) bills monthly retained users, meaning a user who returns at least a day after signing up, per its [pricing page](https://clerk.com/pricing). [Zitadel](https://startwithidentity.com/vendors/open-source/zitadel/) and [Ory](https://startwithidentity.com/vendors/open-source/ory/) count daily actives, [Logto](https://startwithidentity.com/vendors/open-source/logto/) bills tokens, and [Stytch](https://startwithidentity.com/vendors/ciam/stytch/) counts AI agents alongside users.
- **Bands round up.** The index notes that on [Auth0](https://startwithidentity.com/vendors/ciam/auth0/)'s published plans, usage between MAU bands is billed at the next band up.
- **Federated users cost differently.** [Amazon Cognito](https://startwithidentity.com/vendors/ciam/amazon-cognito/) gives 10,000 free MAU for direct sign-in on Lite and Essentials, but only 50 free MAU for users who sign in through SAML or OIDC federation, then $0.015 each, per its [pricing page](https://aws.amazon.com/cognito/pricing/).
- **B2B costs come from connections.** [WorkOS](https://startwithidentity.com/vendors/ciam/workos/) lists $125 per SSO or directory connection (1 to 15), Clerk lists one connection included on paid plans and $75 each for 2 to 15, and [SSOJet](https://startwithidentity.com/vendors/ciam/ssojet/) lists $59 per connection per month on annual billing.

**Worked example (list prices, USD per month, before add-ons):** a B2B app with 100,000 active users, all signing in directly, and 10 enterprise SSO customers.

| Vendor | User charge | Connection charge | Total |
|---|---|---|---|
| WorkOS AuthKit | $0 (free to 1,000,000 MAU) | 10 x $125 = $1,250 | $1,250 |
| Clerk Pro | $25 + 50,000 x $0.02 = $1,025 | 9 x $75 = $675 | $1,700 |
| Amazon Cognito Essentials | 90,000 x $0.015 = $1,350 | Federated users billed per MAU instead | $1,350 plus federated MAU |
| SSOJet | $0 (unlimited users) | 10 x $59 = $590 (annual) | $590 (check which user-login features your plan includes) |

The products are not equivalent; the cheapest line depends on whether your cost driver is users or connections. Rerun the numbers at your two-year forecast in the [TCO calculator](https://startwithidentity.com/tools/tco-calculator/), and read [CIAM pricing models explained](https://startwithidentity.com/articles/ciam-pricing-models-explained/) and the [SSO tax](https://startwithidentity.com/glossary/sso-tax/) entry before you negotiate.

## Test portability before you sign

Exit is where lock-in shows. Two concrete examples from Auth0's documentation:

- Auth0 says all tenant data is available through the Management API except the password hashes of its database users and private keys, which you request [through a support ticket](https://auth0.com/docs/troubleshoot/customer-support/manage-subscriptions/export-data). The option is not available on the Free tier, and Auth0 does not guarantee a specific date.
- Coming in, Auth0's [bulk user import](https://auth0.com/docs/manage-users/user-migration/bulk-user-imports) accepts existing password hashes in supported algorithms, but files are capped at 500KB (roughly 1,000 users with light metadata), a tenant can run two import jobs at once, and jobs time out after 2 hours. Users with unsupported hash algorithms must reset at first login.

Ask every finalist in writing how hashes and MFA enrollments come out, and what the import limits are. See the [CIAM migration guide](https://startwithidentity.com/articles/ciam-migration-guide/) for lazy (on-login) migration patterns.

## What to test in trial

- Performance under burst load (sign-in spikes at 9 AM)
- The recovery flow when an authenticator is lost, and whether it falls back to SMS alone
- An email change
- [Passkey](https://startwithidentity.com/glossary/passkey/) enrollment and sign-in across platforms; compare factor support in the [MFA matrix](https://startwithidentity.com/tools/mfa-matrix/) and the [Phishing-Resistant MFA Matrix 2026](https://startwithidentity.com/reports/phishing-resistant-mfa-matrix-2026/)
- A scripted [credential stuffing](https://startwithidentity.com/techniques/credential-stuffing/) run against your own trial tenant, to see rate limits and bot detection fire
- The audit log for a sequence of normal user actions

## Failure modes real breaches exposed

| Failure | Incident | What to require from the vendor |
|---|---|---|
| Credential stuffing against accounts without mandatory MFA | [23andMe, 2023](https://startwithidentity.com/breaches/incidents/2023-23andme-credential-stuffing-dna-relatives/): about 14,000 accounts accessed, profile data of about 6.9 million people exposed; the UK ICO fined it 2.31 million pounds citing the lack of mandatory MFA | MFA you can make mandatory, breached-password checks, bot detection |
| Repeated stuffing waves | [Roku, 2024](https://startwithidentity.com/breaches/incidents/2024-roku-credential-stuffing/): 15,363 accounts, then about 576,000 more | Login rate limits and anomaly alerts you can see in logs |
| Weak recovery path | [Coinbase, 2021](https://startwithidentity.com/breaches/incidents/2021-coinbase-sms-recovery-flaw/): an SMS account recovery flaw used to take over at least 6,000 customers' accounts | Recovery with step-up, not SMS alone |
| Unauthenticated identity endpoint | [Authy, 2024](https://startwithidentity.com/breaches/incidents/2024-twilio-authy-unauthenticated-endpoint/): phone numbers enumerated through an unauthenticated endpoint | Rate limiting and auth on every lookup API |

See [CIAM account takeover prevention](https://startwithidentity.com/articles/ciam-account-takeover-prevention/).

## Step-by-step evaluation plan

1. Write one scope sheet (peak actives, B2B customers, SMS volume by country, regions, test tenants) and send it to every vendor.
2. Shortlist three to four vendors from the [CIAM rankings](https://startwithidentity.com/rankings/best-ciam-platforms/) or the segment rankings for [startups](https://startwithidentity.com/rankings/best-ciam-for-startups/) and [B2B SaaS](https://startwithidentity.com/rankings/best-ciam-for-b2b-saas/).
3. Get unit prices and overage rules in writing at current, 2x and 10x volume.
4. Run the trial tests, a hash export and a 1,000-user import on each tenant.
5. Hold the reference calls, including one you found yourself.
6. Score with the table above, then negotiate renewal caps and true-up terms.

## Common pitfalls

- Buying based on developer experience alone, ignoring operational fit
- Underestimating the cost of customer SSO support requests
- Choosing a vendor that won't scale to where you'll be in 24 months
- Skipping data export evaluation until lock-in is already happening
- Trusting the vendor's reference customers without finding your own

## Useful internal links

For the universe of options, see [our vendor profiles](https://startwithidentity.com/vendors/) and [head-to-head comparisons](https://startwithidentity.com/compare/), including [Auth0 vs Clerk](https://startwithidentity.com/compare/auth0-vs-clerk/), [Auth0 vs Stytch](https://startwithidentity.com/compare/auth0-vs-stytch/) and [Auth0 vs WorkOS](https://startwithidentity.com/compare/auth0-vs-workos/). If you are still deciding whether to buy at all, read [build vs buy identity](https://startwithidentity.com/guides/buyer-guides/build-vs-buy-identity/).

## How to Get an IAM Job: Skills, Resume, and a Portfolio That Lands Interviews
Source: https://startwithidentity.com/guides/career/how-to-get-an-iam-job/
Last updated: 2026-11-05

IAM hiring rewards people who can show, not just tell. This page is the job search itself: how to
read IAM postings, which titles to target, how to write the resume, how to package your lab work
so a hiring manager actually looks at it, where to apply, and how to close. For what to learn
first, see [how to become an identity engineer](https://startwithidentity.com/guides/career/how-to-become-an-identity-engineer/).

## The market reality: most postings want experience

Of the 53 open listings on our [IAM jobs board](https://startwithidentity.com/jobs/) on 2026-11-05, 2 are tagged junior, 11 mid,
25 senior, and the remaining 15 lead, principal, or manager. That skew is the single most important
fact for a career changer: very few identity roles are posted as entry level. The practical
consequence is to come in sideways (an IAM analyst, IT operations, or help desk role that touches
the directory) or to arrive with enough lab evidence that a mid-level hiring manager takes the risk.

## 1. Learn to read an IAM job posting

Identity job titles are inconsistent. Read the duties, not the title.

| If the posting says | It usually means | What to emphasize |
|---|---|---|
| "IAM engineer," "identity engineer," "Okta engineer" | Workforce SSO, MFA, provisioning on a named platform | Platform depth, SAML and SCIM integrations |
| "IGA engineer," "SailPoint developer," "access governance" | Lifecycle rules, access reviews, role models | Governance projects, audit outcomes |
| "PAM engineer," "privileged access" | Vaulting, session management, admin access workflows | Any privileged access or AD hardening work |
| "Software engineer, identity" or "authentication" | Building login, tokens, and authorization into a product | Code, OAuth and OIDC internals, scale |
| "CIAM" | Customer sign-up, login, passkeys, fraud | Conversion and security trade-offs |
| "Identity threat detection," "ITDR" | Detections and response for identity attacks | Log analysis, attack techniques |
| "ICAM" | Usually US federal: identity, credential, and access management, often with PIV | Clearance eligibility, federal standards |

Requirements lists are wish lists. If you meet the core protocol and platform items and about
half the rest, apply.

## 2. Pick a target and stick to it for the search

Choose one track and one platform for the search: for example, "Entra-focused IAM engineer at a
mid-size enterprise" or "IGA analyst at a SailPoint consultancy." A focused search lets you tailor
one resume and one portfolio. Use [IAM career paths](https://startwithidentity.com/guides/career/iam-career-paths/) to choose.

## 3. Package your portfolio for a 2-minute look

A hiring manager will spend a couple of minutes on your GitHub link at most, so design for that.

- **One repository, one README.** Put a short summary at the top: what you built, which protocols,
  and a diagram.
- **Show decisions, not just code.** A "design decisions" section ("I chose PKCE because the client
  is public; I chose SCIM PATCH over PUT because...") is the part that signals understanding.
- **Show something you broke and fixed.** A SAML certificate rollover or a token validation bug
  written up as a short incident note is unusually persuasive.
- **Keep secrets out.** A committed client secret in a portfolio is an instant negative. See
  [secrets in repositories and CI](https://startwithidentity.com/techniques/secrets-in-repositories-and-ci/).

The [recipes](https://startwithidentity.com/recipes/) give you buildable starting points. Contributing to the open-source
[IAM interview questions repository](https://github.com/Start-With-Identity/iam-interview-questions)
also counts, and every contributor is credited by name.

## 4. Write an outcomes-first resume

Replace task lists with results. "Automated quarterly access reviews for 4,000 users, cutting review
time by 60 percent" beats "responsible for access reviews." Patterns that work:

- **Scale:** users, applications, tenants, integrations.
- **Change:** "migrated 120 applications from AD FS to Entra ID" (see the
  [AD FS to Entra migration guide](https://startwithidentity.com/guides/implementation/adfs-to-entra-migration/)).
- **Risk reduced:** "removed standing domain admin rights from 35 accounts."
- **Protocols and platforms named explicitly**, because applicant tracking systems match on them.

If you are a career changer, translate adjacent work: help desk password resets become "supported
MFA enrollment and recovery for 2,000 users"; sysadmin work becomes "managed AD groups and GPOs for
access control." Cut generic security filler.

## 5. Get one relevant certification

Certifications help most early on and for consulting or vendor-aligned roles. Match the platform in
the postings you are targeting. See [identity security certifications](https://startwithidentity.com/guides/career/identity-security-certifications/)
for issuers, costs, and renewal.

## 6. Apply where identity roles actually are

- **Employer career pages**, filtered by IAM, IGA, PAM, CIAM, and identity security titles.
- **The [IAM jobs board](https://startwithidentity.com/jobs/)**, which tags roles by domain, seniority, and work type.
- **Identity vendors and their partners.** Platform vendors, and the consultancies that implement
  them, hire people who know the product. See the [vendor directory](https://startwithidentity.com/vendors/).
- **Referrals.** Identity is a small field. Practitioner communities, IDPro, and events such as
  [Identiverse](https://startwithidentity.com/conferences/identiverse/), [Authenticate](https://startwithidentity.com/conferences/authenticate/), and the
  [Internet Identity Workshop](https://startwithidentity.com/conferences/iiw/) are where you meet the people who hire. See the
  [conferences](https://startwithidentity.com/conferences/) list.
- **Remote roles** need a slightly different approach; see [remote IAM jobs](https://startwithidentity.com/guides/career/remote-iam-jobs/).

## 7. Prepare for the interview

Expect protocol questions (walk through an OIDC authorization code flow), scenario questions (how
would you handle joiner-mover-leaver, or a compromised admin account), and platform specifics for
the tools in the job description. Practice with [IAM interview questions](https://startwithidentity.com/guides/career/iam-interview-questions/),
which has model answers, and the full open-source
[interview questions bank](https://github.com/Start-With-Identity/iam-interview-questions). Before each
interview, read the employer's own identity setup where it is visible: which IdP their login page
redirects to, whether their product offers SSO and SCIM, and any public breach history in the
[breach database](https://startwithidentity.com/breaches/).

## 8. Evaluate and close the offer

Benchmark the offer with the public data and negotiation steps in the
[IAM salary guide](https://startwithidentity.com/guides/career/iam-salary-guide/). Ask about on-call expectations (identity outages
lock everyone out), the training budget, and which platforms you will own in the first six months.

## Common mistakes

- Applying to senior engineer roles with no production identity experience.
- A portfolio that is a tutorial clone with no explanation of choices.
- Listing every acronym in identity instead of proving depth in four.
- Ignoring the platform named in the posting.

## Related

[IAM career paths](https://startwithidentity.com/guides/career/iam-career-paths/), [how to become an identity engineer](https://startwithidentity.com/guides/career/how-to-become-an-identity-engineer/),
and the [experts directory](https://startwithidentity.com/experts/) for people worth following.

## How WebAuthn and Passkeys Work, Message by Message
Source: https://startwithidentity.com/guides/protocols/webauthn-message-flow/
Last updated: 2026-11-05

A WebAuthn login is a signed challenge. The server sends options with a random challenge, the browser asks an authenticator (a phone, a laptop's platform authenticator, a password manager or a security key) to sign it together with the origin the browser actually sees, and the server verifies that signature with the public key it stored at registration. There are two ceremonies, registration and authentication, and each is one round trip of JSON between your server and the page. This page shows both with fake but realistic values and ties every field to its section in [Web Authentication Level 3](https://www.w3.org/TR/webauthn-3/), a W3C Recommendation.

For what WebAuthn and FIDO2 are, synced versus device-bound passkeys and who implements them, see the [WebAuthn / FIDO2 standard page](https://startwithidentity.com/standards/webauthn-fido2/). This page is the wire-level detail underneath it.

## The sequence at a glance

| # | Ceremony | Message | Spec |
| --- | --- | --- | --- |
| 1 | Registration | Server → page: `PublicKeyCredentialCreationOptions` | [§5.4](https://www.w3.org/TR/webauthn-3/#dictionary-makecredentialoptions) |
| 2 | Registration | Page → server: `PublicKeyCredential` with `AuthenticatorAttestationResponse` | [§5.2.1](https://www.w3.org/TR/webauthn-3/#iface-authenticatorattestationresponse) |
| 3 | Registration | Server verifies and stores the credential record | [§7.1](https://www.w3.org/TR/webauthn-3/#sctn-registering-a-new-credential) |
| 4 | Authentication | Server → page: `PublicKeyCredentialRequestOptions` | [§5.5](https://www.w3.org/TR/webauthn-3/#dictionary-assertion-options) |
| 5 | Authentication | Page → server: `PublicKeyCredential` with `AuthenticatorAssertionResponse` | [§5.2.2](https://www.w3.org/TR/webauthn-3/#iface-authenticatorassertionresponse) |
| 6 | Authentication | Server verifies the assertion and starts a session | [§7.2](https://www.w3.org/TR/webauthn-3/#sctn-verifying-assertion) |

Between the page and the authenticator sits CTAP (for roaming authenticators) or a platform API; the relying party never sees that leg. Level 3 adds `PublicKeyCredential.parseCreationOptionsFromJSON()` and `parseRequestOptionsFromJSON()` ([§5.1.8–5.1.9](https://www.w3.org/TR/webauthn-3/#sctn-parseCreationOptionsFromJSON)) and `toJSON()`, so the base64url JSON shown below is what actually crosses the network.

## Message 1: creation options

```json
{
  "rp": { "id": "example.com", "name": "Example Corp" },
  "user": {
    "id": "dS0xMjM0NS1leGFtcGxlLW9wYXF1ZQ",
    "name": "ada@example.com",
    "displayName": "Ada Example"
  },
  "challenge": "q2Tb3pJm0w8HcXyO7nV5fA9sLk1eRu4Z",
  "pubKeyCredParams": [
    { "type": "public-key", "alg": -7 },
    { "type": "public-key", "alg": -257 }
  ],
  "timeout": 300000,
  "excludeCredentials": [
    { "type": "public-key", "id": "b2xkLXNlY3VyaXR5LWtleS1leGFtcGxl" }
  ],
  "authenticatorSelection": {
    "residentKey": "required",
    "userVerification": "required"
  },
  "attestation": "none",
  "hints": ["client-device"]
}
```

| Field | Meaning | Spec |
| --- | --- | --- |
| `rp.id` | The RP ID: a registrable domain suffix of the page's origin. Every credential is scoped to it for life. | [§5.4.2](https://www.w3.org/TR/webauthn-3/#dictionary-rp-credential-params), [§6.1](https://www.w3.org/TR/webauthn-3/#sctn-authenticator-data) |
| `user.id` | The **user handle**: opaque bytes, at most 64, with no personal data. Returned at login as `userHandle`. | [§5.4.3](https://www.w3.org/TR/webauthn-3/#dictionary-user-credential-params) |
| `user.name`, `displayName` | Shown in the account picker. | [§5.4.3](https://www.w3.org/TR/webauthn-3/#dictionary-user-credential-params) |
| `challenge` | Server-generated random bytes; at least 16 bytes, single-use, stored server-side. | [§5.4](https://www.w3.org/TR/webauthn-3/#dictionary-makecredentialoptions), [§13.4.3](https://www.w3.org/TR/webauthn-3/#sctn-cryptographic-challenges) |
| `pubKeyCredParams` | Acceptable COSE algorithms in preference order: -7 is ES256, -257 is RS256. | [§5.3](https://www.w3.org/TR/webauthn-3/#dictionary-credential-params), [§5.8.5](https://www.w3.org/TR/webauthn-3/#sctn-alg-identifier) |
| `excludeCredentials` | Credentials this user already has, so the same authenticator is not registered twice. | [§5.4](https://www.w3.org/TR/webauthn-3/#dictionary-makecredentialoptions), [§5.8.3](https://www.w3.org/TR/webauthn-3/#dictionary-credential-descriptor) |
| `authenticatorSelection.residentKey` | `required` creates a discoverable credential, which is what makes it a passkey. | [§5.4.4](https://www.w3.org/TR/webauthn-3/#dictionary-authenticatorSelection), [§5.4.6](https://www.w3.org/TR/webauthn-3/#enum-residentKeyRequirement) |
| `userVerification` | `required` demands PIN or biometric. Still verify the UV flag yourself. | [§5.8.6](https://www.w3.org/TR/webauthn-3/#enum-userVerificationRequirement) |
| `attestation` | `none`, `indirect`, `direct` or `enterprise`. Ask for attestation only if you will verify it. | [§5.4.7](https://www.w3.org/TR/webauthn-3/#enum-attestation-convey) |
| `hints` | Level 3 UI hints: `security-key`, `client-device`, `hybrid`. | [§5.8.8](https://www.w3.org/TR/webauthn-3/#enum-hints) |

## Message 2: the registration response

```json
{
  "id": "ZXhhbXBsZS1jcmVkZW50aWFsLWlkLTAx",
  "rawId": "ZXhhbXBsZS1jcmVkZW50aWFsLWlkLTAx",
  "type": "public-key",
  "authenticatorAttachment": "platform",
  "response": {
    "clientDataJSON": "eyJ0eXBlIjoid2ViYXV0aG4uY3JlYXRlIiwiY2hhbGxlbmdlIjoicTJUYjNwSm0wdzhIY1h5TzduVjVmQTlzTGsxZVJ1NFoiLCJvcmlnaW4iOiJodHRwczovL2xvZ2luLmV4YW1wbGUuY29tIiwiY3Jvc3NPcmlnaW4iOmZhbHNlfQ",
    "attestationObject": "o2NmbXRkbm9uZWdhdHRTdG10oGhhdXRoRGF0YVjF...",
    "transports": ["internal", "hybrid"]
  },
  "clientExtensionResults": { "credProps": { "rk": true } }
}
```

Decoded, `clientDataJSON` is:

```json
{
  "type": "webauthn.create",
  "challenge": "q2Tb3pJm0w8HcXyO7nV5fA9sLk1eRu4Z",
  "origin": "https://login.example.com",
  "crossOrigin": false
}
```

And the `attestationObject` is a CBOR map `{ "fmt": "none", "attStmt": {}, "authData": <bytes> }` ([§6.5.4](https://www.w3.org/TR/webauthn-3/#sctn-generating-an-attestation-object)). The `authData` bytes break down as:

| Bytes | Field | Example | Spec |
| --- | --- | --- | --- |
| 32 | `rpIdHash` | SHA-256 of `example.com` | [§6.1](https://www.w3.org/TR/webauthn-3/#sctn-authenticator-data) |
| 1 | `flags` | `0x5D`: UP (bit 0), UV (bit 2), BE (bit 3), BS (bit 4), AT (bit 6) set | [§6.1](https://www.w3.org/TR/webauthn-3/#sctn-authenticator-data) |
| 4 | `signCount` | `0x00000000` (synced passkeys usually report 0) | [§6.1.1](https://www.w3.org/TR/webauthn-3/#sctn-sign-counter) |
| var | `attestedCredentialData` | AAGUID (16 bytes), credential ID length and ID, COSE public key | [§6.5.1](https://www.w3.org/TR/webauthn-3/#sctn-attested-credential-data) |
| var | `extensions` | CBOR map, present only if ED (bit 7) is set | [§6.1](https://www.w3.org/TR/webauthn-3/#sctn-authenticator-data) |

The BE and BS bits are how a relying party knows a credential is synced: BE means backup eligible, BS means currently backed up ([§6.1.3](https://www.w3.org/TR/webauthn-3/#sctn-credential-backup)).

## Messages 4 and 5: authentication

```json
{
  "challenge": "N7vKq3XcM2pT0aYwR9sBe5LhUj8DfG1o",
  "rpId": "example.com",
  "allowCredentials": [],
  "userVerification": "required",
  "timeout": 300000
}
```

An empty `allowCredentials` lets the user pick any discoverable credential for this RP ID, which is the usernameless passkey flow; combine it with `mediation: "conditional"` for autofill ([§5.5](https://www.w3.org/TR/webauthn-3/#dictionary-assertion-options), [§5.1.4](https://www.w3.org/TR/webauthn-3/#sctn-getAssertion)).

```json
{
  "id": "ZXhhbXBsZS1jcmVkZW50aWFsLWlkLTAx",
  "rawId": "ZXhhbXBsZS1jcmVkZW50aWFsLWlkLTAx",
  "type": "public-key",
  "response": {
    "clientDataJSON": "eyJ0eXBlIjoid2ViYXV0aG4uZ2V0IiwiY2hhbGxlbmdlIjoiTjd2S3EzWGNNMnBUMGFZd1I5c0JlNUxoVWo4RGZHMW8iLCJvcmlnaW4iOiJodHRwczovL2xvZ2luLmV4YW1wbGUuY29tIiwiY3Jvc3NPcmlnaW4iOmZhbHNlfQ",
    "authenticatorData": "o3mm9u6vuaVeN4wRgDTidR5oL6ufLTCrE9ISVYbOGUcdAAAAAA",
    "signature": "MEUCIQDexample-signature-bytes-not-realAiB0example",
    "userHandle": "dS0xMjM0NS1leGFtcGxlLW9wYXF1ZQ"
  },
  "clientExtensionResults": {}
}
```

| Field | Meaning | Spec |
| --- | --- | --- |
| `clientDataJSON` | Decodes to `type: webauthn.get`, the challenge, the origin and `crossOrigin`; `topOrigin` appears for cross-origin iframes. | [§5.8.1](https://www.w3.org/TR/webauthn-3/#dictionary-client-data) |
| `authenticatorData` | 37 bytes here: `rpIdHash`, flags, `signCount`; no attested credential data at login. | [§6.1](https://www.w3.org/TR/webauthn-3/#sctn-authenticator-data) |
| `signature` | Over `authenticatorData ‖ SHA-256(clientDataJSON)`, with the credential's private key. | [§6.3.3](https://www.w3.org/TR/webauthn-3/#sctn-op-get-assertion), [§7.2](https://www.w3.org/TR/webauthn-3/#sctn-verifying-assertion) |
| `userHandle` | The `user.id` from registration; required for usernameless flows. | [§5.2.2](https://www.w3.org/TR/webauthn-3/#iface-authenticatorassertionresponse) |

## The checks a relying party must run

Registration ([§7.1](https://www.w3.org/TR/webauthn-3/#sctn-registering-a-new-credential)) and authentication ([§7.2](https://www.w3.org/TR/webauthn-3/#sctn-verifying-assertion)) are numbered algorithms. The checks that carry the security:

1. **`type`** is `webauthn.create` at registration and `webauthn.get` at login (§7.1, §7.2).
2. **`challenge`** equals the base64url of the challenge you generated and stored for this ceremony, and is then discarded ([§13.4.3](https://www.w3.org/TR/webauthn-3/#sctn-cryptographic-challenges)). Never accept a challenge the client supplies.
3. **`origin`** is one you expect, exactly; check `crossOrigin` and `topOrigin` if you allow iframes ([§13.4.9](https://www.w3.org/TR/webauthn-3/#sctn-validating-origin)). This check is what makes WebAuthn phishing-resistant.
4. **`rpIdHash`** equals SHA-256 of your RP ID (§7.1, §7.2).
5. **Flags.** UP is set; UV is set whenever your policy requires user verification; if BE is not set, BS must not be set (§7.2).
6. **Credential ownership.** At login the credential ID belongs to the identified user, or, when the user was not identified first, `userHandle` maps to an account holding that credential ID (§7.2). At registration the credential ID is at most 1023 bytes and not already registered to anyone (§7.1).
7. **Signature** verifies with the stored public key, whose `alg` was one you offered in `pubKeyCredParams` at registration (§7.1, §7.2).
8. **State update.** Store the new `signCount` and backup state; treat a non-zero counter that fails to increase as a possible clone signal ([§6.1.1](https://www.w3.org/TR/webauthn-3/#sctn-sign-counter)). Verify attestation only if you requested it and act on the result ([§13.4.4](https://www.w3.org/TR/webauthn-3/#sctn-attestation-limitations)).

## Common implementation mistakes

| Mistake | What goes wrong | Real examples |
| --- | --- | --- |
| Credential not tied to the account being logged into | Attacker completes a passkey login as the victim | [CVE-2025-26788](https://startwithidentity.com/cves/cve-2025-26788/) (StrongKey FIDO Server, discoverable and non-discoverable credentials confused) |
| Assertions or challenges leaked and not strictly single-use | Captured assertion material is replayed | [CVE-2026-34348](https://startwithidentity.com/cves/cve-2026-34348/) (assertions in Windows event logs, replayed against Entra ID) |
| Origin or RP ID not checked, or a wildcard origin list | The phishing resistance disappears | [AiTM phishing proxy](https://startwithidentity.com/techniques/aitm-phishing-proxy/) succeeds again |
| UV flag ignored | A touch-only assertion satisfies a policy that assumed PIN or biometric | Check UV server-side, not only in options |
| Passkey added but password or SMS left as fallback | Attackers phish the fallback | [OTP relay social engineering](https://startwithidentity.com/techniques/otp-relay-social-engineering/), [help desk social engineering](https://startwithidentity.com/techniques/help-desk-social-engineering/) |
| Endpoint already compromised | Malware extracts key material or drives an authenticator the user already opened | [Credential manager key extraction](https://startwithidentity.com/techniques/credential-manager-key-extraction/) |
| Session cookie not protected after login | The passkey protected sign-in, not the session | [Session cookie theft](https://startwithidentity.com/techniques/session-cookie-theft/) |

The broader table of WebAuthn deployment mistakes, including AAGUID trust and recovery design, is on the [standard page](https://startwithidentity.com/standards/webauthn-fido2/#common-implementation-mistakes-and-attacks).

## Try it

Run a registration and a login against a test relying party in the [WebAuthn tester](https://startwithidentity.com/tools/webauthn-tester/), then inspect the decoded `clientDataJSON` and authenticator flags it shows and compare them with the tables above. To see which business apps let you require passkeys at all, use the [MFA matrix](https://startwithidentity.com/tools/mfa-matrix/). The [add passkeys with WebAuthn recipe](https://startwithidentity.com/recipes/add-passkeys-webauthn/) covers server code.

## Related

[WebAuthn / FIDO2 standard page](https://startwithidentity.com/standards/webauthn-fido2/), [passkeys 101](https://startwithidentity.com/guides/authentication/passkeys-101/), [implementing passkeys in the enterprise](https://startwithidentity.com/guides/authentication/implementing-passkeys-enterprise/), [OIDC message flow](https://startwithidentity.com/guides/protocols/oidc-message-flow/), [Phishing-Resistant MFA Support Matrix 2026](https://startwithidentity.com/reports/phishing-resistant-mfa-matrix-2026/). Glossary: [WebAuthn](https://startwithidentity.com/glossary/webauthn/), [passkey](https://startwithidentity.com/glossary/passkey/), [synced passkey](https://startwithidentity.com/glossary/synced-passkey/), [FIDO2](https://startwithidentity.com/glossary/fido2/), [relying party](https://startwithidentity.com/glossary/relying-party/).

## IAM Audit Preparation Guide: SOX, SOC 2, and HIPAA Readiness
Source: https://startwithidentity.com/guides/compliance/iam-audit-preparation-guide/
Last updated: 2026-11-05

IAM audit findings are among the most common and most consequential compliance issues organizations face. "Excessive access," "inadequate access reviews," "untimely deprovisioning," and "insufficient segregation of duties" appear on audit reports with predictable regularity. These findings carry real consequences: [SOX](https://startwithidentity.com/regulations/united-states/sox/) material weaknesses can affect stock price, SOC 2 qualifications can lose you customers, and HIPAA violations carry financial penalties.

The irony is that most IAM audit failures are not caused by bad technology or malicious intent. They result from poor preparation, organizations that manage access reasonably well day-to-day but cannot produce the evidence to prove it. This guide helps you bridge that gap.

## Prerequisites

- **Understanding of your regulatory scope**, Which frameworks apply? SOX (public companies), SOC 2 (service organizations), HIPAA (healthcare data), PCI DSS (payment data), or others.
- **An IAM platform with logging enabled**, You cannot produce evidence from systems that do not log.
- **Access to audit reports from previous years**, Understanding prior findings accelerates preparation.
- **Collaboration with Internal Audit**, They are your partners in preparation, not your adversaries.

## Architecture: The Audit Evidence Framework

### What Auditors Are Looking For

Across all frameworks, auditors evaluate IAM against a consistent set of control objectives:

**1. Access Provisioning Controls**
- Is access granted based on documented approval?
- Are access rights appropriate for the user's role?
- Is there a formal access request and approval workflow?

**2. Access Review Controls**
- Is existing access reviewed periodically?
- Are reviews performed by appropriate reviewers (managers, data owners)?
- Are review decisions documented and acted upon?

**3. Access Termination Controls**
- Is access revoked timely when employment ends?
- Are there orphan or dormant accounts?
- Is there a process to detect and remediate stale access?

**4. Privileged Access Controls**
- Is privileged access limited to those who need it?
- Is privileged access monitored and reviewed more frequently?
- Are privileged sessions logged and auditable?

**5. Segregation of Duties**
- Are conflicting duties identified and separated?
- Are SoD violations detected and remediated?
- Are exceptions documented with compensating controls?

**6. Authentication Controls**
- Is multi-factor authentication enforced?
- Are password policies appropriate?
- Are authentication events logged?

### Framework-Specific Requirements

**SOX (Sarbanes-Oxley):**
SOX focuses on the integrity of financial reporting. IAM controls are relevant because unauthorized access to financial systems could lead to fraudulent reporting.

Key SOX IAM requirements:
- Access to financial applications must be approved by management.
- Segregation of duties must prevent any individual from controlling all aspects of a financial transaction.
- Access reviews must be performed for systems that affect financial reporting.
- Terminated employees must lose access to financial systems immediately.
- Privileged access to financial databases and applications must be tightly controlled.

Audit scope: Applications that feed into, process, or report financial data. This typically includes ERP systems, general ledger, accounts payable/receivable, payroll, and financial reporting tools.

**SOC 2 (Service Organization Control):**
SOC 2 evaluates controls relevant to security, availability, processing integrity, confidentiality, and privacy. The Trust Services Criteria (TSC) define the control objectives.

Key SOC 2 IAM requirements (Common Criteria):
- CC6.1: Logical and physical access controls, the entity implements controls to restrict logical access based on authorization.
- CC6.2: Prior to issuing system credentials, the entity registers and authorizes new users with appropriate approval.
- CC6.3: The entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles.
- CC6.5: The entity discontinues logical and physical protections over assets only after the ability to protect them is transferred.

**HIPAA (Health Insurance Portability and Accountability Act):**
HIPAA's Security Rule requires covered entities and business associates to implement administrative, physical, and technical safeguards for electronic Protected Health Information (ePHI).

Key HIPAA IAM requirements:
- Unique user identification (164.312(a)(2)(i)), assign a unique identifier for each workforce member.
- Emergency access procedure (164.312(a)(2)(ii)), establish procedures for obtaining ePHI during emergencies.
- Automatic logoff (164.312(a)(2)(iii)), implement electronic procedures to terminate sessions after inactivity.
- Access control ([164.312(a)(1)](https://www.law.cornell.edu/cfr/text/45/164.312)), implement technical policies and procedures that allow access to ePHI systems only to persons or software programs granted access rights.
- Access authorization ([164.308(a)(4)(ii)(B)](https://www.law.cornell.edu/cfr/text/45/164.308), an addressable administrative safeguard), implement policies and procedures for granting access to ePHI, for example through access to a workstation, transaction, program, or process. The companion specification 164.308(a)(4)(ii)(C) covers establishing, documenting, reviewing, and modifying a user's access.
- Audit controls (164.312(b)), implement mechanisms to record and examine activity in systems containing ePHI.

## Step-by-Step: Audit Preparation

### Step 1: Determine Scope and Timeline

**Identify in-scope systems:**

For each regulatory framework, identify which applications, databases, and infrastructure components are in scope:

| Application | SOX In-Scope | SOC 2 In-Scope | HIPAA In-Scope | IAM Integrated |
|---|---|---|---|---|
| SAP ERP | Yes | No | No | Yes |
| AWS Production | Yes | Yes | Yes | Yes (SSO) |
| Salesforce | No | Yes | No | Yes (SSO) |
| Epic EHR | No | No | Yes | Partial |
| Jira | No | Yes | No | Yes (SSO) |

**Establish the audit period:**
- SOX: Fiscal year (Jan 1 - Dec 31 for calendar year companies)
- SOC 2 Type II: Typically 6 or 12 months
- HIPAA: Point-in-time assessment or review period as defined by the auditor

**Create a preparation timeline:**
- T-90 days: Begin evidence collection and gap analysis
- T-60 days: Remediate identified gaps
- T-30 days: Complete evidence packages and conduct dry run
- T-14 days: Final review with Internal Audit
- T-0: External audit fieldwork begins

### Step 2: Collect Access Evidence

**User access listings:**

For each in-scope application, generate a complete user access listing showing:
- User identifier (employee ID or username)
- Full name
- Job title and department
- Access level or role within the application
- Date access was granted
- Approver of the access
- Date of last access review
- Active/disabled status

Automate this extraction. Manual screenshots are error-prone and auditors will question them.

```sql
-- Example: Extract user access listing from your IAM platform
SELECT
  u.employee_id,
  u.display_name,
  u.department,
  u.job_title,
  ua.application_name,
  ua.role_name,
  ua.granted_date,
  ua.approved_by,
  ua.last_review_date,
  u.status
FROM users u
JOIN user_access ua ON u.id = ua.user_id
WHERE ua.application_name IN ('SAP', 'AWS-Production', 'Salesforce')
ORDER BY ua.application_name, u.display_name;
```

**Privileged access listings:**

Separately enumerate all privileged/admin access:
- System administrators
- Database administrators
- Application administrators
- Users with elevated roles (finance approvers, HR administrators)
- Service accounts with privileged access

**Terminated user access evidence:**

For each employee terminated during the audit period, provide:
- Termination date (from HR)
- Date account was disabled in the IdP
- Date access was revoked in each in-scope application
- Time delta between termination and access revocation

This is where many organizations fail. Auditors compare each time delta against your documented termination policy, so a multi-day lag on a policy that promises same-day removal is a finding.

### Step 3: Document Access Review Evidence

**Certification campaign records:**

For each access review campaign during the audit period, provide:
- Campaign scope (which applications, which users)
- Campaign dates (start, deadline, completion)
- Reviewer list (who reviewed which users)
- Decision records (for each entitlement: certified, revoked, or escalated)
- Completion rate (percentage of reviews completed)
- Revocation evidence (for items that were revoked, evidence that access was actually removed)

**Format evidence clearly:**

Auditors review hundreds of controls across many organizations. Make their job easy:

```
Access Review Campaign: Q1 2026 - Financial Applications
Period: January 15 - February 15, 2026
Applications: SAP ERP, Oracle Financials, Concur
Total entitlements reviewed: 2,847
Completion rate: 97.3%
Entitlements certified: 2,712 (95.3%)
Entitlements revoked: 108 (3.8%)
Entitlements pending (escalated): 27 (0.9%)
Revocations completed: 108/108 (100%), Evidence attached as Appendix C
```

### Step 4: Prepare Segregation of Duties Evidence

**SoD rule documentation:**

For each SoD rule, provide:
- Rule definition (which entitlements conflict and why)
- Business risk if the rule is violated
- Current violation count
- Remediation status for each violation
- Exception documentation for approved violations

**SoD exception documentation:**

For each approved SoD exception:
- The specific violation (user, conflicting entitlements)
- Business justification for the exception
- Compensating control description
- Approval from appropriate authority (typically CISO or CFO for financial SoD)
- Exception expiration date
- Evidence that the compensating control is operating effectively

### Step 5: Prepare Authentication and Policy Evidence

**MFA coverage evidence:**
- Total user population
- Users enrolled in MFA
- MFA enforcement policy (screenshot or export of conditional access policy)
- Exceptions to MFA policy with justification
- MFA method distribution (authenticator app, FIDO2, SMS)

**Password policy evidence:**
- Configured password policy (length, complexity, expiration, history)
- Policy enforcement mechanism (IdP configuration screenshot or export)
- Evidence that the policy applies to all in-scope applications

**Conditional access / login policy evidence:**
- All conditional access policies with descriptions
- Policy assignments (who is affected)
- Policy controls (what is enforced)
- Policy exceptions with justification

### Step 6: Conduct a Gap Analysis and Remediate

Before the audit, conduct an honest self-assessment:

**Common gaps and remediation:**

| Gap | Risk Level | Remediation | Timeline (rough estimate) |
|---|---|---|---|
| Terminated users with active access | Critical | Run reconciliation, disable accounts, implement automated deprovisioning | 2 weeks |
| No access reviews for some applications | High | Conduct retroactive review, implement ongoing schedule | 4 weeks |
| Undocumented SoD exceptions | High | Document existing exceptions with compensating controls | 2 weeks |
| Shared/generic accounts in use | Medium | Assign individual accounts, disable shared accounts | 6 weeks |
| Missing approval records for access grants | Medium | Implement request/approval workflow, retroactively document existing access | 4 weeks |
| MFA not enforced for all users | Medium | Enable MFA for remaining users, document exceptions | 3 weeks |

### Step 7: Package Evidence for Auditors

**Evidence package structure:**

```
IAM Audit Evidence Package
├── 1. Access Provisioning
│   ├── Access request and approval policy
│   ├── Sample access request approvals (the sample your auditor selects)
│   └── Access provisioning procedure documentation
├── 2. Access Reviews
│   ├── Access review policy
│   ├── Campaign records (Q1, Q2, Q3, Q4)
│   ├── Revocation evidence
│   └── Review completion reports
├── 3. Access Termination
│   ├── Termination procedure documentation
│   ├── Terminated user list with deprovisioning dates
│   └── Reconciliation evidence (no orphan accounts)
├── 4. Privileged Access
│   ├── Privileged access listing
│   ├── Privileged access review records
│   └── PAM session logs (sample)
├── 5. Segregation of Duties
│   ├── SoD rule matrix
│   ├── Current violation report
│   ├── Exception documentation
│   └── Compensating control evidence
├── 6. Authentication
│   ├── MFA policy and coverage report
│   ├── Password policy configuration
│   └── Conditional access policies
└── 7. Supporting Documentation
    ├── IAM architecture diagram
    ├── In-scope application inventory
    └── IAM policy and standards documents
```

## Best Practices

### Automate Evidence Collection

If evidence collection requires manual effort each audit cycle, it will be incomplete and error-prone. Automate:
- User access listing generation (scheduled exports from your IAM platform)
- Terminated user reconciliation (daily automated comparison of HR data and active accounts)
- Access review completion tracking (real-time dashboards from your IGA platform)
- Privileged access monitoring (continuous logging from your PAM solution)

### Maintain Continuous Audit Readiness

Do not prepare for audits. Maintain continuous compliance:
- Run access reviews on schedule throughout the year, not in a rush before the audit.
- Process terminations within hours, not days.
- Document SoD exceptions when they are approved, not when auditors ask.
- Generate evidence reports monthly, not annually.

Organizations that maintain continuous readiness spend a fraction of the time on audit preparation compared to those that scramble.

### Build Relationships with Auditors

External auditors are evaluating your controls, not trying to catch you. Early communication about your IAM program, proactive disclosure of known issues and remediation plans, and well-organized evidence packages build credibility. Auditors are far more understanding of issues you have identified and are actively remediating than issues they discover that you were unaware of.

### Track Remediation Formally

When auditors identify findings, track remediation with formal project management:
- Assign an owner to each finding
- Set a remediation deadline
- Define success criteria
- Report progress to the governance committee monthly
- Verify remediation before the next audit cycle

## Testing

### Dry Run Audit

Two months before the external audit:
1. Have Internal Audit or a trusted team member role-play as the external auditor.
2. Request the same evidence the external auditor will request.
3. Evaluate the completeness, accuracy, and organization of the evidence.
4. Identify gaps and remediate them before the real audit.

### Sample Testing

Auditors will sample your evidence. Pre-test your samples:
- Pull a random sample of terminated employees and verify all access was revoked within your policy.
- Pull a random sample of access grants and verify approval documentation exists.
- Pull a random sample of SoD exceptions and verify compensating controls are documented and operating.

If you find issues in your pre-test samples, investigate and remediate the underlying cause before the audit.

## Common Pitfalls

### Reactive Audit Preparation

Scrambling to produce evidence in the weeks before an audit is the most common failure mode. Evidence gathered under time pressure is incomplete, inconsistent, and raises auditor skepticism. Start preparation at least 90 days before fieldwork.

### Inconsistent Evidence Across Applications

If your user access listing for Application A is a database export and for Application B is a series of screenshots, auditors will question the reliability. Standardize evidence formats across all in-scope applications.

### Ignoring Service and System Accounts

Auditors increasingly scrutinize non-human accounts. If your privileged access listing only includes human administrators but your financial database has 15 service accounts with admin access, expect a finding.

### Providing Too Much or Too Little Evidence

Overwhelming auditors with raw data dumps is as problematic as providing insufficient evidence. Provide concise, well-organized evidence that directly addresses the control objective. Include summary reports with supporting detail available upon request.

### Not Addressing Prior Year Findings

Repeat findings are worse than first-time findings. They indicate that the organization is not taking compliance seriously. Prioritize remediating prior year findings above all else.

## Conclusion

IAM audit preparation is fundamentally about maintaining disciplined identity governance practices and being able to demonstrate them with evidence. The organizations that pass audits cleanly are not those with perfect IAM, they are those that have documented processes, execute them consistently, identify and remediate gaps proactively, and present evidence clearly.

Invest in automation for evidence collection, maintain continuous audit readiness rather than annual preparation sprints, and treat each audit cycle as an opportunity to improve your IAM program. Over time, audit preparation becomes a routine reporting exercise rather than a fire drill.

## IAM Career Paths: From Analyst to Identity Architect
Source: https://startwithidentity.com/guides/career/iam-career-paths/
Last updated: 2026-11-05

Identity and access management has grown from a back-office IT function into a core security
specialty, because identity is now how most attacks get in. This page is the map: the roles that
exist, what each one does every day, how people move between them, and which direction to grow.
For the step-by-step skills plan, see [how to become an identity engineer](https://startwithidentity.com/guides/career/how-to-become-an-identity-engineer/).

## Start here: the career hub in order

1. **This page** for the map of roles and tracks.
2. [How to become an identity engineer](https://startwithidentity.com/guides/career/how-to-become-an-identity-engineer/) for the skills and a lab plan.
3. [Identity security certifications](https://startwithidentity.com/guides/career/identity-security-certifications/) to choose a credential.
4. [IAM interview questions](https://startwithidentity.com/guides/career/iam-interview-questions/) to practice, plus the open-source [IAM interview questions bank](https://github.com/Start-With-Identity/iam-interview-questions).
5. [How to get an IAM job](https://startwithidentity.com/guides/career/how-to-get-an-iam-job/) for resume, portfolio, and the search itself.
6. [IAM salary guide](https://startwithidentity.com/guides/career/iam-salary-guide/) to benchmark, and [remote IAM jobs](https://startwithidentity.com/guides/career/remote-iam-jobs/) if you want to work remotely.

New to the concepts? Begin with the [start-here learning path](https://startwithidentity.com/start-here/) and
[what is IAM](https://startwithidentity.com/guides/fundamentals/what-is-iam/).

## Is the field growing?

Identity has no occupation code of its own in US government statistics; it sits inside
information security. The US Bureau of Labor Statistics
[projects 21 percent growth for information security analysts](https://www.bls.gov/ooh/computer-and-information-technology/information-security-analysts.htm)
from 2025 to 2035, with about 14,100 openings a year on average. Within that, identity is where a
large share of the work now lands: workforce SSO and MFA, customer login, governance audits, and
the fast-growing problem of [non-human and AI agent identities](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/).

## Where people start

- **IAM analyst or administrator:** runs the day-to-day. [Joiner-mover-leaver](https://startwithidentity.com/glossary/joiner-mover-leaver/),
  access requests, group management, MFA support. The best on-ramp because you learn how identity
  actually behaves in production, including the exceptions nobody documented.
- **Help desk or sysadmin crossover:** many strong IAM people arrive from IT operations after owning
  [Active Directory](https://startwithidentity.com/glossary/active-directory/), [Entra](https://startwithidentity.com/vendors/iam/microsoft-entra/), or
  [Okta](https://startwithidentity.com/vendors/iam/okta/). You already know the directory; the gap is usually protocols and
  automation.
- **Developer crossover:** engineers who implemented login with [OAuth and OIDC](https://startwithidentity.com/standards/openid-connect/)
  often move into customer identity ([CIAM](https://startwithidentity.com/guides/fundamentals/what-is-ciam/)) and
  [authorization](https://startwithidentity.com/guides/fundamentals/rbac-vs-abac-vs-rebac/). You already write code; the gap is
  usually enterprise federation and governance.
- **Security analyst crossover:** SOC and incident response people move into identity threat
  detection, because most of the incidents they triage start with a stolen credential or session.
- **Audit and GRC crossover:** auditors who tested access controls move into governance, where they
  already speak the language of [access certification](https://startwithidentity.com/glossary/access-certification/) and
  [separation of duties](https://startwithidentity.com/glossary/sod/).

## The tracks compared

| Track | What you own day to day | Core skills | Typical next step |
|---|---|---|---|
| Engineering | SSO, MFA, provisioning, federation, integrations | [SAML](https://startwithidentity.com/standards/saml-2-0/), OIDC, [SCIM](https://startwithidentity.com/standards/scim-2-0/), scripting, one or two platforms | Senior engineer, then identity architect |
| Governance (IGA) | Access reviews, role models, lifecycle rules, audit evidence | [IGA](https://startwithidentity.com/guides/fundamentals/what-is-iga/) platforms, role mining, SoD, regulatory controls | IGA lead, identity risk or governance manager |
| Privileged and identity security | Vaulting, just-in-time admin access, detections, incident response | [PAM](https://startwithidentity.com/guides/fundamentals/what-is-pam/), [ITDR](https://startwithidentity.com/guides/fundamentals/what-is-itdr/), AD and cloud attack paths | Identity security architect, detection lead |
| Customer identity (CIAM) | Sign-up, login, passkeys, fraud, consent at consumer scale | OAuth, [passkeys](https://startwithidentity.com/guides/authentication/passkeys-101/), API design, conversion metrics | CIAM architect, identity product lead |
| Leadership | Roadmap, budget, vendor selection, program metrics | Stakeholder management, risk framing, architecture literacy | Head of identity, CISO office |

## What changes at each level

Titles vary by company, so judge the role by scope rather than the word in front of "engineer."

- **Junior or associate:** executes defined tasks, such as onboarding an application to SSO from a
  runbook. Success is accuracy and learning speed.
- **Mid-level:** owns integrations end to end, including the ones that do not fit the runbook.
  Success is that the thing works and keeps working.
- **Senior:** owns a domain (all federation, or all provisioning) and makes design decisions inside
  it. Success is fewer incidents and less manual work.
- **Staff or architect:** owns how domains fit together: which IdP is authoritative, how workforce
  and customer identity relate, how [zero trust](https://startwithidentity.com/guides/fundamentals/what-is-zero-trust/) policy is
  enforced. Success is decisions that still look right three years later.
- **Manager or head of identity:** owns people, budget, and the program's risk story to the board.

The jump from senior to architect is the hardest, because it requires breadth across platforms and
tracks, and the confidence to say no to a design that works today but will not scale.

## Vendor, consultancy, or enterprise

Where you work shapes what you learn. **Enterprise** teams teach you messy reality: legacy apps,
mergers, audit deadlines. **Consultancies and integrators** give you many environments quickly, often
on one platform such as [SailPoint](https://startwithidentity.com/vendors/iga/sailpoint/) or Okta. **Vendors** give product depth
and, in engineering, protocol implementation experience; their sales engineering and customer
success roles are also a common path for people who like both technology and customers. Moving
between the three every few years is one of the fastest ways to build architect-level breadth.

## Specialist or generalist

Specialize early enough to be hireable, then broaden. A useful rule: be deep in one track and
conversant in the two next to it. A governance specialist who understands provisioning protocols
and privileged access is far more valuable than one who only knows the review campaign screens.
Learn one platform deeply, then a second, so you think in protocols and patterns rather than one
vendor's console.

## Where demand is moving

- **Non-human and agent identity:** service accounts, workloads, and AI agents need the same
  lifecycle and least-privilege discipline as people, and few teams have it yet. See [securing AI agent identities](https://startwithidentity.com/guides/machine-identity/securing-ai-agent-identities/).
- **Identity threat detection:** attackers log in rather than break in, so detection engineers who
  understand tokens and sessions are scarce. See the [attack techniques catalog](https://startwithidentity.com/techniques/).
- **Passwordless and phishing-resistant MFA:** rollouts of [passkeys](https://startwithidentity.com/guides/fundamentals/what-is-passwordless/)
  need engineers who understand both WebAuthn and recovery flows.
- **Decentralized identity:** EU digital identity wallets and [verifiable credentials](https://startwithidentity.com/standards/verifiable-credentials/)
  are creating a smaller, specialist track. See [what is self-sovereign identity](https://startwithidentity.com/guides/fundamentals/what-is-self-sovereign-identity/).

## Learn from people already on the path

Read how established practitioners describe their work in the [identity experts directory](https://startwithidentity.com/experts/),
for example [Ian Glazer](https://startwithidentity.com/experts/ian-glazer/) and [Pamela Dingle](https://startwithidentity.com/experts/pamela-dingle/). Listen to
practitioner shows such as [Identity at the Center](https://startwithidentity.com/podcasts/identity-at-the-center/), or follow a
topic through the [podcast learning paths](https://startwithidentity.com/podcasts/learn/). Conferences such as
[Identiverse](https://startwithidentity.com/conferences/identiverse/), [EIC](https://startwithidentity.com/conferences/eic/), and the
[Internet Identity Workshop](https://startwithidentity.com/conferences/iiw/) are where you meet the people who hire for identity roles; the
[conferences calendar](https://startwithidentity.com/conferences/) lists dates.

## Related

[How to become an identity engineer](https://startwithidentity.com/guides/career/how-to-become-an-identity-engineer/),
[certifications](https://startwithidentity.com/guides/career/identity-security-certifications/),
[interview questions](https://startwithidentity.com/guides/career/iam-interview-questions/), and
[IAM salary guide](https://startwithidentity.com/guides/career/iam-salary-guide/).

## IAM Cloud Migration Guide: From On-Prem Active Directory to Cloud Identity
Source: https://startwithidentity.com/guides/implementation/iam-cloud-migration-guide/
Last updated: 2026-11-05

For two decades, on-premises Active Directory has been the gravitational center of enterprise identity. Every employee account, group policy, service principal, and trust relationship lives in AD. But as organizations move workloads to the cloud, the limitations of a data-center-bound directory become painfully apparent: remote workers VPN back to authenticate, cloud applications require clunky federation bridges, and every new SaaS vendor asks why you cannot just use OIDC.

Migrating identity from on-premises AD to cloud IAM is one of the most consequential infrastructure projects an organization will undertake. Get it right and you gain modern authentication, eliminate hardware dependencies, and simplify operations. Get it wrong and you lock users out, break application integrations, and create a hybrid mess that is harder to manage than the original environment.

This guide provides a phased, risk-managed approach to IAM cloud migration that keeps the business running throughout the transition.

## What You Will Learn

- How to assess your current AD environment and plan the migration
- Designing a hybrid identity architecture for the coexistence phase
- Migrating users, groups, policies, and applications in the right order
- Managing the parallel-run period without doubling operational overhead
- Executing the cutover and decommissioning on-premises AD
- Handling the hardest migration challenges: service accounts, legacy apps, and GPOs

## Prerequisites

1. **Current state documentation**, You need a thorough inventory of your AD environment: domains, forests, trust relationships, domain controllers, sites, organizational units (OUs), Group Policy Objects (GPOs), and the applications that depend on AD for authentication or authorization.
2. **Cloud IAM tenant**, An established cloud identity platform tenant. This guide uses Microsoft Entra ID (Azure AD) as the primary example because it has the most mature AD migration path, but the principles apply to Okta, Google Workspace, or JumpCloud migrations as well.
3. **Hybrid connectivity**, Network connectivity between your on-premises environment and the cloud tenant. For Entra ID, this means Entra Connect Sync (formerly Azure AD Connect) or Entra Cloud Sync provisioning agents are deployed or can be deployed. For other platforms, equivalent directory sync agents.
4. **Application inventory**, A catalog of every application that authenticates against AD, including authentication protocol (Kerberos, NTLM, LDAP, SAML, OIDC), level of criticality, and the application owner.
5. **Stakeholder alignment**, Migration touches every department. IT operations, security, compliance, HR, and application owners all need to understand the timeline and their responsibilities.

## Architecture Overview

IAM cloud migration is not a forklift move. It is a graduated transition through three architectural phases: on-premises, hybrid, and cloud-native. As a typical practitioner estimate, most organizations will spend 12-24 months in the hybrid phase, and some will remain there permanently for specific workloads.

### Phase 1: On-Premises (Current State)

Active Directory Domain Services (AD DS) running on domain controllers in your data center. All authentication flows through Kerberos or NTLM. Group Policy manages device configuration. LDAP provides directory lookups for applications. Federation services (ADFS) bridge to cloud applications.

### Phase 2: Hybrid Identity (Transition State)

A cloud directory (Entra ID) synchronized with on-premises AD via a sync agent. Users have a single identity that works in both environments. Authentication can happen on-premises (for legacy apps) or in the cloud (for SaaS and modern apps). This is the coexistence phase where both directories are authoritative for different things.

### Phase 3: Cloud-Native (Target State)

The cloud directory is the authoritative identity source. On-premises AD is either decommissioned entirely or reduced to a minimal footprint for legacy applications that cannot migrate. New users are created in the cloud directory. Policies are managed through cloud-native tools (Conditional Access, Intune) rather than GPOs. Authentication is passwordless, modern, and location-independent.

### Key Decision: Migration Scope

Not every organization needs to reach Phase 3 for every workload. The right target state depends on your environment:

- **Full cloud migration:** All applications can authenticate via modern protocols (SAML, OIDC, SCIM). No Kerberos/NTLM/LDAP dependencies remain. On-premises AD is decommissioned completely.
- **Hybrid permanent:** Cloud IAM is primary for most users and applications, but a reduced on-premises AD remains for legacy applications, manufacturing systems, or air-gapped environments that cannot use cloud authentication.
- **Staged migration:** Different business units or regions migrate at different speeds based on their application portfolio and regulatory requirements.

## Step-by-Step Implementation

### Step 1: Assess the Current Environment

A thorough assessment prevents surprises during migration. Examine the following:

**Domain and forest topology:**

- How many forests and domains exist? Single-forest, single-domain is the simplest migration. Multi-forest environments require careful planning around which forest becomes the cloud sync source.
- Are there external trust relationships with partner organizations? These will need to be replaced with cloud federation.
- What is the domain functional level? Older functional levels may lack features needed for hybrid operation.

**User and group analysis:**

- Total user count (enabled and disabled). Cloud licensing is per-user, so this determines cost.
- Group count and nesting depth. Deeply nested groups (more than 3 levels) cause sync issues and should be flattened before migration.
- Distribution lists vs. security groups. Cloud platforms handle these differently.
- UPN (User Principal Name) format. Cloud authentication requires routable UPNs (e.g., `user@company.com`, not `user@company.local`). If your AD uses a non-routable UPN suffix, you need to add a routable suffix and update user accounts before sync.

**Authentication protocol inventory:**

Catalog every authentication protocol in use and the applications that depend on each:

- **Kerberos:** The default for domain-joined Windows applications. Cannot be used directly in the cloud. Applications using Kerberos need migration to modern protocols or need an on-premises presence (domain controller, application proxy) to continue functioning.
- **NTLM:** Legacy protocol used by older applications. Similar constraints to Kerberos but weaker security. Prioritize migrating NTLM-dependent applications.
- **LDAP / LDAPS:** Applications that query AD directly for user lookups, group membership checks, or authentication. Cloud alternatives include Entra ID Domain Services (managed LDAP) or application-level migration to Graph API / SCIM.
- **SAML / OIDC:** Already cloud-ready. These applications need minimal changes, just point them at the cloud IdP instead of ADFS.

**Group Policy inventory:**

Export all GPOs and categorize them:

- **Device configuration:** Mapped to Intune configuration profiles or compliance policies.
- **Security settings:** Mapped to Conditional Access policies and security baselines.
- **Software deployment:** Mapped to Intune application deployment or endpoint management tools.
- **Login scripts:** Need to be replaced with cloud-native equivalents (Intune scripts, Azure Automation).

### Step 2: Prepare the Environment

**Fix UPN suffixes:** If your AD uses non-routable suffixes (`.local`, `.internal`), add a routable suffix matching your verified domain and update user accounts. This can be scripted for bulk updates but should be tested with a pilot group first.

```powershell
# Add routable UPN suffix to AD forest
Set-ADForest -Identity "company.local" `
  -UPNSuffixes @{Add="company.com"}

# Update user UPN (pilot group)
Get-ADUser -Filter {Department -eq "IT"} |
  ForEach-Object {
    $newUPN = $_.SamAccountName + "@company.com"
    Set-ADUser $_ -UserPrincipalName $newUPN
  }
```

**Clean up stale objects:** Disable or delete user accounts that have not authenticated in 90+ days. Remove empty groups, orphaned computer accounts, and obsolete OUs. Every stale object you sync to the cloud is wasted licensing and noise.

**Flatten group nesting:** Reduce group nesting to a maximum of 2 levels. Cloud sync handles nesting but deep hierarchies cause performance issues and confusing authorization behavior.

**Document service accounts:** Identify every service account, what it is used for, what applications depend on it, and whether it can be migrated to a managed identity or cloud service principal. This is typically the most time-consuming preparation step.

**Configure hybrid networking:** Establish connectivity between your on-premises network and the cloud tenant. For Azure, this means Azure ExpressRoute or VPN Gateway. Verify that DNS resolution works in both directions.

### Step 3: Deploy Hybrid Identity Synchronization

This step establishes the bridge between on-premises AD and the cloud directory.

**For Microsoft Entra ID:**

1. Choose the sync engine. [Microsoft Entra Cloud Sync](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync) runs lightweight provisioning agents that need only outbound connections, keeps its configuration in the cloud, and handles disconnected forests natively. Microsoft Entra Connect Sync (formerly Azure AD Connect) is the older server-based engine; use it when the [Cloud Sync decision guide](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/connect-to-cloud-sync-decision-guide) shows a feature gap for your environment. If you deploy Connect Sync, put it on a dedicated, domain-joined server, not a domain controller.
2. Configure sync scope: select the OUs containing users and groups to sync. Exclude service accounts, computer accounts, and OUs containing objects you cleaned up in Step 2.
3. Choose the authentication method:
   - **Password Hash Sync (PHS):** Syncs a hash of the password hash to Entra ID. Simplest, most resilient option. Users can authenticate to the cloud even if on-premises AD is down. Recommended as the baseline.
   - **Pass-Through Authentication (PTA):** Authentication requests are forwarded to on-premises AD in real time. No password data stored in the cloud. Requires on-premises agents to be available for every authentication.
   - **Federation (ADFS):** All authentication handled by on-premises ADFS. Most complex, least resilient. Only recommended if you have regulatory requirements that prevent any form of password sync.
4. Enable Password Hash Sync even if you choose PTA or ADFS as the primary method. PHS serves as a disaster recovery fallback.
5. Plan desktop single sign-on. On Windows 10 and later, Microsoft recommends SSO through the Primary Refresh Token on Entra joined or Entra hybrid joined devices. Microsoft Entra desktop SSO (Kerberos-based, enabled through Entra Connect) covers older domain-joined devices on the corporate network and works only with PHS or PTA, not AD FS ([Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso)).
6. Run an initial sync and verify: user accounts appear in Entra ID with correct UPN, display name, and group memberships.

**For other platforms:**

- **Okta:** Deploy the Okta AD Agent on a domain-joined server. Configure import rules and attribute mapping in the Okta admin console.
- **Google Workspace:** Deploy Google Cloud Directory Sync (GCDS) to synchronize users and groups.
- **JumpCloud:** Deploy the JumpCloud AD Bridge agent for bidirectional sync.

### Step 4: Migrate Authentication Sources

With hybrid sync running, begin migrating applications from on-premises authentication to cloud authentication.

**Priority order:**

1. **SaaS applications currently using ADFS federation.** Redirect their federation trust from ADFS to Entra ID (or your cloud IdP). This is often a metadata swap, update the SP's IdP metadata URL. Test with a pilot group before switching all users.

2. **Internal web applications using SAML/OIDC.** Update the application's IdP configuration to point at the cloud IdP. If the application uses client libraries (MSAL, passport.js), update the authority URL.

3. **Internal web applications using Windows Integrated Authentication (Kerberos).** Deploy Entra Application Proxy (or equivalent reverse proxy) to broker Kerberos authentication. The proxy authenticates the user via the cloud IdP, then performs Kerberos constrained delegation to the backend application. The application does not change.

4. **LDAP-dependent applications.** Options include:
   - Migrate the application to use Graph API or SCIM for directory queries (best option if the application supports it).
   - Deploy Entra ID Domain Services, which provides managed LDAP and Kerberos endpoints backed by the cloud directory.
   - Maintain a minimal on-premises AD specifically for these applications (hybrid permanent).

5. **Thick client and desktop applications using Kerberos/NTLM.** These are the hardest to migrate. Options include application modernization, terminal server deployment with cloud authentication at the gateway, or maintaining on-premises AD for these specific applications.

### Step 5: Migrate Device Management

Replace Group Policy with cloud-native device management:

1. **Enable Entra ID Join** for new devices. New devices are joined to Entra ID rather than on-premises AD. They are managed by Intune rather than Group Policy.
2. **Migrate existing devices** using Hybrid Entra ID Join as a transitional step. Devices remain joined to on-premises AD but are also registered in Entra ID, allowing Intune policies to be applied alongside GPOs.
3. **Translate GPOs to Intune policies.** Use the Group Policy Analytics tool in Intune to identify which GPOs have direct cloud equivalents. Manually translate custom GPOs.
4. **Phase out GPO dependency.** Once Intune policies cover all required configurations, begin removing GPO assignments. Keep GPOs in place but disabled for rollback during the transition.

### Step 6: Implement Cloud-Native Security Controls

Replace on-premises security infrastructure with cloud-native equivalents:

**Conditional Access replaces network-based security:**

On-premises AD relied on the corporate network as a security boundary. Cloud IAM uses Conditional Access policies that evaluate device compliance, user risk, sign-in risk, location, and application sensitivity to make per-request access decisions.

Build a Conditional Access policy set that covers:

- Require MFA for all users (baseline policy)
- Block legacy authentication protocols (NTLM, basic auth over IMAP/POP)
- Require compliant devices for access to sensitive applications
- Block sign-ins from countries where you do not operate
- Require phishing-resistant MFA (passkeys, certificate-based auth) for administrative roles

**Identity Protection replaces on-premises monitoring:**

Enable risk-based policies that detect and respond to compromised credentials, impossible travel, anonymous network usage, and malware-linked IP addresses.

**Privileged Identity Management (PIM) replaces static admin group membership:**

Configure JIT activation for all privileged cloud roles. Administrators request time-bounded role activation instead of having permanent membership.

### Step 7: Execute the Cutover

The cutover is the point where the cloud directory becomes authoritative and on-premises AD is decommissioned (or reduced to minimal footprint).

**Cutover prerequisites:**

- All user accounts are synced and authentication works via the cloud IdP
- All business-critical applications are migrated to cloud authentication
- All devices are managed via cloud device management (or hybrid joined with Intune coverage)
- Break-glass cloud admin accounts are configured and tested
- A rollback plan exists for each migration component

**Cutover execution:**

1. Make the cloud the source of authority. Entra Connect Sync and Cloud Sync do not have a switch that reverses the sync direction. Instead, create new users directly in Entra ID (typically from HR-driven provisioning) and [transfer the source of authority](https://learn.microsoft.com/en-us/entra/identity/hybrid/user-source-of-authority-overview) for existing synced users to Entra ID. Transfer is not supported for users who still sign in through AD FS, so finish the staged move to cloud authentication first. Users who still need on-premises Kerberos apps get an AD account through Cloud Sync's [provisioning from Entra ID to Active Directory](https://learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/overview-provision-entra-id-to-active-directory); everyone else can have their AD account removed.
2. Disable ADFS relying party trusts. All federation traffic now goes directly to the cloud IdP.
3. Decommission ADFS servers after a 30-day monitoring period confirms no traffic.
4. Begin domain controller decommission. Remove DCs from non-primary sites first. Keep at least two DCs in the primary site until all on-premises dependencies are eliminated.
5. After a 90-day stabilization period with no on-premises authentication activity, decommission the remaining domain controllers and the AD domain.

**Rollback plan:** At each cutover step, document the rollback procedure. The most critical rollback is re-enabling ADFS if cloud authentication fails. Keep ADFS servers in a stopped-but-recoverable state for 90 days after decommission.

## Configuration Best Practices

**Sync only what you need.** Do not sync your entire AD to the cloud. Exclude service accounts, test accounts, computer accounts, and administrative OUs that should remain on-premises.

**Use staged rollout for authentication changes.** Entra ID supports staged rollout, which lets you migrate specific groups of users to cloud authentication while others remain on ADFS. Use this to migrate department by department rather than all-at-once.

**Enable self-service password reset (SSPR) early.** Cloud SSPR with password writeback to on-premises AD reduces help-desk burden during the transition and gives users a consistent password reset experience regardless of where they authenticate.

**Monitor sync health religiously.** Sync failures cause users to have stale attributes in the cloud, leading to authentication and authorization issues. Set up alerts for sync errors and treat them as high-priority incidents.

**License planning.** Cloud IAM platforms charge per user. Entra ID P1 or P2 licenses are required for Conditional Access, PIM, and Identity Protection. Budget for these licenses before migration.

## Testing and Validation

1. **Pilot group testing.** Migrate a small, technically savvy group first (IT staff or willing volunteers). Run them in cloud-only authentication for 2-4 weeks and collect every issue.
2. **Application testing.** For each migrated application, verify: authentication works, attributes are correct, authorization (group-based access) is preserved, and logout/session management behaves correctly.
3. **Device management testing.** Verify that Intune policies produce the same device configuration as the GPOs they replace. Check BitLocker, firewall rules, update policies, and software deployment.
4. **Disaster recovery testing.** Simulate cloud IdP unavailability and verify break-glass procedures work. Simulate on-premises AD unavailability and verify cloud-authenticated users are unaffected.
5. **Performance testing.** Measure authentication latency from all major office locations and for remote users. Cloud authentication should be equal to or faster than on-premises for most users.

## Common Pitfalls

**Underestimating service account dependencies.** Service accounts are the hidden iceberg of AD migration. They connect applications to databases, run scheduled tasks, and authenticate machine-to-machine communication. Each one needs individual analysis and a migration plan. Budget more time for this than you think.

**Ignoring UPN cleanup.** Syncing users with `.local` UPN suffixes causes authentication failures in the cloud. This should be the first preparation step, not an afterthought.

**Trying to replicate AD exactly in the cloud.** Cloud IAM platforms are not AD in the sky. Trying to replicate every OU structure, GPO, and delegation model leads to an overcomplicated cloud configuration. Take the migration as an opportunity to simplify.

**Skipping the hybrid phase.** Some organizations try to go directly from on-premises to cloud-native. This works only if you have a very small, modern application portfolio. For most enterprises, the hybrid phase is essential for managing risk.

**Neglecting end-user communication.** Users will notice changes: new login prompts, MFA enrollment, different password reset flows. Communicate each change before it happens, provide clear instructions, and staff the help desk for increased volume during transition weeks.

**ADFS retirement procrastination.** ADFS is a security liability (it has been the target of multiple high-profile attacks including Golden SAML). Once applications are migrated to cloud federation, decommission ADFS promptly rather than leaving it running "just in case."

## Security Considerations

**Protect the sync server.** The Entra Connect server has access to both on-premises AD and the cloud tenant. A compromised sync server can manipulate identity data in both directions. Harden it as Tier 0 infrastructure: restrict access, monitor logs, and apply patches immediately.

**Disable legacy authentication.** Cloud migration is the ideal time to block legacy protocols (NTLM, basic auth) that are exploited in credential attacks. Use Conditional Access to block legacy auth and monitor sign-in logs for any remaining legacy traffic.

**Implement phishing-resistant MFA.** Moving to the cloud means your users authenticate over the internet. Password-only authentication is not acceptable. Deploy phishing-resistant MFA (FIDO2 keys, passkeys, certificate-based auth) for all users, with priority on administrators.

**Monitor for hybrid identity attacks.** During the coexistence phase, attacks can exploit the sync relationship. Monitor for suspicious changes to synced attributes, unexpected sync agent registrations, and attempts to modify the sync configuration.

## Conclusion

Migrating IAM from on-premises Active Directory to cloud identity is a transformative project that touches every corner of the organization. The key to success is a phased approach: establish hybrid coexistence, migrate applications in priority order, replace GPOs with cloud-native policies, and execute the cutover only when you have validated every dependency.

The organizations that execute this migration well emerge with an identity infrastructure that is more secure, more scalable, and fundamentally better suited to modern work patterns. The organizations that rush it or skip steps end up with a fragile hybrid that combines the worst of both worlds.

Take the time to do it right. Your identity infrastructure is the foundation everything else rests on.

## IAM Disaster Recovery: Building Resilient Identity Infrastructure
Source: https://startwithidentity.com/guides/implementation/iam-disaster-recovery-guide/
Last updated: 2026-11-05

When your identity provider goes down, everything goes down. Users cannot authenticate, applications cannot authorize, APIs cannot validate tokens, and your organization grinds to a halt. Unlike a single application failure that affects one business process, an identity outage is a cascading catastrophe that impacts every connected system simultaneously.

IAM disaster recovery (DR) is not optional. It is the single most critical DR domain in modern IT because identity is the dependency that all other systems share. This guide covers how to design, implement, and test DR for your identity infrastructure.

## Prerequisites

- **Documented identity architecture**, A complete inventory of your IdP, directories, federation services, MFA providers, and all downstream dependencies.
- **Business impact analysis**, Understanding of which business processes depend on identity services and their tolerance for downtime.
- **Executive sponsorship**, DR investment requires budget for redundant infrastructure, and leadership must understand the business case.
- **Monitoring and alerting**, You cannot recover from what you do not detect. Identity service monitoring must be in place before DR planning.

## Architecture: Identity DR Framework

### Understanding Identity Dependencies

Map your identity dependency chain:

```
Users / Applications
    ↓
Load Balancer / DNS
    ↓
Identity Provider (Entra ID, Okta, Ping, etc.)
    ↓ ↓ ↓
Directory Store    MFA Service    Federation Service
    ↓                 ↓                ↓
LDAP/AD DS     Authenticator App   SAML/OIDC Metadata
    ↓           Push Service        Certificate Store
Database/         SMS Gateway
Replication       FIDO2 Service
```

Every component in this chain is a potential failure point. Your DR plan must address each one.

### RTO and RPO for Identity Services

**Recovery Time Objective (RTO)**, How quickly must identity services be restored?

For most organizations, identity RTO should be measured in minutes, not hours. The tiers below are typical practitioner estimates, not a standard; set your own from a business impact analysis:
- **Tier 1 (Critical):** 5-15 minutes, Authentication, token validation, MFA
- **Tier 2 (Important):** 1-4 hours, Provisioning, access reviews, self-service password reset
- **Tier 3 (Standard):** 24 hours, Reporting, analytics, non-critical integrations

**Recovery Point Objective (RPO)**, How much data loss is acceptable?

- **Directory data:** Near-zero RPO. User accounts, group memberships, and access policies must be current. Even minutes of data loss can mean recently offboarded users regain access.
- **Audit logs:** 1-hour RPO (a practitioner estimate) acceptable if logs are streamed to a separate SIEM in real time.
- **Configuration:** Near-zero RPO for policies. All conditional access, MFA, and federation configs must be recoverable to the exact pre-failure state.

## Step-by-Step Implementation

### Step 1: Architect for High Availability First

DR starts with high availability (HA). Before planning for disaster scenarios, eliminate single points of failure in normal operations.

**For cloud IdPs (Entra ID, Okta, Auth0):**

Cloud identity providers handle infrastructure HA for you, geo-distributed data centers, automatic failover, and built-in replication. Your responsibility is:

- Ensure your network can reach the IdP through multiple paths (dual ISPs, SD-WAN).
- Configure DNS with appropriate TTLs for IdP endpoints.
- Maintain local caching proxies for token validation during brief outages.
- Monitor the IdP's status page and subscribe to incident notifications.

**For on-premises IdPs (Active Directory, LDAP):**

- Deploy a minimum of two domain controllers per site.
- Place domain controllers in different failure domains (different racks, power circuits, network switches).
- Ensure at least one FSMO role holder is in each major site.
- Configure Active Directory Sites and Services for optimal replication topology.
- Deploy read-only domain controllers (RODCs) in branch offices.

**For hybrid environments:**

- Maintain Entra Connect (formerly Azure AD Connect) servers in active-passive configuration.
- Stage a warm standby Connect server that can be activated within minutes.
- Ensure the sync engine database is backed up and restorable.

### Step 2: Implement Directory Replication and Backup

**Active Directory backup strategy:**

1. **System State backup**, Back up at least two domain controllers' system state daily. System state includes the AD database (NTDS.DIT), SYSVOL, registry, and certificate services.
2. **Backup retention**, Retain backups for longer than your AD tombstone lifetime (default 180 days). If you need to recover a deleted object, you need a backup from before the deletion.
3. **Backup verification**, Monthly test restores to an isolated environment. A backup you have never tested is not a backup.
4. **Backup storage**, Store backups in a location that does not depend on AD for access. If your backup system requires AD authentication to retrieve backups, you have a circular dependency.

**Cloud directory backup strategy:**

Cloud IdPs typically do not support traditional backup/restore. Instead:

- **Export configurations regularly**, Use APIs to export conditional access policies, named locations, group configurations, app registrations, and service principals. Store these exports in version control.
- **Recycle bin**, Enable the directory recycle bin (Entra soft delete retains deleted users for 30 days).
- **Configuration as code**, Manage IdP configuration through Terraform, Pulumi, or the IdP's own IaC tooling. This gives you version history and the ability to redeploy configuration.

### Step 3: Plan for IdP Failover Scenarios

**Scenario 1: Cloud IdP outage**

When your cloud IdP (Entra, Okta) experiences a global outage:

- **Token caching**, Applications that validate tokens locally (using cached signing keys) can continue operating for the lifetime of existing tokens. Configure token lifetimes strategically, longer lifetimes increase resilience but reduce security responsiveness.
- **Cached credentials**, Windows devices with cached logon credentials allow users to access local resources. Configure group policy to allow sufficient cached logons (default is 10).
- **Break-glass procedures**, Maintain local admin accounts on critical servers that do not depend on the IdP. These accounts should be stored in sealed envelopes or a hardware security module.
- **Secondary IdP**, For organizations that cannot tolerate any identity downtime, maintain a secondary IdP (e.g., an on-premises ADFS instance that can be activated if Entra is unavailable). This is expensive and complex but provides true failover capability.

**Scenario 2: On-premises AD outage (all domain controllers down)**

- **Authoritative restore**, If the AD database is corrupted, perform an authoritative restore from the most recent verified backup.
- **Forest recovery**, If the entire forest is compromised, follow Microsoft's AD forest recovery procedure: isolate, restore one DC per domain, verify replication, and rebuild.
- **Cloud continuity**, If you use hybrid identity, Entra ID retains a copy of all synced identities. Users can continue authenticating to cloud apps even if on-premises AD is completely down.

**Scenario 3: MFA provider outage**

- **Multiple MFA methods**, Require users to register at least two MFA methods. If push notifications fail, TOTP codes or FIDO2 keys still work.
- **Temporary MFA bypass**, Pre-configure emergency conditional access policies that relax MFA requirements during provider outages. These policies should require approval from two security team members to activate. They cannot lift Microsoft's mandatory MFA on Azure and Microsoft admin portals, which is why break-glass accounts need FIDO2 keys or certificate-based authentication rather than no MFA.
- **SMS fallback**, While SMS is the weakest MFA factor, it uses different infrastructure than app-based push. Consider allowing SMS as a last-resort fallback during outages.

### Step 4: Implement Configuration Backup and Recovery

Identity configuration is as critical as identity data. A restored directory with missing conditional access policies is dangerously exposed.

**What to back up:**

- Conditional access policies (all policy definitions, named locations, terms of use)
- Application registrations and service principals
- Group definitions and membership rules (dynamic groups)
- Role assignments (PIM configurations)
- Authentication methods policies
- Cross-tenant access settings
- Identity Protection policies
- Custom security attributes

**How to back up:**

Use Microsoft Graph API or the IdP's equivalent API to export configurations as JSON:

```bash
# Example: Export conditional access policies
az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" \
  --output json > ca-policies-backup-$(date +%Y%m%d).json

# Example: Export named locations
az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/identity/conditionalAccess/namedLocations" \
  --output json > named-locations-backup-$(date +%Y%m%d).json
```

Automate this daily and store exports in a Git repository for version history.

### Step 5: Build and Document Recovery Procedures

**Recovery runbook template:**

For each DR scenario, document:

1. **Detection**, How will we know this failure has occurred? (Monitoring alerts, user reports, vendor status page)
2. **Assessment**, How do we determine the scope of impact? (Which services are affected, how many users)
3. **Communication**, Who do we notify? (Incident commander, security team, leadership, affected users)
4. **Decision**, Under what conditions do we activate DR? (Duration threshold, scope threshold)
5. **Execution**, Step-by-step recovery actions with specific commands and expected outcomes.
6. **Validation**, How do we verify identity services are functioning correctly? (Test authentications, token validation, provisioning)
7. **Return to normal**, Steps to deactivate DR measures and return to primary infrastructure.
8. **Post-incident**, Review, lessons learned, runbook updates.

### Step 6: Establish Emergency Access

Emergency access procedures ensure that critical administrative actions can be performed even during identity outages.

**Break-glass accounts:**
- Create at least two cloud-only Global Administrator accounts on the `*.onmicrosoft.com` domain, not federated or synchronized from on-premises AD.
- Register phishing-resistant MFA on every break-glass account: a FIDO2 security key (passkey), or certificate-based authentication if you already run PKI. Microsoft's [mandatory MFA enforcement](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mandatory-multifactor-authentication) for the Azure portal, Entra admin center, Intune admin center and Microsoft 365 admin center applies to break-glass accounts too, with no exclusion, so an account without MFA cannot reach those portals.
- Use a different method from your everyday admin accounts (for example, FIDO2 keys if admins normally use Microsoft Authenticator), and do not tie the credential to any one person's phone.
- Store the keys and any passwords in fireproof safes in separate locations.
- Exclude the accounts from Conditional Access policies that block or restrict sign-in, using a dedicated group. Report-only policies need no exclusion.
- Configure Azure Monitor or Microsoft Sentinel alerts on any sign-in to these accounts.
- Test at least every 90 days and after admin staff changes: verify the accounts can sign in and perform administrative actions.

These steps follow Microsoft's [emergency access account guidance](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access).

**Local recovery accounts:**
- Maintain local administrator accounts on critical servers.
- Store credentials in a Privileged Access Management (PAM) vault that does not depend on the IdP being recovered.
- Document which servers have local accounts and their purposes.

## Best Practices

### Test Quarterly, Not Annually

Annual DR tests are insufficient for identity services. The identity landscape changes too frequently, new applications, new conditional access policies, new federation trusts. Test quarterly with tabletop exercises and semi-annually with actual failover tests.

### Separate Your Monitoring from Your Identity

If your monitoring system authenticates through the same IdP you are monitoring, you will not receive alerts when that IdP fails. Ensure your identity monitoring uses a separate authentication path, API keys, local service accounts, or a different IdP.

### Document Your Dependencies Obsessively

Maintain a live dependency map that shows every application, API, and service that depends on each identity component. When an identity service fails, this map tells you exactly what is impacted and in what order to restore.

### Automate Recovery Where Possible

Manual recovery procedures are slow and error-prone during high-stress incidents. Automate what you can: failover scripts, configuration redeployment, health checks, and notification workflows. But always maintain manual runbooks as a fallback.

## Testing

### Tabletop Exercise

Gather your identity team, security team, and key application owners. Present a scenario (e.g., "Entra ID has been experiencing intermittent authentication failures for 30 minutes, impacting all cloud applications") and walk through your response plan. Identify gaps and update procedures.

### Controlled Failover Test

In a maintenance window:
1. Simulate a component failure (shut down a domain controller, disable a federation trust, block network access to the IdP).
2. Verify detection, did monitoring alerts fire?
3. Execute recovery procedures, did they work as documented?
4. Measure recovery time, did you meet your RTO?
5. Validate functionality, can users authenticate and access applications?
6. Restore normal operations and verify no data loss.

### Chaos Engineering for Identity

For mature organizations, introduce controlled identity failures in production:
- Briefly disable a single domain controller during business hours.
- Simulate MFA provider latency by introducing network delays.
- Revoke a federation signing certificate in a test environment to verify certificate rollover procedures.

## Common Pitfalls

### Circular Dependencies

The most dangerous DR pitfall is a circular dependency: you need System A to recover System B, but System A depends on System B for authentication. Common examples:
- PAM vault requires AD authentication, but AD recovery credentials are in the vault.
- Backup system requires SSO, but SSO is down.
- Communication tools require identity, so you cannot coordinate recovery.

Audit every step of your recovery procedures for circular dependencies and break them with local accounts, offline credential storage, or alternative communication channels.

### Ignoring Certificate and Key Expiration

Federation trusts, SAML signing certificates, and OIDC signing keys expire. If a certificate expires during a disaster and you need to rebuild a federation trust, you need access to the certificate management system, which may itself depend on identity services. Maintain offline copies of all identity-related certificates and their renewal procedures.

### Over-Relying on Vendor SLAs

Your cloud IdP's 99.99% SLA means they expect up to 52 minutes of downtime per year. That is 52 minutes where your entire organization cannot authenticate. SLAs provide financial credits, not business continuity. Plan for outages that exceed the SLA.

### Not Testing with Real Applications

Testing DR by verifying that users can sign in is insufficient. Test that end-to-end application workflows function, can users access data, can APIs authorize requests, can provisioning pipelines execute? The authentication may work, but downstream dependencies may have cached stale state.

## Conclusion

Identity disaster recovery is unique because identity is the universal dependency. When identity fails, the blast radius is your entire organization. The investment in redundancy, backup, and tested recovery procedures is justified by the catastrophic cost of an extended identity outage.

Build your DR program in layers: high availability first, then backup and configuration management, then failover procedures, and finally regular testing. Document everything, test frequently, and ruthlessly eliminate circular dependencies. The organizations that recover fastest from identity disasters are those that practiced for them.

## IAM Interview Questions: What Identity Roles Actually Test
Source: https://startwithidentity.com/guides/career/iam-interview-questions/
Last updated: 2026-11-05

Identity interviews probe whether you understand protocols as mechanisms, can reason about
trade-offs, and know how identity fails in practice. This page gives real technical questions with
model answers: the level of detail a strong mid-level or senior candidate gives. Answer in your own
words; interviewers follow up on whatever you say, so only claim what you can defend.

> **Practice with the full question bank.** For hundreds more questions with model-answer notes,
> organized by topic and tagged Junior, Mid, or Senior, use our free, open-source
> [IAM Interview Questions repository](https://github.com/Start-With-Identity/iam-interview-questions)
> on GitHub. Contributions welcome, and every contributor is credited.

## Protocols and tokens

**Q: What is the difference between authentication and authorization, and why is an OAuth access
token not proof of login?**
Authentication establishes who the user is; authorization decides what a caller may do. An OAuth
access token is issued to a client for an API (its audience is the resource server), and it says
nothing reliable about whether or when the user authenticated to your application. To log a user
in, use OpenID Connect and validate the [ID token](https://startwithidentity.com/glossary/id-token/), whose audience is your
client. See [authentication vs authorization](https://startwithidentity.com/guides/fundamentals/authentication-vs-authorization/).

**Q: Walk me through the authorization code flow with PKCE.**
The client generates a random `code_verifier`, hashes it with SHA-256 into a `code_challenge`, and
redirects the browser to the authorization endpoint with the challenge, `state`, and requested
scopes. The user authenticates; the server redirects back with a short-lived code. The client
exchanges the code at the token endpoint and includes the original verifier. The server hashes the
verifier and compares it with the stored challenge, so an attacker who intercepted the code cannot
redeem it. [RFC 9700](https://www.rfc-editor.org/rfc/rfc9700.html) makes PKCE mandatory for public
clients and recommended for confidential ones. See [PKCE](https://startwithidentity.com/glossary/pkce/).

**Q: Why is the implicit flow discouraged?**
It returns access tokens in the redirect URL fragment, where they can leak through browser history,
referrer headers, and injected scripts, and there is no way to bind the token to the client that
started the flow. RFC 9700 says clients should not use it and should use the authorization code
flow instead. The OAuth 2.1 draft drops it entirely. See [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/).

**Q: How do you validate a JWT?**
Parse the header, but do not trust its `alg`: verify against an allow-list you configure, as
[RFC 8725](https://www.rfc-editor.org/rfc/rfc8725.html) requires, which defeats `none` and the
RS256-to-HS256 key confusion attack. Fetch the issuer's signing key from its [JWKS](https://startwithidentity.com/glossary/jwks/)
by `kid`, caching and refreshing on unknown `kid` to survive rotation. Verify the signature. Then
check `iss` is the expected issuer, `aud` contains your identifier, `exp` and `nbf` are within
tolerance, and any `nonce` matches the one you sent. Only then read claims.
Practice with the [validate a JWT recipe](https://startwithidentity.com/recipes/validate-a-jwt/).

**Q: A stolen refresh token is being replayed. What controls exist?**
Short refresh token lifetimes, rotation (each use returns a new refresh token and invalidates the
old one, so replay of an old token is detectable), and sender-constraining with
[DPoP](https://startwithidentity.com/glossary/dpop/) ([RFC 9449](https://www.rfc-editor.org/rfc/rfc9449.html)) or mTLS so the token
is useless without the client's private key. RFC 9700 requires one of rotation or sender-constraining
for public clients. See the [refresh token abuse technique](https://startwithidentity.com/techniques/refresh-token-abuse/).

**Q: What does a service provider check on a SAML response?**
That the assertion (not just the outer response) is signed by the IdP's expected certificate; that
the signature covers the element you are actually reading, which defends against XML signature
wrapping; that `AudienceRestriction` names your entity ID; that `Recipient` matches your assertion
consumer service URL; that `NotOnOrAfter` has not passed; and, for SP-initiated flows, that
`InResponseTo` matches a request you sent, which blocks replay of unsolicited assertions. See
[SAML 2.0](https://startwithidentity.com/standards/saml-2-0/) and [federation trust abuse](https://startwithidentity.com/techniques/federation-trust-abuse-saml-forgery/).

**Q: SAML or OIDC for a new enterprise SaaS app?**
Support both. Enterprise customers bring SAML IdPs and will not change for you; OIDC is simpler to
implement, mobile-friendly, and the base for newer standards. If you can only ship one first, ask
what your first ten customers run. See [SAML vs OIDC](https://startwithidentity.com/guides/fundamentals/saml-vs-oidc/).

## Lifecycle and governance

**Q: An employee is terminated. Walk through deprovisioning.**
HR marks the termination in the system of record, the IdP disables the account and revokes sessions
and refresh tokens, and [SCIM](https://startwithidentity.com/standards/scim-2-0/) sends `active: false` to connected
applications. Then handle what SCIM does not reach: local accounts, shared credentials, API keys
the person created, and owned [service accounts](https://startwithidentity.com/glossary/service-account/), which need a new owner.
A strong answer mentions that disabling the IdP account does not end sessions already issued by
downstream apps.

**Q: How do you stop a re-hire from getting a duplicate account?**
Match on a stable identifier, typically the HR employee ID sent as `externalId`, not on email.
Reactivate the existing record with a PATCH setting `active: true`, and do not restore old
entitlements automatically; grant them fresh from the new role.

**Q: Access reviews are rubber-stamped. How do you fix that?**
Shrink what reviewers see: remove birthright access from campaigns, highlight only changes and
high-risk entitlements, provide usage data, and revoke on non-response rather than approve. Pair
reviews with event-driven mover checks, because most excess access comes from
[mover accumulation](https://startwithidentity.com/techniques/mover-entitlement-accumulation/). See
[access certification](https://startwithidentity.com/glossary/access-certification/).

## Authentication and attacks

**Q: How do attackers get past MFA?**
Push fatigue ([MFA fatigue](https://startwithidentity.com/techniques/mfa-fatigue-push-bombing/)), adversary-in-the-middle proxies
that relay the password and code and steal the session cookie
([AiTM phishing](https://startwithidentity.com/techniques/aitm-phishing-proxy/)), [help desk social engineering](https://startwithidentity.com/techniques/help-desk-social-engineering/)
to reset the factor, and [session cookie theft](https://startwithidentity.com/techniques/session-cookie-theft/) by infostealers
after login. Phishing-resistant authenticators (FIDO2 and passkeys) bind the signature to the real
origin, which defeats relay; recovery and help desk processes need equally strong verification.

**Q: Are synced passkeys good enough?**
For most workforce and consumer use, yes: they are phishing resistant and much better than
passwords plus SMS. NIST [SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html) does not allow
exportable keys at AAL3, so the highest-assurance cases need device-bound authenticators such as
hardware security keys. See [synced passkey](https://startwithidentity.com/glossary/synced-passkey/).

**Q: What is Kerberoasting and how do you reduce it?**
Any domain user can request a service ticket for an account with a service principal name; part of
the ticket is encrypted with that account's password hash, so it can be cracked offline. Reduce it
with long random passwords or group managed service accounts, AES-only encryption, removing
unneeded SPNs, and alerting on unusual ticket request volume. See
[Kerberoasting](https://startwithidentity.com/techniques/kerberoasting/).

## Design questions

**Q: Design SSO and lifecycle for a 5,000-person company.**
Structure the answer: (1) sources of truth, HR as authoritative for people; (2) one workforce IdP;
(3) OIDC or SAML for every app, with an inventory of apps that support neither; (4) SCIM for
provisioning, with a plan for non-SCIM apps; (5) MFA policy, phishing-resistant for admins first;
(6) [conditional access](https://startwithidentity.com/glossary/conditional-access/) on device and risk; (7) joiner-mover-leaver
automation; (8) break-glass accounts; (9) logging into the SIEM; (10) how you measure success. Name
the trade-offs you are making as you go.

**Q: How would you replace long-lived cloud keys in CI pipelines?**
Use [workload identity federation](https://startwithidentity.com/glossary/workload-identity-federation/): the CI platform issues
a short-lived OIDC token per job, the cloud provider trusts that issuer with conditions on
repository and branch, and the job exchanges it for temporary credentials. No stored secret remains
to leak. See [secrets in repositories and CI](https://startwithidentity.com/techniques/secrets-in-repositories-and-ci/).

## Behavioral questions

Expect "tell me about an outage you caused," "a time you said no to a stakeholder," and "a migration
that went badly." Pick stories with a specific technical decision, what you measured, and what you
changed afterward. For incident stories, walk through a real case from the [breach teardowns](https://startwithidentity.com/breaches/),
such as the [Okta 2023 support system breach](https://startwithidentity.com/breaches/okta-2023-support-system-breach/), and name
the control that would have stopped it.

## How to prepare

Build something, read the [standards](https://startwithidentity.com/standards/), study the [techniques](https://startwithidentity.com/techniques/), and practice
explaining trade-offs out loud. Record yourself answering three questions from this page and listen
for definitions where there should be mechanisms. Then drill with the
[IAM Interview Questions repository](https://github.com/Start-With-Identity/iam-interview-questions),
which tags every question by level.

## Your next step

Move to [how to get an IAM job](https://startwithidentity.com/guides/career/how-to-get-an-iam-job/) for the resume and portfolio,
and the [IAM salary guide](https://startwithidentity.com/guides/career/iam-salary-guide/) to benchmark offers. For the bigger
picture, see [IAM career paths](https://startwithidentity.com/guides/career/iam-career-paths/) and
[how to become an identity engineer](https://startwithidentity.com/guides/career/how-to-become-an-identity-engineer/).

## IAM Salary Guide 2026: Identity Engineer, Architect, and Leadership Pay
Source: https://startwithidentity.com/guides/career/iam-salary-guide/
Last updated: 2026-11-05

IAM and identity security are well paid within security, because the work is business-critical,
audited, and the experienced talent pool is small. This guide sticks to what public data actually
shows, explains how identity roles map onto it, and spends most of its time on what moves an
individual number up. We do not publish invented salary bands: where no named public source
exists, we describe the pattern without a figure.

## The honest starting point

No government statistics agency tracks "IAM engineer" as an occupation. In the US Standard
Occupational Classification, identity work is spread across a few occupations. The US Bureau of
Labor Statistics (BLS) publishes wages for those from its Occupational Employment and Wage
Statistics survey, most recently for **May 2025**. Those are the most defensible public numbers
available, so use them as the floor of your research, then refine with the salary ranges in actual
job postings.

## What BLS reports (May 2025, US, annual wages)

| BLS occupation | How identity roles map | Lowest 10% | Median | Highest 10% |
|---|---|---|---|---|
| [Information security analysts](https://www.bls.gov/ooh/computer-and-information-technology/information-security-analysts.htm) | IAM analyst, IAM engineer, PAM and identity security engineer | below 75,090 | 129,180 | above 199,850 |
| [Computer network architects](https://www.bls.gov/ooh/computer-and-information-technology/computer-network-architects.htm) | Closest public proxy for identity and security architects | below 79,900 | 134,050 | above 202,680 |
| [Computer and information systems managers](https://www.bls.gov/ooh/management/computer-and-information-systems-managers.htm) | IAM manager, director of identity, head of identity | not used here | 175,140 | not used here |

Figures in US dollars, base wages, from the BLS Occupational Outlook Handbook pages linked above.
The median wage for all US occupations in May 2025 was 50,980 US dollars.

For information security analysts, BLS also reports median wages by industry: 138,650 US dollars
in information, 132,410 in computer systems design and related services, 130,630 in finance and
insurance, 128,950 in management of companies and enterprises, and 125,420 in management,
scientific, and technical consulting services. The spread between industries is smaller than the
spread between the bottom and top 10 percent, which tells you that level and specialty matter more
than sector.

## How to read these numbers

- **They are base wages, not total compensation.** Bonus and equity at large or venture-backed
  companies, and commission in vendor field roles, are not included.
- **They blend levels.** The information security analyst median includes junior SOC analysts and
  senior engineers. A senior identity engineer should expect to sit above the median, a first-year
  IAM analyst below it.
- **They are US only.** For other countries, use that country's statistics office and local posted
  ranges; do not convert US figures.
- **They lag.** May 2025 data published in 2026 describes the market a year earlier.
- **They are not identity-specific.** An information security analyst can be a SOC analyst, a
  vulnerability manager, or an IAM engineer. Treat the occupation as the neighborhood identity pay
  lives in, not the address.

To refine, collect 15 to 20 postings for your exact role on the [IAM jobs board](https://startwithidentity.com/jobs/) and in your
region, and record the posted ranges where employers publish them. That gives you a current,
role-specific band no survey can.

## What moves IAM pay up

- **Specialty.** Privileged access, cloud entitlements, and identity threat detection sit near the
  top of what employers will pay because mistakes there are expensive and experienced people are
  few. See [what is PAM](https://startwithidentity.com/guides/fundamentals/what-is-pam/), [what is CIEM](https://startwithidentity.com/guides/fundamentals/what-is-ciem/),
  and [what is ITDR](https://startwithidentity.com/guides/fundamentals/what-is-itdr/).
- **Cloud and automation depth.** Engineers who wire identity across AWS, Azure, and GCP and manage
  configuration as code are paid differently from those who only operate a console.
- **Software skills in customer identity.** [CIAM](https://startwithidentity.com/guides/fundamentals/what-is-ciam/) roles at
  product companies are often on the software engineering pay ladder, not the IT one, which can be a
  large difference at the same level.
- **Scale and regulation.** Experience at large, regulated organizations (finance, healthcare,
  government) raises both the floor and the ceiling. See the [compliance guides](https://startwithidentity.com/guides/compliance/soc2-for-identity/).
- **Architecture and outcomes.** Moving from running tools to designing systems, and pointing to
  measurable results (audit findings closed, access reviews automated, standing admin access
  removed) is the clearest path to the higher bands. See [IAM career paths](https://startwithidentity.com/guides/career/iam-career-paths/).
- **New problem areas.** [Non-human identity](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/) and AI
  agent security have few experienced practitioners yet, which gives early specialists a
  stronger hand in a negotiation.

## What does not move pay much on its own

A long list of certifications without matching experience, years spent on one console without
growing scope, and job title inflation at a small company. Hiring managers price the problems you
can solve, so translate every credential into an outcome.

## How to use this in a negotiation

1. **Anchor on scope, not title.** "Owns federation for 40,000 users and 300 applications" is a
   stronger anchor than "Senior IAM Engineer."
2. **Bring evidence.** What you built, what it reduced or prevented, and which of the skills above
   you hold. A portfolio link helps here too; see [how to get an IAM job](https://startwithidentity.com/guides/career/how-to-get-an-iam-job/).
3. **Use the posted range.** Where the employer publishes a range, ask where in it the offer sits
   and what would move it to the top.
4. **Negotiate the whole package.** If base is fixed, negotiate signing bonus, equity, a training and
   certification budget, conference travel to events such as [Identiverse](https://startwithidentity.com/conferences/identiverse/),
   or remote flexibility.
5. **Ask how remote pay works.** Some employers pay one national band, others adjust by location.
   See [remote IAM jobs](https://startwithidentity.com/guides/career/remote-iam-jobs/).

## Your next step

To grow into the higher bands, see [how to become an identity engineer](https://startwithidentity.com/guides/career/how-to-become-an-identity-engineer/)
and [identity security certifications](https://startwithidentity.com/guides/career/identity-security-certifications/), rehearse with
the [IAM interview questions](https://startwithidentity.com/guides/career/iam-interview-questions/), and check current openings on
the [IAM jobs board](https://startwithidentity.com/jobs/).

## Identity and Access Management Certifications, Ranked by Use
Source: https://startwithidentity.com/guides/career/identity-security-certifications/
Last updated: 2026-11-05

Certifications will not make you an identity engineer on their own, but the right ones validate
fundamentals, satisfy HR filters, and give your study a structure. This page is the reference for
which credential to pick: who issues it, what the exam looks like, what it costs, and how it
renews, using only what each issuer publishes. Facts were checked against the issuers' own pages
on 2026-11-05. If you are still deciding which kind of identity work you want, read
[IAM career paths](https://startwithidentity.com/guides/career/iam-career-paths/) first.

## The short answer

- **Starting out in a Microsoft shop:** Identity and Access Administrator Associate (SC-300).
- **Starting out in an Okta shop:** Okta Certified Professional, then Administrator.
- **Want to prove breadth beyond one product:** IDPro CIDPRO.
- **Governance or privileged access specialist:** SailPoint or CyberArk credentials for the
  platform you run.
- **Moving into senior, architect, or leadership roles:** CISSP or CISM.

## At a glance

| Certification | Issuer | Type | Prerequisite | Published exam facts | Renewal |
|---|---|---|---|---|---|
| CIDPRO (Certified Identity Professional) | IDPro | Vendor-neutral, identity-specific | None stated | 750 USD; 50 USD practice exam | See IDPro |
| CISSP | ISC2 | Broad security | 5 years of work experience | CAT, 100 to 150 items, 3 hours, pass at 700 of 1000 | CPE-based |
| CISM | ISACA | Security management | Experience requirement via application | 4 domains | CPE-based |
| Identity and Access Administrator Associate (SC-300) | Microsoft | Platform (Entra) | None | 100 minutes, proctored via Pearson VUE | Every 12 months, free online assessment |
| Okta Certified Professional, Administrator, Consultant, Developer, Technical Architect | Okta | Platform | Ladder (see below) | 250 USD first attempt, 100 USD retake | Valid 2 years |
| Identity Security Engineer, IdentityIQ Engineer, Identity Security Administrator | SailPoint | Platform (IGA) | See SailPoint | Not published on the pages we checked | 2-year extension program |
| Defender, Sentry, Guardian | CyberArk (now part of Idira) | Platform (PAM) | Ladder | Delivered through Pearson VUE | See vendor |

## Vendor-neutral

**[CIDPRO](https://idpro.org/cidpro/)** is IDPro's Certified Identity Professional program, which
IDPro describes as a vendor-neutral certification developed with a global team of identity
practitioners. The exam costs 750 US dollars, with discounts for individual and corporate IDPro
members, and a 50 US dollar practice exam is available. Registration runs through Webassessor.
The best preparation is free: the IDPro Body of Knowledge and its reference resources. CIDPRO is
the only certification here that tests identity as a discipline rather than one product or
security in general, which makes it the strongest signal for architect-track and consulting work.
It is less often named in job postings than CISSP or SC-300, so treat it as a credibility and
learning asset more than an HR keyword.

**[CISSP](https://www.isc2.org/certifications/cissp)** from ISC2 requires five years of paid work
experience. The [current exam outline](https://www.isc2.org/certifications/cissp/cissp-certification-exam-outline),
effective 15 April 2024, uses computerized adaptive testing with 100 to 150 items over three hours,
and a passing score of 700 out of 1000. Identity and Access Management is domain 5, weighted at an
average 13 percent. ISC2 has announced that a new outline takes effect on 15 April 2027, so anyone
booking for 2027 should study against that version. CISSP is not an identity credential, but
leadership job descriptions and government contracts often require it.

**[CISM](https://www.isaca.org/credentialing/cism)** from ISACA covers four domains: information
security governance, information security risk management, information security program, and
incident management. It suits people heading toward identity program leadership or the CISO office
more than hands-on engineers.

## Platform certifications

**Microsoft Certified: [Identity and Access Administrator Associate](https://learn.microsoft.com/en-us/credentials/certifications/identity-and-access-administrator/)**
(exam SC-300) is the practical default for anyone working where organizations run [Microsoft Entra](https://startwithidentity.com/vendors/iam/microsoft-entra/). The exam assesses four areas:
user identities, authentication and access management, workload identities, and identity
governance. Microsoft expects familiarity with Active Directory Domain Services, PowerShell, and
Kusto Query Language. You get 100 minutes, the exam is proctored, and pricing depends on the country
where it is proctored. The certification expires after 12 months unless you pass the free online
renewal assessment. Microsoft notes the English version was updated on 28 October 2026, so use the
current study guide, not an older course. Pair it with our
[conditional access policies guide](https://startwithidentity.com/guides/implementation/conditional-access-policies-guide/).

**[Okta certifications](https://okta.com/services/certification/)** form a ladder. Okta Certified
Professional and Okta Certified Developer have no prerequisite. Administrator requires
Professional; Consultant requires Professional and Administrator; Technical Architect requires
Professional, Administrator, Consultant, and Developer, and ends with a board defense. Auth0 Certified Developer covers [Auth0](https://startwithidentity.com/vendors/ciam/auth0/), and there
are specialty exams for Workflows and Access Gateway. Standard exams cost 250 US dollars for the
first attempt and 100 US dollars per retake; the Technical Architect board defense costs 5,000 US
dollars. Exams are proctored online through ProctorU, and certifications are valid for two years.
These matter most in [Okta](https://startwithidentity.com/vendors/iam/okta/) environments and at Okta partners.

**SailPoint** certifications cover its two platforms. In a
[February 2026 announcement](https://www.sailpoint.com/press-releases/sailpoint-launches-recertification-program),
[SailPoint](https://startwithidentity.com/vendors/iga/sailpoint/) named the Identity Security Engineer and IdentityIQ Engineer
credentials, added a new Identity Security Administrator certification, and launched a
recertification program that extends certifications by two years. Choose IdentityIQ if you work on
the self-hosted product and Identity Security Engineer for the SaaS platform. They matter most in [IGA](https://startwithidentity.com/guides/fundamentals/what-is-iga/) delivery and consulting
roles built on SailPoint.

**CyberArk** certifications follow a Defender, Sentry, Guardian ladder. The
[Pearson VUE CyberArk page](https://www.pearsonvue.com/us/en/cyberark.html) lists Defender exams for
Access, EPM, and PAM; Sentry exams for PAM, Privilege Cloud, and Secrets Manager; and a single
Guardian exam. Palo Alto Networks acquired CyberArk and relaunched the portfolio as
[Idira (formerly CyberArk)](https://startwithidentity.com/vendors/pam/cyberark/) in 2026, but on the date we checked the exams
were still listed under the CyberArk name. Expect renaming, and confirm the current exam title
before you book. They matter most in [PAM](https://startwithidentity.com/guides/fundamentals/what-is-pam/) roles built on that
platform.

Other vendors, including [Ping Identity](https://startwithidentity.com/vendors/iam/ping-identity/) and
[Saviynt](https://startwithidentity.com/vendors/iga/saviynt/), run their own programs. Take them if your employer or target
consultancy runs that platform; they carry little weight outside it.

## How to choose

1. **Match the stack you will touch.** A platform certification for the product in the job
   description beats a prestigious one for a product the team does not run. Read 10 target postings
   on the [IAM jobs board](https://startwithidentity.com/jobs/) and count which names recur.
2. **Sequence platform, then breadth, then leadership.** Early career: SC-300 or Okta Professional.
   Mid career: CIDPRO, or a second platform to break single-vendor thinking. Senior: CISSP or CISM if
   the roles you want ask for it.
3. **Count the renewal cost.** Microsoft's annual renewal is free but recurring. Okta's two-year
   cycle means a maintenance exam. CISSP and CISM require continuing education credits. Holding five
   certifications means five renewal calendars.
4. **Do not let the exam replace the lab.** Each certification is far easier, and far more useful,
   if you have built the thing first. Our [how to become an identity engineer](https://startwithidentity.com/guides/career/how-to-become-an-identity-engineer/)
   guide has a lab plan that maps onto SC-300 and Okta Professional topics.

## What certifications do not prove

An exam shows you know where the settings are. It does not show you can debug a broken
[SAML](https://startwithidentity.com/standards/saml-2-0/) assertion, reason about [PKCE](https://startwithidentity.com/glossary/pkce/) downgrade, or design
[zero standing privileges](https://startwithidentity.com/guides/implementation/zero-standing-privileges-rollout/). Interviewers
test those directly, so budget at least as much time for hands-on work and the
[IAM interview questions](https://startwithidentity.com/guides/career/iam-interview-questions/) as for exam prep.

## Your next step

Prepare for interviews with our [IAM interview questions](https://startwithidentity.com/guides/career/iam-interview-questions/)
and the open-source [interview questions bank](https://github.com/Start-With-Identity/iam-interview-questions),
then work through [how to get an IAM job](https://startwithidentity.com/guides/career/how-to-get-an-iam-job/). For structured
listening while you study, the [podcast learning paths](https://startwithidentity.com/podcasts/learn/) group episodes by topic.
Vendor conferences such as [Oktane](https://startwithidentity.com/conferences/oktane/) and
[SailPoint Navigate](https://startwithidentity.com/conferences/sailpoint-navigate/) are built around those platforms if you want
to meet the people who run them; see all events on the [conferences](https://startwithidentity.com/conferences/) page.

## Identity Controls for DORA
Source: https://startwithidentity.com/guides/compliance/identity-controls-for-dora/
Last updated: 2026-11-05

DORA identity controls are the access, authentication and account rules that EU financial entities must run under the [Digital Operational Resilience Act (DORA)](https://startwithidentity.com/regulations/european-union/dora/), Regulation (EU) 2022/2554, which has applied since 17 January 2025. The detail sits in Commission Delegated Regulation (EU) 2024/1774: unique accounts for every person and system, least privilege, strong authentication for remote, privileged and critical access, and access-right updates at least every six months for systems supporting critical or important functions. This guide is for IAM and security teams at banks, insurers, investment firms, payment institutions and their ICT providers.

## What the law and the RTS say

DORA itself is short on identity detail. [Article 9(4)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng) requires policies that limit physical and logical access to what legitimate, approved functions need, and policies and protocols for strong authentication mechanisms based on relevant standards. The [ICT risk management RTS, Delegated Regulation 2024/1774](https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng), adopted 13 March 2024, turns that into checkable requirements:

| Provision | Requirement | What you build |
|---|---|---|
| RTS Art. 20(2)(a) | A unique identity and user account for each staff member, including staff of third-party ICT providers | No shared vendor logins; every provider engineer is a named account |
| RTS Art. 20(2)(b) | Records of all identity assignments, kept after a reorganisation or the end of a contract | Retained provisioning history, not just current state |
| RTS Art. 20(2)(c) | Lifecycle process covering creation, change, review, temporary deactivation and termination, automated where applicable | [Joiner-mover-leaver](https://startwithidentity.com/glossary/joiner-mover-leaver/) automation through IGA and [SCIM](https://startwithidentity.com/standards/scim-2-0/) |
| RTS Art. 21(1)(a)-(b) | Need-to-know, need-to-use and [least privilege](https://startwithidentity.com/glossary/least-privilege/), including remote and emergency access; segregation of duties | Role model plus toxic-combination rules |
| RTS Art. 21(1)(c) | Limit generic and shared accounts; users identifiable for their actions at all times | Shared admin accounts retired or vaulted with check-out attribution |
| RTS Art. 21(1)(e) | Privileged, emergency and administrator access on a need-to-use or ad-hoc basis, dedicated admin accounts, automated PAM where applicable; revoke without undue delay | [Just-in-time](https://startwithidentity.com/glossary/jit-access/) elevation, separate admin identities |
| RTS Art. 21(1)(e)(iv) | Update access rights at least once a year for all ICT systems, and at least every six months for systems supporting critical or important functions | A six-month [access certification](https://startwithidentity.com/glossary/access-certification/) cycle for critical systems |
| RTS Art. 21(1)(f) | Authentication commensurate with asset classification; strong authentication for remote network access, privileged access, critical or important functions, and publicly accessible assets | [Phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/) on those four paths first |

Smaller and non-interconnected entities that qualify for the simplified ICT risk management framework (Title III of the same RTS) get a lighter version: access rights must still be periodically reviewed and withdrawn when no longer required, but the fixed six-month interval does not apply.

## The incident clock

The [incident reporting RTS, Delegated Regulation 2025/301](https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng), sets the deadlines identity detection has to support. The EBA summarises them as an initial notification within [4 hours after classification as major and 24 hours after detection](https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/operational-resilience/joint-technical-standards-major-incident-reporting), an intermediate report within 72 hours, and a final report within one month. An intrusion that signs in with valid credentials produces no malware alert, so if identity telemetry is not watched, the 24-hour clock can expire before anyone knows it started.

## What makes DORA different from a checklist

DORA is a resilience regulation, not a control catalogue, so the question is not whether a control exists but whether you can show it works under stress. For identity that means three testable claims:

- **You can revoke access fast enough to matter.** Not just disable an account, but revoke [refresh tokens](https://startwithidentity.com/glossary/refresh-token/) and sessions, including for third-party ICT providers, and evidence the timeline.
- **You can detect identity-based incidents inside the reporting window.** Feed identity signals into [ITDR](https://startwithidentity.com/glossary/itdr/) or your SOC so a normal-looking login by the wrong person still alerts.
- **You can operate during degradation.** If your identity provider is unavailable, nobody signs in to respond. A tested [break-glass](https://startwithidentity.com/glossary/break-glass/) path is a resilience control, not an IT convenience.

## Third-party ICT access is the exposure

DORA extends scrutiny to ICT providers and requires a Register of Information on ICT third-party arrangements. Vendor access is consistently the least governed path in a financial institution: standing accounts, shared credentials, and remote sessions nobody records. RTS Article 20 removes the shared-login option by requiring unique accounts for provider staff.

The incidents show why:

- **A provider's API key.** At the [US Treasury](https://startwithidentity.com/breaches/incidents/2024-us-treasury-beyondtrust-api-key/), an attacker obtained a key [BeyondTrust](https://startwithidentity.com/vendors/pam/beyondtrust/) used to secure its Remote Support SaaS, bypassed the service's security and remotely accessed Treasury workstations. That is [static API key abuse](https://startwithidentity.com/techniques/static-api-key-abuse/) against the vendor, not the customer.
- **A provider's management plane.** In the [N-able N-central incident](https://startwithidentity.com/breaches/incidents/2026-n-able-n-central-auth-bypass/), attackers exploited [CVE-2026-18577](https://startwithidentity.com/cves/cve-2026-18577/), an authentication bypass giving unauthenticated administrative access, then used Take Control remote sessions to reach systems in managed customer environments. N-able said its first hotfix was incomplete before a second shipped on 7 August 2026.
- **A supplier developer's session.** The [Bybit theft](https://startwithidentity.com/breaches/incidents/2025-bybit-safe-wallet-aws-session-hijack/) of about 1.5 billion dollars in ether ran through a compromised Safe{Wallet} developer machine and hijacked AWS session tokens, a case of [token replay](https://startwithidentity.com/techniques/token-replay-unbound-endpoint/).

## Decision table: where to spend first

| If your gap is... | Do this first | Tool category |
|---|---|---|
| Shared or standing vendor accounts | Named accounts per provider engineer, time-bound grants, session recording | [PAM](https://startwithidentity.com/vendors/pam/) |
| No six-month review evidence for critical systems | Scope critical or important functions, run a certification with revocation counts | [IGA](https://startwithidentity.com/vendors/iga/) |
| Password-only remote or admin access | Phishing-resistant MFA on the four RTS 21(1)(f) paths | IdP plus [MFA](https://startwithidentity.com/vendors/mfa/) |
| No identity detection feeding the 4-hour clock | Identity threat detection wired to incident classification | [ITDR](https://startwithidentity.com/vendors/itdr/) |
| Static secrets in automation and provider integrations | Vault, rotate, then move to short-lived workload credentials | [Secrets management](https://startwithidentity.com/vendors/secrets/) |

Ownership moved in 2026 for several tools on a typical DORA shortlist, which matters for your Register of Information and concentration-risk view. In PAM, [Idira (formerly CyberArk)](https://startwithidentity.com/vendors/pam/cyberark/) is part of Palo Alto Networks since 11 February 2026, and [Delinea](https://startwithidentity.com/vendors/pam/delinea/) closed its acquisition of [StrongDM](https://startwithidentity.com/vendors/pam/strongdm/) on 5 March 2026. In IGA, [SailPoint](https://startwithidentity.com/vendors/iga/sailpoint/) and [Saviynt](https://startwithidentity.com/vendors/iga/saviynt/) remain independent, while [Veza](https://startwithidentity.com/vendors/iga/veza/) is part of ServiceNow since 2 March 2026. For authentication, [Microsoft Entra ID](https://startwithidentity.com/vendors/iam/microsoft-entra/) and [Okta](https://startwithidentity.com/vendors/iam/okta/) cover most workforce estates, with [Yubico](https://startwithidentity.com/vendors/mfa/yubico/) keys for administrators. For identity detection, [Microsoft Defender for Identity](https://startwithidentity.com/vendors/itdr/microsoft-defender-identity/) and [Silverfort](https://startwithidentity.com/vendors/itdr/silverfort/) are common in Active Directory-heavy banks. [HashiCorp Vault](https://startwithidentity.com/vendors/machine-identity/hashicorp-vault/) has been an IBM subsidiary since 27 February 2025.

## Evidence to keep

Access review output with revocation counts per cycle, the list of systems you classify as supporting critical or important functions (it sets the review interval), privileged session recordings, the MFA exemption list with review dates, third-party access grants with their expiry, retained identity assignment records for ended contracts, and incident timelines from detection to notification. See [zero standing privileges](https://startwithidentity.com/glossary/zero-standing-privileges/).

## Where to start

1. **Inventory third-party ICT access.** Every provider account, remote session path and management platform with reach into your environment, each named, owned and expiring.
2. **Classify systems, then set review cadence.** Six-month certifications for critical or important functions, annual for the rest. Planning estimate, not a regulatory figure: a first full cycle usually takes one quarter to stand up.
3. **Close strong-authentication gaps** on remote, privileged, critical and internet-facing access.
4. **Prove revocation speed.** Disable an account and revoke its sessions and tokens, including a provider account, and record the timeline.
5. **Test the break-glass path.** Simulate an identity provider outage, use the emergency accounts, and keep the logged and reviewed record.

## Related

[Identity controls for NIS2](https://startwithidentity.com/guides/compliance/identity-controls-for-nis2/), [IAM audit preparation](https://startwithidentity.com/guides/compliance/iam-audit-preparation-guide/), [financial services vertical](https://startwithidentity.com/verticals/financial-services/), [insurance vertical](https://startwithidentity.com/verticals/insurance/), [best identity tools for financial services](https://startwithidentity.com/rankings/best-identity-tools-financial-services/), [compliance calendar](https://startwithidentity.com/regulations/calendar/).

## Identity Controls for HIPAA
Source: https://startwithidentity.com/guides/compliance/identity-controls-for-hipaa/
Last updated: 2026-11-05

[HIPAA](https://startwithidentity.com/regulations/united-states/hipaa/)'s Security Rule requires safeguards for electronic protected health information (ePHI), and its access-related standards are about identity: who can reach ePHI, how they are authenticated, and how access is controlled in fast-moving clinical settings.

## What HIPAA expects of identity

The Security Rule's technical safeguards include:

- **Access control:** unique user identification, emergency access procedure, automatic logoff, and encryption.
- **Person or entity authentication:** verify that a user is who they claim to be.
- **Audit controls:** record and examine access to systems with ePHI.

These sit in [45 CFR 164.312](https://www.law.cornell.edu/cfr/text/45/164.312). The administrative safeguards add access authorization and access establishment and modification under [164.308(a)(4)](https://www.law.cornell.edu/cfr/text/45/164.308), which is where provisioning approvals and access reviews are anchored.

### The proposed Security Rule update

HHS published a [proposed rule to strengthen the Security Rule](https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information) on 6 January 2025 (90 FR 898, RIN 0945-AA22; comments closed 7 March 2025). It would remove the distinction between required and addressable specifications and require MFA across relevant systems. It is not final: the [Fall 2025 Unified Agenda](https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202510&RIN=0945-AA22) lists it under long-term actions with a final action date of July 2027. The current rule still applies, but building to the proposal's MFA expectation now avoids rework. See the [healthcare vertical](https://startwithidentity.com/verticals/healthcare/) for the wider regulatory picture.

## What good looks like

- Unique identities for every clinician and staff member, no shared logins, with [MFA](https://startwithidentity.com/vendors/mfa/) for remote and privileged access.
- Fast, secure authentication suited to clinical workflows, where badge tap-and-go and [passwordless](https://startwithidentity.com/guides/fundamentals/what-is-passwordless/) reduce friction on shared workstations. This is why healthcare-specific access vendors exist.
- Role-based access to ePHI with periodic [access reviews](https://startwithidentity.com/glossary/access-certification/), and prompt [deprovisioning](https://startwithidentity.com/glossary/deprovisioning/) of leavers.
- Emergency (break-glass) access that is controlled, logged, and reviewed.

## Common pitfalls

- Shared workstation logins that break unique-user attribution.
- Standing broad access to ePHI without review, a common audit finding.
- Break-glass access that is neither logged nor reviewed after use.

## Related

[Healthcare vertical guide](https://startwithidentity.com/verticals/healthcare/), [IAM audit preparation](https://startwithidentity.com/guides/compliance/iam-audit-preparation-guide/). Vendors: [IGA](https://startwithidentity.com/vendors/iga/), [MFA](https://startwithidentity.com/vendors/mfa/).

## The audit-controls requirement is the architecture driver

Of HIPAA's technical safeguards, audit controls shape systems the most, because "who viewed this record and why" has to be answerable years later. That means access to ePHI needs attribution to a unique human at the moment of access, retained, and searchable.

Everything that breaks attribution breaks the control: shared workstation sessions left open, generic clinical logins, and application-level service accounts that read records on a user's behalf without carrying the user's identity through. That last one is the subtle case and the one most often missed in integration design.

## Clinical workflow is the real constraint

Security controls that add seconds to a workflow repeated hundreds of times a shift do not survive, and clinicians will route around them. This is why badge tap-and-go and [passwordless](https://startwithidentity.com/guides/fundamentals/what-is-passwordless/) approaches specifically designed for shared workstations exist as a healthcare category, rather than being a generic MFA deployment.

Design for the shift, not for the audit: fast re-authentication on a shared terminal, automatic session termination that does not lose clinical context, and a break-glass path that a clinician can actually use in an emergency and that generates a reviewed record afterwards. See [break-glass](https://startwithidentity.com/glossary/break-glass/).

## What incidents actually look like

Healthcare breaches in 2026 continued to run through identity rather than through exotic exploitation. In the [August 2026 McKesson incident](https://startwithidentity.com/breaches/incidents/2026-mckesson-employee-accounts-third-party-apps/), McKesson confirmed a cybersecurity incident targeting employee corporate accounts, with unauthorized access to and exfiltration of data from third-party applications. The attackers, ShinyHunters, claim they voice-phished employees from a lookalike domain, took their [Okta](https://startwithidentity.com/vendors/iam/okta/) credentials, and used the single sign-on session to reach Salesforce and Snowflake; McKesson has not confirmed that chain ([our coverage](https://startwithidentity.com/blog/2026-08-28-mckesson-breach-vishing-okta-sso-salesforce-snowflake/)).

The controls that would have changed that outcome are the ones HIPAA already implies: [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/) so a relayed code is worthless, a help desk verification procedure that does not rely on caller-supplied facts, and [step-up authentication](https://startwithidentity.com/glossary/step-up-auth/) on bulk data access.

## Where to start

1. **Inventory every path to ePHI.** Clinical applications, shared workstations, integrations and service accounts, and vendor access, noting which ones carry a unique human identity through to the record.
2. **Remove shared logins.** Give every clinician and staff member a unique ID (164.312(a)(2)(i)), and use badge tap-and-go or [passwordless](https://startwithidentity.com/guides/fundamentals/what-is-passwordless/) re-authentication on shared terminals so speed does not depend on generic accounts.
3. **Put MFA on remote and privileged access first**, on [phishing-resistant](https://startwithidentity.com/glossary/phishing-resistant-mfa/) factors, in line with what the proposed rule would require.
4. **Write down and test the emergency access procedure** (164.312(a)(2)(ii)) as a [break-glass](https://startwithidentity.com/glossary/break-glass/) path that is logged and reviewed after every use.
5. **Anchor provisioning and reviews in policy** under 164.308(a)(4): documented approval for each grant, periodic [access reviews](https://startwithidentity.com/glossary/access-certification/), and prompt [deprovisioning](https://startwithidentity.com/glossary/deprovisioning/) of leavers.

## Identity Controls for ISO 27001
Source: https://startwithidentity.com/guides/compliance/identity-controls-for-iso-27001/
Last updated: 2026-11-05

ISO 27001 identity controls are the Annex A controls in ISO/IEC 27001:2022 that govern who can access information and how: A.5.15 Access control, A.5.16 Identity management, A.5.17 Authentication information, A.5.18 Access rights, A.8.2 Privileged access rights and A.8.5 Secure authentication, with A.8.15 Logging and A.8.16 Monitoring activities producing the audit trail. The standard names outcomes, not products, so certification depends on evidence that these controls operate. This guide is for IAM, GRC and security teams preparing for certification or surveillance audits.

## Where the 2022 edition stands in 2026

ISO published ISO/IEC 27001:2022 on 25 October 2022, according to the IAF's transition document [IAF MD 26](https://iaf.nu/iaf_system/uploads/documents/IAF_MD26_Issue_2_15012023.pdf). The transition ended on 31 October 2025, and all certifications based on the 2013 edition expired or were withdrawn at that point. A climate action amendment, [ISO/IEC 27001:2022/Amd 1:2024](https://www.iso.org/standard/88435.html), is part of the climate action changes the [IAF and ISO announced in February 2024](https://iaf.nu/en/news/iaf-and-iso-publish-joint-communique/), which name climate change as an issue to consider under clauses 4.1 and 4.2. It does not change any identity control.

The 2022 Annex A has 93 controls in four themes: organizational (37), people (8), physical (14) and technological (34), down from 114, according to a [BCS summary of the ISO/IEC 27002 revision](https://www.bcs.org/media/8961/issg-iso27002-standard-270422.pdf). For identity the important changes are renames and merges: "user registration and de-registration" became Identity management, "secure log-on procedures" became Secure authentication, and user access provisioning, review and removal were merged into Access rights. Monitoring activities is one of the 11 new controls.

## Mapping Annex A to identity

| Annex A control | What it expects | What you build | Evidence an auditor samples |
|---|---|---|---|
| A.5.15 Access control | Documented rules for logical and physical access, least privilege | Access policy, role model, [least privilege](https://startwithidentity.com/glossary/least-privilege/) defaults | Approved policy, role catalogue with owners |
| A.5.16 Identity management | Full lifecycle for every identity, human and [non-human](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/) | HR-driven provisioning, [service account](https://startwithidentity.com/glossary/service-account/) ownership | Identity inventory reconciled to HR and system owners |
| A.5.17 Authentication information | Secure issuance, handling and recovery of credentials | [MFA](https://startwithidentity.com/glossary/mfa/), [passkeys](https://startwithidentity.com/glossary/passkey/), secure reset at the help desk | Enrollment coverage, recovery procedure, exemption register |
| A.5.18 Access rights | Provision, review, modify and remove access | [SCIM](https://startwithidentity.com/standards/scim-2-0/) provisioning, [deprovisioning](https://startwithidentity.com/glossary/deprovisioning/), certification campaigns | Review results with revocation counts, leaver samples |
| A.8.2 Privileged access rights | Restrict and manage elevated access | [PAM](https://startwithidentity.com/vendors/pam/), [just-in-time](https://startwithidentity.com/glossary/jit-access/) elevation, separate admin accounts | Privileged account list, elevation logs, a falling standing count |
| A.8.5 Secure authentication | Technically sound authentication | SSO, [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/) for admins, session controls | Conditional access or policy exports |
| A.8.15 Logging, A.8.16 Monitoring | Record and watch activity | Identity provider logs to SIEM, [ITDR](https://startwithidentity.com/glossary/itdr/) | Log retention settings, alert samples |
| A.5.3 Segregation of duties | Conflicting duties separated | Toxic-combination rules in IGA | Conflict reports and resolutions |
| A.5.19 Supplier relationships, A.6.5 Responsibilities after termination | Supplier access and leaver obligations | Time-bound vendor accounts, leaver reconciliation outside SSO | Vendor account expiry dates, terminated-user samples |

## What certification actually tests

Auditors test operation, not intent. The recurring identity findings are predictable: access reviews completed with no revocations, leavers removed from SSO while local and vendor accounts stayed live, privileged rights granted for a project and never withdrawn, and an MFA exemption list that grew without review.

The evidence to keep is equally predictable: review campaigns with revocation counts, a leaver reconciliation across systems outside SSO, a standing-privilege count trending down, and a dated exemption register with a justification per entry.

## Failure modes these controls exist to stop

- **Leavers who keep access (A.5.18, A.6.5).** A former [Cash App Investing employee](https://startwithidentity.com/breaches/incidents/2022-cash-app-former-employee/) downloaded customer reports after employment ended. At [CrowdSec](https://startwithidentity.com/breaches/incidents/2026-crowdsec-departing-engineer-github-token/), a former employee's GitHub account left open to finish work kept a valid OAuth token that was used to copy about 170 private repositories. Both are [orphaned account abuse](https://startwithidentity.com/techniques/orphaned-account-abuse/).
- **Weak recovery (A.5.17).** At [MGM Resorts](https://startwithidentity.com/breaches/incidents/2023-mgm-resorts-help-desk-ransomware/), a help desk call impersonating an employee led to control of Okta super administrator accounts. Verified recovery is part of authentication information, not a help desk nicety. See [help desk social engineering](https://startwithidentity.com/techniques/help-desk-social-engineering/).
- **Unrotated non-human credentials (A.5.16, A.5.17).** [Cloudflare](https://startwithidentity.com/breaches/incidents/2024-cloudflare-unrotated-okta-breach-credentials/) was reached with one access token and three service account credentials stolen in the October 2023 Okta support breach that it had not rotated.
- **Accumulated rights (A.5.18, A.8.2).** [Mover entitlement accumulation](https://startwithidentity.com/techniques/mover-entitlement-accumulation/) is what an access review with zero revocations usually hides.

## Where the ISMS scope bites

ISO 27001 lets you scope the ISMS, and identity systems straddle the boundary. If your [identity provider](https://startwithidentity.com/glossary/identity-provider/) authenticates access to both in-scope and out-of-scope systems, it is in scope, and so are its administrators. Decide that early, record it, and treat the identity provider as tier-zero infrastructure.

## Checking a vendor's ISO 27001 certificate

Buyers often ask whether an identity vendor "holds ISO 27001:2022". Four checks matter more than the logo: the certificate cites the 2022 edition (2013 certificates are no longer valid), the scope covers the service you are buying rather than a head office, it was issued by an accredited certification body, and the Statement of Applicability does not exclude the access control themes. Use the [identity buyer guides](https://startwithidentity.com/guides/buyer-guides/) and vendor profiles such as [Okta](https://startwithidentity.com/vendors/iam/okta/), [Microsoft Entra ID](https://startwithidentity.com/vendors/iam/microsoft-entra/) and [Ping Identity](https://startwithidentity.com/vendors/iam/ping-identity/) as a starting point, then confirm on the vendor's trust center.

## Tooling that maps cleanly

[IGA](https://startwithidentity.com/vendors/iga/) platforms such as [SailPoint](https://startwithidentity.com/vendors/iga/sailpoint/), [Saviynt](https://startwithidentity.com/vendors/iga/saviynt/) and [Omada](https://startwithidentity.com/vendors/iga/omada/) (which acquired EmpowerID on 24 September 2026) produce A.5.18 review evidence. [PAM](https://startwithidentity.com/vendors/pam/) tools such as [Idira (formerly CyberArk)](https://startwithidentity.com/vendors/pam/cyberark/), now part of Palo Alto Networks, and [BeyondTrust](https://startwithidentity.com/vendors/pam/beyondtrust/) cover A.8.2. Tools do not certify you; the evidence they export does.

## Where to start

1. **Settle the ISMS scope for identity.** Put the identity provider and its administrators in scope if it authenticates any in-scope system, and record the decision.
2. **Map controls to owners.** Assign each control in the table to a named owner with the system that produces its evidence.
3. **Bring every identity into the lifecycle.** Reconcile human, service and vendor accounts against HR and system owners, including local accounts outside SSO. See [joiner-mover-leaver](https://startwithidentity.com/glossary/joiner-mover-leaver/).
4. **Run one evidenced review campaign.** Keep revocation counts, not just completion, as the [access certification](https://startwithidentity.com/glossary/access-certification/) artifact.
5. **Start the registers auditors ask for.** A dated MFA exemption register and a standing-privilege count you can show trending down.

## Related

[ISO 27001 glossary entry](https://startwithidentity.com/glossary/iso-27001/), [SOC 2 for identity](https://startwithidentity.com/guides/compliance/soc2-for-identity/), [IAM audit preparation](https://startwithidentity.com/guides/compliance/iam-audit-preparation-guide/), [what is IGA](https://startwithidentity.com/guides/fundamentals/what-is-iga/), [zero standing privileges rollout](https://startwithidentity.com/guides/implementation/zero-standing-privileges-rollout/).

## Identity Controls for NIS2
Source: https://startwithidentity.com/guides/compliance/identity-controls-for-nis2/
Last updated: 2026-11-05

NIS2, [Directive (EU) 2022/2555](https://eur-lex.europa.eu/eli/dir/2022/2555/oj), puts identity controls into law for essential and important entities across sectors such as energy, transport, health, digital infrastructure, and manufacturing. Article 21(2) lists the minimum risk-management measures, and two of them are identity measures by name: "access control policies" under point (i) and "multi-factor authentication or continuous authentication solutions" under point (j). For cloud, data centre, managed service, and other digital providers, [Implementing Regulation (EU) 2024/2690](https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj) turns those words into specific requirements: unique identities, privileged account policies, logged access rights, and MFA matched to asset classification. This guide maps both texts to controls and evidence.

## What the law says

| Provision | Requirement | Identity reading |
|---|---|---|
| Directive Art. 20 | Management bodies approve and oversee Article 21 measures, can be held liable, and must follow training | MFA coverage and privileged access become board-level metrics |
| Art. 21(2)(d) | Supply chain security, including relationships with direct suppliers and service providers | Vendor and MSP access is in scope |
| Art. 21(2)(i) | Human resources security, access control policies and asset management | Joiner-mover-leaver, least privilege, identity inventory |
| Art. 21(2)(j) | MFA or continuous authentication, secured communications, "where appropriate" | MFA by risk, documented where not applied |
| Art. 23(4) | Early warning within 24 hours, notification within 72 hours, final report within one month | Identity attacks must be detected fast enough to report |
| Art. 34(4)-(5) | Maximum fines of at least EUR 10 million or 2% (essential) and EUR 7 million or 1.4% (important) | Sets the stakes for the above |

Member States had to adopt and publish their transposing measures by 17 October 2024 and apply them from 18 October 2024 (Article 41). Track national status on the [regulations calendar](https://startwithidentity.com/regulations/calendar/).

## What Implementing Regulation 2024/2690 adds

Adopted on 17 October 2024, the regulation applies to the digital entity types listed in its Article 1. Its annex section 11, "Access control", is the most detailed identity text in EU cybersecurity law:

- **11.2 Access rights:** assign and revoke on need-to-know, least privilege, and separation of duties; modify on termination or change of employment; limit third-party access "in scope and in duration"; keep a register of access rights; log access rights management; review at planned intervals and document the changes.
- **11.3 Privileged accounts:** strong identification and authentication "such as multi-factor authentication"; dedicated accounts used only for administration; individualised admin privileges; admin accounts used only to connect to administration systems; documented periodic review.
- **11.4 Administration systems:** used only for administration, logically separated, protected by authentication and encryption.
- **11.5 Identification:** unique identities for systems and users, each user identity linked to a single person, shared identities only with explicit approval and documentation, and deactivation "without delay" when no longer needed.
- **11.6 Authentication:** strength matched to asset classification, lockout after failed attempts, inactive session termination, separate credentials for privileged access.
- **11.7 MFA:** multiple factors or continuous authentication "where appropriate, in accordance with the classification of the asset".

Section 3.2.3 lists what logs should include, among them user creation, modification and deletion, permission extensions, authentication events, and all privileged access. Article 3(1)(e) treats a successful, suspectedly malicious unauthorised access capable of causing severe operational disruption as a significant incident, which makes identity compromise a direct reporting trigger. Article 2(2) requires entities to document their reasoning wherever they decide a "where appropriate" requirement does not apply.

## Decision table: where MFA strength goes first

| Access path | Minimum | Target | Why |
|---|---|---|---|
| Admin and cloud console | MFA (11.3) | [Phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/) plus [JIT access](https://startwithidentity.com/glossary/jit-access/) | Highest blast radius |
| Remote access (VPN, VDI, RDP gateways) | MFA | Phishing-resistant MFA, device posture | Most common entry in incidents below |
| Vendor and MSP access | MFA, time-bound grant (11.2) | Brokered sessions through [PAM](https://startwithidentity.com/vendors/pam/) with recording | Article 21(2)(d) supply chain |
| OT engineering workstations | Documented exception if agents cannot run | Inline or network-layer MFA | Shared operator accounts need 11.5.3 approval |
| Standard workforce SaaS | SSO plus MFA | Passkeys | Asset classification drives strength (11.6, 11.7) |

One owner decision: section 11.6.2(c) requires credential changes "at predefined intervals". [NIST SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html) (section 3.1.1.2) says verifiers "SHALL NOT require subscribers to change passwords periodically", so document an interval that fits your risk model, such as long intervals for passwordless or MFA-backed accounts, rather than ignoring the clause.

## Evidence an auditor will ask for

NIS2 attaches management accountability, which changes what "we have MFA" needs to mean. Be able to produce:

- **MFA coverage as a number**, with the exemption list, why each exemption exists, and when it was last reviewed. An unreviewed exemption list is the finding.
- **Privileged access records**: who holds standing elevated rights, session recordings for OT and IT administration, and the approval trail for elevation.
- **Access review output** showing revocations, not just completion. See [access certification](https://startwithidentity.com/glossary/access-certification/).
- **A register of access rights** and the log of changes to it (11.2.2(e)-(f)).
- **Third-party access inventory** with time-bounded grants and an owner per vendor.
- **Shared account approvals** for every identity used by more than one person (11.5.3). See [shared account](https://startwithidentity.com/glossary/shared-account/).
- **Detection coverage** mapped to the 24-hour early warning, which is unachievable if nobody sees the identity attack.

## The OT gap

The sectors NIS2 covers include energy, manufacturing, transport, and water, where the hard problem is not the corporate directory but operational technology: shared operator accounts, engineering workstations with local credentials, and vendor remote access into plant systems.

Those environments frequently cannot take an agent, which is why inline authentication controls that extend [MFA](https://startwithidentity.com/glossary/mfa/) to protocols agents cannot reach, such as [Silverfort](https://startwithidentity.com/vendors/itdr/silverfort/), matter more here than in a pure IT estate. Vendor and contractor remote access is the specific supply-chain exposure the directive names, and it is usually the least governed path in the organization.

## Failure modes NIS2 controls are meant to stop

- **Remote access without MFA.** [Colonial Pipeline](https://startwithidentity.com/breaches/incidents/2021-colonial-pipeline-legacy-vpn/) was entered through a legacy VPN profile with single-factor authentication, [Change Healthcare](https://startwithidentity.com/breaches/incidents/2024-change-healthcare-citrix-no-mfa/) through a Citrix portal without MFA, and [Medibank](https://startwithidentity.com/breaches/incidents/2022-medibank-contractor-credentials-vpn/) through contractor credentials on a VPN that did not require MFA.
- **Dormant accounts never deactivated.** The Colonial profile was believed to be out of use, which is exactly what 11.5.4 targets. Technique: [orphaned account abuse](https://startwithidentity.com/techniques/orphaned-account-abuse/).
- **Supplier credentials as the way in.** At the [US Treasury](https://startwithidentity.com/breaches/incidents/2024-us-treasury-beyondtrust-api-key/) a remote support vendor's key was used to reach workstations, and stolen [ConnectWise application credentials](https://startwithidentity.com/breaches/incidents/2026-connectwise-cloud-backup-app-credential/) opened customer Microsoft 365 tenants. Technique: [static API key abuse](https://startwithidentity.com/techniques/static-api-key-abuse/).
- **Help desk resets.** Attackers bypass MFA by talking support into re-enrolling it. Technique: [help desk social engineering](https://startwithidentity.com/techniques/help-desk-social-engineering/).

## Where to start

1. **Confirm your status.** Check whether you are essential or important under your national law and whether 2024/2690 applies directly.
2. **Inventory identities and access paths.** Human, service, shared, and vendor accounts, with the remote paths into IT and OT. See [non-human identities](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/).
3. **Close remote and admin MFA gaps first.** Every exception gets a documented reason (Article 2(2) of the regulation).
4. **Move privileged access into PAM** with dedicated admin accounts and recorded vendor sessions. Compare options in [how to choose a PAM solution](https://startwithidentity.com/guides/buyer-guides/how-to-choose-a-pam-solution/).
5. **Automate joiner-mover-leaver** through [IGA](https://startwithidentity.com/vendors/iga/), with reviews that produce revocations. See [joiner-mover-leaver](https://startwithidentity.com/glossary/joiner-mover-leaver/).
6. **Log identity events** listed in 3.2.3 and route them to [ITDR](https://startwithidentity.com/vendors/itdr/) detection.
7. **Rehearse the 24-hour clock** with an admin account compromise scenario.
8. **Report upward.** Give the management body MFA coverage, standing privilege counts, and open exceptions each quarter.

## Related

[Energy & utilities](https://startwithidentity.com/verticals/energy-utilities/) and [manufacturing](https://startwithidentity.com/verticals/manufacturing/) verticals. Guides: [identity controls for DORA](https://startwithidentity.com/guides/compliance/identity-controls-for-dora/), [identity controls for ISO 27001](https://startwithidentity.com/guides/compliance/identity-controls-for-iso-27001/), [zero standing privileges rollout](https://startwithidentity.com/guides/implementation/zero-standing-privileges-rollout/). Vendors: [PAM](https://startwithidentity.com/vendors/pam/), [ITDR](https://startwithidentity.com/vendors/itdr/), [IGA](https://startwithidentity.com/vendors/iga/), [MFA](https://startwithidentity.com/vendors/mfa/).

## Identity Controls for PCI DSS
Source: https://startwithidentity.com/guides/compliance/identity-controls-for-pci-dss/
Last updated: 2026-11-05

PCI DSS identity controls are the requirements in [PCI DSS v4.0.1](https://startwithidentity.com/regulations/united-states/pci-dss/) that decide who and what can reach cardholder data and how they prove it: Requirement 7 (access by business need to know) and Requirement 8 (identify users and authenticate access). Since 31 March 2025 they include MFA for all access into the cardholder data environment (CDE), 12-character passwords, six-monthly user access reviews, and managed credentials for system accounts. This guide is for IAM and security teams at merchants and service providers preparing for an assessment.

## Version and dates

The current version is v4.0.1, a limited revision the PCI Security Standards Council [published on 11 June 2024](https://blog.pcisecuritystandards.org/just-published-pci-dss-v4-0-1). It added no requirements and deleted none, but for identity it added one important note: the MFA requirement for non-administrative CDE access does not apply to accounts authenticated only with phishing-resistant factors, and Appendix G now defines phishing-resistant authentication. Version 4.0 was retired on 31 December 2024. The requirements v4.0 had marked as best practice until 31 March 2025 are now mandatory, and most of the identity ones are in that group.

## Requirement map

Requirement text below is summarised from the PCI SSC's v4.0 [SAQ D for merchants](https://listings.pcisecuritystandards.org/documents/PCI-DSS-v4-0-SAQ-D-Merchant.pdf) (v4.0.1 added and deleted no requirements); "2025" marks the items that were best practice until 31 March 2025.

| Req. | What it requires | Since | What you build |
|---|---|---|---|
| 7.2.4 | Review all user accounts and privileges, including third-party and vendor accounts, at least once every six months; address inappropriate access; management acknowledges | 2025 | Six-monthly [access certification](https://startwithidentity.com/glossary/access-certification/) in IGA |
| 7.2.5, 7.2.5.1 | System and application accounts get least privilege, and their access is reviewed at a frequency set by targeted risk analysis | 2025 | Owned [service account](https://startwithidentity.com/glossary/service-account/) inventory with review dates |
| 8.2.2 | Shared or generic accounts only by exception: prevented unless needed, time-limited, justified, approved | Existing | PAM check-out with individual attribution |
| 8.2.6 | Remove or disable inactive user accounts within 90 days | Existing | Automated dormancy job, [deprovisioning](https://startwithidentity.com/glossary/deprovisioning/) |
| 8.2.7 | Third-party remote access accounts enabled only when needed and monitored | Existing | Time-bound vendor access with [session recording](https://startwithidentity.com/glossary/session-recording/) |
| 8.2.8 | Re-authenticate after 15 minutes idle | Existing | Session timeout policy |
| 8.3.4 | Lock out after no more than 10 attempts, for at least 30 minutes or until identity is confirmed | Existing | Lockout plus [password spraying](https://startwithidentity.com/techniques/password-spraying/) detection |
| 8.3.6 | Passwords at least 12 characters (eight if unsupported), numeric and alphabetic | 2025 | Directory and app password policy |
| 8.3.9 | Single-factor passwords changed every 90 days, or dynamic posture analysis | Existing | Prefer removing single-factor access |
| 8.4.1, 8.4.2 | MFA for administrative non-console access, and for all access into the CDE | 8.4.2: 2025 | [Phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/) at the CDE boundary |
| 8.4.3 | MFA for all remote network access from outside that could reach the CDE, including third parties | Existing | MFA on VPN, VDI and remote support |
| 8.5.1 | MFA not replayable, not bypassable without time-limited approved exception, two factor types, all factors must succeed | 2025 | Factor configuration review, bypass register |
| 8.6.1-8.6.3 | System accounts with interactive login controlled; their passwords not hardcoded; passwords rotated per risk analysis and on compromise | 2025 | [Secrets management](https://startwithidentity.com/glossary/secrets-management/), [workload identity](https://startwithidentity.com/glossary/workload-identity/) |

Service providers carry one more single-factor password requirement, 8.3.10.1, which FAQ 1591 treats alongside 8.3.9.

## Scoping is where identity programmes get this wrong

MFA under 8.4.2 now covers all access into the CDE, not only remote administrators. The PCI SSC's [FAQ 1591](https://www.pcisecuritystandards.org/faqs/1591/) clarifies the edges: MFA is not mandatory for in-scope systems outside the CDE, but it is required wherever a user's access to such a system can be used to connect into the CDE, and a password alone is acceptable inside the CDE only after the user has already authenticated into it with MFA.

So the first exercise is an inventory of everything that can authenticate into scope, not everything with a human behind it. Non-human access is where the gap usually is, because those accounts were exempted from MFA on the grounds that they cannot do MFA. The 8.4.2 exemption for automated accounts is real, but 7.2.5 and 8.6 then apply in full: least privilege, owners, review, and no hardcoded secrets.

## Failure modes the requirements map to

- **Remote access without MFA (8.4.3).** At [Change Healthcare](https://startwithidentity.com/breaches/incidents/2024-change-healthcare-citrix-no-mfa/), attackers used compromised credentials on a Citrix remote access portal that did not have MFA, then deployed ransomware nine days later. At [Medibank](https://startwithidentity.com/breaches/incidents/2022-medibank-contractor-credentials-vpn/), a contractor's saved credentials opened a VPN that did not require MFA.
- **Infostealer credentials on cloud data platforms (8.4.2, 8.2.6).** In the [Snowflake customer campaign](https://startwithidentity.com/breaches/incidents/2024-snowflake-customer-tenant-campaign/), about 165 customer accounts were accessed with [infostealer credentials](https://startwithidentity.com/techniques/infostealer-credential-harvesting/), some dating from 2020, on accounts that lacked MFA. [Advance Auto Parts](https://startwithidentity.com/breaches/incidents/2024-advance-auto-parts-snowflake-account/) was one of them.
- **Vendor remote support as the path in (8.2.7).** At the [US Treasury](https://startwithidentity.com/breaches/incidents/2024-us-treasury-beyondtrust-api-key/), a stolen key for [BeyondTrust](https://startwithidentity.com/vendors/pam/beyondtrust/) Remote Support SaaS gave remote access to workstations.
- **Secrets in code and pipelines (8.6.2).** See [secrets in repositories and CI](https://startwithidentity.com/techniques/secrets-in-repositories-and-ci/) and the [tj-actions/changed-files compromise](https://startwithidentity.com/breaches/incidents/2025-tj-actions-changed-files-ci-secrets/).

## Decision table: what to fix first

| Finding | First fix | Tool category |
|---|---|---|
| Password-only access somewhere on the path into the CDE | MFA at the boundary, phishing-resistant for admins and vendors | IdP plus [MFA](https://startwithidentity.com/vendors/mfa/) |
| Shared admin or vendor accounts | Unique accounts, vaulted check-out, session recording | [PAM](https://startwithidentity.com/vendors/pam/) |
| Hardcoded or never-rotated app credentials | Vault and rotate, then short-lived workload credentials | [Secrets management](https://startwithidentity.com/vendors/secrets/) |
| No six-month review evidence | Certification campaign with revocation counts | [IGA](https://startwithidentity.com/vendors/iga/) |

For MFA at the CDE boundary, [Duo](https://startwithidentity.com/vendors/mfa/duo/) (Cisco), [Okta](https://startwithidentity.com/vendors/iam/okta/) and [Microsoft Entra ID](https://startwithidentity.com/vendors/iam/microsoft-entra/) are common, with [Yubico](https://startwithidentity.com/vendors/mfa/yubico/) keys where phishing resistance lets you use the 4.0.1 note. For vaulted admin access, [Idira (formerly CyberArk)](https://startwithidentity.com/vendors/pam/cyberark/), now part of Palo Alto Networks, and [Delinea](https://startwithidentity.com/vendors/pam/delinea/), which now owns StrongDM, sit alongside BeyondTrust. For application secrets, [HashiCorp Vault](https://startwithidentity.com/vendors/machine-identity/hashicorp-vault/) (IBM), [AWS Secrets Manager](https://startwithidentity.com/vendors/secrets/aws-secrets-manager/) and [Idira Secrets Manager](https://startwithidentity.com/vendors/secrets/cyberark-conjur/) (formerly CyberArk Conjur) handle storage and rotation, and [GitGuardian](https://startwithidentity.com/vendors/secrets/gitguardian/) finds what is already hardcoded. For review evidence, see [best compliant IGA platforms](https://startwithidentity.com/rankings/best-compliant-iga-platforms/).

## Retail and e-commerce specifics

For merchants the customer-facing side matters as much as the CDE. [Credential stuffing](https://startwithidentity.com/techniques/credential-stuffing/) against consumer accounts drives [account takeover](https://startwithidentity.com/glossary/account-takeover/) and fraud that sits outside the compliance boundary but inside the risk: at [Chick-fil-A](https://startwithidentity.com/breaches/incidents/2023-chick-fil-a-credential-stuffing/), attackers took over 71,473 loyalty accounts, exposing partial card numbers and reward balances. See the [retail and e-commerce vertical](https://startwithidentity.com/verticals/retail-ecommerce/) and [identity for retail and e-commerce](https://startwithidentity.com/articles/identity-for-retail-ecommerce/).

## Where to start

1. **Confirm the version.** Assess against v4.0.1 and treat the formerly future-dated requirements as mandatory.
2. **Inventory everything that can authenticate into the CDE.** Users, [service accounts](https://startwithidentity.com/glossary/service-account/), application identities and vendor logins, each with a named owner.
3. **Close MFA gaps for all CDE access.** Administrators and remote access first on phishing-resistant factors, then everyone else who can reach the environment.
4. **Remove shared and hardcoded credentials.** Unique identities, vaulted and rotated application secrets, workload identity where the platform supports it.
5. **Run and evidence the first review.** Cover every user account and privilege, including third parties, under 7.2.4, and keep the revocations.

## Related

[PCI DSS glossary entry](https://startwithidentity.com/glossary/pci-dss/), [IAM audit preparation](https://startwithidentity.com/guides/compliance/iam-audit-preparation-guide/), [phishing-resistant MFA matrix](https://startwithidentity.com/tools/mfa-matrix/), [identity controls for DORA](https://startwithidentity.com/guides/compliance/identity-controls-for-dora/).

## Identity Federation Implementation Guide: Protocols, Trust, and Cross-Domain SSO
Source: https://startwithidentity.com/guides/authentication/identity-federation-implementation-guide/
Last updated: 2026-11-05

Identity federation is the foundational mechanism that allows users authenticated by one organization to access resources in another without creating duplicate accounts. It is what makes a consultant log in once at their home company and smoothly access a client's SharePoint, or what lets an employee authenticate via their corporate IdP and immediately use a partner's supply chain portal.

Despite being conceptually straightforward, "trust another organization's authentication", federation implementations are notoriously tricky. They involve protocol negotiations, certificate exchanges, attribute mapping disagreements, and edge cases around session management that only surface in production. A misconfigured federation trust can either lock users out entirely or, worse, grant them more access than intended.

This guide walks through the full lifecycle of a federation implementation: choosing protocols, establishing trust relationships, mapping attributes, handling cross-domain SSO flows, and configuring B2B federation patterns that scale to dozens of partners.

## What You Will Learn

- How SAML 2.0, OpenID Connect, and WS-Federation handle federation differently
- Establishing and managing trust relationships between identity providers
- Attribute mapping strategies that prevent authorization failures
- Cross-domain SSO configuration with session management
- B2B federation patterns for partner and customer organizations
- Testing, troubleshooting, and security hardening

## Prerequisites

1. **Identity Provider (IdP) with federation support**, Your organization needs an IdP capable of acting as both a federation hub and a claims provider. Major platforms (Microsoft Entra ID, Okta, Ping Identity, ADFS, Keycloak) all support this.
2. **Partner coordination**, Federation is inherently bilateral. You need a technical contact at each partner organization who can configure their side of the trust relationship.
3. **Attribute schema agreement**, Both parties must agree on which user attributes will be exchanged and their format (email vs. UPN, department codes vs. names, group names vs. GUIDs).
4. **Certificate management capability**, Federation relies on X.509 certificates for signing and encryption. You need the ability to generate, distribute, and rotate these certificates.
5. **DNS and network access**, Federation endpoints must be reachable over HTTPS from partner environments. If either party uses IP allowlisting, document the required addresses.

## Architecture Overview

Federation introduces a trust layer between separate identity domains. Instead of each application maintaining its own user store, applications delegate authentication to an Identity Provider, and Identity Providers trust each other through federation agreements.

### Core Components

**Identity Provider (IdP):** The authoritative authentication service for a given identity domain. When users from Organization A need to access Organization B's resources, Organization A's IdP authenticates the user and issues a security token (SAML assertion, OIDC ID token, or WS-Federation security token) that Organization B accepts.

**Service Provider (SP) / Relying Party (RP):** The application or service that consumes the security token. It validates the token's signature, extracts user attributes, and makes authorization decisions based on the claims.

**Federation Metadata:** Machine-readable documents (XML for SAML/WS-Fed, JSON for OIDC) that describe each party's endpoints, signing certificates, supported bindings, and attribute requirements. Metadata exchange is the technical handshake that establishes trust.

**Trust Relationship:** A configured, bilateral agreement where each party recognizes the other's signing certificate and endpoints. Trust can be direct (IdP-to-SP) or brokered through a federation hub.

**Attribute/Claims Mapping:** The translation layer that converts attributes from the IdP's schema to the SP's expected format. This is where most federation issues originate.

### Federation Topologies

**Direct federation (point-to-point):** Each IdP trusts each SP directly. Simple for a small number of partners (2-5) but creates an O(n^2) management burden as the number of partners grows.

**Hub-and-spoke federation:** A central federation hub (your IdP or a dedicated federation gateway) brokers trust between multiple partners. Partners trust only the hub; the hub trusts each partner. This reduces the management burden to O(n) and centralizes policy enforcement.

**Multi-hub federation (mesh):** Used in academic (InCommon, eduGAIN) and government (FICAM) contexts where multiple federation hubs interconnect. Complex but enables massive scale.

For most enterprises, a hub-and-spoke model with your primary IdP as the hub is the right starting point.

## Step-by-Step Implementation

### Step 1: Choose Your Federation Protocol

**SAML 2.0** remains the dominant protocol for enterprise federation. Its strengths:

- Universal support across enterprise SaaS applications
- Rich attribute statement capabilities
- Mature tooling for metadata exchange and certificate management
- Well-understood security model with extensive audit support

Use SAML when federating with enterprise partners, SaaS applications, or government entities.

**OpenID Connect (OIDC)** is the modern alternative built on OAuth 2.0. Its strengths:

- Simpler implementation using JSON and REST APIs
- Better suited for mobile and single-page applications
- Native support for token refresh and incremental consent
- Growing enterprise adoption through Microsoft Entra ID and Okta

Use OIDC when federating with modern applications, cloud-native services, or developer-facing platforms.

**WS-Federation** is a legacy protocol still found in Microsoft-heavy environments (ADFS, older SharePoint). Use it only when the target application does not support SAML or OIDC. Plan migration away from WS-Federation for new implementations.

In practice, most federation hubs support all three protocols simultaneously. You choose the protocol per trust relationship based on what the partner supports.

### Step 2: Exchange Federation Metadata

Metadata exchange is the foundation of every trust relationship. Each party publishes a metadata document describing its federation configuration.

**SAML metadata** includes:

- Entity ID (a unique URI identifying the IdP or SP)
- SSO endpoint URLs (HTTP-POST, HTTP-Redirect bindings)
- Single Logout (SLO) endpoint URLs
- Signing certificate(s) (X.509, typically RSA 2048-bit or higher)
- Encryption certificate(s) (optional but recommended)
- Supported NameID formats (email, persistent, transient)

```xml
<!-- Example SAML IdP metadata excerpt -->
<EntityDescriptor entityID="https://idp.company-a.com/saml2">
  <IDPSSODescriptor
    protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <KeyDescriptor use="signing">
      <ds:KeyInfo>
        <ds:X509Data>
          <ds:X509Certificate>MIIDpDCCA...</ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </KeyDescriptor>
    <SingleSignOnService
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
      Location="https://idp.company-a.com/saml2/sso"/>
    <SingleSignOnService
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
      Location="https://idp.company-a.com/saml2/sso"/>
  </IDPSSODescriptor>
</EntityDescriptor>
```

**OIDC discovery** uses a well-known endpoint (`/.well-known/openid-configuration`) that returns a JSON document with the authorization endpoint, token endpoint, JWKS URI (for token validation), supported scopes, and supported claims.

**Exchange process:**

1. Obtain your partner's metadata document (URL or file).
2. Validate the metadata: check the entity ID, verify the signing certificate chain, and confirm the endpoints are reachable.
3. Import the metadata into your IdP/SP configuration.
4. Provide your own metadata to your partner and confirm they have imported it.
5. Both parties verify the trust by inspecting the imported configuration.

**Automation tip:** Where possible, configure metadata URL-based trust rather than static file imports. This allows certificate rollovers and endpoint changes to propagate automatically. SAML metadata URLs should be polled daily; OIDC discovery endpoints are refreshed automatically by most libraries.

### Step 3: Configure Attribute Mapping

Attribute mapping is where federation implementations succeed or fail. The IdP sends user attributes (claims) in the security token, and the SP uses those attributes for identification and authorization. If the mapping is wrong, users either cannot log in or receive incorrect permissions.

**Common attributes to map:**

| Purpose | SAML Attribute | OIDC Claim | Notes |
|---------|---------------|------------|-------|
| Unique ID | NameID (persistent) | sub | Must be immutable. Never use email as the sole identifier. |
| Email | mail or emailAddress | email | Used for account matching. Verify format consistency. |
| Display name | givenName + sn | name | Some SPs expect a single full name; others expect first/last split. |
| Groups/roles | member or groups | groups | The most common source of authorization issues. |
| Organization | o or organization | org (custom) | Useful for multi-tenant applications. |
| Department | department | department (custom) | May use codes vs. names; standardize before federating. |

**Group mapping strategies:**

The highest-friction area in federation is group mapping. Organization A calls a role "IT-Admins" while Organization B expects "Administrator." Three approaches:

1. **Direct group pass-through:** Send Organization A's group names as-is. The SP must be configured to recognize them. Simple but brittle.
2. **Group transformation:** The federation hub maps Organization A's groups to the SP's expected roles during token issuance. More flexible but requires maintenance when groups change.
3. **Role-based claims:** Instead of passing groups, the IdP evaluates group membership and emits role claims (e.g., "role=admin"). The SP only needs to understand the role vocabulary.

For B2B federation, approach 3 (role-based claims) is strongly recommended because it decouples the partner's internal group structure from your application's authorization model.

### Step 4: Configure Cross-Domain SSO

Cross-domain SSO allows users to move between applications in different DNS domains without re-authenticating. This is straightforward within a single IdP's domain but requires careful configuration when spanning federation boundaries.

**IdP-initiated SSO:** The user starts at their IdP portal and clicks a link to the target application. The IdP generates a security token and redirects the user to the SP. This is the simplest flow and works well for portal-based access.

**SP-initiated SSO:** The user navigates directly to the target application (e.g., bookmarks the URL). The SP detects the user is not authenticated and redirects to the appropriate IdP. This requires home realm discovery, determining which IdP should authenticate the user.

**Home realm discovery (HRD) strategies:**

1. **Email-based:** The SP prompts for the user's email address, extracts the domain, and routes to the corresponding IdP. This is the most common approach and what users expect.
2. **Subdomain-based:** The SP uses vanity URLs (e.g., `partner-a.app.example.com`) to determine the IdP.
3. **Cookie-based:** After the first authentication, a cookie remembers the user's IdP preference.
4. **IP-based:** Route based on the user's source IP range. Useful for on-premises users but breaks for remote workers.

**Session management across domains:**

Each domain maintains its own session. When a user authenticates via federation, the SP creates a local session. The IdP maintains a separate session. These sessions have independent lifetimes, which creates complexity:

- If the IdP session expires but the SP session is still active, the user continues working until the SP session expires.
- If the SP session expires but the IdP session is still active, the user is redirected to the IdP, which silently reissues a token (no login prompt), and the user is redirected back, a smooth experience.
- Single Logout (SLO) attempts to terminate all sessions simultaneously, but it is unreliable across domains and protocols. Do not depend on SLO for security-critical session termination.

**Recommended session configuration** (practitioner estimates; tune to your risk and user experience needs):

- IdP session lifetime: 8-12 hours (workday duration)
- SP session lifetime: 1-4 hours (shorter than IdP, so token refresh happens transparently)
- Absolute session maximum: 12 hours (force re-authentication regardless of activity)
- Step-up authentication: Require MFA re-prompt for sensitive operations within an active session

### Step 5: Implement B2B Federation Patterns

B2B federation extends your identity trust to external partner organizations. This is where federation delivers its greatest value, and its greatest complexity.

**Onboarding a new federation partner:**

1. **Legal and governance review.** Before any technical work, establish a data-sharing agreement covering: which attributes will be exchanged, how they will be used, data retention policies, breach notification obligations, and termination procedures.
2. **Technical kickoff.** Exchange metadata, agree on attribute mapping, and configure the trust relationship in both IdPs. Assign a named technical contact on each side.
3. **Test with pilot users.** Create test accounts on both sides and verify the full flow: SP-initiated SSO, IdP-initiated SSO, attribute mapping, group/role assignment, and session management.
4. **Production rollout.** Open the federation trust to production users. Monitor authentication logs on both sides for the first 48 hours.
5. **Ongoing maintenance.** Schedule quarterly reviews to address certificate renewals, attribute mapping changes, and user access adjustments.

**Multi-partner federation at scale:**

When you federate with more than 5-10 partners, direct trust management becomes burdensome. Strategies for scaling:

- **Microsoft Entra B2B collaboration / cross-tenant access settings:** Automates trust configuration between Microsoft Entra ID tenants. Supports SAML and OIDC. Handles consent and attribute mapping through cross-tenant access policies.
- **Okta Org2Org:** Enables federation between Okta organizations with simplified metadata exchange and attribute mapping.
- **Federation gateway:** Deploy a dedicated federation gateway (PingFederate, Shibboleth) that acts as a single trust point for all partners. Partners federate with the gateway; the gateway federates with your applications.

**Guest user lifecycle management:**

Federated users who access your resources are guests. They need lifecycle management:

- **Provisioning:** Automatically create a guest account in your directory when a federated user first authenticates. Populate attributes from the federation token.
- **Access reviews:** Periodically review guest access. If a guest has not authenticated in 90 days, disable the account. After 180 days, delete it.
- **Deprovisioning:** When a partner terminates the federation relationship, immediately disable all associated guest accounts.

### Step 6: Implement Security Controls

**Conditional access policies for federated users:**

Federated users should be subject to conditional access policies that account for their elevated risk profile:

- Require MFA for all federated access (even if the partner's IdP has already performed MFA, defense in depth)
- Restrict federated access to specific applications (do not grant blanket access to all resources)
- Block federated access from countries where your partners do not operate
- Require compliant or managed devices for access to sensitive applications

**Token validation hardening:**

- Validate the token signature against the trusted signing certificate. Reject tokens signed by unknown certificates.
- Check the token audience (aud claim) matches the expected SP entity ID. Reject tokens intended for different SPs.
- Enforce token expiration (NotOnOrAfter / exp claim). Reject expired tokens with zero tolerance.
- Validate the token issuer matches the expected IdP entity ID.
- For SAML, validate InResponseTo to prevent token replay.
- For OIDC, validate the nonce to prevent replay attacks.

**Certificate management:**

Federation signing certificates typically have a 1-3 year validity period. Certificate expiration is the number one cause of federation outages.

- Monitor certificate expiration dates with automated alerts at 90, 60, and 30 days before expiration.
- Implement certificate rollover: publish the new certificate in metadata while the old certificate is still valid. Both certificates are trusted during the overlap period (a practitioner estimate of 2-4 weeks is typical). Remove the old certificate after the overlap.
- Never use self-signed certificates for production federation. Use certificates issued by a trusted CA or your organization's internal PKI.

## Configuration Best Practices

**Use persistent NameIDs for user matching.** Email addresses change when users get married, departments restructure, or companies rebrand. A persistent, opaque identifier (UUID or hash) as the NameID ensures user matching survives these changes.

**Encrypt SAML assertions for sensitive attributes.** While all federation traffic should use TLS, encrypting the assertion itself (using the SP's encryption certificate) provides defense in depth against TLS termination at intermediaries.

**Implement token claim minimization.** Only include attributes in the federation token that the SP actually needs. Do not send the user's full group membership, home address, or phone number to an application that only needs their email and role.

**Log every federation event.** Log successful and failed authentications, token validation failures, attribute mapping issues, and session creation/termination events. Forward to your SIEM for correlation.

**Set up synthetic monitoring.** Configure automated federation health checks that perform a full SSO flow every 15 minutes and alert if any step fails. This catches certificate expirations, endpoint changes, and network issues before users are affected.

## Testing and Validation

1. **Protocol flow testing:** Use SAML-tracer (browser extension) or OIDC Debugger to inspect the actual tokens exchanged during authentication. Verify every attribute is present and correctly formatted.
2. **Negative testing:** Submit expired tokens, tokens with wrong audience, tokens signed by untrusted certificates, and tokens with missing required attributes. Verify the SP rejects all of them.
3. **Cross-browser testing:** Federation flows involve multiple redirects that can behave differently across browsers. Test Chrome, Firefox, Safari, and Edge.
4. **Load testing:** If you expect high-volume federated access (e.g., a partner with 10,000 users), load test the federation endpoints to ensure they handle concurrent authentication flows.
5. **Failover testing:** If your IdP is deployed in HA mode, fail over the primary and verify federation flows continue to work against the secondary.

## Common Pitfalls

**Clock skew.** SAML assertions include NotBefore and NotOnOrAfter timestamps. If the IdP and SP clocks differ by more than the allowed skew (typically 5 minutes), every authentication fails. Use NTP on all federation components.

**Audience restriction mismatch.** The audience in the SAML assertion must exactly match the SP's entity ID. A trailing slash difference (`https://app.example.com` vs. `https://app.example.com/`) causes hard-to-diagnose failures.

**NameID format disagreement.** The IdP sends an email-formatted NameID but the SP expects a persistent opaque identifier, or vice versa. Agree on format during the planning phase.

**Certificate pinning.** Some SPs pin the exact signing certificate rather than trusting metadata updates. This makes certificate rollover a manual, coordinated effort. Identify pinning SPs early.

**Single Logout failures.** SLO is specified in SAML 2.0 but inconsistently implemented. Plan for SLO to fail and implement session timeouts as the primary session termination mechanism.

## Security Considerations

**Federation as an attack vector.** A compromised partner IdP can issue valid tokens for any user in the federated relationship. Mitigate this by limiting the attributes and roles that federated tokens can assert, implementing anomaly detection on federated authentication patterns, and having a kill switch to instantly disable a federation trust.

**Token theft and replay.** Federated tokens can be intercepted and replayed if TLS is compromised. Enforce short token validity (5 minutes for SAML assertions) and validate InResponseTo/nonce. For OAuth and OIDC tokens issued after federation, use sender-constrained tokens such as [DPoP](https://startwithidentity.com/glossary/dpop/) ([RFC 9449](https://datatracker.ietf.org/doc/html/rfc9449)), and for browser sessions consider [Device Bound Session Credentials](https://startwithidentity.com/glossary/device-bound-session-credentials/) where your browsers and apps support them.

**Attribute injection.** A compromised or malicious IdP could inject false attributes (e.g., claiming a user has admin role). Validate attributes against expected patterns and implement attribute filtering at the SP.

## Conclusion

Identity federation is a powerful capability that enables smooth cross-organizational access while keeping identity management decentralized. The implementation requires careful attention to protocol selection, metadata exchange, attribute mapping, and session management, but the payoff is significant: reduced account sprawl, better user experience, and stronger security through centralized authentication.

Start with a single, well-understood federation partner to prove your architecture. Build reusable templates for metadata exchange, attribute mapping, and security policies. Then scale to additional partners using a hub-and-spoke model that keeps management overhead linear.

## Identity Governance Program Guide: Building an Effective IGA Framework
Source: https://startwithidentity.com/guides/implementation/identity-governance-program-guide/
Last updated: 2026-11-05

Identity Governance and Administration (IGA) is the discipline of ensuring the right people have the right access to the right resources at the right time, and proving it. While Identity and Access Management (IAM) handles the mechanics of authentication and authorization, IGA provides the oversight layer: who approved this access, is it still appropriate, does it violate any policies, and can we demonstrate compliance to auditors?

Organizations that lack a formal IGA program accumulate access debt over time. Permissions granted for a project three years ago remain active. Users who changed roles retain entitlements from both positions. Segregation of duties violations go undetected. When auditors arrive, the scramble to produce evidence consumes weeks of effort.

This guide walks you through building an IGA program from the ground up.

## Prerequisites

- **Executive sponsor**, IGA programs require sustained investment and organizational change. Without executive backing, they stall.
- **Identity data foundation**, You need a reasonably accurate directory of who exists in your organization and what access they have. Perfect data is not required to start, but you need a baseline.
- **Application inventory**, A catalog of applications, their owners, and the entitlements they provide.
- **Regulatory context**, Understanding of which regulations apply to your organization (SOX, HIPAA, SOC 2, GDPR, PCI DSS) and their access governance requirements.
- **IGA tooling**, [SailPoint](https://startwithidentity.com/vendors/iga/sailpoint/), [Saviynt](https://startwithidentity.com/vendors/iga/saviynt/), [One Identity](https://startwithidentity.com/vendors/iga/one-identity/), or similar IGA platform. [Microsoft Entra](https://startwithidentity.com/vendors/iam/microsoft-entra/) ID Governance is an option for Microsoft-centric environments.

## Architecture: The IGA Framework

### The Four Pillars of Identity Governance

**1. Access Lifecycle Management**
Managing access from request through approval, provisioning, review, and eventual revocation. This encompasses:
- Access request workflows
- Approval chains with business context
- Time-bound access grants
- Automated provisioning and deprovisioning

**2. Access Certification (Reviews)**
Periodic validation that existing access is still appropriate:
- Manager certifications (does this person still need this access?)
- Application owner certifications (should this role exist?)
- Entitlement owner certifications (is this permission still valid?)

**3. Segregation of Duties (SoD)**
Preventing toxic combinations of access that create fraud or compliance risk:
- Define conflicting entitlements
- Detect violations in real time
- Enforce preventive controls
- Manage exceptions with compensating controls

**4. Policy and Role Management**
Defining and maintaining the rules that govern access:
- Role mining and engineering
- Access policies and standards
- Entitlement catalogs
- Governance workflows

### The Governance Operating Model

```
Board / Audit Committee
    ↓ (oversight)
CISO / CIO (Executive Sponsors)
    ↓ (direction)
Identity Governance Committee
    ↓ (policy, standards)
IGA Operations Team
    ↓ (execution)
Business Unit Access Owners ←→ Application Owners
    ↓ (certification, approval)
End Users (request access, participate in reviews)
```

## Step-by-Step Implementation

### Step 1: Establish Governance Structure

**Form an Identity Governance Committee** with representatives from:
- Information Security (chair)
- IT Operations
- Internal Audit
- Compliance / Legal
- HR
- Key business units (Finance, Engineering, Sales)

This committee meets monthly to:
- Review IGA program metrics and health
- Approve new governance policies
- Adjudicate escalated SoD exceptions
- Prioritize application onboarding

**Define roles and responsibilities:**

| Role | Responsibility |
|---|---|
| IGA Program Manager | Overall program execution, reporting, stakeholder management |
| Access Certification Manager | Certification campaign design, scheduling, completion tracking |
| SoD Analyst | Rule definition, violation analysis, exception management |
| Application Owner | Certify application access, define entitlements, approve requests |
| Business Manager | Certify direct reports' access, approve access requests |
| Data Owner | Define data classification, approve access to sensitive data |

### Step 2: Build Your Application and Entitlement Inventory

You cannot govern what you cannot see. Build a complete inventory:

**Application inventory fields:**
- Application name and identifier
- Business owner and technical owner
- Criticality rating (critical, high, medium, low)
- Regulatory scope (SOX, HIPAA, PCI, etc.)
- Number of users and entitlements
- Integration method (SCIM, API, manual)
- Last certification date

**Entitlement inventory fields:**
- Entitlement name and description
- Application association
- Risk level (high, medium, low)
- SoD relevance (is this entitlement part of any SoD rule?)
- Business meaning (not just the technical name, but what this entitlement allows the user to do)

**Prioritization:** Start with applications in regulatory scope. SOX-relevant financial systems, HIPAA-covered health systems, and PCI-scoped payment systems should be onboarded first.

### Step 3: Design Access Certification Campaigns

Access certifications are the core activity of identity governance. Design them for effectiveness, not just compliance.

**Campaign types:**

**Manager certification**, Each manager reviews all access held by their direct reports.
- Frequency: Quarterly for high-risk applications, semi-annually for others.
- Scope: All entitlements across all applications for each direct report.
- Decision: Certify (access is appropriate), Revoke (access should be removed), Delegate (another reviewer should decide).

**Application owner certification**, Each application owner reviews all users with access to their application.
- Frequency: Semi-annually.
- Scope: All users and their entitlements within the application.
- Best for: Applications with many users where the app owner understands access better than individual managers.

**Entitlement certification**, Review specific high-risk entitlements across all holders.
- Frequency: Quarterly or as triggered by events.
- Scope: A specific entitlement (e.g., "Domain Admin" or "Financial System Approver") and every user who holds it.
- Best for: Privileged access and SoD-relevant entitlements.

**Event-triggered certification**, Triggered by lifecycle events rather than schedule.
- Trigger: Role change (mover event), extended leave return, project completion.
- Scope: All access held by the affected user.
- Rationale: Access that was appropriate before the event may no longer be appropriate after.

### Step 4: Implement Segregation of Duties

SoD prevents any single person from controlling all aspects of a critical business process. The classic example: the person who creates a purchase order should not also be able to approve it and process the payment.

**Defining SoD rules:**

Work with business process owners to identify toxic combinations:

```
Rule: Financial SoD - AP Processing
Conflicting Entitlements:
  Side A: "Create Vendor" OR "Modify Vendor Bank Details"
  Side B: "Approve Payment" OR "Process Payment Run"
Risk Level: Critical
Compensating Control: Monthly reconciliation by Finance Director
```

```
Rule: IT SoD - Change Management
Conflicting Entitlements:
  Side A: "Deploy to Production"
  Side B: "Approve Change Request"
Risk Level: High
Compensating Control: Automated deployment audit log review
```

**SoD enforcement levels:**

1. **Preventive**, Block the access request if it would create a violation. This is the strongest control but requires complete SoD rule coverage.
2. **Detective**, Allow the access but generate an alert. An analyst reviews the violation and either requires remediation or approves an exception with compensating controls.
3. **Monitoring**, Run periodic SoD scans across all access. Report violations for remediation. This is the starting point for most organizations.

### Step 5: Build Access Request Workflows

Replace ad-hoc access requests (email, tickets) with structured governance workflows.

**Request workflow design:**

1. **User initiates request**, From a self-service portal or catalog. The catalog shows only entitlements the user is eligible to request.
2. **Risk assessment**, The system automatically evaluates the request against SoD rules and policy. Flag any violations.
3. **Approval routing**, Route to the appropriate approver(s) based on the entitlement risk level:
   - Low risk: Manager approval only
   - Medium risk: Manager + application owner approval
   - High risk: Manager + application owner + security team approval
   - SoD violation: All of the above + IGA committee or designated exception approver
4. **Time-bound option**, Allow requesters to specify an end date. Encourage time-bound access for project-based needs.
5. **Provisioning**, Upon approval, automatically provision the access through SCIM, API, or ticketed manual provisioning.
6. **Confirmation**, Notify the requester that access is provisioned and remind them of the expiration date if time-bound.

### Step 6: Configure Governance Reporting

**Operational dashboards:**
- Certification campaign completion rates (typical practitioner target, not a benchmark: 95%+ on-time completion)
- Open SoD violations by risk level
- Access request volume and average fulfillment time
- Orphan account count
- Accounts with no manager assigned

**Compliance reports:**
- Certification history for each user (when was their access last reviewed, by whom, what was the decision?)
- SoD violation inventory with exception approvals and compensating controls
- Access provisioning and deprovisioning audit trail
- Policy violation summary

**Executive metrics:**
- Overall governance program maturity score
- Percentage of applications under governance
- Trend in excess access (permissions revoked during certifications)
- Audit finding trends related to access governance

### Step 7: Launch and Iterate

**Phase 1: Foundation (Months 1-3)**
- Establish governance committee
- Deploy IGA platform
- Onboard first 5 applications (highest risk/regulatory priority)
- Run first manager certification campaign
- Define first 10 SoD rules

**Phase 2: Expansion (Months 4-8)**
- Onboard next 15-20 applications
- Implement access request workflows
- Enable preventive SoD controls for critical rules
- Run application owner certifications
- Begin entitlement cleanup based on certification results

**Phase 3: Maturity (Months 9-12)**
- Onboard remaining in-scope applications
- Implement role mining and engineering
- Automate event-triggered certifications
- Establish governance reporting cadence
- Conduct first program maturity assessment

## Best Practices

### Make Certifications Meaningful

The biggest failure mode in access certification is rubber-stamping, reviewers approve everything without actually evaluating access. Combat this by:

- Providing business-readable descriptions of each entitlement (not just technical names).
- Showing usage data alongside entitlements (this user has not accessed this application in 180 days).
- Keeping certification scopes manageable (no more than 50 decisions per reviewer per campaign).
- Implementing a "micro-certification" model with smaller, more frequent reviews.
- Tracking and reporting rubber-stamping patterns (reviewers who certify 100% of access in under 2 minutes).

### Start with Detective SoD, Not Preventive

Preventive SoD controls (blocking requests that create violations) sound ideal but can paralyze operations if your SoD rules are not perfectly tuned. Start with detective controls, allow access but flag violations for review. Once you have validated your rules over 2-3 cycles and understand your exception patterns, graduate to preventive controls.

### Treat Exceptions as First-Class Citizens

SoD exceptions are not failures, they are business decisions to accept risk with compensating controls. Manage exceptions formally:
- Require documented business justification.
- Require a compensating control for every exception.
- Set expiration dates on exceptions (maximum 12 months, then re-approve).
- Track exception trends and address root causes.

### Govern Service Accounts Too

Service accounts and technical identities are often excluded from governance programs because they do not have human managers. This is a mistake. Service accounts frequently have the most powerful access. Assign technical owners to every service account and include them in certification campaigns.

## Testing

### Certification Campaign Testing

Before launching your first production campaign:
1. Run a pilot campaign with a friendly department (IT or Security).
2. Gather feedback on the reviewer experience, is the interface intuitive, are descriptions meaningful, is the scope manageable?
3. Test the revocation workflow, when access is revoked during certification, is it actually deprovisioned?
4. Verify escalation, what happens when a reviewer does not complete their certification by the deadline?

### SoD Rule Testing

1. Create test accounts with known access combinations.
2. Verify that SoD rules detect the violations correctly.
3. Test false positive scenarios, access combinations that look like violations but are business-legitimate.
4. Validate that exception workflows function correctly.

## Common Pitfalls

### Boiling the Ocean

Trying to onboard all applications simultaneously overwhelms the team and produces low-quality governance. Start with 5-10 critical applications and expand methodically.

### Ignoring Data Quality

Governance is only as good as the data it operates on. If entitlement names are meaningless technical strings, reviewers cannot make informed decisions. Invest in entitlement cataloging and business-readable descriptions before launching certifications.

### Making It a Technology Project

IGA is an organizational change initiative that uses technology, not a technology implementation. If you focus only on deploying the platform without building the governance processes, culture, and accountability, the program will fail.

### Not Closing the Loop

Certifications that revoke access on paper but do not actually deprovision the access are worse than no certifications at all, they create a false sense of security. Ensure automated deprovisioning for every revocation decision.

## Conclusion

An effective identity governance program is the backbone of access compliance and risk management. It transforms access management from an ad-hoc, trust-based system into a structured, evidence-based discipline. The investment is significant, in technology, process design, and organizational change, but the returns are tangible: clean audit findings, reduced access risk, faster access provisioning, and demonstrable compliance.

Start with the governance committee and a handful of critical applications. Build credibility through successful certification campaigns and visible SoD violation remediation. Expand methodically, measure relentlessly, and treat governance as an ongoing program, not a one-time project.

## Identity Threat Detection and Response (ITDR) Guide
Source: https://startwithidentity.com/guides/security/identity-threat-detection-response-guide/
Last updated: 2026-11-05

Stolen and abused credentials are among the most common ways attackers get in, and adversaries increasingly use identity-based techniques, credential theft, privilege escalation, lateral movement, and MFA bypass, to achieve their objectives. Traditional security tools like firewalls and endpoint detection are necessary but insufficient. They were not designed to detect the subtle signals of identity compromise.

Identity Threat Detection and Response (ITDR) fills this gap. ITDR is a security discipline focused on detecting attacks that target the identity infrastructure itself, directory services, authentication protocols, identity providers, and privileged access, and responding to those attacks before they cause damage.

This guide walks you through building an ITDR capability, from architecture through detection engineering to response playbooks.

## What You Will Learn

- The ITDR framework and how it fits into your security stack
- Key identity attack techniques and how to detect them
- Building detection rules for credential theft, privilege escalation, and lateral movement
- Designing response playbooks for identity incidents
- Integrating ITDR with your existing SIEM and SOAR

## Prerequisites

1. **Centralized logging**, Identity events from your IdP, Active Directory, cloud IAM, VPN, and critical applications must flow to a central SIEM or data lake.
2. **Active Directory auditing**, AD is the primary target for identity attacks. Advanced audit policies must be enabled (discussed in Step 2).
3. **IdP event logging**, Your IdP (Okta, Microsoft Entra ID, Ping) must export authentication, authorization, and administrative events.
4. **Baseline behavior data**, At least 30 days of historical identity event data to establish behavioral baselines.
5. **Incident response team**, People who will triage and respond to identity alerts. This can be your existing SOC team with identity-specific training.

## Architecture Overview

ITDR operates as a specialized detection and response layer focused on identity signals:

- **Identity Data Sources:** Active Directory, Microsoft Entra ID, Okta, cloud IAM (AWS, GCP, Azure), VPN, PAM, RADIUS, and application authentication logs. Identity providers that support the Shared Signals Framework can also push [RISC](https://startwithidentity.com/glossary/risc/) account events, such as credential compromise or sessions revoked, instead of waiting for a log pull.
- **ITDR Detection Engine:** Analyzes identity events in real-time and near-real-time, applying detection rules, behavioral analytics, and machine learning models.
- **Alert Correlation:** Correlates individual identity signals into attack narratives (e.g., password spray followed by MFA bypass followed by privilege escalation = likely compromise).
- **Response Orchestration:** Integrates with SOAR platforms to automate containment actions (disable account, revoke sessions, force re-authentication, block IP).
- **Identity Posture Management:** Continuously assesses the security configuration of identity infrastructure (AD misconfigurations, overprivileged accounts, stale credentials).

**Data flow:** Identity systems generate events -> Events stream to SIEM/ITDR platform -> Detection rules evaluate events -> Alerts fire for suspicious activity -> SOC analysts investigate -> Response playbooks execute containment and remediation actions.

The ITDR platform can be a dedicated product ([CrowdStrike Falcon Identity Protection](https://startwithidentity.com/vendors/itdr/crowdstrike-falcon-identity/), [Microsoft Defender for Identity](https://startwithidentity.com/vendors/itdr/microsoft-defender-identity/), [Semperis](https://startwithidentity.com/vendors/itdr/semperis/)) or a set of detection rules and playbooks built on your existing SIEM (Splunk, Sentinel, Google Security Operations).

## Step-by-Step Implementation

### Step 1: Instrument Identity Data Sources

The quality of your detection depends on the quality of your data. Enable complete logging on every identity system:

**Active Directory:**
```powershell
# Enable advanced audit policy via Group Policy
# Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy

# Critical audit categories:
# Account Logon:
#   - Audit Credential Validation: Success and Failure
#   - Audit Kerberos Authentication Service: Success and Failure
#   - Audit Kerberos Service Ticket Operations: Success and Failure

# Account Management:
#   - Audit User Account Management: Success and Failure
#   - Audit Security Group Management: Success and Failure

# Logon/Logoff:
#   - Audit Logon: Success and Failure
#   - Audit Special Logon: Success

# Directory Service Access:
#   - Audit Directory Service Changes: Success

# Verify audit policy is applied
auditpol /get /category:*
```

**Cloud IdP (example: Okta):**
```json
{
  "log_streaming": {
    "destination": "siem",
    "event_types": [
      "user.authentication.sso",
      "user.authentication.auth_via_mfa",
      "user.session.start",
      "user.account.lock",
      "user.mfa.factor.update",
      "policy.evaluate_sign_on",
      "application.user_membership.add",
      "group.user_membership.add",
      "system.api_token.create",
      "user.account.privilege.grant"
    ],
    "format": "json",
    "real_time": true
  }
}
```

**Cloud IAM (AWS CloudTrail):**
```json
{
  "Trail": {
    "Name": "identity-events",
    "S3BucketName": "security-logs",
    "IsMultiRegionTrail": true,
    "EventSelectors": [
      {
        "ReadWriteType": "All",
        "IncludeManagementEvents": true,
        "DataResources": [
          {
            "Type": "AWS::IAM::Role",
            "Values": ["arn:aws:iam::*"]
          }
        ]
      }
    ]
  }
}
```

### Step 2: Build Core Detection Rules

Start with high-fidelity detection rules for the most common identity attack techniques:

**Detection: Password Spray Attack**
```yaml
rule:
  name: "Password Spray Detected"
  description: "Multiple accounts experiencing failed authentication from same source in short window"
  data_source: "idp_authentication_logs"
  logic: |
    SELECT source_ip, COUNT(DISTINCT username) as unique_users, COUNT(*) as total_failures
    FROM auth_events
    WHERE event_type = 'authentication_failure'
      AND timestamp > NOW() - INTERVAL '10 minutes'
    GROUP BY source_ip
    HAVING unique_users > 10 AND total_failures > 25
  severity: high
  mitre_att_ck: "T1110.003"
  response: "password_spray_playbook"
```

**Detection: Impossible Travel**
```yaml
rule:
  name: "Impossible Travel Detected"
  description: "User authenticated from two geographically distant locations within an impossible timeframe"
  data_source: "idp_authentication_logs"
  logic: |
    WITH user_logins AS (
      SELECT username, source_ip, geo_location, timestamp,
        LAG(geo_location) OVER (PARTITION BY username ORDER BY timestamp) as prev_location,
        LAG(timestamp) OVER (PARTITION BY username ORDER BY timestamp) as prev_timestamp
      FROM auth_events
      WHERE event_type = 'authentication_success'
    )
    SELECT * FROM user_logins
    WHERE geo_distance(geo_location, prev_location) > 500  -- km
      AND EXTRACT(EPOCH FROM (timestamp - prev_timestamp)) / 3600 < 2  -- hours
  severity: high
  mitre_att_ck: "T1078"
  response: "impossible_travel_playbook"
```

**Detection: Kerberoasting**
```yaml
rule:
  name: "Kerberoasting Activity Detected"
  description: "Excessive TGS requests for service accounts with RC4 encryption from single source"
  data_source: "windows_security_log"
  logic: |
    Event ID 4769 (Kerberos Service Ticket Requested)
    WHERE TicketEncryptionType = 0x17 (RC4)
      AND ServiceName NOT LIKE '%$'  -- Exclude machine accounts
      AND COUNT(DISTINCT ServiceName) > 5 WITHIN 5 minutes FROM same IpAddress
  severity: critical
  mitre_att_ck: "T1558.003"
  response: "kerberoasting_playbook"
```

**Detection: DCSync Attack**
```yaml
rule:
  name: "DCSync Attack Detected"
  description: "Non-domain-controller machine requesting directory replication"
  data_source: "windows_security_log"
  logic: |
    Event ID 4662 (Directory Service Access)
    WHERE Properties CONTAINS '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2'  -- DS-Replication-Get-Changes
      OR Properties CONTAINS '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'   -- DS-Replication-Get-Changes-All
      AND SubjectUserName NOT IN (known_domain_controllers)
  severity: critical
  mitre_att_ck: "T1003.006"
  response: "dcsync_playbook"
```

**Detection: MFA Fatigue Attack**
```yaml
rule:
  name: "MFA Fatigue Attack Detected"
  description: "Multiple MFA push notifications sent to same user in short period with repeated denials"
  data_source: "idp_mfa_logs"
  logic: |
    SELECT username, COUNT(*) as push_count,
      SUM(CASE WHEN result = 'denied' THEN 1 ELSE 0 END) as denied_count
    FROM mfa_events
    WHERE factor_type = 'push'
      AND timestamp > NOW() - INTERVAL '10 minutes'
    GROUP BY username
    HAVING push_count > 5 AND denied_count > 3
  severity: high
  mitre_att_ck: "T1621"
  response: "mfa_fatigue_playbook"
```

**Detection: Privilege Escalation via Group Membership**
```yaml
rule:
  name: "Sensitive Group Membership Change"
  description: "User added to privileged group outside of change window"
  data_source: "active_directory_logs"
  logic: |
    Event ID 4728 (Member Added to Security Group)
    WHERE TargetGroupName IN (
      'Domain Admins', 'Enterprise Admins', 'Schema Admins',
      'Account Operators', 'Backup Operators', 'Server Operators'
    )
    AND NOT within_change_window()
    AND SubjectUserName NOT IN (authorized_identity_admins)
  severity: critical
  mitre_att_ck: "T1078.002"
  response: "privilege_escalation_playbook"
```

### Step 3: Implement Behavioral Analytics

Rule-based detection catches known patterns. Behavioral analytics catches unknown patterns:

- **Authentication baseline:** Build a profile of each user's normal authentication behavior (time of day, source IP ranges, applications accessed, geographic locations). Alert on deviations.
- **Access pattern baseline:** Track which resources each user normally accesses. Alert when a user accesses a resource they have never accessed before, especially if it is a sensitive resource.
- **Velocity anomalies:** Detect sudden increases in authentication events, group membership changes, or permission modifications that exceed normal rates.
- **Peer group analysis:** Compare a user's behavior to their peer group (same department, same role). If one member of the Finance team suddenly starts accessing engineering resources, that is anomalous.

```python
# Simplified behavioral anomaly detection
def detect_anomaly(user_id, event):
    baseline = get_user_baseline(user_id)

    # Check for unusual login time
    if not baseline.is_normal_hour(event.timestamp.hour):
        create_alert("unusual_login_time", user_id, event, severity="medium")

    # Check for new source IP
    if event.source_ip not in baseline.known_ips:
        create_alert("new_source_ip", user_id, event, severity="medium")

    # Check for first-time resource access
    if event.resource not in baseline.accessed_resources:
        if event.resource in sensitive_resources:
            create_alert("new_sensitive_resource_access", user_id, event, severity="high")

    # Check for velocity anomaly
    recent_event_count = count_events(user_id, last_minutes=30)
    if recent_event_count > baseline.avg_30min_events * 3:
        create_alert("velocity_anomaly", user_id, event, severity="high")
```

### Step 4: Build Response Playbooks

Detection without response is just expensive logging. Build automated and semi-automated response playbooks:

**Playbook: Password Spray Response**
```yaml
playbook:
  name: "Password Spray Response"
  trigger: "password_spray_detected"
  steps:
    - action: "block_source_ip"
      target: "firewall, waf"
      parameters:
        ip: "{{ alert.source_ip }}"
        duration: "24h"

    - action: "identify_compromised_accounts"
      description: "Find accounts that authenticated successfully from the spray source"
      query: |
        SELECT username FROM auth_events
        WHERE source_ip = '{{ alert.source_ip }}'
          AND event_type = 'authentication_success'
          AND timestamp BETWEEN '{{ alert.start_time }}' AND '{{ alert.end_time }}'

    - action: "force_password_reset"
      target: "compromised_accounts"
      description: "Reset passwords for any account that authenticated from the spray source"

    - action: "revoke_sessions"
      target: "compromised_accounts"

    - action: "notify_soc"
      message: "Password spray from {{ alert.source_ip }}. {{ compromised_count }} accounts potentially compromised. Containment actions executed."

    - action: "create_incident_ticket"
      severity: "high"
```

**Playbook: Compromised Account Response**
```yaml
playbook:
  name: "Compromised Account Response"
  trigger: "account_compromise_confirmed"
  steps:
    - action: "disable_account"
      target: "{{ alert.username }}"
      systems: ["active_directory", "idp", "cloud_iam"]

    - action: "revoke_all_sessions"
      target: "{{ alert.username }}"

    - action: "revoke_all_tokens"
      target: "{{ alert.username }}"
      systems: ["oauth_server", "saml_idp"]

    - action: "reset_mfa"
      target: "{{ alert.username }}"

    - action: "audit_recent_activity"
      target: "{{ alert.username }}"
      window: "72h"
      description: "Gather all actions taken by this account in the last 72 hours for forensic analysis"

    - action: "check_lateral_movement"
      description: "Identify systems the compromised account accessed and check for persistence"

    - action: "notify_user_manager"
      message: "{{ alert.username }}'s account has been disabled due to suspected compromise. Contact the security team for re-enablement."

    - action: "escalate_to_ir_team"
      if: "lateral_movement_detected OR sensitive_data_accessed"
```

### Step 5: Establish Identity Posture Management

ITDR is not only about detecting active attacks. It also involves continuously assessing and improving the security posture of your identity infrastructure:

- **AD security assessment:** Regularly scan for AD misconfigurations: unconstrained delegation, SPNs on privileged accounts, AdminCount without AdminSDHolder protection, weak Kerberos configurations.
- **IdP configuration review:** Audit authentication policies, conditional access rules, and administrative access quarterly.
- **Stale identity cleanup:** Identify and disable accounts that have not authenticated in 90 days.
- **Privilege creep review:** Quarterly access reviews for privileged group memberships and role assignments.

```powershell
# Example AD posture checks
# Find accounts with unconstrained delegation (attack target for Kerberos delegation attacks)
Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation |
  Select-Object Name, TrustedForDelegation

# Find SPNs on privileged accounts (Kerberoasting targets)
Get-ADUser -Filter {ServicePrincipalName -ne "$null" -and AdminCount -eq 1} `
  -Properties ServicePrincipalName |
  Select-Object Name, ServicePrincipalName

# Find accounts with passwords older than 1 year
Get-ADUser -Filter {Enabled -eq $true -and PasswordLastSet -lt $((Get-Date).AddDays(-365))} `
  -Properties PasswordLastSet |
  Select-Object Name, PasswordLastSet
```

## Configuration Best Practices

- **Tune before you alert.** Run detection rules in logging-only mode, typically 2-4 weeks as a practitioner estimate, to establish baselines and eliminate false positives before enabling alerting.
- **Prioritize high-fidelity rules.** Start with DCSync, Golden Ticket, and Kerberoasting detection, these have high true-positive rates and indicate serious compromise.
- **Correlate across sources.** A single failed login is noise. A failed login from a new IP followed by a successful login followed by a privilege escalation is a story. Build correlation rules that chain events.
- **Automate containment.** For high-confidence, high-severity detections (DCSync from a non-DC, Golden Ticket usage), automate containment (disable account, isolate host) without waiting for human approval.
- **Maintain detection rule hygiene.** Review and update detection rules quarterly. Attackers evolve their techniques, and your detections must evolve with them.

## Testing and Validation

1. **Purple team exercises:** Simulate identity attacks (password spray, Kerberoasting, DCSync) in a controlled environment and verify that detection rules fire correctly.
2. **Detection coverage mapping:** Map your detection rules to the MITRE ATT&CK framework. Identify gaps in coverage for identity-related techniques.
3. **Playbook dry runs:** Walk through each response playbook as a tabletop exercise with the SOC team before an actual incident.
4. **False positive analysis:** After 30 days of operation, review all alerts. Calculate the false positive rate and tune rules to reduce noise.
5. **Mean time to detect (MTTD):** Measure how long it takes from attack execution to alert firing. A typical practitioner target, not a measured benchmark, is under 5 minutes for critical detections.
6. **Mean time to respond (MTTR):** Measure how long it takes from alert to containment. As a practitioner estimate, automated playbooks should achieve under 2 minutes.

## Common Pitfalls and Troubleshooting

| Pitfall | Impact | Mitigation |
|---------|--------|------------|
| Insufficient AD logging | Critical attacks go undetected | Enable advanced audit policies; verify events appear in SIEM |
| Alert fatigue from noisy rules | SOC ignores identity alerts | Tune aggressively; suppress known false positives; prioritize high-fidelity rules |
| No correlation across identity sources | Attack narrative fragmented | Normalize identity events to a common schema; correlate on username + time window |
| Automated response without guardrails | False positive triggers account lockout | Require high confidence threshold for automated actions; build in human approval for borderline cases |
| Stale baselines | Behavioral models produce false positives after legitimate changes | Retrain baselines monthly; account for organizational changes (new hires, role changes) |

## Security Considerations

1. **Protect the ITDR platform.** If attackers compromise your detection platform, they can suppress alerts while conducting their attack. Treat the ITDR platform as critical infrastructure with dedicated admin accounts and MFA.
2. **Log integrity.** Attackers who compromise AD can potentially tamper with security logs. Forward logs to a write-once/append-only store (immutable storage) to preserve forensic evidence.
3. **Insider threat detection.** ITDR should detect not only external attackers but also malicious insiders who use their legitimate credentials for unauthorized purposes. Behavioral analytics is essential for this use case.
4. **Privacy considerations.** Behavioral monitoring touches on employee privacy. Work with legal and HR to ensure your ITDR program complies with local privacy laws and internal policies.
5. **Detection evasion.** Sophisticated attackers will attempt to evade detection by operating slowly (low-and-slow attacks), using legitimate tools (living off the land), or compromising monitoring agents. Layer multiple detection approaches (rules, behavioral analytics, deception) to increase coverage.

## Conclusion

ITDR is not optional, it is the natural evolution of security operations in an identity-centric world. As organizations move to zero trust architectures and identity becomes the primary security perimeter, the ability to detect and respond to identity-based attacks becomes as important as endpoint detection and network monitoring.

Start with the fundamentals: instrument your identity data sources, build high-fidelity detection rules for known attack patterns, and create response playbooks that contain threats quickly. Then layer in behavioral analytics for unknown patterns and posture management for preventive controls. Each capability you add reduces your exposure to identity-based attacks.

## Identity-first architecture: principles that hold up at scale
Source: https://startwithidentity.com/guides/architecture/identity-first-architecture/
Last updated: 2026-11-05

Identity-first architecture is a design approach that makes identity, not network location, the primary control point for every access decision: each request is evaluated on who or what is asking, with what assurance and context, before it reaches a resource. It applies equally to employees, customers, workloads, devices, and AI agents. These seven principles separate architectures that scale from architectures that get redesigned at every order of magnitude. For the strategy view, see [identity-first security strategy](https://startwithidentity.com/articles/identity-first-security-strategy/).

## The principles at a glance

| Principle | Failure mode when skipped | Real incident | Implementing standard or pattern |
| --- | --- | --- | --- |
| One system of record per identity type | Forgotten identities nobody owns | [Midnight Blizzard via a legacy test tenant](https://startwithidentity.com/breaches/incidents/2024-microsoft-midnight-blizzard-password-spray/) | Separate directories, federated at decision time |
| Separate authentication and authorization | Login success treated as permission | [Optus API returning data without valid authorization](https://startwithidentity.com/breaches/incidents/2022-optus-unauthenticated-api/) | [AuthZEN](https://startwithidentity.com/standards/authzen/) PDP and PEP |
| Short-lived credentials | Leaked secrets stay valid for months | [Cloudflare's unrotated credentials](https://startwithidentity.com/breaches/incidents/2024-cloudflare-unrotated-okta-breach-credentials/) | [SPIFFE](https://startwithidentity.com/glossary/spiffe/), [token exchange](https://startwithidentity.com/glossary/token-exchange/) |
| Risk signals at every decision | Stolen sessions keep working after risk changes | [Okta support HAR session tokens](https://startwithidentity.com/breaches/incidents/2023-okta-support-system-har-session-tokens/) | [Shared Signals Framework](https://startwithidentity.com/standards/shared-signals-framework/) |
| First-class audit | Compromise found by the victim, not the provider | [Storm-0558 token forgery](https://startwithidentity.com/breaches/incidents/2023-storm-0558-microsoft-signing-key-forgery/) | Structured identity event logs |
| Recover gracefully | Recovery becomes the bypass | [MGM Resorts help desk](https://startwithidentity.com/breaches/incidents/2023-mgm-resorts-help-desk-ransomware/) | Phishing-resistant recovery |
| Federate, don't replicate | Stale copies of access outlive their source | [Orphaned account abuse](https://startwithidentity.com/techniques/orphaned-account-abuse/) | [OpenID Connect](https://startwithidentity.com/standards/openid-connect/), [SCIM 2.0](https://startwithidentity.com/standards/scim-2-0/) |

## Principle 1: One system of record per identity type

Humans, workloads, devices, and [AI agents](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/) are distinct identity types. They share patterns but should not share a primary directory. Modeling workload identity inside an HR-driven directory leads to schema gymnastics and lifecycle mismatches, because a container does not onboard like an employee. Keep the systems of record separate, give each identity an owner, and federate them at the point of the access decision. Microsoft's Midnight Blizzard incident started with a non-production test tenant account without MFA and a legacy OAuth app that still had elevated access to the corporate tenant: an identity nobody treated as production.

## Principle 2: Authentication and authorization are separate concerns

[Authentication](https://startwithidentity.com/guides/fundamentals/authentication-vs-authorization/) answers "who is this?" Authorization answers "what can they do here?" Make them different services so each can change without destabilizing the other. Since January 2026 there is a standard seam between them: the [AuthZEN Authorization API 1.0](https://openid.net/specs/authorization-api-1_0.html) is a Final OpenID Foundation specification in which a Policy Enforcement Point (an app, gateway, or MCP server) asks a Policy Decision Point whether a subject may perform an action on a resource. Engines such as [OpenFGA](https://startwithidentity.com/vendors/authorization/openfga/) and [Cerbos](https://startwithidentity.com/vendors/authorization/cerbos/) can sit behind it, so you can swap the engine without rewriting every application.

## Principle 3: Short-lived credentials by default

Long-lived API keys, service-account passwords, and 90-day rotating secrets are what attackers look for in [repositories and CI](https://startwithidentity.com/techniques/secrets-in-repositories-and-ci/) and abuse through [static API keys](https://startwithidentity.com/techniques/static-api-key-abuse/). Cloudflare's Atlassian intrusion used one access token and three service account credentials from the Okta support breach that had not been rotated. Issue short-lived credentials, valid for minutes rather than months, from a central authority. [Workload identity](https://startwithidentity.com/guides/machine-identity/workload-identity-101/) via [SPIFFE / SPIRE](https://startwithidentity.com/vendors/machine-identity/spiffe-spire/) (CNCF graduated, [September 2022](https://www.cncf.io/announcements/2022/09/20/spiffe-and-spire-projects-graduate-from-cloud-native-computing-foundation-incubator/)) or cloud-native federation is the baseline, and [RFC 8693](https://www.rfc-editor.org/rfc/rfc8693.html) token exchange lets a service trade one token for a narrower, shorter one when it calls downstream. Signing keys need the same discipline: Storm-0558 forged enterprise tokens with an acquired Microsoft consumer signing key.

## Principle 4: Risk signals at every decision point

Static role assignments lose context the moment they are granted. Feed device posture, location, behavior, and session risk into every meaningful access decision, and keep evaluating after login. In the Okta support breach, attackers used live session tokens from HAR files to hijack sessions at five customers; a session that cannot learn about risk after issuance is a bearer instrument. The [OpenID Shared Signals Framework](https://openid.net/specs/openid-sharedsignals-framework-1_0-final.html) (Final, August 2025) with [CAEP](https://startwithidentity.com/glossary/caep/) lets an IdP tell SaaS apps that a session was revoked or a device fell out of compliance. Also defend against [session cookie theft](https://startwithidentity.com/techniques/session-cookie-theft/) and [refresh token abuse](https://startwithidentity.com/techniques/refresh-token-abuse/).

## Principle 5: Audit logs are first-class

Every identity-affecting event must produce a structured audit log entry: who, what, which credential, from where, and the policy decision. Storm-0558 was detected by the US State Department through its own audit logs, which is the argument for treating logs as a product feature rather than a premium add-on. Build coverage from the first commit; retrofitting it is far harder.

## Principle 6: Recover gracefully

Lost devices, departed admins, and compromised credentials are where identity systems fail. Design recovery before the happy path. At MGM Resorts, a call to the IT help desk impersonating an employee led to control of Okta super administrator accounts. [Help desk social engineering](https://startwithidentity.com/techniques/help-desk-social-engineering/) and the [Coinbase SMS recovery flaw](https://startwithidentity.com/breaches/incidents/2021-coinbase-sms-recovery-flaw/) show that recovery must be at least as strong as sign-in: verified identity, no SMS-only reset for privileged roles, and [break-glass](https://startwithidentity.com/glossary/break-glass/) accounts that are monitored.

## Principle 7: Federate, don't replicate

If you are copying user data from one system to another, you are building a synchronization problem. Federate to the source of truth with OIDC or SAML, provision with SCIM where an app needs a local account, and treat replication as a deliberate exception with an owner. Stale copies feed [mover entitlement accumulation](https://startwithidentity.com/techniques/mover-entitlement-accumulation/) and orphaned accounts.

## A reference shape for the access path

A request carries an identity assertion from an identity provider such as [Okta](https://startwithidentity.com/vendors/iam/okta/), [Microsoft Entra](https://startwithidentity.com/vendors/iam/microsoft-entra/), or [Ping Identity](https://startwithidentity.com/vendors/iam/ping-identity/); a policy decision point evaluates that identity plus live signals against policy; a policy enforcement point at the resource allows or denies; and every step emits an audit event. Workloads and agents get attested identities and short-lived tokens rather than shared secrets, through SPIFFE or a workload access broker such as [Aembit](https://startwithidentity.com/vendors/ai-identity/aembit/). Entitlement visibility across this graph is its own layer: note that [Veza](https://startwithidentity.com/vendors/iga/veza/) is now part of ServiceNow (closed 2026-03-02), [SGNL](https://startwithidentity.com/vendors/authorization/sgnl/) part of CrowdStrike (closed 2026-02-20), and [Idira (formerly CyberArk)](https://startwithidentity.com/vendors/pam/cyberark/) part of Palo Alto Networks (closed 2026-02-11), so check roadmap commitments before you standardize. This shape is the enforcement backbone a [zero trust rollout](https://startwithidentity.com/guides/implementation/zero-trust-rollout/) depends on; for the product layer, see [what is an identity fabric](https://startwithidentity.com/guides/fundamentals/what-is-identity-fabric/).

## Standards status, November 2026

- **Final or stable:** OpenID Connect, SCIM 2.0, Shared Signals Framework 1.0 (CAEP, RISC), AuthZEN Authorization API 1.0, RFC 8693 Token Exchange.
- **Drafts to track:** [WIMSE](https://startwithidentity.com/standards/wimse/) for workload identity across systems, [OAuth Transaction Tokens](https://startwithidentity.com/standards/oauth-transaction-tokens/) for carrying caller context inside a call chain, and [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/).

Each principle marks a fork where the harder short-term choice avoids a rebuild at the next order of magnitude.

## Implementing Attribute-Based Access Control (ABAC): A Practical Guide
Source: https://startwithidentity.com/guides/authorization/implementing-abac-guide/
Last updated: 2026-11-05

Role-Based Access Control (RBAC) works well when access requirements are straightforward: developers access development resources, managers approve expenses, administrators manage systems. But when access decisions depend on combinations of attributes, the user's department AND the document's classification AND the time of day AND the user's location, RBAC collapses under role explosion. You end up with thousands of roles trying to represent every possible attribute combination.

Attribute-Based Access Control (ABAC) solves this by evaluating policies against attributes at the time of access, rather than pre-assigning permissions through roles. Instead of "User X has Role Y which grants Permission Z," ABAC says "Allow access if the user's clearance level is greater than or equal to the document's classification level AND the user's department matches the document's owning department AND the request originates from a trusted network."

This guide covers the practical implementation of ABAC, from policy design to deployment.

## Prerequisites

- **Clear access requirements** that involve multiple attributes (if your access model is simple enough for RBAC, use RBAC).
- **Reliable attribute sources**, User attributes from your IdP, resource attributes from your application, environment attributes from your infrastructure.
- **A policy engine**, Open Policy Agent (OPA), Axiomatics, PlainID, an [AuthZEN](https://startwithidentity.com/glossary/authzen/)-compliant engine, or XACML-based engine.
- **Application architecture** that supports externalized authorization (the application can call an external policy engine for access decisions).

## Architecture: ABAC Components

### The ABAC Reference Architecture

ABAC follows a standard architecture defined in NIST SP 800-162:

```
Subject (User)           Resource (Data/Service)
  ↓ attributes              ↓ attributes
  ↓                          ↓
Policy Enforcement Point (PEP)
  ↓ (authorization request)
Policy Decision Point (PDP)
  ↓ (evaluates policies)    ← Policy Administration Point (PAP)
  ↓ (retrieves attributes)  ← Policy Information Point (PIP)
  ↓
Decision: Permit / Deny / Not Applicable / Indeterminate
```

**Policy Enforcement Point (PEP):** The component that intercepts access requests and enforces the PDP's decision. This lives in or near your application, an API gateway, a middleware layer, or within the application code itself.

**Policy Decision Point (PDP):** The engine that evaluates policies against attributes and returns an authorization decision. This is the core of ABAC, OPA, Axiomatics, Cedar, or a XACML engine.

**Policy Administration Point (PAP):** Where policies are authored, tested, and managed. This is the administrative interface for your policy engine.

**Policy Information Point (PIP):** External attribute sources that the PDP queries when it needs attributes not included in the request. For example, querying the HR system for a user's department or querying a data catalog for a resource's classification level.

### ABAC vs. RBAC: When to Choose What

| Criteria | Use RBAC | Use ABAC |
|---|---|---|
| Access model complexity | Simple, role-aligned | Multi-dimensional, attribute-dependent |
| Number of access combinations | Manageable (dozens of roles) | Explosive (thousands of combinations) |
| Dynamic context needed | No (static role assignment sufficient) | Yes (time, location, risk level matter) |
| Regulatory requirements | Basic compliance (who has access to what) | Fine-grained compliance (why and under what conditions) |
| Implementation effort | Lower | Higher |
| Operational complexity | Lower | Higher |

The pragmatic answer for most organizations: **use RBAC as the foundation and add ABAC for specific high-value decisions** where RBAC alone cannot express the required policy.

## Step-by-Step Implementation

### Step 1: Define Your Attribute Taxonomy

Before writing policies, catalog the attributes you will use in access decisions.

**Subject attributes (about the user):**
- Identity: user ID, email, name
- Organizational: department, title, manager, cost center, location
- Security: clearance level, risk score, authentication strength, MFA status
- Contextual: current IP address, device type, device compliance status

**Resource attributes (about the thing being accessed):**
- Classification: public, internal, confidential, restricted
- Ownership: owning department, data steward, creator
- Type: document, database record, API endpoint, file
- Sensitivity: PII, PHI, financial, intellectual property

**Action attributes (what the user wants to do):**
- Operation: read, write, delete, approve, export, share
- Scope: single record, bulk export, administrative action

**Environment attributes (contextual conditions):**
- Time: current time, business hours, maintenance window
- Location: network zone, geographic region, trusted/untrusted
- Risk: threat intelligence signals, session risk score

### Step 2: Design Your Policies

ABAC policies follow a consistent structure: **Subject** wants to perform **Action** on **Resource** in **Environment**, allow or deny based on attribute conditions.

**Policy design principles:**

1. **Default deny**, If no policy explicitly permits the action, deny it.
2. **Positive authorization**, Write permit policies, not deny policies where possible. Deny policies should be reserved for explicit overrides.
3. **Policy modularity**, Break complex policies into composable, testable units.
4. **Business language first**, Write policies in business terms, then translate to technical policy language.

**Example policies in natural language:**

Policy 1: "Allow employees to read documents if the document's classification level does not exceed the employee's clearance level and the employee's department matches the document's owning department."

Policy 2: "Allow managers to approve expense reports if the expense amount is within their approval limit and the report was not submitted by themselves."

Policy 3: "Deny all access to financial systems outside of business hours unless the user has an active on-call assignment."

### Step 3: Choose and Deploy a Policy Engine

**Open Policy Agent (OPA) / Rego:**

OPA is the most widely adopted open-source policy engine. Policies are written in Rego, a declarative query language.

```rego
package document.access

import rego.v1

default allow := false

# Allow read if clearance >= classification and department matches
allow if {
    input.action == "read"
    input.subject.clearance_level >= input.resource.classification_level
    input.subject.department == input.resource.owning_department
}

# Allow managers to approve if within limit and not self-approval
allow if {
    input.action == "approve"
    input.subject.role == "manager"
    input.resource.type == "expense_report"
    input.resource.amount <= input.subject.approval_limit
    input.resource.submitter != input.subject.user_id
}

# Deny financial system access outside business hours
deny if {
    input.resource.system_type == "financial"
    not is_business_hours
    not input.subject.on_call
}

is_business_hours if {
    hour := time.clock(time.now_ns())[0]
    hour >= 8
    hour < 18
}
```

Deploy OPA as a sidecar, a centralized service, or embedded in your application:

```yaml
# OPA as a sidecar in Kubernetes
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-api
spec:
  template:
    spec:
      containers:
      - name: api
        image: my-api:latest
      - name: opa
        image: openpolicyagent/opa:latest
        args:
        - "run"
        - "--server"
        - "--addr=localhost:8181"
        - "/policies"
        volumeMounts:
        - name: policies
          mountPath: /policies
      volumes:
      - name: policies
        configMap:
          name: opa-policies
```

**AWS Cedar:**

Cedar is Amazon's policy language, used in Amazon Verified Permissions:

```cedar
permit (
    principal,
    action == Action::"ReadDocument",
    resource
)
when {
    principal.clearanceLevel >= resource.classificationLevel &&
    principal.department == resource.owningDepartment
};
```

**XACML:**

XACML (eXtensible Access Control Markup Language) is the original ABAC standard. It is XML-based and enterprise-grade but verbose:

```xml
<Policy PolicyId="document-read-policy"
        RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides">
  <Target>
    <AnyOf>
      <AllOf>
        <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
          <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>
          <AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"
                               AttributeId="action-id"
                               DataType="http://www.w3.org/2001/XMLSchema#string"/>
        </Match>
      </AllOf>
    </AnyOf>
  </Target>
  <Rule RuleId="clearance-check" Effect="Permit">
    <Condition>
      <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:integer-greater-than-or-equal">
        <AttributeDesignator Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
                             AttributeId="clearance-level"
                             DataType="http://www.w3.org/2001/XMLSchema#integer"/>
        <AttributeDesignator Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
                             AttributeId="classification-level"
                             DataType="http://www.w3.org/2001/XMLSchema#integer"/>
      </Apply>
    </Condition>
  </Rule>
</Policy>
```

Most modern implementations favor OPA/Rego or Cedar over XACML due to readability and developer experience.

### Step 4: Integrate the Policy Enforcement Point

The PEP is where your application calls the policy engine. This can be implemented at several layers:

**API Gateway PEP:**

For API-centric architectures, enforce authorization at the gateway:

```javascript
// Express.js middleware calling OPA
async function authorize(req, res, next) {
  const input = {
    subject: {
      user_id: req.user.sub,
      department: req.user.department,
      clearance_level: req.user.clearance_level,
      role: req.user.role,
    },
    action: mapHttpMethodToAction(req.method),
    resource: {
      type: req.params.resourceType,
      id: req.params.resourceId,
      // Resource attributes loaded from database or cache
      ...await getResourceAttributes(req.params.resourceType, req.params.resourceId),
    },
    environment: {
      ip_address: req.ip,
      timestamp: new Date().toISOString(),
    },
  };

  const response = await fetch("http://localhost:8181/v1/data/document/access/allow", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ input }),
  });

  const decision = await response.json();

  if (decision.result === true) {
    next();
  } else {
    res.status(403).json({ error: "Access denied by policy" });
  }
}
```

**Application-embedded PEP:**

For fine-grained decisions within application logic:

```python
# Python application calling OPA for row-level access control
import requests

def get_accessible_records(user, query):
    all_records = database.execute(query)
    accessible = []

    for record in all_records:
        decision = requests.post(
            "http://localhost:8181/v1/data/record/access/allow",
            json={
                "input": {
                    "subject": user.attributes,
                    "action": "read",
                    "resource": record.attributes,
                }
            }
        ).json()

        if decision.get("result"):
            accessible.append(record)

    return accessible
```

For performance, batch authorization decisions or use data filtering policies that generate query conditions rather than evaluating per-record.

### Step 5: Implement Policy Information Points (PIPs)

When the PEP cannot provide all necessary attributes in the request, the PDP queries PIPs:

```rego
# OPA policy with external data (loaded via bundle)
package document.access

import rego.v1

# User clearance loaded from external data bundle
user_clearance := data.users[input.subject.user_id].clearance_level

# Resource classification loaded from external data bundle
resource_classification := data.resources[input.resource.id].classification_level

allow if {
    input.action == "read"
    user_clearance >= resource_classification
}
```

OPA supports loading external data through:
- **Bundles**, Periodic bulk data loads (suitable for relatively static data like user attributes).
- **HTTP API**, Real-time queries to external services (suitable for dynamic data).
- **File system**, Local data files updated by external processes.

## Best Practices

### Start Hybrid: RBAC + ABAC

Do not rip out your RBAC system. Instead, use RBAC for coarse-grained access (which applications can the user access?) and ABAC for fine-grained decisions within those applications (which records can the user see? what actions can they perform?).

### Cache Attribute Data

ABAC performance depends on attribute retrieval speed. Cache frequently-used attributes (user department, resource classification) and define cache invalidation strategies. A stale cache can grant or deny access incorrectly.

### Version Your Policies

Treat policies as code. Store them in Git, require pull request reviews, run automated tests before deployment, and maintain rollback capability. A bad policy deployment can lock out users or grant unauthorized access.

### Test Policies Exhaustively

Write unit tests for every policy:

```rego
# OPA test
package document.access_test

import rego.v1

test_allow_read_matching_department if {
    allow with input as {
        "action": "read",
        "subject": {"clearance_level": 3, "department": "engineering"},
        "resource": {"classification_level": 2, "owning_department": "engineering"}
    }
}

test_deny_read_insufficient_clearance if {
    not allow with input as {
        "action": "read",
        "subject": {"clearance_level": 1, "department": "engineering"},
        "resource": {"classification_level": 3, "owning_department": "engineering"}
    }
}
```

## Testing

1. **Unit tests**, Test every policy rule with positive and negative cases. Aim for 100% policy coverage.
2. **Integration tests**, Test the full PEP-PDP-PIP chain with realistic scenarios.
3. **Performance tests**, Measure authorization latency under load. Target sub-10ms per decision for synchronous enforcement.
4. **Shadow mode**, Deploy new policies in log-only mode alongside existing authorization. Compare decisions to identify discrepancies before cutover.
5. **Chaos testing**, Simulate PDP unavailability and verify fallback behavior (fail-closed for security-critical resources, fail-open with logging for non-critical resources).

## Common Pitfalls

### Policy Explosion

ABAC can suffer from policy explosion just as RBAC suffers from role explosion. If you create a separate policy for every specific scenario instead of writing generalizable policies with attribute conditions, you will end up with an unmanageable policy set. Design policies that are attribute-driven and composable.

### Ignoring Performance

Every access decision in ABAC requires policy evaluation and attribute retrieval. If your policy engine adds 500ms to every API call, user experience suffers. Optimize with local caching, batch decisions, pre-computed data, and sidecar deployment patterns.

### Inconsistent Attribute Schemas

If different applications define "department" differently (one uses department names, another uses department codes), policies become fragile. Establish a canonical attribute schema and normalize all attribute sources to it.

### No Observability

Without logging which policies were evaluated, which attributes were used, and what decisions were made, you cannot debug access issues or audit authorization. Instrument your PEP and PDP with complete decision logging.

## Conclusion

ABAC provides the fine-grained, dynamic, and context-aware authorization that modern applications demand. It moves beyond the static role assignments of RBAC to evaluate access decisions against rich attribute combinations in real time. The implementation requires investment in policy design, engine deployment, attribute management, and testing, but for organizations with complex access requirements, ABAC is the only model that scales without role explosion.

Start with a hybrid RBAC+ABAC approach: keep RBAC for coarse-grained application access and introduce ABAC for the specific fine-grained decisions where it adds the most value. Grow your policy coverage iteratively, measure performance, and treat policies as first-class code artifacts.

## Implementing Passkeys in the Enterprise
Source: https://startwithidentity.com/guides/authentication/implementing-passkeys-enterprise/
Last updated: 2026-11-05

Passkeys represent the most significant shift in enterprise authentication since the introduction of SSO. Built on the [FIDO2/WebAuthn](https://startwithidentity.com/standards/webauthn-fido2/) standard, passkeys replace passwords with cryptographic credentials that are phishing-resistant, require no memorization, and deliver a faster login experience than traditional methods. Apple, Google, and Microsoft have all committed to passkey support across their platforms, making broad adoption inevitable. For the basics first, see [passkeys 101](https://startwithidentity.com/guides/authentication/passkeys-101/) and [what is passwordless](https://startwithidentity.com/guides/fundamentals/what-is-passwordless/).

Yet enterprise passkey deployment is different from consumer deployment. Enterprises must manage device policies, attestation requirements, account recovery at scale, and the coexistence of passkeys with existing authentication methods during transition. This guide addresses the enterprise-specific challenges of passkey implementation.

## What You Will Learn

- How passkeys differ from traditional FIDO2 security keys in an enterprise context
- Configuring WebAuthn for enterprise requirements (attestation, allowed authenticators)
- Designing account recovery workflows that do not undermine passkey security
- Managing passkeys on corporate-managed devices
- Planning a gradual rollout from pilot to full enforcement

## Prerequisites

1. **SSO infrastructure**, Passkeys should be deployed at the IdP level to cover all federated applications. Ensure SSO is in place.
2. **IdP passkey support**, Verify your IdP supports FIDO2/WebAuthn and passkeys. Most major IdPs ([Okta](https://startwithidentity.com/vendors/iam/okta/), [Microsoft Entra ID](https://startwithidentity.com/vendors/iam/microsoft-entra/), [Ping Identity](https://startwithidentity.com/vendors/iam/ping-identity/)) support it today.
3. **Device management**, An MDM solution (Intune, Jamf, Workspace ONE) for managing passkey-related policies on corporate devices.
4. **User communication plan**, Passkeys change the login experience fundamentally. Users need clear, advance communication.
5. **Help-desk procedures**, Updated account recovery and credential reset procedures for the passkey model.

## Choosing a passkey provider

Most enterprises deploy passkeys through the IdP they already run. [Okta](https://startwithidentity.com/vendors/iam/okta/) (FastPass), [Microsoft Entra ID](https://startwithidentity.com/vendors/iam/microsoft-entra/), and [Ping Identity](https://startwithidentity.com/vendors/iam/ping-identity/) all support FIDO2/WebAuthn passkeys natively, and for high-assurance roles you pair them with hardware security keys such as [YubiKey](https://startwithidentity.com/vendors/mfa/yubico/).

If passkeys are core to your customer or workforce experience rather than one factor among many, specialist passwordless providers can shorten the build:

- **[Transmit Security](https://startwithidentity.com/vendors/ciam/transmit-security/)** offers a passwordless-first platform with passkey issuance, device binding, and risk signals, aimed at organizations that want passkeys plus fraud and identity-verification capabilities in one stack.
- **[MojoAuth](https://startwithidentity.com/vendors/ciam/mojoauth/)** provides a developer-friendly passwordless and passkey API (passkeys, magic links, OTP) that lets teams add phishing-resistant login quickly without building the WebAuthn plumbing themselves.

Both target application and customer identity ([CIAM](https://startwithidentity.com/guides/fundamentals/what-is-ciam/)); for workforce SSO, deploy passkeys at your existing IdP. For a broader shortlist see [best passwordless CIAM providers](https://startwithidentity.com/rankings/best-passwordless-ciam-providers/) and the [MFA and passwordless vendor directory](https://startwithidentity.com/vendors/mfa/).

## Architecture Overview

Enterprise passkey architecture builds on the standard WebAuthn model with additional enterprise controls:

- **Identity Provider (IdP):** The WebAuthn Relying Party. Handles passkey registration, authentication, and lifecycle management.
- **Platform authenticator:** The user's device (MacBook with Touch ID, Windows PC with Windows Hello, iPhone/Android with biometrics) that creates and stores passkeys.
- **Passkey sync fabric:** Apple's iCloud Keychain, Google Password Manager, or a third-party credential manager that syncs passkeys across the user's devices.
- **MDM/UEM:** Manages device policies including which authenticators are allowed, whether passkey sync is permitted, and attestation requirements.
- **FIDO Metadata Service (MDS):** An optional service that provides metadata about authenticator models, enabling attestation-based policies.

**Enterprise-specific considerations:**

Synced passkeys introduce a dependency on the user's personal cloud account (Apple ID, Google Account). In a corporate context, this means:
- The security of passkeys is partly dependent on the user's personal account security.
- If the user leaves the organization, their passkeys travel with them (but become useless once the IdP account is disabled).
- IT cannot remotely wipe a synced passkey from the user's personal cloud.

For environments requiring the highest security assurance, device-bound passkeys (hardware security keys or non-synced platform credentials) remain the gold standard.

## Step-by-Step Implementation

### Step 1: Define Your Passkey Policy

Before any technical work, define clear policies:

```yaml
passkey_policy:
  general_workforce:
    allowed_credential_types:
      - synced_passkey        # iCloud Keychain, Google Password Manager
      - platform_authenticator # Device-bound
      - security_key          # YubiKey, etc.
    minimum_credentials: 2     # At least 2 passkeys per user
    attestation_required: false
    sync_allowed: true

  privileged_users:
    allowed_credential_types:
      - security_key           # Hardware-bound only
      - platform_authenticator # Device-bound, no sync
    minimum_credentials: 2
    attestation_required: true
    sync_allowed: false
    approved_authenticators:
      - "YubiKey 5 Series"
      - "YubiKey 5 FIPS Series"

  shared_workstation_users:
    allowed_credential_types:
      - security_key           # Must be portable
    minimum_credentials: 2
    attestation_required: true
    sync_allowed: false
```

### Step 2: Configure WebAuthn at the IdP

Configure your IdP's WebAuthn settings to enforce your policy:

**Registration options for general workforce:**

```javascript
const registrationOptions = {
  rp: {
    name: "Contoso Corp",
    id: "contoso.com"
  },
  authenticatorSelection: {
    residentKey: "required",      // Discoverable credential (passkey)
    userVerification: "required",  // Biometric or PIN
    // Do NOT set authenticatorAttachment to allow both platform and cross-platform
  },
  attestation: "none",  // No attestation for general users
  pubKeyCredParams: [
    { type: "public-key", alg: -7 },   // ES256
    { type: "public-key", alg: -257 }  // RS256
  ],
  excludeCredentials: existingCredentials,  // Prevent duplicates
  extensions: {
    credProps: true  // Request credential properties
  }
};
```

**Registration options for privileged users:**

```javascript
const privilegedRegistrationOptions = {
  rp: {
    name: "Contoso Corp",
    id: "contoso.com"
  },
  authenticatorSelection: {
    residentKey: "required",
    userVerification: "required",
    authenticatorAttachment: "cross-platform"  // Security keys only
  },
  attestation: "direct",  // Require attestation
  pubKeyCredParams: [
    { type: "public-key", alg: -7 }  // ES256 only (YubiKey native)
  ],
  excludeCredentials: existingCredentials
};
```

### Step 3: Implement Attestation Verification

For privileged users, verify that the authenticator is an approved model:

```javascript
async function verifyAttestation(registrationResponse) {
  const { fmt, attStmt, authData } = parseAttestationObject(
    registrationResponse.attestationObject
  );

  // Extract the AAGUID from authData
  const aaguid = extractAAGUID(authData);

  // Check against approved authenticator list. Populate it from the
  // vendor's published AAGUID list or the FIDO Metadata Service,
  // never from memory: AAGUIDs differ by model and firmware.
  const approvedAAGUIDs = await loadApprovedAAGUIDs();

  if (!approvedAAGUIDs.includes(aaguid)) {
    throw new Error('Authenticator not in approved list');
  }

  // Verify the attestation signature
  if (fmt === "packed") {
    await verifyPackedAttestation(attStmt, authData, registrationResponse.clientDataJSON);
  } else if (fmt === "tpm") {
    await verifyTPMAttestation(attStmt, authData, registrationResponse.clientDataJSON);
  }

  return { verified: true, aaguid };
}
```

Note: Attestation verification adds complexity and can break when a vendor ships a new model or firmware with a new AAGUID. Yubico, for example, [issues new AAGUIDs](https://docs.yubico.com/hardware/yubikey/yk-tech-manual/yk5-apps-fido.html) for new FIDO2 products and when FIDO2 features are added or removed, and points to its support article for the full list. Use attestation only where the security requirement justifies the operational overhead.

### Step 4: Build Account Recovery Workflows

Account recovery is the most critical enterprise passkey challenge. If a user loses all their passkeys, they need a secure way to regain access without undermining the phishing resistance that passkeys provide.

**Recovery approach 1: Multiple registered passkeys**
Require every user to register at least two passkeys on different devices or authenticators. If one is lost, the other provides access.

**Recovery approach 2: Temporary access pass**
The IT help-desk issues a time-limited, single-use access pass after verifying the user's identity through an out-of-band channel.

```javascript
// Admin API: Generate temporary access pass
async function generateTemporaryAccessPass(userId) {
  const tap = {
    userId: userId,
    code: generateSecureRandom(8).toString('hex'),  // 16-character hex code
    expiresAt: new Date(Date.now() + 30 * 60 * 1000),  // 30 minutes
    singleUse: true,
    purpose: "passkey_recovery"
  };

  await storeTAP(tap);
  return tap.code;

  // The help-desk reads this code to the user over the phone
  // or sends it via a verified communication channel
}

// Login handler: Accept TAP
app.post('/auth/tap-login', async (req, res) => {
  const { userId, tapCode } = req.body;
  const tap = await getTAP(userId, tapCode);

  if (!tap || tap.expiresAt < new Date() || tap.used) {
    return res.status(401).json({ error: 'Invalid or expired access pass' });
  }

  // Mark TAP as used
  await markTAPUsed(tap.id);

  // Create session with limited scope: user must register a new passkey
  const session = await createLimitedSession(userId, {
    allowedActions: ['register_passkey'],
    expiresIn: '15m'
  });

  res.json({ sessionToken: session.token, action: 'register_passkey' });
});
```

**Recovery approach 3: Manager approval**
The user requests access recovery through a self-service portal. Their manager receives an approval request via email or Slack. Upon manager approval, the user receives a temporary access pass.

**Critical rule: Recovery must lead to passkey re-enrollment.** Any recovery mechanism must force the user to register a new passkey before accessing applications. Never allow the recovery mechanism to become a permanent alternative to passkeys.

### Step 5: Configure MDM Policies

For corporate-managed devices, configure MDM policies to support passkey deployment:

**macOS (Jamf/Intune):**
- Enforce a minimum macOS version that your IdP and browsers support for passkeys, and require Touch ID enrollment during device onboarding.
- Decide per user tier whether iCloud Keychain sync is allowed on managed Macs, using the restriction payloads your MDM exposes. Check Apple's device management documentation for the exact keys rather than copying them from examples.

**Windows (Intune):**
- Enable Windows Hello for Business with a PIN policy and biometrics, and allow FIDO2 security keys for sign-in where shared or privileged workstations need them.
- Use the settings catalog in Intune rather than hand-built JSON, so the policy matches the current schema.

**Mobile (iOS/Android):**
- Ensure biometric enrollment is required as part of device onboarding.
- For BYOD, use app-level passkey management rather than device-level policies.

### Step 6: Plan the Gradual Rollout

**Month 1, Preparation:**
- Configure IdP passkey settings
- Update help-desk procedures
- Create user training materials
- Order hardware security keys for privileged users

**Month 2, Pilot (IT + Security teams, 50-100 users):**
- Enable passkey registration as optional
- Monitor registration rates and help-desk tickets
- Refine documentation based on feedback

**Month 3, Early Adopters (500-1000 users):**
- Promote passkey registration with in-app prompts
- Offer drop-in sessions for hands-on registration help
- Track metrics: registration rate, authentication success rate, help-desk volume

**Month 4-5, Broad Enrollment:**
- Enable passkey registration prompts for all users
- Set a grace period: "Register a passkey by [date]"
- Enforce minimum 2 passkeys per user

**Month 6, Enforcement:**
- Require passkey authentication for all users
- Disable password-only login
- Maintain break-glass procedures for emergencies

## Configuration Best Practices

- **Require discoverable credentials.** Set `residentKey: "required"` to enable the username-less passkey experience. Non-discoverable credentials cannot be found without the user providing an identifier first.
- **Allow both platform and cross-platform authenticators.** Unless policy restricts to security keys only, leave `authenticatorAttachment` unset to support the broadest range of devices.
- **Set credential display names.** When users register a passkey, prompt them to name it ("Work MacBook," "Personal iPhone") so they can identify credentials in their management UI.
- **Monitor credential counts.** Alert when a user has fewer than 2 active credentials. Prompt them to register a backup.
- **Automate credential cleanup.** When an employee offboards, disable their IdP account. The passkeys become inert since they are bound to the RP ID and cannot be used at another Relying Party.

## Testing and Validation

1. **Cross-platform registration:** Register passkeys on macOS (Touch ID), Windows (Windows Hello), iOS (Face ID), Android (fingerprint), and a hardware security key. Verify all work for login.
2. **Cross-device authentication:** Register a synced passkey on an iPhone and verify it is available for login on a Mac and iPad signed into the same iCloud account.
3. **QR-code cross-device flow:** On a desktop without a registered passkey, verify that the browser offers a QR code that the user can scan with their phone to authenticate.
4. **Account recovery:** Simulate user losing all passkeys. Walk through the full recovery flow: identity verification, temporary access pass, new passkey registration.
5. **Attestation enforcement:** For privileged user flow, attempt registration with an unapproved authenticator and verify it is rejected.
6. **Offboarding:** Disable a user's IdP account and verify that their passkeys can no longer authenticate.

## Common Pitfalls and Troubleshooting

| Problem | Cause | Solution |
|---------|-------|----------|
| Passkey not syncing to new device | User not signed into the same cloud account | Verify iCloud/Google account is signed in on both devices |
| "No passkeys available" on login | Credential was device-bound, not synced | Register a synced passkey or register separately on each device |
| Attestation fails after authenticator firmware update | AAGUID changed in new firmware | Update the approved AAGUID list; consider using FIDO MDS for dynamic lookups |
| User cannot register on corporate laptop | Browser or OS version too old | Enforce minimum OS/browser versions via MDM |
| Help-desk social engineering during recovery | Weak identity verification | Require video call + manager approval for passkey recovery |
| Passkey prompt does not appear | WebAuthn JavaScript not triggered by user gesture | Ensure the API call is in a click handler, not auto-triggered |

## Security Considerations

1. **Synced passkey trust model.** [Synced passkeys](https://startwithidentity.com/glossary/synced-passkey/) depend on the security of the user's cloud account (Apple ID, Google Account). If an attacker compromises the cloud account, they can access the synced passkeys. [NIST SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html), [final since July 2025](https://csrc.nist.gov/pubs/sp/800/63/b/4/final), allows syncable authenticators "for applications that seek to implement up to AAL2" and rules them out at [AAL3](https://startwithidentity.com/glossary/aal/), which requires a non-exportable private key. For high-security roles, mandate device-bound credentials (hardware security keys).
2. **Phishing resistance is the primary value.** The reason to deploy passkeys is that they are origin-bound and cannot be phished. Never undermine this by offering fallback authentication methods (like SMS OTP) that are phishable. During the transition, accept the fallback risk but set a firm deadline for deprecating weak methods.
3. **Lost credential recovery is the attack surface.** Attackers will target the recovery workflow. Make recovery deliberately difficult: require multi-channel identity verification, manager approval, and mandatory re-enrollment.
4. **Credential theft at the IdP.** The IdP stores public keys, not private keys, so a breach of the IdP database does not compromise passkeys. However, the IdP's authentication logic is still critical, a compromised IdP could be modified to accept any credential.
5. **Insider threat.** A user with legitimate passkeys has legitimate access. Passkeys do not protect against insider threats. Pair passkey authentication with authorization controls, monitoring, and DLP.

## Passkey platforms and vendors

Beyond the workforce IdPs covered in "Choosing a passkey provider" above (Okta FastPass, Microsoft Entra ID, Ping Identity, paired with YubiKey hardware keys), these platforms support passkeys and are worth evaluating depending on where identity sits in your stack.

**Customer identity (CIAM) with passkeys:**

- **[Auth0](https://startwithidentity.com/vendors/ciam/auth0/)** provides passkeys and WebAuthn with adaptive MFA and attack protection in a broad, extensible platform, with Organizations for B2B multi-tenancy.
- **MojoAuth** is a developer-first passwordless and passkeys platform that also acts as an OIDC and SAML identity provider, so one project can add passkey login and app SSO quickly with transparent pricing.
- **[Descope](https://startwithidentity.com/vendors/ciam/descope/)** offers a visual, no-code flow builder with passkeys first-class, useful for iterating on enrollment and step-up journeys without redeploying code.
- **[Stytch](https://startwithidentity.com/vendors/ciam/stytch/)** is an API-first platform with passkeys, strong session control, and device-fingerprinting fraud prevention.
- **[Microsoft Entra External ID](https://startwithidentity.com/vendors/ciam/microsoft-entra-external-id/)** is Microsoft's customer identity product (distinct from Active Directory) with passwordless and passkey support for external users.

**B2B SaaS enterprise SSO (add passkeys alongside enterprise SSO and SCIM):**

- **[WorkOS](https://startwithidentity.com/vendors/ciam/workos/)** pairs AuthKit passkeys and magic links with enterprise SSO, SCIM directory sync, and a customer admin portal.
- **[SSOJet](https://startwithidentity.com/vendors/ciam/ssojet/)** focuses on enterprise SSO and SCIM provisioning for B2B products, with a self-service onboarding flow for customer administrators.

**Phishing-resistant workforce and hardware:**

- **[HYPR](https://startwithidentity.com/vendors/mfa/hypr/)** and **[Beyond Identity](https://startwithidentity.com/vendors/mfa/beyond-identity/)** deliver device-bound, phishing-resistant passwordless for the workforce, with desktop login and device trust.

For a scored shortlist, see the [best passwordless CIAM providers](https://startwithidentity.com/rankings/best-passwordless-ciam-providers/) ranking, and for self-hostable options, the [top open-source MFA and passwordless tools](https://startwithidentity.com/articles/top-6-open-source-mfa-passwordless-tools/).

## Conclusion

Passkeys are the future of enterprise authentication. They eliminate the largest attack vector, phishable credentials, while delivering a faster, simpler user experience. The enterprise implementation challenges are real but manageable: define clear policies by user tier, build resilient account recovery workflows, use MDM for device management, and roll out gradually with strong communications.

Organizations that move early gain a security advantage and reduce their attack surface immediately. The technology is ready, the platform support is universal, and the user experience is superior. The only barrier is organizational will.

## Implementing Privileged Access Management: Architecture, Vaulting, and JIT Access
Source: https://startwithidentity.com/guides/architecture/implementing-privileged-access-management/
Last updated: 2026-11-05

Privileged accounts are the skeleton keys of every organization. A single compromised domain admin credential, database root password, or cloud infrastructure key can give an attacker unrestricted access to your most sensitive systems and data. Privileged identities are a small share of accounts but a large share of attacker objectives: once an intruder holds one, lateral movement and data access follow quickly.

Privileged Access Management (PAM) addresses this risk by placing strict controls around who can use privileged credentials, how they gain access, what they can do during a session, and how every action is recorded for audit. Yet PAM projects have a reputation for complexity: they touch infrastructure teams, security operations, application owners, and auditors, and they require changes to deeply ingrained operational workflows.

This guide provides a practical, step-by-step approach to implementing PAM that balances security rigor with operational reality. By the end, you will have a clear path from initial discovery through production deployment.

## What You Will Learn

- How to design a PAM architecture that fits your environment
- Discovering and onboarding privileged accounts at scale
- Configuring credential vaulting with automated rotation
- Setting up session recording and monitoring
- Implementing just-in-time (JIT) access for least-privilege enforcement
- Building break-glass procedures for emergency access
- Testing, validation, and common pitfalls to avoid

## Prerequisites

Before starting a PAM implementation, ensure the following foundations are in place:

1. **Privileged account inventory**, You need a baseline understanding of where privileged accounts exist. This includes domain admins, local administrator accounts, database DBAs, cloud IAM roles with elevated permissions, network device admin credentials, and service accounts with broad access. A spreadsheet is fine at this stage; the PAM tool will formalize the inventory later.
2. **Network segmentation awareness**, Document which networks host critical infrastructure (domain controllers, database servers, hypervisors, cloud management planes). PAM components need network access to these zones.
3. **Directory integration**, An authoritative user directory (Active Directory, Microsoft Entra ID, Okta) that PAM will use to authenticate administrators before granting privileged access.
4. **Change management process**, PAM changes how administrators work. You need a change advisory board or lightweight approval process to manage the transition.
5. **Executive sponsorship**, PAM restricts access that teams currently enjoy. Without executive backing, adoption stalls when the first team pushes back.

## Architecture Overview

A well-designed PAM architecture has five core components that work together to secure, manage, and audit privileged access.

### The Credential Vault

The vault is the heart of PAM. It is a hardened, encrypted store that holds privileged credentials, passwords, SSH keys, API tokens, certificates, and releases them only under controlled conditions. No human should know the actual password for a vaulted account. The vault generates complex credentials, stores them encrypted at rest, and rotates them on a schedule or after each use.

Leading PAM platforms ([Idira, formerly CyberArk](https://startwithidentity.com/vendors/pam/cyberark/); [Delinea](https://startwithidentity.com/vendors/pam/delinea/); [BeyondTrust](https://startwithidentity.com/vendors/pam/beyondtrust/)) implement the vault as a dedicated appliance or clustered service with its own encryption key hierarchy, tamper detection, and audit logging. [HashiCorp Vault](https://startwithidentity.com/vendors/machine-identity/hashicorp-vault/) is a secrets manager rather than a PAM platform: it is a strong fit for application and pipeline secrets, but it does not provide the session proxy, recording, and human access workflows described below on its own (HashiCorp pairs it with [Boundary](https://startwithidentity.com/vendors/pam/hashicorp-boundary/) for brokered sessions).

### The Session Proxy

Rather than handing credentials to administrators and trusting them to connect, the session proxy brokers the connection. The administrator authenticates to the PAM portal, requests access to a target system, and the proxy establishes the session (RDP, SSH, database client, web console) using the vaulted credential. The administrator never sees or handles the actual password.

This proxy layer enables session recording (every keystroke, screen action, or command is captured), real-time monitoring (security teams can watch active sessions), and session termination (suspicious activity triggers automatic disconnection).

### The Access Request Workflow

PAM introduces a request-and-approval workflow for privileged access. Instead of having standing access to critical systems, administrators submit a request specifying the target system, the reason, and the desired duration. Approvers (team leads, security staff, or automated policies) evaluate and approve or deny the request. Approved sessions are time-bounded.

### The Discovery Engine

You cannot protect what you do not know exists. The discovery engine continuously scans your environment, Active Directory, cloud accounts, network devices, databases, to find privileged accounts, including ones created outside the PAM process. Newly discovered accounts are flagged for onboarding.

### The Analytics and Audit Layer

Every vault access, session initiation, command executed, and approval decision is logged to a tamper-evident audit trail. Analytics detect anomalies: an administrator accessing a system they have never touched before, sessions at unusual hours, or commands that match known attack patterns.

## Step-by-Step Implementation

### Step 1: Discover and Classify Privileged Accounts

Start with a complete discovery phase. Use your PAM tool's built-in scanners alongside manual enumeration to find every privileged account.

**Active Directory:** Enumerate members of Domain Admins, Enterprise Admins, Schema Admins, and any custom groups with elevated permissions. Do not forget nested group memberships. Scan for local administrator accounts on every domain-joined machine using LAPS (Local Administrator Password Solution) data or agent-based discovery.

**Cloud platforms:** In AWS, identify IAM users and roles with Administrator Access, PowerUser, or custom policies granting broad permissions. In Azure, enumerate Global Admins, Privileged Role Admins, and subscription-level Owner roles. In GCP, identify accounts with Owner or Editor roles at the organization or project level.

**Databases:** Find accounts with DBA, sysadmin, or superuser privileges across Oracle, SQL Server, PostgreSQL, MySQL, and any other database platforms in use.

**Network infrastructure:** Catalog admin credentials for firewalls, routers, switches, load balancers, and wireless controllers.

**Applications:** Identify built-in admin accounts for business applications (SAP BASIS, ServiceNow admin, Salesforce system admin).

Classify each account by criticality tier:

- **Tier 0:** Domain controllers, PKI infrastructure, PAM infrastructure itself, hypervisor management, cloud root/organization accounts
- **Tier 1:** Member servers, databases, application infrastructure, cloud workload accounts
- **Tier 2:** Workstations, developer tools, non-critical applications

### Step 2: Deploy the PAM Infrastructure

Deploy PAM components in a hardened configuration:

1. **Vault servers.** Deploy in a high-availability pair across separate availability zones or data centers. Harden the operating system, disable unnecessary services, and restrict network access to only required ports. Encrypt the vault with a master key protected by an HSM (Hardware Security Module) where budget permits.

2. **Session proxy servers.** Deploy proxies close to the target systems they serve. For multi-region environments, deploy regional proxies to minimize latency. Size the proxies based on expected concurrent session counts; plan for at least 2x your current peak.

3. **Web portal.** Deploy the administrator-facing web portal behind your existing load balancer and WAF. Integrate with your IdP for SSO and enforce MFA on every login.

4. **Discovery agents.** Deploy lightweight agents or configure agentless scanning (WinRM, SSH) to reach target systems for credential rotation and session brokering.

5. **Disaster recovery.** Replicate the vault to a DR site. Test failover quarterly. Document the recovery procedure and ensure it does not depend on access to the PAM system itself (this is where break-glass comes in).

### Step 3: Configure Credential Vaulting and Rotation

Onboard discovered accounts into the vault in priority order, starting with Tier 0.

**For each account:**

1. Create a vault entry with metadata: target system, account name, current credential, owner, criticality tier, and rotation policy.
2. Verify the vault can connect to the target system and validate the credential.
3. Perform an initial rotation to replace the known password with a vault-generated credential. This is the point of no return, after rotation, only the vault knows the password.
4. Assign an access policy defining who can check out the credential, under what conditions, and for how long.

**Rotation policies** (practitioner estimates, not a standard; adjust to your risk and audit requirements):

- **Tier 0 accounts:** Rotate after every use (one-time passwords). Maximum credential age of 24 hours even if unused.
- **Tier 1 accounts:** Rotate daily or after each use, whichever comes first.
- **Tier 2 accounts:** Rotate weekly. For accounts used by automated processes, rotate monthly with coordinated updates to dependent systems.

**Service account considerations:** Service accounts are the hardest to vault because rotating their credentials requires updating every system that uses them. Map dependencies before onboarding. Use the PAM tool's dual-account or zero-downtime rotation features where available: the vault creates a new credential, updates all dependent systems, verifies connectivity, and then retires the old credential.

### Step 4: Implement Session Recording

Configure the session proxy to record all privileged sessions:

1. **RDP sessions:** Record as video with keystroke logging. Store recordings compressed; as a rough planning estimate, a 1-hour RDP session generates 50-200 MB of recording data.
2. **SSH sessions:** Record as text-based session logs (terminal replay). Far more storage-efficient than video. Include command input and output.
3. **Database sessions:** Log all SQL commands executed through the proxy. Flag commands that modify schema, drop tables, or access sensitive data.
4. **Web console sessions:** Record browser-based admin sessions (cloud consoles, application admin portals) as video.

**Storage planning:** As a rough planning estimate, a mid-size enterprise with 500 daily privileged sessions generates approximately 2-5 TB of recording data per month. Plan retention based on your compliance requirements; 1-3 years is a common practitioner estimate, but check the retention period each framework you are audited against actually sets. Use tiered storage: hot storage for the last 90 days, cold storage for the remainder.

**Monitoring configuration:** Set up real-time alerts for high-risk commands: `rm -rf`, `DROP DATABASE`, `net user /add`, `chmod 777`, PowerShell execution policy changes, and any command matching known attack tool signatures. Route alerts to your SOC or SIEM.

### Step 5: Implement Just-in-Time Access

JIT access eliminates standing privileges. Instead of administrators having permanent membership in privileged groups, they receive temporary, scoped access only when approved.

**Configuration steps:**

1. Remove standing privileged group memberships. For example, remove IT staff from the Domain Admins group. This is the step that generates the most resistance, communicate the change well in advance.
2. Create JIT policies in the PAM tool specifying: who can request access, what they can request (target systems, roles), maximum session duration (typically 1-4 hours), required approvals, and required justification.
3. Configure auto-approval for low-risk, high-frequency tasks (e.g., a DBA requesting 1-hour access to a development database). Require manual approval for high-risk requests (e.g., domain controller access, production database admin).
4. Set up automatic deprovisioning: when the approved time window expires, the PAM tool automatically removes the temporary group membership, terminates the session, and rotates the credential.

**Microsoft Entra Privileged Identity Management (PIM)** provides native JIT for Entra ID roles. Idira, Delinea, and BeyondTrust offer JIT workflows for on-premises and multi-cloud environments.

### Step 6: Build Break-Glass Procedures

Break-glass (also called emergency access) procedures provide a way to access critical systems when the PAM infrastructure itself is unavailable, during a PAM outage, a disaster recovery scenario, or a security incident affecting the PAM platform.

**Design principles:**

1. **Offline credentials.** Generate a set of emergency credentials for Tier 0 systems. Print them, seal them in tamper-evident envelopes, and store them in a physical safe. Maintain two copies at geographically separated locations.
2. **Dual-control access.** Require two authorized individuals (e.g., CISO plus Infrastructure Director) to open the safe and retrieve credentials. Log the event physically (sign-out sheet with date, time, and reason).
3. **Time-limited validity.** Break-glass credentials should be rotated immediately after use. The PAM tool should be configured to detect break-glass account usage and trigger alerts.
4. **Periodic testing.** Quarterly, perform a break-glass drill: verify the envelopes are intact, the credentials still work, and the team knows the procedure. Document the drill results.
5. **Cloud break-glass.** For cloud environments, maintain a dedicated break-glass account (e.g., an AWS root account with a hardware MFA token stored in the safe) separate from the PAM-managed accounts.

```yaml
# Example break-glass account inventory
break_glass_accounts:
  - system: "Active Directory"
    account: "bg-admin-01"
    storage: "HQ Safe, Envelope #1"
    backup: "DR Site Safe, Envelope #1"
    last_tested: "2026-03-15"
    next_test: "2026-06-15"
  - system: "AWS Root Account"
    account: "root@company-breakglass.com"
    mfa: "YubiKey serial #8847231 (HQ Safe)"
    storage: "HQ Safe, Envelope #2"
    last_tested: "2026-03-15"
    next_test: "2026-06-15"
```

### Step 7: Integrate with SIEM and Incident Response

Connect PAM audit logs to your SIEM platform for correlation with other security data:

1. Forward all PAM events (authentication, session start/stop, credential checkout, rotation success/failure, policy violations) to your SIEM via syslog or API integration.
2. Create correlation rules: if a PAM session coincides with a malware detection or data exfiltration alert on the same target system, escalate immediately.
3. Include PAM session recordings in your incident response playbook. When investigating a compromise, the first question should be: "Was a PAM session active on the affected system during the incident timeframe?"

## Configuration Best Practices

**Password complexity:** Configure the vault to generate credentials with at least 30 characters, mixing uppercase, lowercase, digits, and special characters. For systems that support it, use 60+ character passwords, since no human types them, length costs nothing.

**Session timeouts:** Set maximum session durations based on task requirements. Four hours is a reasonable default for interactive sessions. Automated processes may need longer windows but should be monitored differently.

**Approval escalation:** If an approval request is not acted upon within 30 minutes, auto-escalate to a backup approver. Do not let legitimate urgent requests languish because an approver is in a meeting.

**Network isolation:** Place PAM vault servers in a dedicated management VLAN with strict firewall rules. Only the session proxy and web portal should communicate with the vault. Block all direct internet access from vault servers.

**Backup encryption:** Encrypt PAM backups with a key stored separately from the backup itself. A stolen backup containing all your privileged credentials would be catastrophic.

## Testing and Validation

### Pre-Production Testing

1. **Credential rotation testing:** For each account type (AD, Linux root, database, cloud IAM), verify that rotation succeeds and the new credential works. Test rotation failure handling, does the vault roll back gracefully?
2. **Session proxy testing:** Verify RDP, SSH, and database sessions work through the proxy with acceptable latency. Test with your team's actual workflows, not just simple logins.
3. **JIT workflow testing:** Walk through the full request-approve-connect-expire cycle. Verify that access is actually removed when the window closes.
4. **Break-glass testing:** Simulate a PAM outage and execute the full break-glass procedure. Measure how long it takes.
5. **Failover testing:** Shut down the primary vault and verify that the secondary takes over without session interruption.

### User Acceptance Testing

Invite representatives from each operations team to use the PAM system for their daily tasks during a two-week pilot. Collect feedback on workflow friction, latency, and missing features. Adjust policies based on legitimate operational needs before forcing adoption.

## Common Pitfalls

**Boiling the ocean.** Trying to onboard every privileged account simultaneously guarantees failure. Start with Tier 0, prove the model, then expand. As a typical practitioner estimate, a phased rollout over 3-6 months is realistic for most enterprises.

**Ignoring service accounts.** Interactive accounts get attention because humans complain. Service accounts are silent but far more numerous and dangerous. Budget significant time for service account dependency mapping.

**Overly restrictive policies at launch.** If you make PAM so painful that administrators find workarounds (shared credentials outside the vault, SSH keys on USB drives), you have achieved negative security value. Start with monitoring mode, then tighten controls incrementally.

**Neglecting the user experience.** A PAM portal that takes 15 clicks to start a session will not be adopted voluntarily. Invest in browser plugins, CLI integrations, and native RDP/SSH client support that minimize friction.

**Single point of failure.** If your PAM platform goes down and you have no break-glass procedure, you have locked yourself out of your entire infrastructure. Design for failure from day one.

**Forgetting PAM system hardening.** The PAM platform itself is the highest-value target in your environment. If an attacker compromises the vault, they own every credential. Apply the same rigor to securing PAM that you apply to domain controllers.

## Security Considerations

**Protect the vault encryption keys.** Use an HSM for master key storage where possible. At minimum, use split-knowledge key management so no single administrator can extract the master key.

**Monitor for PAM bypass.** Attackers who know PAM exists will try to bypass it, creating new privileged accounts outside PAM, using cached credentials, or attacking target systems directly without going through the proxy. Your detection rules should cover all these scenarios.

**Secure the PAM supply chain.** Keep the PAM platform patched. Subscribe to your vendor's security advisories. PAM platform vulnerabilities are among the most critical patches you will ever apply.

**Implement mutual TLS.** All communication between PAM components (vault, proxy, portal, agents) should use mutual TLS with certificates managed by the PAM platform's internal CA.

**Audit PAM administrator access.** Who admins the PAM admins? The PAM platform's own administrative accounts need the same controls: MFA, session recording, JIT access, and dual-control for sensitive operations like vault key export.

## Conclusion

Implementing PAM is one of the highest-impact security investments an organization can make. By centralizing privileged credential storage, eliminating standing access, recording every privileged session, and building strong break-glass procedures, you dramatically reduce the risk of privilege-based attacks.

The key to success is treating PAM as an ongoing program rather than a one-time project. Start with your highest-risk accounts, prove the model with a willing pilot group, and expand methodically. Continuously refine policies based on operational feedback and evolving threats.

The organizations that get PAM right do not just check a compliance box, they fundamentally change how privileged access works, making it controlled, auditable, and resilient.

## Implementing RBAC in the Enterprise
Source: https://startwithidentity.com/guides/authorization/implementing-rbac-enterprise/
Last updated: 2026-11-05

Role-Based Access Control (RBAC) is the most widely adopted access control model in enterprise environments. Instead of assigning permissions directly to individual users, which becomes unmanageable at scale, RBAC groups permissions into roles, and users are assigned to roles. When an employee joins the Sales department, they receive the "Sales Representative" role, which automatically grants them access to the CRM, sales pipeline, quoting tool, and customer database. When they move to Marketing, the Sales role is removed and the Marketing role is assigned.

In theory, RBAC is elegant and simple. In practice, most RBAC implementations devolve into chaos: hundreds of overlapping roles, roles that grant far more access than needed, and a role assignment process that only adds roles (never removes them). This guide shows you how to implement RBAC correctly and keep it healthy over time.

## What You Will Learn

- How to design a role model that scales
- Role mining: deriving roles from existing access patterns
- Building role hierarchies and composite roles
- When to choose RBAC, ABAC, or a hybrid model
- Governance processes that prevent role sprawl

## Prerequisites

1. **Centralized identity and access management**, An IdP or IAM platform ([Okta](https://startwithidentity.com/vendors/iam/okta/), [Microsoft Entra ID](https://startwithidentity.com/vendors/iam/microsoft-entra/), [SailPoint](https://startwithidentity.com/vendors/iga/sailpoint/), [Saviynt](https://startwithidentity.com/vendors/iga/saviynt/)) that supports role assignment and policy enforcement.
2. **Application inventory**, A list of applications, their permission models, and integration capabilities (SCIM, SAML group assertions, API-based provisioning).
3. **Organizational data**, HR data including job titles, departments, locations, and reporting hierarchy. This feeds role assignment rules.
4. **Stakeholder alignment**, Application owners, HR, compliance, and IT security must be involved. RBAC crosses organizational boundaries.
5. **Current access data**, Export of current user-to-permission assignments from key applications. This is the raw material for role mining.

## Architecture Overview

An enterprise RBAC system consists of:

- **Role Repository:** The central definition of all roles, their permissions, and their relationships. Stored in the IAM platform or a dedicated IGA (Identity Governance and Administration) tool.
- **Role Assignment Engine:** Automatically assigns roles based on user attributes (department, job title, location) and manual requests. This can be rule-based (automated) or request-based (with approval workflow).
- **Provisioning Engine:** Translates role assignments into application-level permissions. When a user is assigned the "Finance Analyst" role, the provisioning engine grants the specific entitlements in each connected application (SAP access group, SharePoint permissions, database read rights).
- **Certification/Review System:** Periodically asks managers and application owners to review and certify that role assignments are still appropriate.
- **Analytics and Reporting:** Provides visibility into role usage, role overlap, orphan permissions, and role explosion metrics.

**Role types in a well-designed model:**

- **Business roles:** Aligned to job functions (e.g., "Sales Representative," "Financial Analyst," "Software Engineer"). These are what managers understand and request.
- **Technical roles:** Mapped to specific application entitlements (e.g., "Salesforce-ReadWrite," "Jira-Admin," "AWS-S3-ReadOnly"). These are what IT manages.
- **Composite roles:** Business roles that are composed of multiple technical roles. The business role "Financial Analyst" might include technical roles "SAP-FI-Viewer," "Excel-Online-User," and "SharePoint-Finance-Member."

## Step-by-Step Implementation

### Step 1: Conduct a Role Mining Exercise

Role mining derives roles from actual access patterns. Start with data, not assumptions.

**Extract current access data:**

```sql
-- Extract user-to-permission mappings from each application
-- Example: combine data from multiple sources into a normalized format

SELECT
  u.employee_id,
  u.department,
  u.job_title,
  u.location,
  a.application_name,
  p.permission_name,
  p.permission_level
FROM users u
JOIN user_permissions up ON u.employee_id = up.employee_id
JOIN permissions p ON up.permission_id = p.permission_id
JOIN applications a ON p.application_id = a.application_id
WHERE u.status = 'active'
ORDER BY u.department, u.job_title, a.application_name;
```

**Analyze access clusters:**

```python
import pandas as pd
from sklearn.cluster import KMeans

# Load normalized access data
access_data = pd.read_csv("user_permissions.csv")

# Create a user-permission matrix
user_perm_matrix = access_data.pivot_table(
    index='employee_id',
    columns='permission_name',
    values='has_access',
    fill_value=0
)

# Cluster users with similar access patterns
kmeans = KMeans(n_clusters=20, random_state=42)  # Start with 20 candidate roles
user_perm_matrix['cluster'] = kmeans.fit_predict(user_perm_matrix)

# Analyze each cluster to understand the common permissions
for cluster_id in range(20):
    cluster_users = user_perm_matrix[user_perm_matrix['cluster'] == cluster_id]
    # Permissions held by >80% of cluster members are "core" to this role
    core_permissions = cluster_users.drop('cluster', axis=1).mean()
    core_permissions = core_permissions[core_permissions > 0.8]
    print(f"\nCluster {cluster_id} ({len(cluster_users)} users):")
    print(f"  Core permissions: {list(core_permissions.index)}")
    print(f"  Common departments: {access_data[access_data['employee_id'].isin(cluster_users.index)]['department'].value_counts().head(3).to_dict()}")
```

This analysis reveals natural groupings. A cluster of 150 users from the Sales department who all have Salesforce-ReadWrite, HubSpot-User, and Slack-Standard access is a strong candidate for a "Sales Team Member" role.

### Step 2: Design the Role Model

Based on mining results and business input, define your role structure:

```yaml
role_model:
  business_roles:
    - name: "Sales Representative"
      description: "Standard access for quota-carrying sales team members"
      assignment_rule:
        department: "Sales"
        job_title_contains: ["Representative", "Account Executive", "SDR"]
      technical_roles:
        - "Salesforce-Standard-User"
        - "HubSpot-Sales-User"
        - "Slack-Standard"
        - "Google-Workspace-Standard"
        - "Zoom-Licensed"
      owner: "VP of Sales"
      review_frequency: "quarterly"

    - name: "Sales Manager"
      description: "Sales representative access plus management tools"
      inherits: "Sales Representative"  # Role hierarchy
      assignment_rule:
        department: "Sales"
        job_title_contains: ["Manager", "Director"]
      additional_technical_roles:
        - "Salesforce-Reports-Admin"
        - "HubSpot-Analytics"
        - "Clari-Forecasting"
      owner: "VP of Sales"
      review_frequency: "quarterly"

    - name: "Software Engineer"
      description: "Standard access for engineering team members"
      assignment_rule:
        department: "Engineering"
        job_title_contains: ["Engineer", "Developer"]
      technical_roles:
        - "GitHub-Developer"
        - "Jira-User"
        - "Slack-Standard"
        - "Google-Workspace-Standard"
        - "AWS-Dev-ReadOnly"
      owner: "VP of Engineering"
      review_frequency: "quarterly"

  technical_roles:
    - name: "Salesforce-Standard-User"
      application: "Salesforce"
      entitlements:
        - profile: "Standard User"
        - permission_set: "Sales Cloud User"
      provisioning: "SCIM"

    - name: "GitHub-Developer"
      application: "GitHub Enterprise"
      entitlements:
        - org_role: "member"
        - team: "auto-assign based on sub-department"
      provisioning: "SCIM"
```

### Step 3: Build the Role Hierarchy

Role hierarchies reduce redundancy. A "Sales Manager" role inherits all permissions from "Sales Representative" and adds management-specific permissions.

```
Organization Baseline Role
├── Sales Representative
│   └── Sales Manager
│       └── Sales Director
├── Software Engineer
│   ├── Senior Software Engineer
│   │   └── Staff Engineer
│   └── Engineering Manager
├── Financial Analyst
│   └── Senior Financial Analyst
│       └── Finance Manager
└── Customer Support Agent
    └── Support Team Lead
        └── Support Manager
```

**Rules for hierarchy design:**

- Maximum depth of 3-4 levels. Deeper hierarchies become confusing.
- A child role should include everything the parent has, plus additional permissions.
- Avoid multiple inheritance (a role inheriting from two unrelated parents), it creates complexity.
- Use composition (combining multiple technical roles) rather than deep hierarchy for cross-functional access.

### Step 4: Implement Role Assignment Automation

Automate role assignment based on HR attributes:

```javascript
// Role assignment rules engine
const roleAssignmentRules = [
  {
    role: "Sales Representative",
    conditions: {
      department: "Sales",
      job_title: { matches: /representative|account executive|sdr|bdr/i },
      employment_type: "full-time"
    },
    priority: 100  // Higher priority wins in conflicts
  },
  {
    role: "Sales Manager",
    conditions: {
      department: "Sales",
      job_title: { matches: /manager|director/i },
      employment_type: "full-time"
    },
    priority: 200
  },
  {
    role: "Contractor - Limited Access",
    conditions: {
      employment_type: "contractor"
    },
    priority: 50
  }
];

function evaluateRoles(user) {
  const assignedRoles = [];

  for (const rule of roleAssignmentRules) {
    if (matchesConditions(user, rule.conditions)) {
      assignedRoles.push({
        role: rule.role,
        source: "automatic",
        reason: `Matched rule: department=${user.department}, title=${user.job_title}`
      });
    }
  }

  return assignedRoles;
}

// Triggered by HR system events (new hire, transfer, termination)
async function onUserChanged(event) {
  const user = event.user;
  const desiredRoles = evaluateRoles(user);
  const currentRoles = await getCurrentRoles(user.id);

  // Add new roles
  for (const role of desiredRoles) {
    if (!currentRoles.includes(role.role)) {
      await assignRole(user.id, role.role, role.reason);
    }
  }

  // Remove roles no longer matched (mover/leaver scenario)
  for (const role of currentRoles) {
    if (!desiredRoles.find(r => r.role === role) && isAutoAssigned(user.id, role)) {
      await removeRole(user.id, role, "No longer matches assignment rule");
    }
  }
}
```

### Step 5: Implement Request-Based Role Assignment

Not all roles can be automatically assigned. Some require explicit requests with approval:

```yaml
# Request workflow for sensitive roles
request_workflows:
  - role: "Production Database Admin"
    approval_chain:
      - approver: "direct_manager"
        sla: "24h"
      - approver: "data_security_team"
        sla: "48h"
    time_limit: "90d"  # Auto-revoke after 90 days
    justification_required: true
    certification_frequency: "monthly"

  - role: "AWS Production Admin"
    approval_chain:
      - approver: "direct_manager"
        sla: "24h"
      - approver: "cloud_security_team"
        sla: "24h"
      - approver: "ciso"
        sla: "48h"
    time_limit: "30d"
    justification_required: true
    certification_frequency: "weekly"
```

### Step 6: Establish Governance Processes

RBAC without governance decays rapidly. Implement these processes from day one:

**Quarterly access certification:**
Managers review their direct reports' role assignments and certify or revoke. Application owners review who has access to their application and certify or revoke.

**Role lifecycle management:**
Every role has an owner. The owner is responsible for keeping the role's permissions current. New permission requests go through the role owner. Unused permissions are identified and removed.

**Role explosion prevention:**
Track the ratio of roles to users over time. There is no standard target ratio, so watch the trend: a ratio that keeps rising means roles are being created for individuals. If it approaches 1:1, you have role explosion, each user has a unique role, which defeats the purpose of RBAC.

```python
# Role health metrics
def calculate_role_health():
    total_users = count_active_users()
    total_roles = count_active_roles()
    role_ratio = total_roles / total_users

    # Role explosion check
    if role_ratio > 0.3:  # Example threshold (1 role per 3 users); tune to your organization
        alert("Role explosion detected", severity="warning")

    # Orphan role check (roles with no members)
    orphan_roles = get_roles_with_no_members()
    if orphan_roles:
        alert(f"{len(orphan_roles)} orphan roles detected", severity="info")

    # Over-permissioned role check
    for role in get_all_roles():
        unused_perms = get_unused_permissions(role, lookback_days=90)
        if len(unused_perms) > 0:
            alert(f"Role {role.name} has {len(unused_perms)} unused permissions", severity="info")
```

## Configuration Best Practices

- **Start with fewer roles.** It is easier to split a broad role into two specific roles than to merge two overlapping roles. Begin with a small set of broad business roles that cover the most common job functions, and add more only when a validated access pattern justifies it.
- **Avoid one-off roles.** If a role would have only 1-2 members, use a direct permission assignment instead of creating a role. Roles should represent patterns, not individuals.
- **Separate duty roles.** For Separation of Duties (SoD) compliance, define conflicting role pairs (e.g., "Payment Approver" and "Payment Creator" cannot be held by the same person) and enforce them in the IAM platform.
- **Use time-limited privileged roles.** Roles that grant administrative or production access should be time-limited and require re-approval.
- **Document every role.** Each role should have a name, description, owner, assignment criteria, and the list of permissions it grants. This documentation is essential for auditing and certification.
- **Integrate with HR.** Role assignment should be triggered by HR events (hire, transfer, termination) automatically. Manual role assignment should be the exception, not the rule.

## Testing and Validation

1. **Joiner testing:** Create a test user with specific HR attributes (department, title, location). Verify that the correct roles are automatically assigned and the correct application access is provisioned.
2. **Mover testing:** Change the test user's department and title. Verify that old roles are removed and new roles are assigned. Confirm that access to the old department's applications is revoked.
3. **Leaver testing:** Terminate the test user. Verify that all roles are removed, all application access is revoked, and the user account is disabled.
4. **SoD testing:** Attempt to assign conflicting roles to the same user. Verify the system blocks the assignment or flags it for review.
5. **Certification testing:** Trigger a certification campaign. Verify that managers receive review requests and can certify or revoke access.
6. **Permission drift testing:** After 90 days, compare actual application permissions against expected permissions from role assignments. Identify and remediate drift.

## Common Pitfalls and Troubleshooting

| Pitfall | Impact | Mitigation |
|---------|--------|------------|
| Role explosion | Hundreds of roles, each slightly different | Merge similar roles; use ABAC for fine-grained differences |
| Roles only added, never removed | Users accumulate permissions over time ("creep") | Automated role removal on HR events; quarterly certification |
| Roles designed by IT alone | Roles do not match business needs | Involve business stakeholders in role design workshops |
| No role owner | Nobody maintains the role; permissions become stale | Assign an owner to every role; alert when a role owner leaves the org |
| Over-reliance on exceptions | Most access is granted outside of roles | Track exception-to-role ratio; convert frequent exceptions into roles |
| Ignoring service accounts | Service accounts are not part of RBAC | Create dedicated service account roles with tight permissions |

## Security Considerations

1. **Least privilege is the goal.** RBAC should enforce least privilege. If a role grants access to 10 applications but the average member only uses 5, the role is over-permissioned. Use access analytics to right-size roles.
2. **SoD enforcement.** Define and enforce Separation of Duties constraints. The person who creates a purchase order must not be the person who approves it. Implement SoD checks at role assignment time and during certification.
3. **Privileged role governance.** Roles that grant administrative access to production systems, financial data, or PII must have tighter governance: time limits, additional approvals, more frequent certification, and mandatory logging.
4. **Role assignment as an attack target.** If an attacker can modify role assignments (by compromising the IAM platform or HR system), they can grant themselves any access. Protect role assignment with strong authentication, approval workflows, and audit logging.
5. **RBAC does not cover all scenarios.** Some access decisions depend on context (time of day, device, location, data sensitivity) that RBAC cannot express. Use ABAC (Attribute-Based Access Control) for context-aware decisions and RBAC for base-level access.

## Conclusion

RBAC is the foundation of enterprise access management. Done well, it simplifies administration, accelerates onboarding, supports compliance, and enforces least privilege. Done poorly, it creates a false sense of control while permissions sprawl unchecked.

The keys to successful RBAC are: start with data (role mining), design roles around business functions (not technical systems), automate assignment based on HR attributes, and govern relentlessly (certification, role lifecycle, health metrics). RBAC is not a project with a finish date, it is an ongoing program that requires continuous investment and attention.

## Kubernetes Identity and Security Guide: RBAC, Service Accounts, and Pod Identity
Source: https://startwithidentity.com/guides/machine-identity/kubernetes-identity-security-guide/
Last updated: 2026-11-05

Kubernetes has become the de facto container orchestration platform, but its identity model is one of the most misunderstood aspects of cloud-native security. Out of the box, Kubernetes provides a powerful but complex identity framework, Role-Based Access Control for API authorization, service accounts for workload identity, and multiple extension points for integrating with external identity providers.

The problem is that most Kubernetes deployments use the defaults, and the defaults are not secure. Default service accounts have tokens auto-mounted into every pod. RBAC roles are often overly permissive. Secrets are stored as base64-encoded (not encrypted) values. This guide walks you through securing identity in Kubernetes from the ground up.

## Prerequisites

- **A running Kubernetes cluster on a supported release.** Upstream Kubernetes maintains the three most recent minor releases, 1.35, 1.36, and 1.37 as of November 2026 (see [kubernetes.io/releases](https://kubernetes.io/releases/)). Managed services (EKS, AKS, GKE) publish their own support windows. The examples assume bound service account tokens, which every supported release uses.
- **kubectl** configured with cluster-admin access for initial setup.
- **Familiarity with Kubernetes concepts**, Pods, Deployments, Namespaces, ConfigMaps, Secrets.
- **An external identity provider** if integrating OIDC (Entra ID, Okta, Dex, Keycloak).
- **A secrets management solution** ([HashiCorp Vault](https://startwithidentity.com/vendors/machine-identity/hashicorp-vault/), [AWS Secrets Manager](https://startwithidentity.com/vendors/secrets/aws-secrets-manager/), [Azure Key Vault](https://startwithidentity.com/vendors/secrets/azure-key-vault/)) for production workloads.

## Architecture: Kubernetes Identity Model

### Human Identity vs. Workload Identity

Kubernetes distinguishes between two identity types:

**Human users**, Developers, operators, and administrators who interact with the Kubernetes API via kubectl or dashboards. Kubernetes does not manage human user accounts internally. Instead, it relies on external identity providers through authentication plugins (OIDC, webhook token authentication, client certificates).

**Service accounts**, Identities assigned to workloads (pods) running inside the cluster. These are Kubernetes-native objects managed by the API server. Service accounts are used for pod-to-API-server communication and, with workload identity federation, for pod-to-external-service communication.

### The Authentication and Authorization Flow

```
Request → Authentication → Authorization → Admission → API Server

Authentication: Who are you?
  - OIDC tokens (recommended for humans)
  - Service account tokens (for workloads)
  - Client certificates
  - Webhook token review

Authorization: What can you do?
  - RBAC (primary, recommended)
  - ABAC (legacy, not recommended)
  - Webhook authorization
  - Node authorization

Admission: Should this action be allowed?
  - Validating webhooks
  - Mutating webhooks
  - Pod Security Admission
```

## Step-by-Step Implementation

### Step 1: Configure OIDC Authentication for Human Users

Stop using client certificates or static token files for human authentication. OIDC provides proper identity, supports MFA through the IdP, and integrates with your existing identity infrastructure.

**Configure the API server for OIDC:**

For managed clusters, this is configured through the cloud provider's Kubernetes service. For self-managed clusters, add these flags to the API server:

```yaml
# API server configuration
--oidc-issuer-url=https://login.microsoftonline.com/{tenant-id}/v2.0
--oidc-client-id=your-kubernetes-client-id
--oidc-username-claim=email
--oidc-groups-claim=groups
--oidc-username-prefix=oidc:
--oidc-groups-prefix=oidc:
```

**For Amazon EKS:**

```bash
aws eks associate-identity-provider-config \
  --cluster-name my-cluster \
  --oidc \
  --identity-provider-config '{
    "identityProviderConfigName": "entra-id",
    "issuerUrl": "https://login.microsoftonline.com/{tenant-id}/v2.0",
    "clientId": "your-client-id",
    "usernameClaim": "email",
    "groupsClaim": "groups",
    "usernamePrefix": "oidc:"
  }'
```

**For Azure AKS:**

AKS natively integrates with Entra ID:

```bash
az aks update \
  --resource-group myResourceGroup \
  --name myAKSCluster \
  --enable-aad \
  --aad-admin-group-object-ids "your-admin-group-id"
```

**Configure kubectl for OIDC:**

Use kubelogin or oidc-login plugin:

```bash
kubectl config set-credentials oidc-user \
  --exec-api-version=client.authentication.k8s.io/v1beta1 \
  --exec-command=kubelogin \
  --exec-arg=get-token \
  --exec-arg=--oidc-issuer-url=https://login.microsoftonline.com/{tenant-id}/v2.0 \
  --exec-arg=--oidc-client-id=your-client-id \
  --exec-arg=--oidc-client-secret=your-client-secret
```

### Step 2: Design and Implement RBAC

RBAC in Kubernetes uses four objects: Role, ClusterRole, RoleBinding, and ClusterRoleBinding.

**Principle 1: Namespace isolation**

Use namespaces to isolate teams and environments. Bind roles at the namespace level, not the cluster level.

```yaml
apiVersion: v1
kind: Namespace
metadata:
  name: team-payments
  labels:
    team: payments
    environment: production
```

**Principle 2: Least privilege roles**

Never use the built-in cluster-admin role for regular operations. Create custom roles with minimal permissions:

```yaml
# Developer role - can manage deployments and view logs
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: team-payments
  name: developer
rules:
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiGroups: [""]
  resources: ["pods", "pods/log", "services", "configmaps"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["pods/exec"]
  verbs: []  # explicitly deny exec in production
```

```yaml
# SRE role - broader access but still not cluster-admin
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: team-payments
  name: sre
rules:
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets", "statefulsets", "daemonsets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: [""]
  resources: ["pods", "pods/log", "pods/exec", "services", "configmaps", "secrets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["networking.k8s.io"]
  resources: ["networkpolicies", "ingresses"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
```

**Principle 3: Bind to groups, not users**

Always bind roles to groups from your IdP, not individual users. This allows access management through group membership rather than Kubernetes RBAC modifications:

```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: payments-developers
  namespace: team-payments
subjects:
- kind: Group
  name: oidc:payments-developers  # matches IdP group
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io
```

### Step 3: Harden Service Accounts

**Disable auto-mounting of service account tokens:**

By default, Kubernetes mounts a service account token into every pod. Most pods do not need to communicate with the Kubernetes API. Disable auto-mounting at the service account level:

```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app
  namespace: team-payments
automountServiceAccountToken: false
```

Or at the pod level:

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  automountServiceAccountToken: false
  serviceAccountName: my-app
```

**Create dedicated service accounts per workload:**

Never use the default service account. Create a purpose-specific service account for each application:

```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: payment-processor
  namespace: team-payments
  annotations:
    description: "Service account for the payment processing service"
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: payment-processor-role
  namespace: team-payments
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "watch"]
  resourceNames: ["payment-config"]  # restrict to specific resources
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: payment-processor-binding
  namespace: team-payments
subjects:
- kind: ServiceAccount
  name: payment-processor
  namespace: team-payments
roleRef:
  kind: Role
  name: payment-processor-role
  apiGroup: rbac.authorization.k8s.io
```

**Use bound service account tokens (TokenRequest API):**

Instead of the legacy long-lived tokens, use bound tokens that are audience-scoped and time-limited:

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  serviceAccountName: payment-processor
  automountServiceAccountToken: false
  containers:
  - name: app
    volumeMounts:
    - name: token
      mountPath: /var/run/secrets/tokens
      readOnly: true
  volumes:
  - name: token
    projected:
      sources:
      - serviceAccountToken:
          audience: "https://my-api.example.com"
          expirationSeconds: 3600
          path: token
```

### Step 4: Implement Workload Identity Federation

Workload identity federation allows Kubernetes pods to authenticate to cloud services without storing static credentials. Each cloud provider has its own implementation.

**AWS EKS Pod Identity / IRSA:**

```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: s3-reader
  namespace: team-payments
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/s3-reader-role
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: data-processor
spec:
  template:
    spec:
      serviceAccountName: s3-reader
      containers:
      - name: app
        # AWS SDK automatically uses the IRSA token
```

**Azure AKS Workload Identity:**

```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: keyvault-reader
  namespace: team-payments
  annotations:
    azure.workload.identity/client-id: "your-managed-identity-client-id"
  labels:
    azure.workload.identity/use: "true"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: secret-consumer
spec:
  template:
    metadata:
      labels:
        azure.workload.identity/use: "true"
    spec:
      serviceAccountName: keyvault-reader
```

**GCP GKE Workload Identity:**

```bash
gcloud iam service-accounts add-iam-policy-binding \
  gcs-reader@my-project.iam.gserviceaccount.com \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:my-project.svc.id.goog[team-payments/gcs-reader]"
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: gcs-reader
  namespace: team-payments
  annotations:
    iam.gke.io/gcp-service-account: gcs-reader@my-project.iam.gserviceaccount.com
```

### Step 5: Secure Secrets Management

Upstream Kubernetes stores Secrets base64-encoded and does not encrypt them at rest unless you configure it. For production workloads, use external secrets management.

**Enable encryption at rest:**

Configure the API server to encrypt secrets in etcd:

```yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
    - secrets
    providers:
    - aescbc:
        keys:
        - name: key1
          secret: <base64-encoded-key>
    - identity: {}
```

For managed clusters, check the provider default before adding configuration. [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/envelope-encryption.html) applies envelope encryption to all Kubernetes API data, not just Secrets, on clusters running Kubernetes 1.28 or later, using KMS v2 with an AWS owned key by default and an optional customer managed KMS key if you need key control and CloudTrail visibility. On AKS and GKE, enable the KMS integration with Azure Key Vault or Cloud KMS.

**Use External Secrets Operator:**

The External Secrets Operator syncs secrets from external vaults into Kubernetes:

```yaml
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
  namespace: team-payments
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: db-creds
  data:
  - secretKey: username
    remoteRef:
      key: payments/database
      property: username
  - secretKey: password
    remoteRef:
      key: payments/database
      property: password
```

**Use CSI Secrets Store Driver for direct mount:**

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    volumeMounts:
    - name: secrets
      mountPath: /mnt/secrets
      readOnly: true
  volumes:
  - name: secrets
    csi:
      driver: secrets-store.csi.k8s.io
      readOnly: true
      volumeAttributes:
        secretProviderClass: azure-keyvault
```

## Best Practices

### Audit RBAC Regularly

Use tools like kubectl-who-can, rakkess, or rbac-lookup to audit who has what access:

```bash
# Who can delete pods in the payments namespace?
kubectl-who-can delete pods -n team-payments

# What can the payment-processor service account do?
kubectl auth can-i --list --as=system:serviceaccount:team-payments:payment-processor -n team-payments
```

Run these audits monthly and feed results into your IGA program.

### Implement Network Policies Alongside Identity

RBAC controls API access, but network policies control pod-to-pod communication. Use both:

```yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: payment-processor-policy
  namespace: team-payments
spec:
  podSelector:
    matchLabels:
      app: payment-processor
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api-gateway
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
```

### Use Pod Security Admission

Enforce security standards at the namespace level:

```yaml
apiVersion: v1
kind: Namespace
metadata:
  name: team-payments
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted
```

The restricted profile prevents running as root, requires dropping all capabilities, and requires a RuntimeDefault or Localhost seccomp profile ([Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/)).

## Testing

1. **RBAC testing**, Create test users/service accounts with each role and verify they can perform exactly the allowed actions and nothing more.
2. **Workload identity testing**, Deploy a test pod with workload identity and verify it can access the target cloud service. Then remove the identity binding and verify access is denied.
3. **Secrets testing**, Verify that secrets are encrypted at rest by examining etcd directly (in test environments). Verify that External Secrets Operator syncs correctly and handles rotation.
4. **Penetration testing**, Use kube-bench for CIS benchmark checks and a maintained scanner such as Trivy for misconfigurations. Avoid relying on kube-hunter: its [README](https://github.com/aquasecurity/kube-hunter) states it is no longer under active development and recommends Trivy instead.

## Common Pitfalls

### Granting cluster-admin to CI/CD

CI/CD pipelines often receive cluster-admin because "it is easier." This means a compromised pipeline can destroy the entire cluster. Create scoped roles that allow only the specific actions your pipeline needs (deploy to specific namespaces, update specific resources).

### Not Rotating Service Account Tokens

Legacy (pre-1.24) service account tokens do not expire. If your cluster has workloads using these tokens, migrate to bound tokens with expiration. Audit for long-lived tokens regularly.

### Storing Secrets in ConfigMaps

ConfigMaps are not encrypted and are often less strictly controlled than Secrets. Never store sensitive data in ConfigMaps, even temporarily.

### Ignoring the Default Namespace

The default namespace often has overly permissive RBAC and should not be used for production workloads. Deploy everything to purpose-specific namespaces.

## Conclusion

Kubernetes identity security requires a multi-layered approach: OIDC for human authentication, RBAC for authorization, hardened service accounts for workload identity, workload identity federation for cloud service access, and external secrets management for credential protection. The defaults are not secure enough for production. Invest the time to configure each layer properly, audit regularly, and treat Kubernetes identity as part of your broader IAM program.

## Machine Identity Management Guide
Source: https://startwithidentity.com/guides/machine-identity/machine-identity-management-guide/
Last updated: 2026-11-05

Every organization invests heavily in managing human identities, user accounts, passwords, MFA, access reviews. But the majority of identities in a modern enterprise are not human. They are machines: servers, containers, microservices, CI/CD pipelines, IoT devices, APIs, and automated scripts. In most enterprises they now outnumber human identities, and every new service, pipeline, and AI agent adds more.

Machine identities are often poorly managed. Service accounts with static passwords that never rotate, API keys hardcoded in source code, certificates that expire without warning, and secrets spread across configuration files and environment variables. Each of these is a breach waiting to happen.

This guide provides a structured approach to machine identity management, from discovery through lifecycle automation.

## What You Will Learn

- The types of machine identities and their use cases
- How to design a machine identity governance framework
- Setting up a Private PKI for certificate-based authentication
- Managing service accounts, API keys, and secrets securely
- Automating secrets rotation with zero downtime
- Machine-to-machine authentication patterns (mTLS, OAuth, SPIFFE)

## Prerequisites

1. **Machine identity inventory**, Before you can manage machine identities, you need to know what exists. Prepare to discover service accounts, certificates, API keys, and secrets across your environment.
2. **Secrets management platform**, A centralized vault ([HashiCorp Vault](https://startwithidentity.com/vendors/machine-identity/hashicorp-vault/), [AWS Secrets Manager](https://startwithidentity.com/vendors/secrets/aws-secrets-manager/), [Azure Key Vault](https://startwithidentity.com/vendors/secrets/azure-key-vault/), [Conjur, now Idira Secrets Manager](https://startwithidentity.com/vendors/secrets/cyberark-conjur/)) for storing and distributing secrets.
3. **Certificate infrastructure**, Either a cloud-based CA (AWS Private CA, Google Cloud CA Service) or the ability to deploy a private PKI.
4. **Configuration management**, A way to deploy configuration changes to machines (Ansible, Puppet, Chef, or Kubernetes ConfigMaps/Secrets).
5. **Monitoring stack**, Logging and alerting infrastructure to monitor certificate expiry, secret access, and anomalous machine behavior.

## Architecture Overview

Machine identity management involves several interconnected systems:

- **Certificate Authority (CA):** Issues, renews, and revokes X.509 certificates for servers, services, and devices.
- **Secrets Vault:** Centrally stores and controls access to API keys, database credentials, encryption keys, and other secrets. Provides dynamic secrets where possible.
- **Identity Broker:** Enables machine-to-machine authentication using short-lived credentials. [SPIFFE/SPIRE](https://startwithidentity.com/vendors/machine-identity/spiffe-spire/) is the emerging standard for [workload identity](https://startwithidentity.com/glossary/workload-identity/).
- **Discovery Engine:** Scans the environment for machine identities, certificates on load balancers, secrets in environment variables, service accounts in AD/cloud IAM.
- **Lifecycle Automation:** Handles credential rotation, renewal, and revocation without human intervention.

**Types of machine identities:**

| Type | Format | Typical Lifetime | Use Case |
|------|--------|-----------------|----------|
| X.509 certificate | PEM/DER | 90 days - 1 year | TLS, mTLS, code signing |
| Service account | Username/password or token | Permanent (bad) / rotated (good) | Application-to-database, AD service |
| API key | String token | Permanent (bad) / rotated (good) | SaaS API access, third-party integrations |
| OAuth client credential | client_id + client_secret | Secret rotated, ID permanent | Machine-to-machine API authorization |
| SSH key | RSA/Ed25519 key pair | Varies | Server access, Git operations |
| SPIFFE SVID | X.509 or JWT | Minutes to hours | Workload-to-workload in service mesh |
| Managed identity | Platform token | Minutes (auto-rotated) | Cloud-native workloads (AWS IAM roles, Azure MI) |

## Step-by-Step Implementation

### Step 1: Discover Existing Machine Identities

You cannot secure what you do not know about. Run a complete discovery:

**Certificates:**
```bash
# Scan all servers for TLS certificates
nmap --script ssl-cert -p 443 10.0.0.0/16 -oX cert-scan.xml

# Check certificate details
openssl s_client -connect server:443 -servername server.example.com </dev/null 2>/dev/null | \
  openssl x509 -noout -subject -issuer -dates -serial
```

**Service accounts in Active Directory:**
```powershell
# Find all service accounts
Get-ADServiceAccount -Filter * | Select-Object Name, Enabled, PasswordLastSet, LastLogonDate

# Find accounts with non-expiring passwords
Get-ADUser -Filter {PasswordNeverExpires -eq $true -and Enabled -eq $true} -Properties PasswordLastSet |
  Where-Object { $_.PasswordLastSet -lt (Get-Date).AddDays(-90) }
```

**Secrets in source code (DO NOT do this in production, scan in CI/CD):**
```bash
# Use a secret scanner like truffleHog or gitleaks
gitleaks detect --source /path/to/repo --report-format json --report-path leaks.json
```

**Cloud IAM service accounts:**
```bash
# AWS: List IAM roles and their last activity
aws iam list-roles --query 'Roles[*].[RoleName,CreateDate]' --output table

# GCP: List service accounts
gcloud iam service-accounts list --format="table(email, disabled)"

# Azure: List service principals
az ad sp list --all --query "[].{Name:displayName, AppId:appId}" --output table
```

Create a central inventory of all discovered machine identities, including owner, purpose, credential type, rotation status, and expiry date.

### Step 2: Deploy a Secrets Management Platform

Centralize all machine secrets in a vault:

```hcl
# HashiCorp Vault: Enable secrets engine for database credentials
vault secrets enable database

# Configure dynamic database credentials
vault write database/config/mydb \
  plugin_name=postgresql-database-plugin \
  allowed_roles="app-readonly" \
  connection_url="postgresql://{{username}}:{{password}}@db.example.com:5432/mydb" \
  username="vault_admin" \
  password="REDACTED"

# Create a role that generates short-lived credentials
vault write database/roles/app-readonly \
  db_name=mydb \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
  default_ttl="1h" \
  max_ttl="24h"
```

With dynamic secrets, the vault generates a unique database credential for each application instance, valid for only 1 hour. When the lease expires, the vault automatically revokes the credential. No more shared, static database passwords.

### Step 3: Implement Certificate-Based Machine Authentication

For service-to-service communication, mTLS (mutual TLS) with short-lived certificates is the gold standard:

```yaml
# SPIFFE/SPIRE configuration for workload identity
# spire-server.conf
server {
  bind_address = "0.0.0.0"
  bind_port = "8081"
  trust_domain = "example.com"
  data_dir = "/opt/spire/data/server"
  ca_ttl = "24h"
  default_x509_svid_ttl = "1h"
}

plugins {
  NodeAttestor "k8s_psat" {
    plugin_data {
      clusters = {
        "production" = {
          service_account_allow_list = ["spire:spire-agent"]
        }
      }
    }
  }
  KeyManager "disk" {
    plugin_data {
      keys_path = "/opt/spire/data/server/keys.json"
    }
  }
}
```

SPIFFE (Secure Production Identity Framework for Everyone) assigns each workload a cryptographic identity (SVID, SPIFFE Verifiable Identity Document) in the form of an X.509 certificate or JWT. SPIRE is the reference implementation that automates issuance and rotation.

### Step 4: Implement API Key Rotation

For third-party API keys and SaaS integrations that cannot use mTLS or OAuth:

```python
# Automated API key rotation script
import vault_client
import saas_admin_api

def rotate_api_key(service_name, vault_path):
    # Step 1: Generate new API key at the SaaS provider
    new_key = saas_admin_api.create_api_key(
        service=service_name,
        name=f"{service_name}-{datetime.now().isoformat()}",
        permissions=["read", "write"]
    )

    # Step 2: Store new key in vault
    vault_client.write(vault_path, {
        "api_key": new_key.key,
        "created_at": datetime.now().isoformat(),
        "expires_at": new_key.expires_at
    })

    # Step 3: Wait for applications to pick up the new key
    # Applications should read from vault on each request or on a short poll
    time.sleep(300)  # 5 minutes grace period

    # Step 4: Revoke the old key
    old_key_id = vault_client.read(f"{vault_path}/previous")["key_id"]
    saas_admin_api.revoke_api_key(service=service_name, key_id=old_key_id)

    # Step 5: Log the rotation event
    log_rotation_event(service_name, old_key_id, new_key.id)
```

### Step 5: Secure Service Accounts

Service accounts in Active Directory and cloud IAM require special treatment:

1. **Eliminate password-based service accounts.** Migrate to Group Managed Service Accounts (gMSA) in AD, which automatically rotate passwords. In cloud environments, use managed identities (AWS IAM roles for EC2/Lambda, Azure Managed Identity, GCP Workload Identity).

2. **Apply least privilege.** Every service account should have the minimum permissions required. Audit and remove unused permissions quarterly.

3. **Disable interactive login.** Service accounts should never be used for interactive (human) login. Disable interactive logon rights and monitor for violations.

```powershell
# Create a Group Managed Service Account (gMSA)
New-ADServiceAccount -Name "svc-webapp" `
  -DNSHostName "svc-webapp.contoso.com" `
  -PrincipalsAllowedToRetrieveManagedPassword "WebServers" `
  -KerberosEncryptionType AES256

# Install gMSA on the target server
Install-ADServiceAccount -Identity "svc-webapp"
```

### Step 6: Implement Monitoring and Alerting

Machine identities need continuous monitoring:

```yaml
# Monitoring rules for machine identity health
alerts:
  - name: "Certificate expiring within 30 days"
    query: |
      certificate_expiry_days < 30 AND certificate_auto_renew = false
    severity: warning
    action: notify_certificate_owner

  - name: "Service account password not rotated in 90 days"
    query: |
      service_account_password_age_days > 90
    severity: critical
    action: notify_security_team

  - name: "API key used from unexpected IP"
    query: |
      api_key_usage WHERE source_ip NOT IN allowed_ips
    severity: high
    action: alert_security_ops

  - name: "Machine identity used outside business hours"
    query: |
      service_account_login WHERE hour NOT BETWEEN 0 AND 23
      AND service_type = "batch_job"
      AND login_hour NOT IN expected_schedule
    severity: medium
    action: investigate

  - name: "Vault secret access anomaly"
    query: |
      vault_secret_reads WHERE count > baseline * 3
    severity: high
    action: alert_security_ops
```

## Configuration Best Practices

- **Eliminate static secrets.** Replace every static credential with a dynamic one (vault-issued, managed identity, SPIFFE SVID) or at minimum enforce automated rotation.
- **Use managed identities in cloud.** AWS IAM roles, Azure Managed Identity, and GCP Workload Identity eliminate the need for static credentials entirely in cloud-native workloads.
- **Certificate lifetimes should be short.** 90 days maximum for server certificates, 1 hour for workload identity certificates (SPIFFE SVIDs). Shorter lifetimes reduce the window of exposure from a compromised credential.
- **Separate machine and human identities.** Never share credentials between humans and machines. Service accounts should have dedicated credentials, dedicated permissions, and dedicated monitoring.
- **Tag every machine identity with an owner.** Every service account, API key, and certificate must have a documented owner who is responsible for its lifecycle.
- **Automate everything.** Manual rotation does not scale. Invest in automation for issuance, rotation, and revocation from day one.

## Testing and Validation

1. **Rotation testing:** Trigger a manual rotation for each credential type and verify that applications continue to function without downtime.
2. **Revocation testing:** Revoke a certificate and verify that the relying service rejects it immediately (OCSP) or within the CRL refresh interval.
3. **Failover testing:** Simulate a vault outage. Verify that applications gracefully degrade (use cached credentials) rather than crash.
4. **Secret scanner testing:** Intentionally commit a dummy secret to a test repository and verify that the CI/CD scanner catches it.
5. **Expiry alerting:** Set a test certificate to expire in 7 days and verify that the alerting pipeline fires correctly.
6. **Least privilege audit:** Attempt to use a service account for an operation outside its granted permissions. Verify the operation is denied.

## Common Pitfalls and Troubleshooting

| Problem | Cause | Solution |
|---------|-------|----------|
| Application crashes during secret rotation | App caches the credential and does not re-read from vault | Implement credential refresh logic; use vault agent for sidecar injection |
| Certificate renewal fails silently | ACME client or renewal script has a bug | Monitor for renewal failures with dedicated alerts; test renewal before expiry |
| Service account lockout | Too many failed auth attempts from a misconfigured app | Implement circuit breakers; alert on repeated auth failures |
| Secrets sprawl | Developers copy secrets to local .env files and config maps | Enforce vault-only access; scan for secrets in CI/CD and at deploy time |
| Orphaned machine identities | Service decommissioned but identity not cleaned up | Implement automated deprovisioning tied to infrastructure lifecycle (Terraform, Kubernetes) |
| mTLS breaks after certificate rotation | Client cached the old server certificate | Use trust bundles that include both old and new CA certificates during rollover |

## Security Considerations

1. **Machine identity compromise is stealthy.** Unlike human account compromise (which may trigger MFA challenges or user reports), machine identity compromise can go undetected for months. Invest heavily in behavioral monitoring for machine identities.
2. **The vault is a crown jewel.** If an attacker compromises your secrets vault, they gain access to every credential it manages. Treat the vault with the same security rigor as your domain controllers: dedicated infrastructure, hardware-backed encryption, strict access controls, and complete audit logging.
3. **Supply chain attacks target machine identities.** The SolarWinds attack demonstrated how compromised build pipelines and signing certificates can have catastrophic consequences. Protect CI/CD credentials with the same vigor as production credentials.
4. **Certificate authority compromise is existential.** If your private CA's root key is compromised, every certificate it issued is untrustworthy. Use an HSM for root key storage and keep the root CA offline.
5. **Orphaned machine identities are a backdoor.** A service account that belongs to a decommissioned application but was never disabled is an attacker's gift. Implement automated identity lifecycle tied to infrastructure provisioning tools.

## Conclusion

Machine identity management is one of the most underinvested areas of enterprise security, yet machine identities outnumber human identities by orders of magnitude. The attack surface they present is enormous: static credentials, expired certificates, over-privileged service accounts, and secrets scattered across configuration files.

The path forward is clear: centralize secrets in a vault, automate credential rotation, use short-lived certificates for service authentication, migrate to managed identities in the cloud, and monitor machine identity usage with the same rigor you apply to human identity. Each step materially reduces risk and brings your organization closer to a mature machine identity posture.

## MFA Implementation Best Practices
Source: https://startwithidentity.com/guides/authentication/mfa-implementation-best-practices/
Last updated: 2026-11-05

Multi-factor authentication (MFA) remains the single most effective control against account compromise. In an [August 2019 post](https://www.microsoft.com/en-us/security/blog/2019/08/20/one-simple-action-you-can-take-to-prevent-99-9-percent-of-account-attacks/), Microsoft said MFA can block over 99.9 percent of account compromise attacks. That figure is from 2019 and covers MFA in general, not any single method. Yet many organizations either have not deployed MFA at all or have deployed it with methods that are vulnerable to modern phishing techniques. MFA fatigue attacks, SIM swapping, and real-time phishing proxies have shown that not all MFA methods are created equal.

This guide covers how to choose the right MFA methods for your environment, deploy them across your organization, handle edge cases, and ultimately move toward phishing-resistant MFA.

## What You Will Learn

- How different MFA methods compare in security, usability, and cost
- What makes MFA "phishing-resistant" and why it matters
- Step-by-step deployment strategies for enterprise MFA
- How to balance security requirements with user experience
- Handling exceptions, help-desk impact, and adoption challenges

## Prerequisites

1. **Centralized Identity Provider**, MFA should be enforced at the IdP level, not per-application. Ensure you have SSO deployed or planned.
2. **User directory**, An up-to-date directory with phone numbers and email addresses for enrollment bootstrapping.
3. **Device inventory**, Understanding what devices users have (corporate-managed, BYOD, shared workstations) determines which MFA methods are feasible.
4. **Help-desk readiness**, MFA will generate help-desk tickets during enrollment and when users lose authenticators. Prepare scripts and staffing.
5. **Communication plan**, Users need advance notice, training materials, and clear instructions. Surprise MFA rollouts fail.

## Architecture Overview

MFA works by requiring the user to prove their identity using two or more independent factors:

- **Knowledge:** Something you know (password, PIN)
- **Possession:** Something you have (phone, security key, smart card)
- **Inherence:** Something you are (fingerprint, face, voice)

The strongest MFA combines a possession factor with an inherence factor, eliminating knowledge-based secrets entirely. However, the most common deployment today uses password (knowledge) plus a second factor (possession or inherence).

**MFA Methods Comparison:**

| Method | Phishing Resistant | UX Score | Cost | Deployment Complexity |
|--------|-------------------|----------|------|----------------------|
| SMS OTP | No | Medium | Low | Low |
| Voice Call | No | Low | Low | Low |
| TOTP (Authenticator App) | No | Medium | Free | Medium |
| Push Notification | No (unless number-matching) | High | Medium | Medium |
| Push with Number Matching | Partially | High | Medium | Medium |
| FIDO2 Security Key | Yes | High | High | Medium |
| Platform Authenticator (Passkey) | Yes | Very High | Free | Medium |
| Smart Card/PIV | Yes | Low | High | High |
| Email OTP | No | Low | Free | Low |

The clear takeaway: FIDO2-based methods (security keys and platform authenticators) are the only fully phishing-resistant options. Push with number matching is a significant improvement over basic push but is not truly phishing-resistant against real-time proxy attacks.

## Step-by-Step Implementation

### Step 1: Define Your MFA Tiers

Not every user needs the same level of MFA. Define tiers based on risk:

**Tier 1, Standard users:**
- Acceptable methods: Push notification with number matching, TOTP, platform authenticator
- Use case: General workforce accessing email, productivity apps, and internal tools

**Tier 2, Privileged users:**
- Required method: FIDO2 security key or platform authenticator
- Use case: System administrators, developers with production access, security team

**Tier 3, Executives and high-value targets:**
- Required method: FIDO2 security key (hardware-bound, not synced)
- Use case: C-suite, board members, finance approvers

```yaml
# Example MFA policy configuration
mfa_policies:
  - name: "Standard Workforce"
    groups: ["All-Employees"]
    allowed_methods:
      - push_with_number_matching
      - totp
      - platform_authenticator
      - security_key
    enforcement: required
    grace_period_days: 14

  - name: "Privileged Users"
    groups: ["IT-Admins", "DevOps", "Security-Team"]
    allowed_methods:
      - security_key
      - platform_authenticator
    enforcement: required
    grace_period_days: 7

  - name: "Executives"
    groups: ["C-Suite", "Board-Members"]
    allowed_methods:
      - security_key
    enforcement: required
    grace_period_days: 7
```

### Step 2: Configure MFA at the IdP

Every major IdP supports MFA configuration. The general steps are:

1. **Enable MFA globally.** Turn on MFA enforcement for all users. Start with an enrollment-only mode that prompts users to set up MFA but does not block access yet.
2. **Configure allowed methods.** For each tier, enable only the approved methods. Disable SMS if your policy does not allow it.
3. **Set up enrollment policies.** Define how users enroll: self-service during login, administrator-assisted, or via a dedicated enrollment portal.
4. **Configure session policies.** Decide when MFA is required: every login, every 24 hours, only from untrusted networks, only for sensitive applications.
5. **Enable recovery options.** Configure backup methods (recovery codes, backup phone number) for users who lose their primary authenticator.

```json
{
  "mfa_settings": {
    "enforcement": "required",
    "enrollment_mode": "self_service_with_prompt",
    "session_lifetime": "24h",
    "step_up_for_sensitive_apps": true,
    "allowed_methods": ["webauthn", "totp", "push_number_matching"],
    "disallowed_methods": ["sms", "voice", "email_otp"],
    "recovery": {
      "backup_codes": true,
      "backup_code_count": 10,
      "admin_reset": true
    }
  }
}
```

### Step 3: Pilot with Early Adopters

Before rolling out to the entire organization:

1. Select a pilot group of 50-100 users across different departments and technical skill levels.
2. Distribute security keys (if applicable) and provide enrollment instructions.
3. Enable MFA enforcement for the pilot group.
4. Monitor the help-desk for issues and collect feedback daily.
5. Iterate on documentation and enrollment flow based on feedback.
6. Run the pilot for 2-4 weeks before expanding.

### Step 4: Roll Out in Waves

After a successful pilot, expand in waves:

**Wave 1 (Week 1-2):** IT department and technical teams, they can self-troubleshoot.
**Wave 2 (Week 3-4):** Business units with tech-savvy users.
**Wave 3 (Week 5-6):** Remaining employees.
**Wave 4 (Week 7-8):** Contractors, partners, and external collaborators.

Each wave follows the same pattern:
1. Send advance communication 7 days before enforcement.
2. Open an enrollment window (grace period) where users are prompted but not blocked.
3. Enable enforcement at the end of the grace period.
4. Follow up with non-enrolled users individually.

### Step 5: Handle Edge Cases

Every MFA rollout encounters these edge cases:

**Shared workstations:** Users on shared terminals (factory floor, hospital) cannot easily use push notifications on personal phones. Solution: FIDO2 security keys that users badge in and out with, or proximity-based authentication.

**Users without smartphones:** Some users do not have smartphones or refuse to install apps on personal devices. Solution: Provide hardware security keys or issue company phones.

**Service accounts:** MFA does not apply to non-interactive service accounts. Protect these with strong API keys, certificate-based auth, or managed identities instead.

**Offline scenarios:** Users who work in disconnected environments cannot receive push notifications. Solution: TOTP codes work offline, as do FIDO2 security keys.

**Accessibility needs:** Ensure at least one MFA method works for users with disabilities. FIDO2 security keys with tactile buttons and TOTP with screen-reader-accessible apps are good options.

### Step 6: Move to Phishing-Resistant MFA

Once basic MFA is deployed and adoption is high, plan the migration to phishing-resistant methods:

1. Provision FIDO2 security keys for all privileged users. Budget two keys per user (primary + backup).
2. Enable platform authenticator (passkey) enrollment for all users.
3. Gradually disable non-phishing-resistant methods (TOTP, push without number matching).
4. Implement conditional access policies that require phishing-resistant MFA for sensitive applications.
5. Set a target date for full phishing-resistant MFA enforcement.

## Configuration Best Practices

- **Disable SMS and voice MFA.** SIM swapping attacks make these methods unreliable. If you must support SMS for a transition period, add additional controls like SIM binding checks.
- **Enable number matching for push.** If you use push notifications, always enable number matching. Without it, users will approve prompts they did not initiate (MFA fatigue attacks).
- **Require MFA for all admin consoles.** IdP admin, cloud console, and infrastructure management should require step-up MFA on every session.
- **Use conditional access.** Not every login needs MFA. Use risk-based policies: require MFA for new devices, unfamiliar locations, or after a configurable session timeout. Always require MFA for sensitive operations.
- **Issue backup codes during enrollment.** Generate 10 single-use backup codes and instruct users to store them securely. This prevents lockouts when authenticators are lost.
- **Audit MFA bypasses.** Any MFA exception or bypass should be logged, reviewed weekly, and time-limited.

## Testing and Validation

1. **Enrollment flow testing:** Walk through enrollment for each MFA method on different devices and browsers. Verify that the instructions are clear and the flow completes without errors.
2. **Authentication testing:** Test login with each MFA method and verify success. Test with incorrect OTP, denied push, and wrong security key to verify failure handling.
3. **Recovery testing:** Simulate a lost authenticator. Use a backup code to log in. Verify that the backup code is consumed and cannot be reused.
4. **Phishing simulation:** Conduct a phishing exercise against users with phishing-resistant MFA. Verify that FIDO2 credentials cannot be harvested by a proxy.
5. **Fatigue attack simulation:** Send multiple rapid push notifications and verify that number matching prevents blind approval.
6. **Help-desk testing:** Have a test user call the help-desk claiming to have lost their MFA device. Verify that the help-desk follows the identity verification procedure before resetting MFA.

## Common Pitfalls and Troubleshooting

| Problem | Cause | Solution |
|---------|-------|----------|
| Users approve push prompts they didn't initiate | MFA fatigue attack | Enable number matching; alert on repeated denied prompts |
| TOTP codes rejected | Clock skew between user's phone and server | Allow a time-step tolerance of +/- 1 (30 seconds); advise users to enable automatic time sync |
| Security key not recognized | Browser or OS does not support the key's protocol | Verify FIDO2 support; update browser; try a different USB port |
| User locked out after phone factory reset | TOTP seeds were not backed up | Use backup codes; re-enroll after identity verification |
| Conditional access too aggressive | MFA required on every request | Adjust session timeout; exempt trusted networks/devices |
| Help-desk social engineering | Attacker convinces help-desk to reset MFA | Require strong identity verification (video call, manager approval) before MFA reset |

## Security Considerations

1. **MFA fatigue is a real threat.** Attackers who have stolen a password will send dozens of push notifications hoping the user approves one out of annoyance. Number matching, rate limiting (max 3 prompts per minute), and anomaly alerting are essential countermeasures.
2. **Real-time phishing proxies bypass TOTP and push.** Tools like Evilginx2 can intercept TOTP codes and session cookies in real time, then replay the cookie in a [pass-the-cookie](https://startwithidentity.com/glossary/pass-the-cookie/) attack. Only FIDO2-based MFA is resistant to these attacks because the credential is origin-bound.
3. **MFA reset is the weakest link.** If an attacker can convince the help-desk to reset a user's MFA, the strongest MFA method is irrelevant. Implement rigorous identity verification for MFA reset requests: require manager approval, video verification, or in-person identity check.
4. **Recovery codes must be protected.** Backup codes are effectively single-use passwords. Advise users to store them in a password manager or physical safe, not in a text file on their desktop.
5. **Session hijacking after MFA.** MFA protects the authentication event but not the session. Use sender-constrained tokens such as [DPoP](https://startwithidentity.com/glossary/dpop/) ([RFC 9449](https://datatracker.ietf.org/doc/html/rfc9449)), bind browser sessions to the device with [Device Bound Session Credentials](https://startwithidentity.com/glossary/device-bound-session-credentials/) where supported, and add short session lifetimes and anomaly detection to protect the authenticated session.

## Conclusion

MFA is no longer optional, it is a baseline security control. The question is not whether to deploy MFA but which methods to deploy and how aggressively to enforce phishing-resistant options. The ideal end state is phishing-resistant MFA (FIDO2) for all users, with the journey there following a phased, user-friendly rollout that prioritizes adoption over perfection.

Start by deploying MFA with any available method to close the biggest gap (unprotected passwords). Then systematically upgrade to stronger methods. Every step along this path materially reduces your risk of account compromise.

## MFA rollout: a practical sequence that doesn't break the org
Source: https://startwithidentity.com/guides/authentication/mfa-rollout/
Last updated: 2026-11-05

An **MFA rollout** is the phased program that takes multi-factor authentication from optional to enforced for every account that matters: admins first, then high-risk roles, then all staff and contractors, ending on [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/). The short answer on sequencing: protect the accounts that can change the tenant before you protect everyone, and harden recovery before you enforce, because recovery is where attackers go next.

Every breach report says MFA would have prevented this, and the data backs it up: in an [August 2019 post](https://www.microsoft.com/en-us/security/blog/2019/08/20/one-simple-action-you-can-take-to-prevent-99-9-percent-of-account-attacks/), Microsoft said MFA can block over 99.9 percent of account compromise attacks. Yet full enforcement remains rare, and the blockers are operational, not technical: legacy apps that cannot do MFA, help-desk capacity, and executive exceptions that quietly propagate. Not all MFA is equal either. The [Snowflake breaches](https://startwithidentity.com/breaches/snowflake-2024-credential-attacks/) hit accounts with no MFA at all, while [MFA-fatigue attacks](https://startwithidentity.com/breaches/mfa-fatigue-push-bombing/) defeated simple push approvals. The goal is phishing-resistant MFA everywhere it matters. This guide is for IAM and security teams planning the program; for factor-level configuration see [MFA implementation best practices](https://startwithidentity.com/guides/authentication/mfa-implementation-best-practices/).

## What changed in 2025-2026

- **NIST tightened the baseline.** [SP 800-63B-4](https://csrc.nist.gov/pubs/sp/800/63/b/4/final), final in July 2025, says verifiers "SHALL offer at least one phishing-resistant authentication option at AAL2" and keeps out-of-band codes over the phone network as *restricted* ([NIST 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html)). See [NIST 800-63](https://startwithidentity.com/glossary/nist-800-63/) and [AAL](https://startwithidentity.com/glossary/aal/).
- **Cloud providers now enforce MFA for you.** Microsoft's [mandatory MFA](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mandatory-multifactor-authentication) required MFA for the Azure portal, Entra admin center and Intune admin center from October 2024, the Microsoft 365 admin center from February 2025, and Azure CLI, PowerShell, IaC tools and the control-plane REST API from October 1, 2025, with Phase 2 postponement available only until July 1, 2026. Break-glass accounts are not exempt, and Microsoft recommends passkeys (FIDO2) or certificate-based authentication for them.
- **Number matching is the floor for push.** In [Microsoft Entra](https://startwithidentity.com/vendors/iam/microsoft-entra/), [number matching](https://startwithidentity.com/glossary/number-matching/) is enabled for all [Microsoft Authenticator](https://startwithidentity.com/vendors/mfa/microsoft-authenticator/) push notifications and users cannot opt out ([Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-mfa-number-match)).
- **Passkeys are standardized.** WebAuthn Level 3 became a W3C Recommendation on August 25, 2026 (see [WebAuthn/FIDO2](https://startwithidentity.com/standards/webauthn-fido2/)), so the phishing-resistant end state no longer depends on a draft.

## Pick the factor by population

| Population | Target factor | Interim factor | Never allow |
| --- | --- | --- | --- |
| Tenant admins, break-glass | FIDO2 security key or certificate-based auth | None | SMS, voice, plain push |
| Finance, legal, executives, assistants | Device-bound passkey or security key | Number-matching push | SMS-only |
| General staff | Passkey (platform or synced) | Number-matching push or TOTP | Approve/deny push |
| Contractors and third-party staff | Same as staff, keys for prod or admin access | Number-matching push | Exclusion groups |
| Frontline and shared devices | Security key or smart card | TOTP hardware token | Shared SMS phone |
| Service accounts | Workload identity, no human MFA | None | User accounts used as service accounts |

Compare vendor support per factor in the [MFA matrix](https://startwithidentity.com/tools/mfa-matrix/) and the [Phishing-Resistant MFA Support Matrix 2026](https://startwithidentity.com/reports/phishing-resistant-mfa-matrix-2026/).

## A sequence that works

1. **Inventory.** Every app that touches sensitive data. Tag each with MFA capability (native, via IdP federation, or none), and list every remote access portal, VPN and vendor-facing login separately.
2. **Phase 1, admin accounts only.** Enforce phishing-resistant MFA (FIDO2 hardware keys such as [Yubico](https://startwithidentity.com/vendors/mfa/yubico/) keys, or [passkeys](https://startwithidentity.com/guides/authentication/passkeys-101/)) on every admin. Two weeks, no exceptions (an estimate for a typical mid-size tenant). Admins are tier zero.
3. **Phase 2, high-risk roles.** Finance, legal, executives and their assistants, and anyone with access to crown-jewel data. Same factor mix as admins.
4. **Phase 3, everyone, with number-matching push.** General population on an authenticator app with number matching and context, never blind approve/deny. Risk-based policy suppresses prompts on trusted devices to reduce fatigue. Bring contractors into the same policy on the same day.
5. **Phase 4, phishing-resistant for everyone.** Move the general population from push to FIDO2 and passkeys over the following year (estimate), with hardware-key issuance and platform-authenticator support.
6. **Phase 5, legacy app cleanup.** Anything that cannot do modern MFA gets federated through the IdP, replaced, or sunset. Legacy and service accounts excluded from MFA are exactly where attackers like [Midnight Blizzard](https://startwithidentity.com/breaches/midnight-blizzard-2024-microsoft/) get in. Move user accounts used for automation to [workload identities](https://startwithidentity.com/glossary/workload-identity-federation/), which Microsoft's enforcement does not cover.

## Failure modes and the incidents behind them

| Failure mode | What happened | Technique | Control |
| --- | --- | --- | --- |
| No MFA on a remote access portal | [Change Healthcare](https://startwithidentity.com/breaches/incidents/2024-change-healthcare-citrix-no-mfa/): compromised credentials on a Citrix portal without MFA, ransomware nine days later | Stolen credentials | Inventory every portal in step 1 |
| No MFA on a SaaS tenant | [Snowflake customer campaign](https://startwithidentity.com/breaches/incidents/2024-snowflake-customer-tenant-campaign/): about 165 customer accounts accessed with infostealer credentials | [Infostealer credential harvesting](https://startwithidentity.com/techniques/infostealer-credential-harvesting/) | Enforce at the IdP, block local login |
| Push approved under pressure | [Uber](https://startwithidentity.com/breaches/incidents/2022-uber-mfa-fatigue/) and [Cisco](https://startwithidentity.com/breaches/incidents/2022-cisco-vishing-mfa-fatigue/) | [MFA fatigue](https://startwithidentity.com/techniques/mfa-fatigue-push-bombing/) | Number matching, then passkeys |
| Codes relayed to a phishing page | [0ktapus](https://startwithidentity.com/breaches/incidents/2022-0ktapus-phishing-campaign/): 5,441 MFA codes captured across more than 130 organizations | [OTP relay](https://startwithidentity.com/techniques/otp-relay-social-engineering/), [AiTM phishing](https://startwithidentity.com/techniques/aitm-phishing-proxy/) | Origin-bound factors |
| Help desk resets the factor | [MGM Resorts](https://startwithidentity.com/breaches/incidents/2023-mgm-resorts-help-desk-ransomware/) | [Help desk social engineering](https://startwithidentity.com/techniques/help-desk-social-engineering/) | Verified recovery (below) |
| Session stolen after MFA | [CircleCI](https://startwithidentity.com/breaches/incidents/2023-circleci-engineer-session-token-theft/): a 2FA-backed SSO cookie stolen by malware | [Session cookie theft](https://startwithidentity.com/techniques/session-cookie-theft/) | Short sessions, device binding |

The last row matters for expectations: MFA protects the login, not the session that follows. Our analysis found that [46.5% of 2025-2026 identity breaches had no login for MFA to protect](https://startwithidentity.com/blog/2026-11-03-half-of-recent-identity-breaches-had-no-login-for-mfa-to-protect/).

## Account recovery and enrollment: the step attackers target

Most real-world MFA bypasses do not break the factor; they exploit weak enrollment and recovery. [Scattered Spider](https://startwithidentity.com/breaches/scattered-spider-helpdesk-social-engineering/) simply called the help desk and asked for a reset. Harden this path:

- Require strong, hard-to-phish proof of identity before any reset, such as manager approval or a video check for sensitive roles.
- Bootstrap new factors with a time-limited credential such as a [Temporary Access Pass](https://startwithidentity.com/glossary/temporary-access-pass/) rather than a reset to SMS.
- Treat MFA re-enrollment as a high-assurance event with logging and alerting, not a casual self-service action.
- Alert on the pattern of a reset immediately followed by a login from a new device or location.

## Vendor requirements

Number-matching push (not just approve/deny), hardware-key and [WebAuthn/FIDO2](https://startwithidentity.com/standards/webauthn-fido2/) support for passwordless step-up, a risk-based policy engine, strong recovery controls, and an audit-log API for the SOC. [Cisco Duo](https://startwithidentity.com/vendors/mfa/duo/), Microsoft Entra and [Okta](https://startwithidentity.com/vendors/iam/okta/) cover the workforce IdP side; compare options in [MFA and passwordless vendors](https://startwithidentity.com/vendors/mfa/), the [best phishing-resistant MFA](https://startwithidentity.com/rankings/best-phishing-resistant-mfa/) ranking and the [how to choose an MFA solution](https://startwithidentity.com/guides/buyer-guides/how-to-choose-an-mfa-solution/) guide.

## Common pitfalls

- SMS as the only second factor; it is phishable and SIM-swappable. Set a retirement date (see [the SMS off-ramp](https://startwithidentity.com/blog/sms-mfa-off-ramp-2027/)).
- Executive exceptions that creep across the org chart.
- Contractor and vendor accounts parked in an MFA exclusion group.
- Enforcing MFA without addressing the legacy and service-account population first.
- Blind-approval push without number matching, which invites fatigue attacks.
- Underestimating help-desk volume and recovery risk during rollout.

## Success metrics

Percent of workforce, including contractors, on phishing-resistant MFA. Percent of apps, portals and service accounts covered. Time-to-recover for a locked-out user. Push approval rates with no fatigue patterns. Zero successful credential phishing in red-team exercises.

## Migrating from AD FS to Microsoft Entra ID
Source: https://startwithidentity.com/guides/implementation/adfs-to-entra-migration/
Last updated: 2026-11-05

Migrating from AD FS to [Microsoft Entra ID](https://startwithidentity.com/vendors/iam/microsoft-entra/) has two separate workstreams: move each application's federation from AD FS to Entra, then convert user authentication for your domains from federated to managed (cloud) authentication. Do them in that order, test both with pilot groups, and decommission AD FS only when sign-in data shows it is idle. This guide is for identity engineers running a hybrid Microsoft estate; every product behavior below is from Microsoft Learn.

## Why migrate off AD FS

Running AD FS means patching federation and Web Application Proxy servers, rotating token-signing certificates, and keeping an on-premises dependency in the critical sign-in path. It is also a high-value target: the token-signing key is what makes every [SAML](https://startwithidentity.com/standards/saml-2-0/) assertion trusted, and whoever holds it can forge sign-ins, the core of [federation trust abuse and SAML forgery](https://startwithidentity.com/techniques/federation-trust-abuse-saml-forgery/). Microsoft's [AD FS security best practices](https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/best-practices-securing-ad-fs) recommend protecting those keys in an HSM and never storing certificates on a network share; its [emergency rotation guide](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-emergency-ad-fs-certificate-rotation) covers what a compromise forces you to do. Token forgery with a stolen signing key is not theoretical, as [Storm-0558](https://startwithidentity.com/breaches/incidents/2023-storm-0558-microsoft-signing-key-forgery/) showed against Microsoft's own consumer key. Moving to Entra removes that key from your estate and enables Conditional Access, ID Protection, and [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/).

## Decide your target sign-in method

Microsoft's [federation-to-cloud migration guide](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/migrate-from-federation-to-cloud-authentication) recommends password hash sync (PHS).

| Option | Use it when | Trade-off |
| --- | --- | --- |
| Password hash sync (PHS) | Default for most organizations | No on-premises dependency at sign-in; enables leaked-credential detection |
| Pass-through authentication (PTA) | Policy requires on-prem password validation at sign-in | Needs agents: two or three suffice for most customers, max 12 per tenant |
| Stay federated (for now) | Nonpersistent VDI on Windows 10 1903 or later | Microsoft says moving to a managed domain is not supported on nonpersistent VDI |

## Before you start: checklist

- [ ] Microsoft Entra Connect installed or upgraded to the latest version (Microsoft says this cuts migration time "from potentially hours to minutes").
- [ ] Current federation settings documented with `Get-MgDomainFederationConfiguration`, especially `PreferredAuthenticationProtocol`, `federatedIdpMfaBehavior`, `SupportsMfa`, and `PromptLoginBehavior`.
- [ ] AD FS backed up (the AD FS Rapid Restore Tool) and the Microsoft 365 relying party trust exported, including custom claim rules.
- [ ] Inventory of every relying party and its protocol: SAML, [WS-Fed](https://startwithidentity.com/glossary/federation/), or [OIDC](https://startwithidentity.com/standards/openid-connect/)/OAuth.
- [ ] AD FS access control policies mapped to Entra [Conditional Access](https://startwithidentity.com/glossary/conditional-access/), authored in report-only mode.
- [ ] A Conditional Access policy to block legacy authentication, which Microsoft recommends because of the risk legacy protocols carry. The [Midnight Blizzard password spray](https://startwithidentity.com/breaches/incidents/2024-microsoft-midnight-blizzard-password-spray/) started at a legacy test account without MFA.
- [ ] Hybrid Identity Administrator role available for staged rollout.
- [ ] Two cloud-only emergency access accounts that do not depend on AD FS.

## Phase 1: Migrate applications

Use the [AD FS application migration](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/migrate-ad-fs-application-howto) dashboard under Usage & insights. It needs Entra ID P1 or P2, Entra Connect, and the Connect Health AD FS agents. It lists relying parties with sign-ins in the last 30 days (filterable to 1, 7, or 30 days) and excludes Microsoft relying parties such as Office 365. Each app gets a status:

| Status | Meaning | Action |
| --- | --- | --- |
| Ready to migrate | Configuration fully supported as-is | One-click migration (SAML only) |
| Needs review | Some settings need review, none are blockers | Migrate, then fix the flagged settings |
| Additional steps required | Entra does not support some settings | Redesign before migrating |

The wizard creates the app registration and service principal, sets the SAML identifier and reply URL, assigns users and synced groups from the AD FS access control policy, and configures compatible claims. It does not migrate the signing certificate, does not create Conditional Access policies, and does not handle OIDC, OAuth, or WS-Fed apps. The new app stays inactive until you redirect sign-in traffic, so rollback is deleting it.

Microsoft's [migration stages](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/migrate-adfs-apps-stages) suggest moving apps on modern protocols first, testing a test instance against a test tenant (optional), then a test instance against production, then the production app. Line-of-business apps on OAuth 2.0, OIDC, or WS-Federation become app registrations; custom SAML or WS-Fed apps become non-gallery enterprise apps. Legacy-protocol apps go behind Application Proxy or a Secure Hybrid Access partner.

### Claim rules: the long tail

The wizard's claim rule tests flag what will not translate. The common blockers: regular expressions in conditions or transformations (replace with functions such as `IfEmpty()`, `StartWith()`, `Contains()`, `Extract()`, `ToLower()`), `ADD` issuance rules (rebuild as multiple transformations), and attribute stores other than Active Directory, which Entra cannot source claims from. Budget time for that tail, plus apps with AD FS endpoints or certificates hardcoded in config.

## Phase 2: Pilot cloud authentication with staged rollout

[Staged rollout](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-staged-rollout) moves selected users to PHS or PTA (plus Kerberos-based desktop SSO via the AZUREADSSO computer account) while the domain stays federated. Limits that trip teams up:

- Maximum 10 groups per feature; nested and dynamic groups are not supported; use cloud security groups to avoid sync latency.
- A newly added group is limited to 200 users to avoid a UI time-out; add more afterward. Membership edits can take up to 24 hours.
- Only synced users, browser and modern-auth clients; legacy-auth apps fall back to federation, and apps that send `domain_hint` keep using federation.
- Newly added users need one more federated sign-in before managed auth applies; Microsoft's workaround is a Temporary Access Pass for the first sign-in.

## Phase 3: Convert domains and harden MFA

Convert one domain at a time, starting with a test domain or the one with fewest users, using Entra Connect (if it configured AD FS originally) or `Update-MgDomain -DomainId <domain> -AuthenticationType "Managed"`. Allow up to 60 minutes for the change. Rollback is `New-MgDomainFederationConfiguration` with your documented settings.

While any domain stays federated, set `federatedIdpMfaBehavior` to `rejectMfaByFederatedIdp` unless you rely on a third-party MFA provider at the federation server. If neither it nor `SupportsMfa` is set, Entra defaults to accepting MFA claims from the federated IdP, which lets anyone who can impersonate that IdP claim MFA was done. After cutover, roll over the Kerberos decryption key of the AZUREADSSO computer account at least every 30 days; it is manual.

## Phase 4: Decommission

Use Connect Health usage data to confirm no new authentication requests reach AD FS and all users sign in through Entra, then remove the Microsoft 365 relying party trust. If no other relying parties remain, follow Microsoft's AD FS decommission guide.

## Common failure modes

| Failure | Cause | Prevention |
| --- | --- | --- |
| Logins break at cutover | Domain converted before relying parties moved | App phase first, sign-in logs before conversion |
| Users surprised by MFA | Conditional Access never ran in report-only | Report-only for a full business cycle |
| PTA outage | Domain converted with inactive agents | Confirm agent status Active first |
| App missing from dashboard | No sign-ins in 30 days, or a Microsoft RP | Cross-check the full AD FS relying party list |
| MFA bypass via federation | Default `acceptIfMfaDoneByFederatedIdp` | Set `rejectMfaByFederatedIdp` |
| Permanent hybrid | Staged rollout left running | Treat it as temporary; schedule the domain cutover |

## Related

Guides: [IAM cloud migration](https://startwithidentity.com/guides/implementation/iam-cloud-migration-guide/), [conditional access policies](https://startwithidentity.com/guides/implementation/conditional-access-policies-guide/), [SAML vs OIDC](https://startwithidentity.com/guides/fundamentals/saml-vs-oidc/). Techniques: [federation trust abuse and SAML forgery](https://startwithidentity.com/techniques/federation-trust-abuse-saml-forgery/), [password spraying](https://startwithidentity.com/techniques/password-spraying/). Standards: [SAML 2.0](https://startwithidentity.com/standards/saml-2-0/), [OpenID Connect](https://startwithidentity.com/standards/openid-connect/). Glossary: [federation](https://startwithidentity.com/glossary/federation/), [conditional access](https://startwithidentity.com/glossary/conditional-access/).

## Multi-Cloud IAM Strategy Guide: Unified Identity Across AWS, Azure, and GCP
Source: https://startwithidentity.com/guides/implementation/multi-cloud-iam-strategy-guide/
Last updated: 2026-11-05

Most enterprises today operate across multiple cloud providers. Whether by strategic choice, acquisition, or organic growth, the reality is that your workloads, data, and users span AWS, Azure, GCP, and often several SaaS platforms. Each cloud provider has its own IAM model, its own terminology, its own permission boundaries, and its own approach to identity.

This fragmentation creates real risk. An employee might have admin access in AWS but read-only in Azure, or the reverse, and nobody has a unified view. Service accounts proliferate in each cloud without centralized oversight. Offboarding an employee means remembering to revoke access in three separate consoles. Audit evidence requires pulling reports from three different systems and correlating them manually.

A multi-cloud IAM strategy addresses this by establishing a single identity plane that federates into each cloud provider, unified governance that spans all environments, and consistent security policies regardless of where workloads run.

## Prerequisites

- **A central Identity Provider**, Microsoft Entra ID, Okta, or Ping Identity serving as your identity hub.
- **Accounts/subscriptions/projects** in two or more cloud providers.
- **Basic familiarity** with IAM concepts in AWS (IAM, Organizations, SSO), Azure (Entra ID, RBAC, subscriptions), and GCP (IAM, projects, organizations).
- **Organizational commitment** to a unified approach rather than cloud-team silos managing identity independently.

## Architecture: The Multi-Cloud Identity Model

### The Hub-and-Spoke Pattern

The most effective multi-cloud IAM architecture uses a hub-and-spoke model:

```
Central Identity Provider (Hub)
  ├── SAML/OIDC Federation → AWS IAM Identity Center
  ├── Native Integration → Azure (Entra ID is often the hub itself)
  ├── SAML/OIDC Federation → GCP Cloud Identity / Workforce Identity
  ├── SAML/OIDC Federation → SaaS Applications
  └── SCIM Provisioning → Each cloud's user directory
```

The central IdP is the single source of truth for human identity. Users authenticate once and receive federated access to whichever cloud provider they need. No cloud-local passwords, no separate MFA enrollment per cloud, no duplicate identity management.

### Comparing Cloud IAM Models

| Concept | AWS | Azure | GCP |
|---|---|---|---|
| Identity source | IAM Identity Center, IAM users | Entra ID | Cloud Identity, Workforce Identity Federation |
| Permission model | IAM policies (JSON) | Azure RBAC (role assignments) | IAM policies (role bindings) |
| Permission boundary | AWS account | Subscription / Resource group | Project / Folder |
| Service identity | IAM roles (for services) | Managed Identities | Service accounts |
| Privilege escalation risk | Inline policies, wildcard actions | Owner role, custom role creation | Primitive roles, setIamPolicy |
| MFA | IAM MFA, Identity Center MFA | Entra conditional access | Cloud Identity MFA settings |
| Audit logging | CloudTrail | Activity Log, Sign-in logs | Cloud Audit Logs |

### Federation Architecture Deep Dive

**AWS IAM Identity Center (formerly AWS SSO):**

```
Central IdP → SAML 2.0 → AWS IAM Identity Center
                              ↓
                    Permission Sets (mapped to IdP groups)
                              ↓
                    AWS Accounts (via AWS Organizations)
```

Permission sets define what users can do in each AWS account. Map IdP groups to permission sets and accounts to create your access model.

**Azure (when Entra ID is not the hub):**

If your central IdP is Okta or Ping, federate into Entra ID:

```
Central IdP → SAML/OIDC → Entra ID (External Identity)
                              ↓
                    Azure RBAC Role Assignments
                              ↓
                    Subscriptions / Resource Groups
```

**GCP Workforce Identity Federation:**

```
Central IdP → OIDC → Workforce Identity Pool
                          ↓
                    IAM Role Bindings (with principal identifiers)
                          ↓
                    GCP Projects / Folders / Organization
```

## Step-by-Step Implementation

### Step 1: Establish Your Central Identity Provider

If you do not already have a single IdP, choose one and migrate all human identity management to it. The three common choices:

**Microsoft Entra ID**, Natural choice if you are a Microsoft shop. Native integration with Azure, strong SAML/OIDC federation for AWS and GCP.

**Okta**, Cloud-native, strong federation support for all three providers, good SCIM provisioning.

**Ping Identity**, Strong enterprise features, good for complex hybrid environments.

Regardless of your choice, the central IdP must:
- Be the authoritative source for group membership
- Enforce MFA policies consistently
- Support SAML 2.0 and OIDC for federation
- Support SCIM for automated provisioning
- Provide complete audit logging

### Step 2: Federate Into Each Cloud Provider

**AWS Federation via IAM Identity Center:**

1. In the AWS Management Console, navigate to IAM Identity Center.
2. Choose "External identity provider" as the identity source.
3. Configure SAML federation with your central IdP:
   - Upload IdP metadata (or enter issuer URL and certificate).
   - Download the AWS SAML metadata and register it in your IdP.
4. Enable automatic provisioning (SCIM) to sync users and groups.
5. Create permission sets that map to your access model.
6. Assign IdP groups to permission sets and AWS accounts.

**Azure Federation (if not using Entra as hub):**

1. Configure your IdP as an external identity provider in Entra ID.
2. Set up B2B direct connect or cross-tenant access settings.
3. Map external groups to Azure RBAC roles on subscriptions and resource groups.

**GCP Federation via Workforce Identity:**

1. Create a Workforce Identity Pool in GCP.
2. Configure an OIDC provider pointing to your central IdP.
3. Map IdP attributes (groups, email) to GCP principal identifiers.
4. Bind IAM roles to workforce identity principals:

```bash
gcloud projects add-iam-policy-binding my-project \
  --member="principalSet://iam.googleapis.com/locations/global/workforcePools/my-pool/group/developers" \
  --role="roles/viewer"
```

### Step 3: Design a Unified Permission Model

Each cloud uses different terminology and structures for permissions. Create an abstraction layer that maps your organizational roles to cloud-specific permissions:

```yaml
organizational_role: "Platform Engineer"
description: "Engineers who build and maintain cloud infrastructure"
cloud_permissions:
  aws:
    permission_set: "PlatformEngineer"
    accounts: ["infrastructure-prod", "infrastructure-staging"]
    policies:
      - arn:aws:iam::aws:policy/PowerUserAccess
      - custom:DenyBillingAccess
  azure:
    role: "Contributor"
    scope: "/subscriptions/infra-sub/resourceGroups/platform-rg"
    deny_assignments:
      - "Microsoft.Authorization/roleAssignments/write"
  gcp:
    role: "roles/editor"
    projects: ["infra-prod", "infra-staging"]
    deny_policies:
      - "iam.serviceAccounts.actAs"

organizational_role: "Security Analyst"
description: "Security team members who monitor and investigate"
cloud_permissions:
  aws:
    permission_set: "SecurityAnalyst"
    accounts: ["ALL"]  # read access to all accounts
    policies:
      - arn:aws:iam::aws:policy/SecurityAudit
      - arn:aws:iam::aws:policy/ReadOnlyAccess
  azure:
    role: "Security Reader"
    scope: "/subscriptions/*"  # all subscriptions
  gcp:
    role: "roles/iam.securityReviewer"
    resource: "organizations/123456"  # org-wide
```

### Step 4: Manage Service and Workload Identities

Human identity federation is the easier problem. Service and workload identities across clouds are harder because each cloud handles them differently.

**Principles for multi-cloud workload identity:**

1. **No long-lived credentials**, Use workload identity federation (AWS IRSA/Pod Identity, Azure Managed Identity, GCP Workload Identity) instead of access keys.
2. **Cross-cloud access via federation**, When a workload in AWS needs to access a GCP resource, use OIDC federation rather than embedding GCP service account keys in AWS.
3. **Centralized inventory**, Maintain a single registry of all service/workload identities across all clouds, including their permissions and owners.

**Cross-cloud workload identity example (AWS to GCP):**

```
AWS EKS Pod → IRSA (get AWS credentials)
    ↓
AWS STS → AssumeRoleWithWebIdentity
    ↓
GCP Workload Identity Pool (trusts AWS STS as token issuer)
    ↓
GCP IAM role binding → GCP resource access
```

This allows an application running in AWS to access GCP resources using short-lived, automatically rotated credentials without storing any secrets.

### Step 5: Implement Unified Governance

**Centralized access reviews:**

Your IGA platform should review access across all cloud providers in a single certification campaign. The reviewer should see "User X has these permissions in AWS, these in Azure, and these in GCP", not three separate certification campaigns.

**Unified audit and compliance:**

Aggregate cloud audit logs into a single SIEM or security data lake:

```
AWS CloudTrail → S3 → Log Aggregation Pipeline
Azure Activity Logs → Event Hub → Log Aggregation Pipeline  → SIEM
GCP Audit Logs → Pub/Sub → Log Aggregation Pipeline
```

Create cross-cloud correlation alerts:
- "User was deprovisioned in the central IdP but still has active sessions in AWS."
- "Service account in GCP was granted admin permissions but has no corresponding change ticket."
- "Privileged access was used in Azure outside of the PIM activation window."

**Cross-cloud SoD rules:**

Define segregation of duties that span clouds:
- A developer with deploy access in AWS should not also have deploy access in the disaster recovery GCP environment.
- A user with billing access in one cloud should not have billing access in another (unless explicitly approved).

### Step 6: Automate with Infrastructure as Code

Manage IAM configuration across all clouds using IaC:

**Terraform example (multi-cloud IAM):**

```hcl
# AWS Permission Set
resource "aws_ssoadmin_permission_set" "platform_engineer" {
  name             = "PlatformEngineer"
  instance_arn     = aws_ssoadmin_instance.main.arn
  session_duration = "PT4H"
}

# Azure Role Assignment
resource "azurerm_role_assignment" "platform_engineer" {
  scope                = azurerm_resource_group.platform.id
  role_definition_name = "Contributor"
  principal_id         = azuread_group.platform_engineers.object_id
}

# GCP IAM Binding
resource "google_project_iam_binding" "platform_engineer" {
  project = "infra-prod"
  role    = "roles/editor"
  members = [
    "principalSet://iam.googleapis.com/locations/global/workforcePools/main/group/platform-engineers",
  ]
}
```

Store all IAM configuration in Git with mandatory pull request reviews. No manual IAM changes in any cloud console.

## Best Practices

### Establish a Cloud IAM Center of Excellence

Do not let each cloud team manage IAM independently. Establish a cross-cloud IAM team or CoE that owns the federated identity architecture, permission model standards, and governance processes across all cloud providers.

### Normalize Permission Levels

Create an organizational permission taxonomy that maps consistently across clouds:
- **Read-only** = AWS ReadOnlyAccess / Azure Reader / GCP Viewer
- **Operator** = AWS specific service permissions / Azure Contributor (scoped) / GCP Editor (scoped)
- **Admin** = AWS AdministratorAccess (scoped) / Azure Owner (scoped) / GCP Owner (scoped)
- **Billing** = AWS Billing / Azure Billing Reader / GCP Billing Account Viewer

### Monitor for Drift

IAM configurations drift when someone makes a manual change in a cloud console that is not reflected in your IaC. Use drift detection tools (Cloud Custodian, Cortex Cloud (formerly Prisma Cloud), custom scripts) to detect and alert on IAM changes made outside of your automation pipeline.

### Implement Break-Glass Per Cloud

Each cloud needs its own break-glass mechanism that does not depend on federation:
- **AWS:** IAM user with MFA in the management account (not federated)
- **Azure:** Break-glass Entra ID accounts (cloud-only, excluded from conditional access)
- **GCP:** Super admin account in Cloud Identity (not federated)

## Testing

1. **Federation testing**, Verify that SAML/OIDC authentication works correctly for each cloud. Test with users in different groups to verify permission mapping.
2. **Deprovisioning testing**, Disable a test user in the central IdP and verify that access is revoked in all three clouds within your target time window.
3. **Cross-cloud access testing**, Test workload identity federation between clouds (e.g., AWS pod accessing GCP bucket).
4. **Audit trail testing**, Perform sensitive actions in each cloud and verify they appear in your centralized SIEM with correct user attribution.

## Common Pitfalls

### Managing Identity Per Cloud

The biggest anti-pattern is treating each cloud's IAM as a separate system. This leads to inconsistent permissions, duplicated effort, and gaps in governance. Even if federation is not perfect, it is always better than independent identity management per cloud.

### Ignoring Cloud-Specific Nuances

While you should unify governance, you cannot ignore the differences in how each cloud handles IAM. AWS IAM policies are JSON documents with explicit deny semantics. Azure RBAC uses role definitions and scope hierarchies. GCP IAM uses allow policies at the resource level. Your unified model must account for these differences, not paper over them.

### Overcomplicating the Permission Model

The temptation with multi-cloud is to create an elaborate abstraction that covers every possible scenario. Start simple: 3-5 organizational roles mapped to each cloud. Add complexity only when real-world requirements demand it.

### Not Accounting for Latency in Federation

Federated authentication adds latency compared to cloud-native authentication. For time-sensitive workloads (CI/CD pipelines, automated deployments), ensure your federation setup does not create bottlenecks. Use cached tokens and workload identity federation for automated processes.

## Conclusion

Multi-cloud IAM is not about choosing the lowest common denominator across cloud providers. It is about establishing a unified identity plane that uses each cloud's strengths while maintaining consistent governance, visibility, and security. The hub-and-spoke federation model, combined with Infrastructure as Code and centralized governance, gives you control without sacrificing the flexibility that multi-cloud provides.

Start by federating human identity through a single IdP, then address workload identity with federation rather than static credentials, and finally implement unified governance with cross-cloud certification campaigns and audit correlation. The investment in multi-cloud IAM coherence pays dividends in security, compliance, and operational efficiency.

## Non-Human Identity (NHI) Security: The 2026 Guide
Source: https://startwithidentity.com/guides/machine-identity/non-human-identity-security/
Last updated: 2026-10-31

For twenty years, identity security was built around people. But the identities that log in, hold permissions, and move data today are mostly not people. They are service accounts, API keys, OAuth apps, certificates, workloads, bots, and now AI agents. Collectively these are non-human identities (NHIs), and they have become the fastest-growing and least-governed part of the attack surface.

## The scale of the problem

Non-human identities now outnumber humans dramatically. Palo Alto Networks' 2026 Identity Security Landscape counts 109 machine identities per human, AI agents included, up from the more than 80 to 1 CyberArk reported a year earlier. The growth is compounding as organizations adopt more SaaS, more automation, and more AI.

The governance has not kept pace. In the Cloud Security Alliance's State of Non-Human Identity and AI Security research, only a small minority of organizations feel confident in their ability to prevent NHI-based attacks, and a meaningful share do not even track the creation of AI-related identities. The result is a large population of powerful accounts that no one clearly owns.

For the sourced numbers, see our [research page](https://startwithidentity.com/research/) and the [secrets sprawl data](https://startwithidentity.com/research/).

## What counts as a non-human identity

NHIs are not one thing. The common types, each with a different lifecycle and risk profile:

- **Service accounts** used by applications and automation. Often long-lived and over-privileged. See [securing service accounts](https://startwithidentity.com/articles/securing-service-accounts-best-practices/).
- **API keys and tokens** that authenticate one service to another, and leak easily into code and logs.
- **OAuth apps and third-party integrations** granted broad scopes into your SaaS, a fast-growing and often invisible category.
- **Certificates and cryptographic keys** that identify machines and workloads. See [certificate lifecycle management](https://startwithidentity.com/guides/machine-identity/certificate-lifecycle-management-guide/).
- **Workloads** (containers, functions, VMs) that need runtime identity. See [workload identity 101](https://startwithidentity.com/guides/machine-identity/workload-identity-101/).
- **Bots and RPA** that automate business processes with standing credentials.
- **AI agents** that act autonomously on a user's behalf, the newest and most dynamic category.

## The pain points

Five problems recur across almost every NHI program:

1. **Sprawl and no inventory.** You cannot govern what you cannot see, and most organizations have no complete inventory of their NHIs across cloud, SaaS, and on-premises.
2. **Over-privilege and standing access.** NHIs are typically granted broad permissions that never expire, so a single leaked credential can reach far.
3. **No ownership.** When no person owns an NHI, no one rotates its secret, reviews its access, or decommissions it when the workload is gone.
4. **Secret leakage.** Keys and tokens end up in source code, CI logs, and config files. Leaked secrets are a leading root cause of cloud breaches, and many stay valid long after exposure.
5. **No lifecycle.** Human identities have joiner-mover-leaver processes. Most NHIs have none, so orphaned accounts accumulate indefinitely.

## Use cases: where NHI security pays off

- **Cloud and Kubernetes.** Replacing long-lived keys with short-lived, workload-bound credentials. See the [Kubernetes identity security guide](https://startwithidentity.com/guides/machine-identity/kubernetes-identity-security-guide/).
- **CI/CD pipelines.** Removing static secrets from build systems in favor of just-in-time, scoped credentials.
- **SaaS-to-SaaS integrations.** Discovering and right-sizing the OAuth apps connected to your Google, Microsoft, and Salesforce tenants.
- **Third-party and vendor access.** Governing the machine credentials partners use into your systems.
- **AI agents.** Giving autonomous agents scoped, delegated, revocable identities instead of shared service accounts.

## How to secure non-human identities

A practical program runs in this order:

1. **Discover and inventory.** Find every NHI across environments and map what each can access.
2. **Assign ownership.** Every NHI gets a human or team accountable for it.
3. **Right-size access.** Remove standing privileges, apply least privilege, and prefer just-in-time access. See [just-in-time access tools](https://startwithidentity.com/articles/top-5-just-in-time-access-tools/).
4. **Move to short-lived credentials.** Replace static keys with rotating secrets and workload identity wherever possible. Vault and rotate the rest with [secrets management](https://startwithidentity.com/guides/fundamentals/what-is-secrets-management/) and the [top secrets tools](https://startwithidentity.com/articles/top-8-secrets-management-tools/).
5. **Monitor behavior.** Detect anomalous NHI activity, the same way you watch human accounts, with [identity threat detection](https://startwithidentity.com/guides/fundamentals/what-is-itdr/).
6. **Govern the lifecycle.** Certify NHI access periodically and decommission accounts when the workload ends.

## The vendor landscape

The tooling spans several categories. [Secrets management](https://startwithidentity.com/vendors/secrets/) platforms vault and rotate credentials; [machine identity](https://startwithidentity.com/vendors/machine-identity/) and workload identity tools (including the [SPIFFE/SPIRE](https://startwithidentity.com/glossary/spiffe/) standard) handle the cryptographic layer; and a newer category of NHI governance and posture management focuses specifically on discovery, ownership, and least privilege for non-human identities. Consolidation is rapid: traditional IAM, PAM, and IGA vendors are racing to add NHI capabilities, and 2026 has already seen major acquisitions in the space, tracked deal by deal in the [Identity Consolidation Report 2026](https://startwithidentity.com/reports/identity-consolidation-report-2026/).

For a scored shortlist, see [best machine identity for enterprises](https://startwithidentity.com/rankings/best-machine-identity-for-enterprises/) and the [top machine identity management platforms](https://startwithidentity.com/articles/top-5-machine-identity-management-platforms/).

## The bottom line

Non-human identities are now the majority of your identities and the softest part of your attack surface. The organizations that get ahead of this treat NHIs as first-class identities: discovered, owned, least-privileged, short-lived, monitored, and governed for their whole lifecycle. Start with discovery, because everything else depends on knowing what you have. Then read our companion guide on the fastest-moving corner of this problem, [securing AI agent identities](https://startwithidentity.com/guides/machine-identity/securing-ai-agent-identities/).

## OAuth 2.0 and OpenID Connect Implementation Guide
Source: https://startwithidentity.com/guides/implementation/oauth-2-openid-connect-implementation/
Last updated: 2026-11-05

OAuth 2.0 and OpenID Connect (OIDC) are the foundational protocols for modern authorization and authentication on the web. OAuth 2.0 handles authorization, granting an application limited access to a user's resources. OIDC is a layer on top of OAuth 2.0 that adds authentication, verifying the user's identity and providing profile information.

Despite their ubiquity, these protocols are frequently implemented incorrectly. Misconfigurations lead to token leakage, privilege escalation, and account takeover. This guide provides a rigorous, implementation-focused walkthrough so you can deploy OAuth 2.0 and OIDC correctly from the start.

## What You Will Learn

- The OAuth 2.0 authorization flows and when to use each one
- How OIDC extends OAuth 2.0 for authentication
- Implementing the Authorization Code Flow with PKCE
- Token lifecycle management (access tokens, refresh tokens, ID tokens)
- Scope and permission design for APIs
- Securing your authorization server and resource servers

## Prerequisites

1. **TLS everywhere.** OAuth 2.0 security depends on transport-layer security. Every endpoint must be served over HTTPS.
2. **Authorization server.** You need an OAuth 2.0/OIDC-compliant authorization server. This can be a cloud IdP (Okta, Auth0, Microsoft Entra ID), a self-hosted server (Keycloak, IdentityServer), or a custom implementation.
3. **Understanding of HTTP.** OAuth relies on HTTP redirects, POST requests, and headers. Familiarity with HTTP fundamentals is assumed.
4. **Client application.** A web app, mobile app, or SPA where you want to add authentication and/or API authorization.
5. **API or resource server.** The backend API that the client will access using OAuth tokens.

## Architecture Overview

The OAuth 2.0/OIDC architecture involves four roles:

- **Resource Owner:** The user who owns the data and grants access.
- **Client:** The application requesting access (your web app, mobile app, or SPA).
- **Authorization Server (AS):** Issues tokens after authenticating the user and obtaining consent. In OIDC, this is also the OpenID Provider (OP).
- **Resource Server (RS):** The API that accepts access tokens and serves protected resources.

**Key endpoints on the Authorization Server:**

- `/authorize`, User-facing endpoint for authentication and consent (browser redirect).
- `/token`, Backend endpoint for exchanging authorization codes for tokens.
- `/userinfo`, Returns user profile claims (OIDC).
- `/.well-known/openid-configuration`, Discovery document with all endpoint URLs and supported features. Plain OAuth servers publish the same information as [Authorization Server Metadata](https://startwithidentity.com/glossary/authorization-server-metadata/) (RFC 8414).

**Token types:**

- **Access Token:** Short-lived token that grants access to a resource server. Can be opaque or a JWT.
- **Refresh Token:** Long-lived token used to obtain new access tokens without re-authenticating.
- **ID Token:** A JWT specific to OIDC that contains user identity claims (sub, name, email). Consumed by the client, not the resource server.

## Step-by-Step Implementation

### Step 1: Choose the Right Flow

OAuth 2.0 defines several authorization flows. Choosing the wrong one is a common source of vulnerabilities.

**Authorization Code Flow with PKCE**, Use this for everything.
- Web applications (server-rendered and SPAs)
- Mobile applications
- Desktop applications
- Machine-to-machine (use Client Credentials instead, see below)

The authorization code flow with PKCE is the recommended flow for all interactive clients. The implicit flow is deprecated and should never be used for new implementations.

**Client Credentials Flow**, Use for machine-to-machine.
- Backend services calling APIs
- Cron jobs, daemons, microservices
- No user involvement

```
Flow Decision Tree:
1. Is a user involved?
   YES -> Authorization Code Flow with PKCE
   NO  -> Client Credentials Flow
```

### Step 2: Register the Client

Register your application with the authorization server:

```json
{
  "client_name": "My Web Application",
  "client_type": "confidential",
  "redirect_uris": [
    "https://myapp.example.com/auth/callback"
  ],
  "post_logout_redirect_uris": [
    "https://myapp.example.com/"
  ],
  "grant_types": ["authorization_code", "refresh_token"],
  "response_types": ["code"],
  "scope": "openid profile email",
  "token_endpoint_auth_method": "client_secret_basic"
}
```

Key decisions:
- **Confidential vs. public client:** Server-side web apps are confidential (they can securely store a `client_secret`). SPAs and mobile apps are public (they cannot). Public clients must use PKCE and should not receive a `client_secret`.
- **Redirect URIs:** Register exact URIs. Never use wildcards. Include all environments (development, staging, production) as separate registrations.
- **Token endpoint authentication:** Confidential clients should use `client_secret_basic` (HTTP Basic Auth) or, for higher security, `private_key_jwt` (JWT bearer assertion). Public clients use `none` (no authentication) with PKCE.

### Step 3: Implement Authorization Code Flow with PKCE

PKCE (Proof Key for Code Exchange) protects against authorization code interception. It is required for public clients and recommended for all clients.

**3a. Generate PKCE parameters:**

```javascript
// Generate code_verifier: a random 43-128 character string
const codeVerifier = generateSecureRandom(64).toString('base64url');

// Generate code_challenge: SHA-256 hash of the verifier
const codeChallenge = crypto
  .createHash('sha256')
  .update(codeVerifier)
  .digest('base64url');

// Store code_verifier in session (server-side) or sessionStorage (SPA)
session.codeVerifier = codeVerifier;
```

**3b. Build the authorization URL:**

```javascript
const authUrl = new URL('https://auth.example.com/authorize');
authUrl.searchParams.set('response_type', 'code');
authUrl.searchParams.set('client_id', CLIENT_ID);
authUrl.searchParams.set('redirect_uri', 'https://myapp.example.com/auth/callback');
authUrl.searchParams.set('scope', 'openid profile email');
authUrl.searchParams.set('state', generateSecureRandom(32).toString('hex'));
authUrl.searchParams.set('nonce', generateSecureRandom(32).toString('hex'));
authUrl.searchParams.set('code_challenge', codeChallenge);
authUrl.searchParams.set('code_challenge_method', 'S256');

// Redirect the user's browser to authUrl
res.redirect(authUrl.toString());
```

- `state`: CSRF protection. Store it in the session and verify it when the callback arrives.
- `nonce`: Replay protection for the ID token. Include it in the authorization request and verify it appears in the returned ID token.

**3c. Handle the callback:**

```javascript
app.get('/auth/callback', async (req, res) => {
  const { code, state, error } = req.query;

  // Verify state matches
  if (state !== req.session.state) {
    return res.status(403).send('CSRF detected');
  }

  if (error) {
    return res.status(400).send(`Authorization error: ${error}`);
  }

  // Exchange code for tokens
  const tokenResponse = await fetch('https://auth.example.com/token', {
    method: 'POST',
    headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
    body: new URLSearchParams({
      grant_type: 'authorization_code',
      code: code,
      redirect_uri: 'https://myapp.example.com/auth/callback',
      client_id: CLIENT_ID,
      client_secret: CLIENT_SECRET,  // Only for confidential clients
      code_verifier: req.session.codeVerifier
    })
  });

  const tokens = await tokenResponse.json();
  // tokens contains: access_token, refresh_token, id_token, expires_in

  // Validate the ID token
  const idTokenClaims = await validateIdToken(tokens.id_token, {
    issuer: 'https://auth.example.com',
    audience: CLIENT_ID,
    nonce: req.session.nonce
  });

  // Create application session
  req.session.user = {
    sub: idTokenClaims.sub,
    email: idTokenClaims.email,
    name: idTokenClaims.name
  };
  req.session.accessToken = tokens.access_token;
  req.session.refreshToken = tokens.refresh_token;

  res.redirect('/dashboard');
});
```

### Step 4: Implement Token Management

**Access token usage:**

```javascript
// Call the resource server with the access token
const apiResponse = await fetch('https://api.example.com/data', {
  headers: {
    'Authorization': `Bearer ${session.accessToken}`
  }
});

if (apiResponse.status === 401) {
  // Token expired, use refresh token
  await refreshAccessToken(session);
  // Retry the request
}
```

**Refresh token rotation:**

```javascript
async function refreshAccessToken(session) {
  const response = await fetch('https://auth.example.com/token', {
    method: 'POST',
    headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
    body: new URLSearchParams({
      grant_type: 'refresh_token',
      refresh_token: session.refreshToken,
      client_id: CLIENT_ID,
      client_secret: CLIENT_SECRET
    })
  });

  const tokens = await response.json();

  // IMPORTANT: Always store the new refresh token (rotation)
  session.accessToken = tokens.access_token;
  if (tokens.refresh_token) {
    session.refreshToken = tokens.refresh_token;  // Rotated refresh token
  }
}
```

Always enable refresh token rotation on the authorization server. With rotation, each refresh token can only be used once. If a stolen refresh token is replayed, the authorization server detects the reuse and revokes the entire token family.

### Step 5: Design Scopes and Permissions

Scopes define what the client can do with the access token. Design them carefully:

```
# OIDC standard scopes
openid        - Required for OIDC. Returns sub claim.
profile       - name, family_name, given_name, etc.
email         - email, email_verified

# Custom API scopes
read:orders   - Read order data
write:orders  - Create/update orders
delete:orders - Delete orders
admin:users   - Manage user accounts
```

Best practices for scope design:
- Use resource-specific scopes (`read:orders`) rather than broad scopes (`read:all`).
- Follow the `action:resource` naming convention.
- Minimize the scopes your client requests. Request only what the current session needs.
- Use fine-grained scopes for sensitive operations and coarse-grained scopes for common operations.
- When one authorization server fronts several APIs, send [Resource Indicators](https://startwithidentity.com/glossary/resource-indicators/) (RFC 8707) so each token is audience-restricted to the API that will receive it.

### Step 6: Protect the Resource Server

The resource server must validate the access token on every request. If clients discover your API at runtime, as MCP clients do, also publish [Protected Resource Metadata](https://startwithidentity.com/glossary/protected-resource-metadata/) (RFC 9728) so they can find which authorization server issues its tokens.

```javascript
// Resource server middleware
async function validateToken(req, res, next) {
  const authHeader = req.headers.authorization;
  if (!authHeader?.startsWith('Bearer ')) {
    return res.status(401).json({ error: 'missing_token' });
  }

  const token = authHeader.substring(7);

  try {
    // For JWT access tokens: validate locally
    const claims = await verifyJwt(token, {
      issuer: 'https://auth.example.com',
      audience: 'https://api.example.com',
      algorithms: ['RS256']
    });

    // Check scopes
    const tokenScopes = claims.scope?.split(' ') || [];
    req.tokenScopes = tokenScopes;
    req.userId = claims.sub;

    next();
  } catch (err) {
    return res.status(401).json({ error: 'invalid_token' });
  }
}

// Scope enforcement per route
function requireScope(scope) {
  return (req, res, next) => {
    if (!req.tokenScopes.includes(scope)) {
      return res.status(403).json({ error: 'insufficient_scope' });
    }
    next();
  };
}

app.get('/api/orders', validateToken, requireScope('read:orders'), getOrders);
app.post('/api/orders', validateToken, requireScope('write:orders'), createOrder);
```

For opaque access tokens, the resource server must call the authorization server's [token introspection](https://startwithidentity.com/glossary/token-introspection/) endpoint (`/introspect`, RFC 7662) to validate the token. This adds latency but allows the AS to revoke tokens immediately.

### Step 7: Implement Client Credentials Flow

For machine-to-machine communication:

```javascript
async function getM2MToken() {
  const response = await fetch('https://auth.example.com/token', {
    method: 'POST',
    headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
    body: new URLSearchParams({
      grant_type: 'client_credentials',
      client_id: SERVICE_CLIENT_ID,
      client_secret: SERVICE_CLIENT_SECRET,
      scope: 'read:orders'
    })
  });

  const { access_token, expires_in } = await response.json();

  // Cache the token until near expiry
  tokenCache.set('orders-api', access_token, expires_in - 60);

  return access_token;
}
```

## Configuration Best Practices

- **Short access token lifetimes.** 5-15 minutes for user-facing flows, 30-60 minutes for machine-to-machine. Short lifetimes limit the damage window from a stolen token.
- **Refresh token rotation.** Enable it always. Detect and revoke on reuse.
- **Sender-constrained tokens.** Where possible, use DPoP (Demonstration of Proof-of-Possession) to bind tokens to the client's key pair, preventing token theft.
- **Exact redirect URI matching.** Never allow partial matching, wildcards, or open redirectors in redirect URIs.
- **JWKS key rotation.** Rotate the authorization server's signing keys periodically. Publish both old and new keys in JWKS during the rotation window.
- **Token revocation endpoint.** Implement and expose `/revoke` so clients can explicitly revoke tokens on logout.

## Testing and Validation

1. **Happy path testing:** Complete the full flow from authorization to token exchange to API call. Verify all token claims are correct.
2. **PKCE validation:** Attempt to exchange an authorization code without the correct `code_verifier`. The AS must reject the request.
3. **State validation:** Tamper with the `state` parameter in the callback. The client must reject the response.
4. **Token expiry:** Wait for the access token to expire. Verify the refresh token flow works and the client retries the API call.
5. **Scope enforcement:** Request a token with `read:orders` scope and attempt a write operation. The resource server must return 403.
6. **Redirect URI validation:** Attempt authorization with an unregistered redirect URI. The AS must reject the request.
7. **CSRF testing:** Attempt to initiate an authorization flow without a state parameter and verify it is rejected.

## Common Pitfalls and Troubleshooting

| Problem | Cause | Solution |
|---------|-------|----------|
| "Invalid redirect_uri" error | URI mismatch between client registration and request | Ensure exact match including trailing slashes and port numbers |
| ID token validation fails | Clock skew or wrong issuer | Sync server clocks; verify issuer matches exactly |
| Refresh token rejected | Refresh token rotation detected reuse | The token family has been revoked; user must re-authenticate |
| "Invalid grant" on code exchange | Code already used or expired | Authorization codes are single-use and short-lived (typically 60 seconds) |
| CORS errors on token endpoint (SPA) | Authorization server does not allow CORS from SPA origin | Configure CORS headers on the AS, or use a backend-for-frontend proxy |
| Token too large for headers | JWT contains too many claims | Move claims to the userinfo endpoint; keep the token lean |

## Security Considerations

1. **Never expose tokens in URLs.** Do not include access tokens in query parameters. Use the Authorization header for API calls and POST body for token exchange.
2. **Validate all tokens server-side.** Never trust a token solely based on client-side validation. The resource server must verify the signature, issuer, audience, and expiry.
3. **Use the nonce claim.** For OIDC flows, include a nonce in the authorization request and verify it in the ID token to prevent replay attacks.
4. **Protect the client secret.** For confidential clients, the client secret is as sensitive as a password. Store it in a secrets manager, not in source code.
5. **Implement token revocation on logout.** When a user logs out, revoke both the access token and the refresh token at the authorization server.
6. **Watch for open redirector attacks.** If your application has open redirect vulnerabilities, an attacker can steal authorization codes by manipulating the redirect flow. Validate all redirect URIs strictly.

## Conclusion

OAuth 2.0 and OpenID Connect are powerful protocols that, when implemented correctly, provide secure and user-friendly authentication and authorization. The key is discipline: use the authorization code flow with PKCE for all interactive clients, keep tokens short-lived, validate everything server-side, and design scopes that enforce least privilege.

The protocols themselves are well-designed. Most OAuth vulnerabilities come from implementation mistakes, using the wrong flow, accepting unregistered redirect URIs, or failing to validate tokens. By following the patterns in this guide and testing rigorously, you can build a solid OAuth/OIDC implementation that protects your users and your APIs.

## OAuth vs OIDC: The Difference and How the OIDC Flow Works
Source: https://startwithidentity.com/guides/fundamentals/oauth-vs-oidc/
Last updated: 2026-11-05

**OAuth 2.0 vs OIDC comes down to one question: access or identity.** OAuth 2.0 is an authorization framework that gives an application delegated access to an API through access tokens. OpenID Connect (OIDC) is an identity layer on top of OAuth 2.0 that adds authentication through a signed ID token describing who the user is. Use OIDC to log a user in; use OAuth to let an app call an API.

Using the wrong one creates real security holes, which is why the distinction matters more than the acronyms. The same split runs through [authentication vs authorization](https://startwithidentity.com/guides/fundamentals/authentication-vs-authorization/).

## OAuth 2.0 vs OIDC side by side

| | OAuth 2.0 | OpenID Connect |
|---|---|---|
| Answers | What may this app do on the user's behalf? | Who is the user, and when did they sign in? |
| Specification (November 2026) | [RFC 6749](https://startwithidentity.com/standards/oauth-2-0/) (2012), hardened by RFC 9700 (January 2025); [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/) at draft-17 | [OIDC Core 1.0](https://startwithidentity.com/standards/openid-connect/) with errata set 2 (December 2023); ISO/IEC 26131:2024 |
| Main token | [Access token](https://startwithidentity.com/glossary/access-token/), format not defined by RFC 6749 | [ID token](https://startwithidentity.com/glossary/id-token/), always a signed [JWT](https://startwithidentity.com/glossary/jwt/) |
| Token audience | The resource server (API) | The client application |
| Trigger | Any scope, such as `calendar.read` | The `openid` scope |
| Extra endpoints | Authorization, token | Adds userinfo, discovery (`/.well-known/openid-configuration`), [JWKS](https://startwithidentity.com/glossary/jwks/) |
| Typical use | API access, integrations, AI agents calling tools | Single sign-on, social login, customer sign-in |

## How the OIDC flow works

The authorization code flow with [PKCE](https://startwithidentity.com/glossary/pkce/) is the one to use, for every client type:

1. **Discovery.** The client reads the provider's metadata from `/.well-known/openid-configuration`: endpoints, supported algorithms and the JWKS URI.
2. **Authorization request.** The client redirects the browser to the authorization endpoint with `response_type=code`, `scope=openid` plus any other scopes, a `state`, a `nonce` and a PKCE `code_challenge`.
3. **Authentication.** The provider signs the user in, applying its own MFA and policy, and redirects back with a one-time code.
4. **Token request.** The client sends the code and the PKCE `code_verifier` to the token endpoint and receives an ID token, usually an access token, and optionally a [refresh token](https://startwithidentity.com/glossary/refresh-token/).
5. **Validation.** The client checks the ID token signature against the provider's published keys, that `iss` matches exactly, `aud` contains its `client_id`, `exp` is in the future and `nonce` matches.
6. **Session.** The client creates its own session from the `sub` claim and sends only the access token to APIs.

Plain OAuth is the same dance without step 5's ID token: the client gets an access token and calls the API, and never learns who the user is in a standard way. See the [authorization code flow](https://startwithidentity.com/glossary/authorization-code-flow/) entry and the [OAuth 2.0 and OIDC implementation guide](https://startwithidentity.com/guides/implementation/oauth-2-openid-connect-implementation/).

## Why the confusion causes real bugs

**Using an access token as proof of identity.** An access token says a client was authorized for some scope. It does not say who the user is, and in many designs it is not audience-restricted to your application. Accepting one as a login credential lets a token minted for a different application authenticate against yours. Use the ID token for authentication and derive your own session from it.

**Sending an ID token to an API.** The mirror image, and just as common. ID tokens are for the client, validated once at sign-in. Resource servers should receive access tokens. An API that accepts ID tokens is validating the wrong audience, or not validating at all.

**Skipping validation entirely.** [CVE-2026-48558](https://startwithidentity.com/cves/cve-2026-48558/) let attackers forge OIDC tokens against SimpleHelp servers that did not properly validate signatures, giving technician access without credentials or MFA, and it was exploited in 2026 ([incident record](https://startwithidentity.com/breaches/incidents/2026-simplehelp-oidc-token-forgery/)). [CVE-2025-9485](https://startwithidentity.com/cves/cve-2025-9485/) in a WordPress OAuth SSO plugin and [CVE-2026-5430](https://startwithidentity.com/cves/cve-2026-5430/) in WSO2 API Manager are the same class: JWT checks that accepted what they should have rejected.

## What attackers do with OAuth in practice

The OAuth incidents in SWI's [breach database](https://startwithidentity.com/breaches/) rarely break the protocol. They abuse grants that work as designed:

- **Consent phishing.** [UNC6040](https://startwithidentity.com/breaches/incidents/2025-unc6040-salesforce-vishing-campaign/) phoned employees and talked them into authorizing a modified Salesforce Data Loader app ([OAuth consent phishing](https://startwithidentity.com/techniques/oauth-consent-phishing/)). A password reset does not revoke a grant.
- **Stolen refresh tokens.** In the [Salesloft Drift](https://startwithidentity.com/breaches/incidents/2025-salesloft-drift-oauth-token-theft/) campaign, third-party app tokens gave standing access to many Salesforce tenants until Salesloft and Salesforce revoked them ([refresh token abuse](https://startwithidentity.com/techniques/refresh-token-abuse/)).
- **Token replay.** Bearer tokens work for whoever holds them. In 2026 stolen Microsoft 365 session tokens were [replayed into 79 organizations](https://startwithidentity.com/breaches/incidents/2026-microsoft-365-token-replay-79-orgs/), with [device code phishing](https://startwithidentity.com/techniques/device-code-phishing/) among the methods ([token replay](https://startwithidentity.com/techniques/token-replay-unbound-endpoint/)).
- **Forged signing keys.** [Storm-0558](https://startwithidentity.com/breaches/incidents/2023-storm-0558-microsoft-signing-key-forgery/) forged tokens with a stolen Microsoft consumer key, and a validation flaw let them open enterprise mailboxes. Strict issuer and audience checks are the client-side defense.

## The current best practice

OAuth 2.1 consolidates a decade of security guidance into defaults worth adopting even if you stay on 2.0:

- **Authorization code with PKCE for every client**, confidential ones included.
- **No implicit flow.** Returning tokens in the redirect puts them in URLs, browser history, and referrer headers.
- **No resource owner password grant.** It requires the application to handle credentials, which is the thing OAuth exists to avoid.
- **Exact redirect URI matching**, not prefix or wildcard.
- **No bearer tokens in query strings**, and only the `S256` PKCE method.
- **Rotate refresh tokens on use** and detect reuse of a spent token, which is the signal that a copy is circulating.

## Where OAuth and OIDC are heading in 2026

Bearer tokens are the last large replay hole, which is why sender-constraining is gaining ground: [DPoP](https://startwithidentity.com/glossary/dpop/) binds a token to a key the client proves possession of, and [mTLS](https://startwithidentity.com/glossary/mtls/) does the same where you control the transport. AI agents run on the same machinery: the [MCP authorization](https://startwithidentity.com/standards/mcp-authorization/) revision of July 28, 2026 builds on the OAuth 2.1 draft and RFC 9728, [token exchange](https://startwithidentity.com/glossary/token-exchange/) narrows scope at each hop, and the [ID-JAG draft](https://startwithidentity.com/standards/id-jag-cross-app-access/) (draft-06, October 31, 2026) lets an enterprise IdP broker one app's access to another. [GNAP](https://startwithidentity.com/glossary/gnap/) (RFC 9635) is the clean-slate IETF alternative, but new deployments still build on OAuth 2.1.

## Choosing an OIDC provider

For customer web login, most teams buy an OpenID provider rather than run one. Free tiers checked on October 30, 2026 for the [Identity Pricing Transparency Index](https://startwithidentity.com/reports/identity-pricing-transparency-index-2026/) include [Microsoft Entra External ID](https://startwithidentity.com/vendors/ciam/microsoft-entra-external-id/) at 50,000 MAU, [Auth0](https://startwithidentity.com/vendors/ciam/auth0/) at 25,000 MAU and [Amazon Cognito](https://startwithidentity.com/vendors/ciam/amazon-cognito/) at 10,000 MAU. Self-hosted options include [Keycloak](https://startwithidentity.com/vendors/open-source/keycloak/) and [Zitadel](https://startwithidentity.com/vendors/open-source/zitadel/). Compare them in the [best CIAM platforms](https://startwithidentity.com/rankings/best-ciam-platforms/) ranking, and read [SAML vs OIDC](https://startwithidentity.com/guides/fundamentals/saml-vs-oidc/) if enterprise customers will federate in.

## Passkeys 101: What they are and when to ship them
Source: https://startwithidentity.com/guides/authentication/passkeys-101/
Last updated: 2026-11-05

## Problem statement

Passwords are the largest single source of account compromise. Passkeys replace shared secrets with public-key credentials bound to a device and a user verification step.

## How they work

A passkey is a WebAuthn credential. Registration creates a key pair, the public key goes to the server, the private key stays on the authenticator. Authentication is a signed challenge.

## When to ship

Ship passkeys behind a feature flag, alongside passwords, with a clear recovery path. Do not force passkeys until your recovery flow is honest about lost devices.

## Synced vs device-bound

This is the decision that matters most and the one rollout plans skip. A **synced passkey** lives in a platform credential manager (iCloud Keychain, Google Password Manager, a password manager) and follows the user across their devices. That is what makes consumer adoption possible, because nobody buys two hardware keys for a shopping account.

A **device-bound passkey** never leaves the authenticator, typically a hardware security key or a platform authenticator with attestation. It cannot be synced, which means it also cannot be recovered from the sync fabric if the device is lost.

Research published in August 2026 sharpened the trade-off. In [Pass the Passkey](https://unit42.paloaltonetworks.com/passwordless-authentication-security-risks/) (August 3, 2026), Unit 42 showed that the Security Domain Secret protecting Google Password Manager passkeys in Chrome on Windows remains accessible in Chrome's process memory, and that "there is no way to rotate or revoke the SDS." Every presented attack relies on malware already on the victim's device, so this is not an argument against passkeys, but it is an argument for tiering: synced passkeys for consumers, device-bound authenticators for administrators and anyone with production access.

## Server-side validation that actually matters

The relying party controls the assurance level, and getting these wrong produces a passwordless flow with a password's security:

- **Validate `userVerification` server side.** If you request `preferred` and accept an assertion with the flag unset, you have possession without user presence. Use `required` for anything sensitive and check the flag on the server, not in the client.
- **Pin your relying party identifier early.** The RP ID fixes the origin a credential will sign for, and changing it later invalidates every enrolled credential. Decide the domain before launch.
- **Check the signature counter** where the authenticator provides one, as a cloning signal. Under the [WebAuthn spec](https://www.w3.org/TR/webauthn-3/), authenticators that do not implement a counter leave `signCount` "constant at zero", and synced passkeys commonly report `0` ([SimpleWebAuthn notes](https://simplewebauthn.dev/docs/packages/server) Touch ID on macOS always does), so treat zero as "no counter" rather than a failure.
- **Use attestation** if you need to enforce a specific class of authenticator, for example requiring hardware keys for admins. Most consumer deployments should not.

## The recovery problem

Recovery is where passkey projects fail, because removing the password also removes the fallback everyone quietly relied on. Three rules:

1. **Enrol at least two credentials per account.** Prompt for a second device at the first successful sign-in rather than at registration, when the user is already invested. WhatsApp [added support for more than one passkey per account](https://blog.whatsapp.com/one-billion-people-are-now-protected-with-passkeys-on-whatsapp-plus-more-account-security-features) on August 25, 2026, so people who use both Android and iOS devices can enroll a credential on each.
2. **Do not fall back to SMS.** An account protected by a phishing-resistant credential with an SMS recovery path is protected by SMS.
3. **Be honest in the UI about what happens when every device is gone.** For consumer products that usually means identity verification. For workforce, a help desk process that does not rely on caller-supplied facts, which is the exact path [Scattered Spider](https://startwithidentity.com/breaches/scattered-spider-helpdesk-social-engineering/) exploits.

## A rollout sequence that works

1. Ship passkeys as an option alongside passwords, behind a flag, for internal users first.
2. Measure enrolment and successful authentication rates before promoting the option.
3. Prompt existing users to enrol after a successful password sign-in, not before.
4. Once enrolment is high enough, stop offering passwords to enrolled users.
5. Only then consider removing passwords entirely, with a tested recovery path in place.

## Where to start

Work through the [passkey rollout checklist](https://startwithidentity.com/templates/passkey-rollout-checklist/), read the [WebAuthn and FIDO2 standard](https://startwithidentity.com/standards/webauthn-fido2/) page for the protocol detail, and follow the [add passkeys with WebAuthn recipe](https://startwithidentity.com/recipes/add-passkeys-webauthn/) for implementation. For the vendor shortlist see [best passwordless CIAM providers](https://startwithidentity.com/rankings/best-passwordless-ciam-providers/) and [best phishing-resistant MFA](https://startwithidentity.com/rankings/best-phishing-resistant-mfa/).

## Passwordless Authentication Implementation Guide
Source: https://startwithidentity.com/guides/authentication/passwordless-authentication-implementation-guide/
Last updated: 2026-11-05

Passwords are the oldest and weakest link in authentication. They are phishable, reusable, guessable, and expensive to manage, because every forgotten password becomes a reset request. Credential stuffing attacks exploit the fact that users reuse passwords across sites. Even sophisticated password policies cannot eliminate the fundamental problem: secrets that humans must remember and type are inherently vulnerable.

Passwordless authentication eliminates passwords entirely, replacing them with cryptographic credentials that are bound to the user's device, cannot be phished, and require no memorization. With the maturation of FIDO2, WebAuthn, and passkeys, passwordless is no longer experimental. It is production-ready and rapidly becoming the standard.

This guide walks you through implementing passwordless authentication, from understanding the underlying protocols to deploying passkeys across your organization.

## What You Will Learn

- How FIDO2, WebAuthn, and passkeys work together
- Choosing between platform authenticators, roaming authenticators, and synced passkeys
- Server-side WebAuthn implementation
- Migration strategy from passwords to passwordless
- Enterprise rollout and user adoption techniques

## Prerequisites

1. **HTTPS everywhere**, WebAuthn only works over secure origins. Every application and service must be served over HTTPS.
2. **Modern browser support**, Chrome, Safari, Firefox, and Edge all support WebAuthn. Verify that your user base is on supported versions.
3. **Identity Provider support**, Your IdP must support FIDO2/WebAuthn. [Okta](https://startwithidentity.com/vendors/iam/okta/), [Microsoft Entra ID](https://startwithidentity.com/vendors/iam/microsoft-entra/), [Ping Identity](https://startwithidentity.com/vendors/iam/ping-identity/), and most modern IdPs do.
4. **User device inventory**, Know what devices your users have. Platform authenticators require biometric hardware (Touch ID, Windows Hello, Android biometrics).
5. **Fallback mechanism**, You need a fallback authentication method during the transition period. This could be OTP, magic links, or password + MFA.

## Architecture Overview

Passwordless authentication using FIDO2/WebAuthn involves three parties:

- **Relying Party (RP):** Your application or IdP server. It generates challenges, stores public keys, and verifies assertions.
- **Authenticator:** The device or software that creates and stores the private key and performs the cryptographic operation. This can be a platform authenticator (built into the device, like Touch ID) or a roaming authenticator (external, like a [YubiKey](https://startwithidentity.com/vendors/mfa/yubico/)).
- **Client (Browser):** Mediates between the RP and the authenticator using the WebAuthn JavaScript API.

**Registration flow:**
1. RP generates a random challenge and sends it to the browser.
2. Browser calls `navigator.credentials.create()` with the challenge and RP information.
3. Authenticator generates a new key pair, stores the private key, and returns the public key and a signed attestation.
4. Browser sends the public key and attestation to the RP.
5. RP validates the attestation and stores the public key associated with the user.

**Authentication flow:**
1. RP generates a random challenge and sends it to the browser along with the user's credential IDs.
2. Browser calls `navigator.credentials.get()`.
3. Authenticator finds the matching credential, signs the challenge with the private key, and returns the assertion.
4. Browser sends the signed assertion to the RP.
5. RP verifies the signature using the stored public key. If valid, the user is authenticated.

**Passkeys** are a user-friendly evolution of FIDO2 credentials. They are WebAuthn credentials that are synced across the user's devices via the platform's cloud (iCloud Keychain for Apple, Google Password Manager for Android/Chrome). This solves the key recovery problem that plagued earlier FIDO2 deployments.

## Step-by-Step Implementation

### Step 1: Choose Your Authenticator Strategy

You have three options, and most organizations will support all three:

**Platform Authenticators** (Touch ID, Windows Hello, Android biometric):
- Built into the device, no additional hardware required
- Excellent user experience, users just scan a fingerprint or glance at the camera
- Credential is bound to the device (unless using synced passkeys)

**Roaming Authenticators** (YubiKey, Feitian, SoloKeys):
- External USB/NFC/BLE devices
- Work across any device with a USB port or NFC reader
- Ideal for shared workstations or environments where platform authenticators are not available

**Synced Passkeys** (iCloud Keychain, Google Password Manager):
- WebAuthn credentials synced across the user's devices
- Solve the device-loss recovery problem
- Slight reduction in security assurance since the credential is no longer device-bound

For enterprise environments, the recommended approach is: synced passkeys as the default for most users, hardware security keys for high-privilege accounts (admins, executives), and platform authenticators as a middle ground.

### Step 2: Configure the Relying Party

The RP configuration defines how your server interacts with WebAuthn. Key settings:

```javascript
// Relying Party configuration
const rpConfig = {
  rp: {
    name: "Your Company",
    id: "yourcompany.com"  // Must match the origin's registrable domain
  },
  user: {
    id: userIdBuffer,       // Opaque user handle (NOT email)
    name: "user@yourcompany.com",
    displayName: "Jane Smith"
  },
  challenge: generateSecureRandom(32),  // 32-byte random challenge
  pubKeyCredParams: [
    { type: "public-key", alg: -7 },    // ES256 (preferred)
    { type: "public-key", alg: -257 }   // RS256 (fallback)
  ],
  authenticatorSelection: {
    authenticatorAttachment: "platform",  // or "cross-platform" for security keys
    residentKey: "required",              // for passkeys/discoverable credentials
    userVerification: "required"          // biometric or PIN required
  },
  timeout: 60000,  // 60 seconds
  attestation: "none"  // "direct" if you need attestation verification
};
```

Important decisions:
- Set `residentKey: "required"` for passkeys (discoverable credentials). This enables username-less login.
- Set `userVerification: "required"` to ensure the authenticator verifies the user (biometric or PIN) before signing.
- Use `attestation: "none"` unless you have a regulatory requirement to verify the authenticator model. Attestation adds complexity.

### Step 3: Implement Registration (Server Side)

The example below uses the current [`@simplewebauthn/server`](https://simplewebauthn.dev/docs/packages/server) API (v13 and later). Since v11 the library takes a `credential` object rather than the old `authenticator` argument, and `userID` must be a `Uint8Array`, not a string.

```javascript
import {
  generateRegistrationOptions,
  verifyRegistrationResponse,
} from '@simplewebauthn/server';
import { isoUint8Array } from '@simplewebauthn/server/helpers';

const rpName = 'Your Company';
const rpID = 'yourcompany.com';
const origin = `https://${rpID}`;

app.post('/api/webauthn/register/begin', async (req, res) => {
  const user = await getAuthenticatedUser(req);
  const userPasskeys = await getUserPasskeys(user.id);

  const options = await generateRegistrationOptions({
    rpName,
    rpID,
    userName: user.email,
    userDisplayName: user.name,
    userID: isoUint8Array.fromUTF8String(user.webauthnUserID), // opaque handle, not the email
    attestationType: 'none',
    excludeCredentials: userPasskeys.map((passkey) => ({
      id: passkey.id,
      transports: passkey.transports,
    })),
    authenticatorSelection: {
      residentKey: 'required',
      userVerification: 'required',
    },
  });

  await storeRegistrationOptions(user.id, options); // short TTL, single use
  res.json(options);
});

app.post('/api/webauthn/register/complete', async (req, res) => {
  const user = await getAuthenticatedUser(req);
  const currentOptions = await getRegistrationOptions(user.id);

  let verification;
  try {
    verification = await verifyRegistrationResponse({
      response: req.body,
      expectedChallenge: currentOptions.challenge,
      expectedOrigin: origin,
      expectedRPID: rpID,
      requireUserVerification: true,
    });
  } catch (error) {
    return res.status(400).json({ error: error.message });
  }

  if (verification.verified) {
    const { credential, credentialDeviceType, credentialBackedUp } =
      verification.registrationInfo;

    await savePasskey({
      userId: user.id,
      webAuthnUserID: currentOptions.user.id,
      id: credential.id,
      publicKey: credential.publicKey, // Uint8Array: store as bytes
      counter: credential.counter,
      transports: credential.transports,
      deviceType: credentialDeviceType, // 'singleDevice' or 'multiDevice'
      backedUp: credentialBackedUp,     // true for synced passkeys
    });
  }

  res.json({ verified: verification.verified });
});
```

Use a well-tested library like `@simplewebauthn/server` (Node.js), `py_webauthn` (Python), or `webauthn-rs` (Rust) rather than implementing the cryptographic verification yourself. Storing `deviceType` and `backedUp` lets you tell synced passkeys from device-bound ones later, for example to require device-bound credentials for admins.

### Step 4: Implement Authentication (Server Side)

```javascript
import {
  generateAuthenticationOptions,
  verifyAuthenticationResponse,
} from '@simplewebauthn/server';

app.post('/api/webauthn/login/begin', async (req, res) => {
  // Omit allowCredentials for the discoverable (username-less) passkey flow
  const options = await generateAuthenticationOptions({
    rpID,
    userVerification: 'required',
  });

  await storeChallengeForSession(req.sessionId, options.challenge);
  res.json(options);
});

app.post('/api/webauthn/login/complete', async (req, res) => {
  const expectedChallenge = await getChallengeForSession(req.sessionId);

  const passkey = await getPasskeyById(req.body.id);
  if (!passkey) {
    return res.status(401).json({ error: 'Unknown credential' });
  }

  let verification;
  try {
    verification = await verifyAuthenticationResponse({
      response: req.body,
      expectedChallenge,
      expectedOrigin: origin,
      expectedRPID: rpID,
      requireUserVerification: true,
      credential: {
        id: passkey.id,
        publicKey: passkey.publicKey,
        counter: passkey.counter,
        transports: passkey.transports,
      },
    });
  } catch (error) {
    return res.status(400).json({ error: error.message });
  }

  if (verification.verified) {
    const { newCounter } = verification.authenticationInfo;
    await updatePasskeyCounter(passkey.id, newCounter);

    await createSession(passkey.userId, req);
  }

  res.json({ verified: verification.verified });
});
```

**Signature counters and synced passkeys.** Do not treat a counter of `0` as an error. The [WebAuthn spec](https://www.w3.org/TR/webauthn-3/) says authenticators that do not implement a signature counter leave `signCount` "constant at zero", and synced passkeys commonly report `0` on every sign-in. The [SimpleWebAuthn docs](https://simplewebauthn.dev/docs/packages/server) note that some authenticators, such as Touch ID on macOS, always return zero. Counter checks are only a cloning signal for credentials that actually increment, which in practice means device-bound authenticators.

### Step 5: Implement the Client Side

```javascript
// Registration (client)
async function registerPasskey() {
  const optionsRes = await fetch('/api/webauthn/register/begin', { method: 'POST' });
  const options = await optionsRes.json();

  // Convert base64 fields to ArrayBuffer
  options.challenge = base64ToBuffer(options.challenge);
  options.user.id = base64ToBuffer(options.user.id);

  const credential = await navigator.credentials.create({ publicKey: options });

  await fetch('/api/webauthn/register/complete', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(serializeCredential(credential))
  });
}

// Authentication (client)
async function loginWithPasskey() {
  const optionsRes = await fetch('/api/webauthn/login/begin', { method: 'POST' });
  const options = await optionsRes.json();

  options.challenge = base64ToBuffer(options.challenge);

  const assertion = await navigator.credentials.get({ publicKey: options });

  const result = await fetch('/api/webauthn/login/complete', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(serializeAssertion(assertion))
  });

  if (result.ok) {
    window.location.href = '/dashboard';
  }
}
```

### Step 6: Plan the Migration

Going passwordless is not a switch you flip overnight. Use a phased approach:

**Phase 1, Passwordless as an option (Months 1-3):**
Users can register a passkey alongside their existing password. Promote passkey registration through in-app prompts and communications.

**Phase 2, Passwordless preferred (Months 4-6):**
Default the login page to passkey authentication. Users can still click "Sign in with password" as a fallback. Track adoption metrics.

**Phase 3, Passwordless enforced (Months 7-12):**
For groups with high adoption (>90%), disable password login. High-privilege users (admins) must use hardware security keys. Maintain a break-glass password reset process.

**Phase 4, Password elimination (Month 12+):**
Remove password fields from the database. Passwords no longer exist in your system.

## Configuration Best Practices

- **Support multiple credentials per user.** Users should register at least two authenticators (e.g., platform authenticator + security key) so they have a backup if one is lost.
- **Use discoverable credentials.** Set `residentKey: "required"` to enable the passkey flow where users do not need to type a username.
- **Do not require attestation** unless you have a specific compliance need. Attestation complicates registration and causes compatibility issues with some authenticators.
- **Set reasonable timeouts.** 60 seconds is reasonable for registration and authentication. Longer timeouts increase the risk of challenge replay.
- **Store credentials securely.** The public key is not secret, but the credential ID and user association must be protected. Use the same security controls as your user database.
- **Implement credential management UI.** Give users a self-service page to view registered credentials, rename them, and delete lost ones.

## Testing and Validation

1. **Cross-browser testing:** Test registration and authentication in Chrome, Safari, Firefox, and Edge on both desktop and mobile.
2. **Authenticator diversity:** Test with platform authenticators (Touch ID, Windows Hello), hardware security keys (YubiKey 5), and synced passkeys (iCloud, Google).
3. **Error handling:** Test what happens when the user cancels the biometric prompt, uses the wrong finger, or removes the security key mid-operation.
4. **Counter verification:** For an authenticator that increments its counter, simulate a counter that goes backward (indicating a cloned authenticator) and verify that your server rejects the authentication. Confirm that synced passkeys reporting `0` still sign in.
5. **Recovery flow:** Simulate a user losing their device. Verify that the recovery process works and that the lost credential can be revoked.
6. **Accessibility testing:** Ensure that users who cannot use biometrics can fall back to a PIN on the authenticator.

## Common Pitfalls and Troubleshooting

| Problem | Cause | Solution |
|---------|-------|----------|
| `NotAllowedError` during registration | RP ID does not match the origin | Ensure `rpId` is the registrable domain of your origin |
| User cannot find their passkey | Credential was not discoverable | Set `residentKey: "required"` during registration |
| Authentication works on laptop but not phone | Credential was created with `authenticatorAttachment: "platform"` on laptop | Use synced passkeys or register credentials on each device |
| "This passkey already exists" | User trying to re-register an existing credential | Use `excludeCredentials` in registration options |
| Safari blocks the WebAuthn prompt | User gesture requirement not met | Ensure the WebAuthn call is triggered by a direct user click, not a timer or page load |

## Security Considerations

1. **Phishing resistance.** WebAuthn is inherently phishing-resistant because the browser binds the credential to the origin. A phishing site on a different domain cannot trigger the authenticator. This is the single biggest security advantage over passwords and OTPs.
2. **Device loss.** If a user loses their only registered authenticator, they are locked out. Require at least two registered credentials and provide a secure account recovery process.
3. **Synced passkey security model.** Synced passkeys trade device-binding for usability. The private key is stored in a cloud vault (iCloud Keychain, Google Password Manager), which means the security of the credential depends on the security of the user's cloud account. For high-security environments, require device-bound credentials (hardware security keys).
4. **Replay protection.** Always generate a fresh, random challenge for each authentication ceremony. Never reuse challenges.
5. **Counter tracking.** Authenticators that implement a signature counter increment it with each use. If a non-zero counter goes backward, it may indicate a cloned authenticator: alert and investigate. Synced passkeys usually report `0`, so the check gives no signal for them.

## Conclusion

Passwordless authentication is the most significant improvement in authentication security in decades. By eliminating passwords, you eliminate phishing, credential stuffing, password spraying, and password reuse as attack vectors.

The technology is mature, the standards are finalized, and the user experience is superior to passwords. The main challenge is organizational: migrating users, supporting diverse devices, and handling edge cases. By following the phased migration approach outlined in this guide and supporting multiple authenticator types, you can transition your organization to passwordless with minimal disruption.

## Passwordless: a strategy that survives reality
Source: https://startwithidentity.com/guides/authentication/passwordless-strategy/
Last updated: 2026-11-05

A **passwordless strategy** is a plan for replacing passwords with methods matched to each user population's threat model, rolled out in phases, with a recovery path as strong as the sign-in it protects. The verdict for 2026: make passkeys the default, keep magic links and one-time codes only as fallbacks for low-value accounts, and design recovery before you remove a single password.

"Passwordless" is a marketing word that covers very different security postures. A strategy that survives contact with real users starts by being precise about which passwordless you mean, and matching it to the threat you actually face.

## The honest framing

Magic links are passwordless. One-time codes are passwordless. [Passkeys](https://startwithidentity.com/guides/fundamentals/what-is-passwordless/) are passwordless. Only the last is also phishing-resistant, because a passkey is a [WebAuthn/FIDO2](https://startwithidentity.com/standards/webauthn-fido2/) credential bound to the origin it was created for, so it cannot be replayed against a lookalike domain. Magic links and codes remove the reused-password risk but still send a bearer secret through a channel an attacker can intercept or a user can be tricked into forwarding. Pick the method for the threat model, not for the word on the pricing page.

## What changed in 2025-2026

- **WebAuthn Level 3 is final.** It became a [W3C Recommendation](https://www.w3.org/TR/webauthn-3/) on 25 August 2026, with no substantive changes since its May 2026 Candidate Recommendation Snapshot.
- **NIST accepts synced passkeys at AAL2.** [SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html) (final July 2025) says syncable authenticators may support AAL2 if "user access to authentication keys in the sync fabric SHALL be protected by AAL2-equivalent MFA", and that they "SHALL NOT be used at AAL3." It also requires AAL2 verifiers to offer at least one phishing-resistant option. See [synced passkey](https://startwithidentity.com/glossary/synced-passkey/) and [AAL](https://startwithidentity.com/glossary/aal/).
- **Passkey portability is half done.** The FIDO Alliance approved the Credential Exchange Format (CXF) 1.0 as a Proposed Standard in August 2025, while the Credential Exchange Protocol (CXP) that moves credentials between providers was still under development as of [1Password's October 2025 update](https://www.1password.community/developers-blog-53/portability-without-compromise-1password-helps-author-a-new-standard-for-secure-credential-transfer-23166). Plan for platform migration as a recovery case, not a solved problem.

## Compare methods by threat model

| Method | Phishing-resistant | Main weakness | Best fit |
| --- | --- | --- | --- |
| [Magic link](https://startwithidentity.com/glossary/magic-link/) | No | Email account takeover, link forwarding | Low-value consumer accounts |
| SMS [OTP](https://startwithidentity.com/glossary/one-time-password/) | No | Relay to phishing pages, [SIM swap](https://startwithidentity.com/glossary/sim-swap/) | Temporary fallback only |
| Email OTP | No | Same as magic link, plus relay | Fallback, onboarding verification |
| Authenticator app ([TOTP](https://startwithidentity.com/glossary/totp/)) | No | Code relay, seed sync to a cloud account | Legacy apps without WebAuthn |
| Synced passkey | Yes | Security of the sync account | Consumers and general staff (AAL2) |
| Device-bound passkey | Yes | Lost device without a backup | High-value staff, regulated flows |
| FIDO2 security key | Yes | Cost and logistics | Admins and high-risk roles (AAL3) |

How this maps to populations:

- **Consumer apps, low value:** Magic links or OTP. Low friction, acceptable security when the account protects little of worth.
- **Consumer apps, high value (financial, health, social):** Passkeys with an email or OTP fallback, so the strong path is the default and the fallback is the exception.
- **Workforce, general population:** Passkeys, plus an authenticator app for legacy applications that cannot yet consume WebAuthn.
- **Workforce, admins and high-risk roles:** FIDO2 hardware security keys, for example from [Yubico](https://startwithidentity.com/vendors/mfa/yubico/), no exceptions. This is the population attackers target first.

## Implementation order

1. Add passkey enrollment alongside existing flows. Do not force it. Measure adoption and failure rates.
2. After a few months of voluntary adoption (a planning estimate, not a benchmark), default new accounts to passkeys. For onboarding, verify the email or phone once, then offer the passkey on the same screen.
3. Prompt existing password users to enroll a passkey at sign-in, using conditional UI so it feels like autofill.
4. Demote passwords to a recovery-only role, or remove them, once passkey coverage is high.

Track enrollment rate, passkey sign-in success rate, and support tickets per thousand sign-ins at each step. If success rate drops or tickets spike, hold the phase until you understand why. Our read of the [Passkey Index 2026](https://startwithidentity.com/blog/passkey-index-2026-what-it-means-for-your-rollout/) covers what adoption numbers to manage. The deeper mechanics are in the [passwordless authentication implementation guide](https://startwithidentity.com/guides/authentication/passwordless-authentication-implementation-guide/) and, for staff, the [implementing passkeys in the enterprise](https://startwithidentity.com/guides/authentication/implementing-passkeys-enterprise/) guide.

## Recovery is the hard part

Passwordless without a credible recovery story will lock users out, and passwordless with a weak recovery story just moves the attack to recovery. Plan for:

- Lost device with no backup authenticator enrolled
- Device and platform migration, for example Android to iOS, where synced passkeys may not follow
- Family member, assistant, or delegated access without shared credentials
- A recovery flow that is itself resistant to phishing, rather than a "click this email link" bypass of everything you just built

A fallback ladder that keeps both lockouts and tickets down:

1. **Second authenticator.** Prompt for a second passkey or a hardware key at enrollment, so a lost device is an inconvenience rather than a lockout.
2. **Verified channel plus step-up.** An email or authenticator code, combined with device and risk signals, for routine recovery on lower-value accounts.
3. **Assisted recovery with proofing.** [Identity proofing](https://startwithidentity.com/glossary/identity-proofing/) or a manager-verified workflow for admins and high-value accounts, with every new credential logged and alerted.

Revoke existing sessions and notify the user whenever a new credential is added through recovery.

## Failure modes to design against

- **SMS recovery as the weak door.** At [Coinbase](https://startwithidentity.com/breaches/incidents/2021-coinbase-sms-recovery-flaw/), attackers abused a flaw in SMS account recovery to obtain the codes needed to take over accounts.
- **Codes relayed in real time.** The [0ktapus campaign](https://startwithidentity.com/breaches/incidents/2022-0ktapus-phishing-campaign/) and the [Twilio SMS phishing](https://startwithidentity.com/breaches/incidents/2022-twilio-sms-phishing/) attack captured credentials and codes on fake login pages; see [OTP relay](https://startwithidentity.com/techniques/otp-relay-social-engineering/) and [AiTM phishing](https://startwithidentity.com/techniques/aitm-phishing-proxy/).
- **Synced secrets without protection.** At [Retool](https://startwithidentity.com/breaches/incidents/2023-retool-sms-phishing-authenticator-sync/), authenticator seeds synced to a Google account meant one account compromise exposed the codes. The same logic is why NIST requires MFA on the passkey sync fabric.
- **Attackers adding their own methods.** In the [Microsoft 365 token replay campaign](https://startwithidentity.com/breaches/incidents/2026-microsoft-365-token-replay-79-orgs/), the actor wiped and replaced victims' MFA methods. Alert on every authenticator change.
- **The session after sign-in.** Passkeys protect the login, not the cookie. The [CircleCI](https://startwithidentity.com/breaches/incidents/2023-circleci-engineer-session-token-theft/) intrusion used a stolen 2FA-backed session; see [session cookie theft](https://startwithidentity.com/techniques/session-cookie-theft/) and [device-bound session credentials](https://startwithidentity.com/glossary/device-bound-session-credentials/).

## Vendor requirements

When you evaluate platforms, insist on WebAuthn support for both platform and roaming authenticators, conditional UI for browser autofill, account recovery that supports multiple methods, and telemetry that surfaces failed-authentication patterns. Customer-facing options include [Stytch](https://startwithidentity.com/vendors/ciam/stytch/) (acquired by Twilio, closed November 2025), [Descope](https://startwithidentity.com/vendors/ciam/descope/), [Corbado](https://startwithidentity.com/vendors/ciam/corbado/) and open-source [Hanko](https://startwithidentity.com/vendors/open-source/hanko/); on the workforce side, [Microsoft Entra](https://startwithidentity.com/vendors/iam/microsoft-entra/) and [Okta](https://startwithidentity.com/vendors/iam/okta/) both support passkeys; Okta's [Passkeys (FIDO2 WebAuthn) authenticator](https://help.okta.com/oie/en-us/Content/Topics/identity-engine/authenticators/configure-passkeys.htm) also lets admins block synced passkeys org-wide when policy requires device-bound keys. Compare providers in the [best passwordless CIAM providers](https://startwithidentity.com/rankings/best-passwordless-ciam-providers/) ranking, the [top passwordless authentication platforms](https://startwithidentity.com/articles/top-7-passwordless-authentication-platforms/) article and the [MFA matrix](https://startwithidentity.com/tools/mfa-matrix/). The goal is not "no passwords." The goal is authentication that is both stronger and easier than the passwords it replaces.

## RBAC vs ABAC vs ReBAC: Which Access Control Model to Use
Source: https://startwithidentity.com/guides/fundamentals/rbac-vs-abac-vs-rebac/
Last updated: 2026-11-05

**RBAC vs ABAC vs ReBAC: RBAC grants access through roles, ABAC evaluates attributes of the user, resource and context, and ReBAC derives access from relationships between objects.** Use RBAC when permissions fit a short list of job functions, ABAC when access depends on data already on the request, and ReBAC when access follows ownership, membership or hierarchy. Most production systems blend them: roles for the coarse grant, attributes or relationships for the fine-grained condition.

Once a user is authenticated, [authorization](https://startwithidentity.com/guides/fundamentals/authentication-vs-authorization/) decides what they can do, and this is where the most severe application vulnerabilities live. Broken Access Control is A01 in the [OWASP Top 10:2025](https://top10.owasp.org/2025), as it was in the 2021 edition, so choose the model deliberately rather than letting one accrete.

## RBAC vs ABAC vs ReBAC compared

| | RBAC | ABAC | ReBAC |
|---|---|---|---|
| Decides on | Roles held by the user | Attributes of subject, resource, action, environment | Relationship paths between subject and object |
| Reference | NIST model (1992), ANSI INCITS 359-2004, revised 2012 | NIST SP 800-162 (2014, updated 2019) | Google Zanzibar paper, USENIX ATC 2019 |
| Example rule | `billing_admin` can edit invoices | Edit if same tenant and status is not locked | View if member of a team that edits the parent folder |
| "Who can see X?" | Easy lookup | Hard: a computation over all attributes | Answerable by graph expansion |
| State needed | Role assignments | Attributes on the request or fetched at decision time | A relationship store kept in sync |
| Typical engines | Built into apps and IdPs, Cerbos, OPA | OPA (Rego), Cerbos, Cedar | OpenFGA, SpiceDB |
| Main failure | Role explosion, stale roles | Unreadable policies, missing attributes | Stale relationships, consistency lag |

## RBAC (role-based)

Access is granted through **roles** (admin, editor, viewer). NIST formalized the model in 1992 and it became [ANSI INCITS 359](https://csrc.nist.gov/projects/role-based-access-control) in 2004. Simple, well understood, and easy to audit, but it tends toward **role explosion** as every exception becomes a new role, and toward **role accumulation** when people change jobs.

**How to implement RBAC, in brief:** list the permissions your application exposes; group them into a small set of roles mapped to job functions; assign roles to groups from your identity provider, not to individuals; check permission on the server for every object; and review membership on a schedule. The [implementing RBAC guide](https://startwithidentity.com/guides/authorization/implementing-rbac-enterprise/) and [role mining](https://startwithidentity.com/glossary/role-mining/) cover the detail.

## ABAC (attribute-based)

Decisions use **attributes** of the user, resource, action, and context (department, region, time, sensitivity). [NIST SP 800-162](https://csrc.nist.gov/pubs/sp/800/162/upd2/final) describes ABAC as evaluating attributes of the subject, object and requested operation, and sometimes the environment, against policy. An ABAC policy in Cedar, the language behind Amazon Verified Permissions:

```
permit(principal, action == Action::"view", resource)
when { resource.tenant == principal.tenant && resource.status != "locked" };
```

Far more expressive than roles, but policies get hard to reason about. See [implementing ABAC](https://startwithidentity.com/guides/authorization/implementing-abac-guide/).

## ReBAC (relationship-based)

Access flows from **relationships** between objects, the model behind Google Zanzibar. The [Zanzibar paper](https://research.google/pubs/zanzibar-googles-consistent-global-authorization-system/) reports trillions of access control lists, millions of authorization requests per second, 95th-percentile latency under 10 milliseconds and availability above 99.999% over three years. Relationships are stored as tuples:

```
folder:roadmap#editor@team:platform#member
document:q3-plan#parent@folder:roadmap
```

A check for "can Anne view q3-plan" walks from the document to its folder to the team Anne belongs to. ReBAC is ideal for sharing, hierarchies, and nested ownership, and it needs a relationship store and careful modeling. See [RBAC to ReBAC](https://startwithidentity.com/guides/authorization/rbac-to-rebac/).

## What real systems actually do

The models are presented as alternatives and used as layers:

```
role: billing_admin          # coarse: can this class of user touch billing at all
condition: resource.tenant == principal.tenant AND resource.status != 'locked'
```

Trying to express the condition as roles produces role explosion. Trying to express the coarse grant as attributes produces policies nobody can audit.

## The questions that decide the model

- **Does access depend on a relationship that changes constantly?** Ownership, sharing, membership, folder inheritance. If yes, [ReBAC](https://startwithidentity.com/glossary/rebac/).
- **Does access depend on data already on the request?** Tenant, department, resource status, time. If yes, [ABAC](https://startwithidentity.com/glossary/abac/) with a stateless engine, because there is no second data store to keep consistent.
- **Can you list the permissions on one page?** Then [RBAC](https://startwithidentity.com/glossary/rbac/) is enough and adding an engine is overhead.

## How access control fails in practice

- **No object-level check at all.** The [Optus breach](https://startwithidentity.com/breaches/incidents/2022-optus-unauthenticated-api/) in 2022 came from an internet-facing API that returned customer data without valid authorization, affecting about 9.5 million people. No model helps if the check is missing.
- **Roles that only grow.** [Mover entitlement accumulation](https://startwithidentity.com/techniques/mover-entitlement-accumulation/) is RBAC's typical failure: provisioning adds the new role and nothing removes the old one.
- **Bugs in the policy layer itself.** [CVE-2026-5712](https://startwithidentity.com/cves/cve-2026-5712/), a role-editing authorization flaw in SailPoint IdentityIQ, and [CVE-2025-14778](https://startwithidentity.com/cves/cve-2025-14778/), a Keycloak UMA policy privilege escalation, show that the engine is part of your attack surface.
- **Delegation that widens access.** In agent and microservice chains, one hop that trusts the scope a caller claims produces [scope escalation through delegation](https://startwithidentity.com/techniques/scope-escalation-delegation/).

## The operational costs people underestimate

ReBAC means running a stateful service on the request path and reasoning about consistency: a check that reads stale relationship data grants stale access, and the window after a revocation is a real security property. ABAC means every attribute a decision depends on must be present in the request, which is easy for request-scoped data and hard for anything requiring a lookup. Both mean authorization is now a service that must be available, fast, and versioned, because a policy change is a production change.

## Authorization engines in 2026

| Engine | Model | Status and price (per SWI profiles) |
|---|---|---|
| [Open Policy Agent](https://startwithidentity.com/vendors/authorization/styra-opa/) | Policy as code (Rego), RBAC and ABAC | CNCF graduated, free; creators and many Styra staff joined Apple in August 2025 |
| [Cerbos](https://startwithidentity.com/vendors/authorization/cerbos/) | YAML policies, RBAC and ABAC | Engine free; Hub from $25 a month |
| [Amazon Verified Permissions](https://startwithidentity.com/vendors/authorization/aws-verified-permissions/) | Cedar, RBAC and ABAC | $5 per million single requests since June 2025 |
| [OpenFGA](https://startwithidentity.com/vendors/authorization/openfga/) | Zanzibar ReBAC | CNCF incubating since October 28, 2025, free |
| [AuthZed](https://startwithidentity.com/vendors/authorization/authzed/) (SpiceDB) | Zanzibar ReBAC | SpiceDB free; cloud from $2 per hour |
| [Oso](https://startwithidentity.com/vendors/authorization/oso/) | Polar, all three in one model | Oso Cloud quoted |
| [Permit.io](https://startwithidentity.com/vendors/authorization/permit-io/), [Aserto](https://startwithidentity.com/vendors/authorization/aserto/) | Policy plus relationships | Permit.io free Community plan, Enterprise quoted; Aserto Topaz engine free to self-host |
| [SGNL](https://startwithidentity.com/vendors/authorization/sgnl/) | Continuous, context-aware enterprise authorization | Acquired by CrowdStrike, closed February 20, 2026 |

Whichever engine you choose, call it through the [AuthZEN Authorization API 1.0](https://startwithidentity.com/standards/authzen/), a Final OpenID Foundation specification since January 11, 2026, so the application code does not depend on one vendor's SDK. Compare engines in the [best authorization tools](https://startwithidentity.com/rankings/best-authorization-tools/) ranking, [OpenFGA vs Cerbos](https://startwithidentity.com/compare/openfga-vs-cerbos/), [AuthZed vs OpenFGA](https://startwithidentity.com/compare/authzed-vs-openfga/) and the [open source authorization tools](https://startwithidentity.com/articles/top-7-open-source-authorization-tools/) roundup, and see [fine-grained authorization](https://startwithidentity.com/glossary/fga/).

## Remote IAM Jobs: How to Find and Land Them in 2026
Source: https://startwithidentity.com/guides/career/remote-iam-jobs/
Last updated: 2026-11-05

Identity and access management is one of the more remote-friendly specialties in security. Most of
the work is configuration, automation, policy, and design, not physical presence. This page covers
what is specific to remote identity work: how common it really is, how to read the fine print on
"remote," which roles travel well, and how to show a distributed team you can be trusted with the
keys. For the general search process, see [how to get an IAM job](https://startwithidentity.com/guides/career/how-to-get-an-iam-job/).

## How common remote IAM work is

On our [IAM jobs board](https://startwithidentity.com/jobs/) on 2026-11-05, 14 of 53 open listings were fully remote, 30 were
hybrid, and 9 were on-site. So remote roles exist in real numbers, but hybrid is the most common
arrangement, and you will compete with a wider pool for each fully remote opening. The board lets
you filter by work type, so you can see the current mix at any time.

## Read the fine print on "remote"

"Remote" rarely means "anywhere." Of those 14 open remote listings, 12 named a specific country or
region, such as "Remote, US," "Remote (United States or Canada)," or "remote in Romania." Before you
apply, check:

- **Country or state eligibility.** Employers usually hire only where they can run payroll and
  comply with local employment law.
- **Time zone overlap.** Identity changes often need coordination with service desks and change
  windows. Ask for the core hours.
- **Travel.** Some remote roles expect quarterly onsites or customer visits, common in consulting
  and vendor field roles.
- **On-call.** Identity outages stop everyone from working, so many teams run an on-call rotation.
  Ask how often and whether it is paid.
- **Hybrid creep.** Ask whether the role has ever been converted from remote to hybrid, and what
  the policy says about that.
- **Equipment and access.** Expect a managed laptop and often a hardware security key. Teams that
  take [privileged access](https://startwithidentity.com/guides/fundamentals/what-is-pam/) seriously will require it.

## Which roles are commonly remote

- **Most remote-friendly:** software engineering on identity products (authentication, authorization,
  [CIAM](https://startwithidentity.com/guides/fundamentals/what-is-ciam/)), cloud identity, platform and automation engineering,
  and workforce IAM engineering at software companies. In the open remote listings above,
  general IAM, authentication, and directory and SSO roles made up most of them.
- **Often remote or hybrid:** [IGA](https://startwithidentity.com/guides/fundamentals/what-is-iga/) and governance, identity
  security and [ITDR](https://startwithidentity.com/guides/fundamentals/what-is-itdr/) detection engineering, consulting delivery.
- **More likely on-site or in-country:** government, defense, and some regulated finance roles
  (security clearance and data residency drive this), and positions with hands-on privileged access
  to sensitive production systems.

## Where to find remote IAM jobs

- The [IAM jobs board](https://startwithidentity.com/jobs/), filtered to remote. Each listing links straight to the employer's
  own posting.
- **Identity vendors.** Product companies in IAM, CIAM, IGA, and PAM hire engineering, solutions,
  and customer success roles, many of them remote. Start from the [vendor directory](https://startwithidentity.com/vendors/)
  and check careers pages for the platforms you know, such as [Okta](https://startwithidentity.com/vendors/iam/okta/),
  [Microsoft Entra](https://startwithidentity.com/vendors/iam/microsoft-entra/), [SailPoint](https://startwithidentity.com/vendors/iga/sailpoint/), and
  [Idira (formerly CyberArk)](https://startwithidentity.com/vendors/pam/cyberark/).
- **Consultancies and integrators** that deliver those platforms, which often staff remote delivery
  teams.
- **Communities and events.** Remote hiring still runs on referrals. Practitioner podcasts such as
  [Identity at the Center](https://startwithidentity.com/podcasts/identity-at-the-center/) and conferences such as
  [Identiverse](https://startwithidentity.com/conferences/identiverse/) and the [Internet Identity Workshop](https://startwithidentity.com/conferences/iiw/)
  are where distributed teams meet people. See the [conferences](https://startwithidentity.com/conferences/) list.

## How pay works for remote roles

Employers take one of two approaches: a single national band regardless of where you live, or a
band adjusted to your location. Neither is universal, so ask which applies before the offer stage.
Judge an offer against your own cost of living and the scope of the role, not a single headline
number. For the public wage data that does exist and how to negotiate, see the
[IAM salary guide](https://startwithidentity.com/guides/career/iam-salary-guide/).

## How to stand out as a remote candidate

Remote identity work rewards people who write clearly and operate independently, because a design
decision made in a document has to survive without you in the room. Prove it with:

- **A written design document** in your portfolio: the problem, options considered, the decision,
  and the rollback plan. For example, a short design for moving an application from SAML to OIDC.
- **Runbooks.** A step-by-step SCIM onboarding or certificate rollover runbook shows you can hand
  work across time zones.
- **Automation over clicks.** Scripts and configuration as code are reviewable by teammates who are
  asleep when you write them. The [recipes](https://startwithidentity.com/recipes/) are good starting points.
- **A working demo** with SSO, MFA, and [SCIM](https://startwithidentity.com/standards/scim-2-0/), built using the plan in
  [how to become an identity engineer](https://startwithidentity.com/guides/career/how-to-become-an-identity-engineer/).

## Security expectations for remote identity admins

Identity administrators hold the keys to every other system, so expect a remote employer to treat
your laptop as a privileged access workstation. Common conditions are a managed device that must pass
[device posture](https://startwithidentity.com/glossary/device-posture/) checks, a hardware security key for admin roles,
[just-in-time](https://startwithidentity.com/glossary/jit-access/) elevation rather than standing admin rights, and session
recording for the most sensitive consoles. Treat these as a sign of a mature team, and mention in
interviews that you already work this way.

## Remote interview tips

- Expect a take-home or live shared-screen exercise: tracing an OAuth flow, reading a SAML assertion,
  or writing a short design. Practice explaining while you type.
- Ask how decisions are documented and how changes to the IdP are reviewed; the answer tells you how
  mature the team is.
- Ask how they protect remote admins: phishing-resistant MFA, device posture checks, just-in-time
  elevation. A team that cannot answer is a warning sign. See
  [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/).

## Your next step

Prepare with our [IAM interview questions](https://startwithidentity.com/guides/career/iam-interview-questions/) and the
open-source [interview questions bank](https://github.com/Start-With-Identity/iam-interview-questions),
benchmark offers with the [IAM salary guide](https://startwithidentity.com/guides/career/iam-salary-guide/), and browse current
openings on the [IAM jobs board](https://startwithidentity.com/jobs/). For the wider field, see
[IAM career paths](https://startwithidentity.com/guides/career/iam-career-paths/) and the
[certifications guide](https://startwithidentity.com/guides/career/identity-security-certifications/).

## Reusable Identity and KYC with Verifiable Credentials
Source: https://startwithidentity.com/guides/decentralized-identity/reusable-identity-and-kyc-with-verifiable-credentials/
Last updated: 2026-11-05

**Reusable KYC** is identity verification done once and reused many times: a trusted issuer verifies a person, issues a [verifiable credential](https://startwithidentity.com/standards/verifiable-credentials/) attesting to the result, and the person presents that credential to the next bank, exchange or marketplace instead of uploading documents again. The verifier checks a signature, a holder binding and a revocation status in seconds. In 2026 it is the clearest near-term return from decentralized identity, because government-issued sources (the [EUDI Wallet](https://startwithidentity.com/standards/eidas-2-eudi-wallet/) and [mobile driver's licenses](https://startwithidentity.com/standards/iso-18013-5-mdl/)) are arriving at scale.

This guide is for onboarding, fraud and compliance teams. It covers the flow, the credential sources, the regulatory reliance question, the failure modes and a pilot plan. For the consumer-facing explainer, read [reusable identity verification](https://startwithidentity.com/articles/reusable-identity-verification/); for the wider context, [decentralized identity explained](https://startwithidentity.com/guides/decentralized-identity/decentralized-identity-explained/).

## The problem with today's KYC

Every service that needs to know who you are runs its own [KYC](https://startwithidentity.com/glossary/kyc/): capture an ID, take a selfie, run checks, store the data. The same person repeats this at every bank, exchange, marketplace and gig platform. It is expensive, it causes onboarding drop-off, and it scatters copies of identity documents across dozens of databases.

Those copies are a real breach surface, not a theoretical one. Coinbase's [May 2025 8-K](https://www.sec.gov/Archives/edgar/data/1679788/000167978825000094/coin-20250514.htm) says the data paid [support insiders](https://startwithidentity.com/breaches/incidents/2025-coinbase-paid-support-insiders/) collected included government ID images such as driver's licenses and passports. In October 2026, [DigiCert reported](https://bugzilla.mozilla.org/show_bug.cgi?id=2084460) that an internal system archiving customer-provided identity-validation documents, including some driver's licenses, passports and utility bills, was reachable through [self-registered accounts that skipped MFA](https://startwithidentity.com/breaches/incidents/2026-digicert-self-registered-account-archive-access/). Reusable credentials with [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/) let a verifier record "verified, over 18, resident of X" without keeping the document image at all.

## How the verify-once, reuse-many flow works

1. **Proofing.** An issuer (a government, a bank, or an [identity verification](https://startwithidentity.com/vendors/identity-verification/) provider) performs [identity proofing](https://startwithidentity.com/glossary/identity-proofing/) to a defined assurance level.
2. **Issuance.** The issuer signs a credential and delivers it to the person's [wallet](https://startwithidentity.com/glossary/digital-wallet/), usually over [OpenID4VCI](https://startwithidentity.com/glossary/openid4vci/) 1.0, bound to a key held on the device.
3. **Presentation.** The next service sends an [OpenID4VP](https://startwithidentity.com/glossary/openid4vp/) request for only the claims it needs. The wallet shows who is asking and returns a [verifiable presentation](https://startwithidentity.com/glossary/verifiable-presentation/).
4. **Verification.** The verifier checks the issuer signature, the key binding against its nonce, the status list entry, and whether the issuer is on its trust list.
5. **Decision and record.** The verifier applies its own risk rules and stores the verification result and evidence reference, not the source document.

[Zero-knowledge proofs](https://startwithidentity.com/glossary/zero-knowledge-proof/) push minimization further, for example proving age without revealing a birth date; see [age verification](https://startwithidentity.com/glossary/age-verification/).

## Credential sources compared

| Source | Assurance | Reach in late 2026 | Best for | Watch out for |
| --- | --- | --- | --- | --- |
| EUDI Wallet person identification data | High, government-issued | Member states must offer wallets by end of 2026; rollout uneven | EU onboarding, cross-border banking | Relying-party registration, per-state wallet differences |
| Mobile driver's license (mDL, ISO mdoc) | High, issuing-authority signed | US states and other jurisdictions issue their own | Age checks, US onboarding | Coverage varies by state; online use needs ISO 18013-7 or OpenID4VP |
| National digital ID schemes | High, varies by country | See [digital IDs by country](https://startwithidentity.com/digital-ids/) | Domestic regulated onboarding | Scheme-specific APIs, not always VC-based |
| Bank or IDV-provider reusable credential | Depends on the issuer's proofing | Network-dependent | Fintech, marketplaces, gig platforms | Reliance contracts and liability |
| Self-asserted or social credentials | Low | Wide | Low-risk personalization | Not KYC |

Reusable networks already exist outside the VC standards too: [ID.me](https://startwithidentity.com/vendors/identity-verification/id-me/) and [CLEAR](https://startwithidentity.com/vendors/identity-verification/clear/) run reusable consumer identity networks strongest in the US, and [Dentity](https://startwithidentity.com/vendors/decentralized-identity/dentity/) issues reusable credentials on open standards. For VC-based acceptance across many digital IDs through one API, see [Trinsic](https://startwithidentity.com/vendors/decentralized-identity/trinsic/). Ranked options: [best decentralized identity for KYC](https://startwithidentity.com/rankings/best-decentralized-identity-for-kyc/).

## The regulatory reliance question

A credential is evidence, not a compliance outcome. Two 2025-2026 developments matter:

- **EU.** eIDAS 2.0, [Regulation (EU) 2024/1183](https://eur-lex.europa.eu/eli/reg/2024/1183/oj), requires each member state to offer at least one wallet within 24 months of the implementing acts, which the [Commission says](https://ec.europa.eu/digital-building-blocks/sites/spaces/EUDIGITALIDENTITYWALLET/pages/915931903/The%2Blegal%2Band%2Btechnical%2Broad%2Bto%2BEU%2BDigital%2BIdentity%2BWallets) means availability by the end of 2026, with public authorities required to accept them. Article 5f then extends acceptance duties to regulated private relying parties, including banking and financial services; our [eIDAS 2 page](https://startwithidentity.com/standards/eidas-2-eudi-wallet/) tracks the clock.
- **US.** NIST [SP 800-63-4](https://csrc.nist.gov/pubs/sp/800/63/4/final), final on 31 July 2025, describes two federation models in [SP 800-63C-4](https://pages.nist.gov/800-63-4/sp800-63c.html): general-purpose identity providers and subscriber-controlled wallets. That gives US agencies and regulated firms a vocabulary for accepting wallet-held credentials.

Neither removes your AML duties. Document who did the proofing, to what level, how you validated the credential, and how you handle revocation and ongoing monitoring.

## Failure modes

- **Trusting the signature, not the presenter.** A valid credential on a stolen or shared phone still passes a signature check. Require holder binding and, for high-risk flows, a face match or liveness step.
- **Recovery is the soft spot.** If a lost wallet can be reissued over a phone call, attackers will call. That is [help desk social engineering](https://startwithidentity.com/techniques/help-desk-social-engineering/), the path used against [MGM Resorts](https://startwithidentity.com/breaches/incidents/2023-mgm-resorts-help-desk-ransomware/). Reissue through the same proofing as first issuance.
- **Lawful access abused at scale.** In Denmark, [a company's lawful access to the national CPR register](https://startwithidentity.com/breaches/incidents/2026-denmark-cpr-register-access-abuse/) was used for about 14 million automated searches covering about 8.8 million people. Central lookup services are a target; presentation-based checks avoid giving every verifier a query interface.
- **Stale status.** Caching a status list too long accepts revoked credentials; fetching per presentation leaks timing. Set a cache window per risk tier.
- **Over-collection.** Requesting the full PID when you need "over 18" defeats the privacy benefit, and under the EU wallet rules a request beyond your registered intended use is what wallets are built to catch.

## Pilot plan

1. **Pick one flow** where document capture hurts conversion, such as account opening for returning customers or age-gated checkout.
2. **Accept one high-assurance source** (for example mDL or an EUDI Wallet PID) as an alternative to document capture, with full fallback.
3. **Define acceptance rules** with compliance: accepted issuers, assurance level, claims, status freshness and record-keeping.
4. **Measure** completion rate, time to verify, fallback rate, and cost per verified customer against your current baseline. As a planning estimate, run at least one full billing cycle before judging cost.
5. **Expand** to more sources and flows, and consider becoming an issuer once your own verification is reusable by partners.

The [verifiable credentials implementation guide](https://startwithidentity.com/guides/decentralized-identity/verifiable-credentials-implementation-guide/) covers the build, and [choosing a decentralized identity platform](https://startwithidentity.com/guides/decentralized-identity/choosing-a-decentralized-identity-platform/) covers vendor selection.

## Where to go next

Directories: [identity verification vendors](https://startwithidentity.com/vendors/identity-verification/), [digital IDs by country](https://startwithidentity.com/digital-ids/). Guides: [customer identity verification guide](https://startwithidentity.com/guides/compliance/customer-identity-verification-guide/). Standards: [Verifiable Credentials](https://startwithidentity.com/standards/verifiable-credentials/), [OpenID4VC](https://startwithidentity.com/standards/openid4vc/), [mDL](https://startwithidentity.com/standards/iso-18013-5-mdl/), [eIDAS 2 / EUDI Wallet](https://startwithidentity.com/standards/eidas-2-eudi-wallet/).

## Rolling out zero standing privileges
Source: https://startwithidentity.com/guides/implementation/zero-standing-privileges-rollout/
Last updated: 2026-11-05

[Zero standing privileges](https://startwithidentity.com/glossary/zero-standing-privileges/) (ZSP) means no human or workload holds permanent elevated access: privileges are granted [just in time](https://startwithidentity.com/glossary/jit-access/), scoped to a task, and expire on their own. It is the strongest practical form of [least privilege](https://startwithidentity.com/glossary/least-privilege/). If no account carries standing admin rights, a phished password, a stolen [session](https://startwithidentity.com/glossary/session-hijacking/), or a leaked token has far less to abuse, and [privilege escalation](https://startwithidentity.com/glossary/privilege-escalation/) and lateral movement get much harder. This guide is for IAM, PAM, and cloud platform teams planning a 6 to 12 month rollout.

## Why standing privilege is the fuel

Standing rights turn one compromised identity into a full incident. The pattern repeats across the [Identity Breach Database](https://startwithidentity.com/breaches/):

- **Insider with permanent cloud admin.** At [Ubiquiti](https://startwithidentity.com/breaches/incidents/2021-ubiquiti-insider-cloud-credentials/), a senior developer used his own administrative access to AWS and GitHub to steal data, then posed as an outside attacker. Standing access meant nothing had to be requested or approved.
- **Workload identities with standing rights.** In the [JadePuffer attacks](https://startwithidentity.com/breaches/incidents/2026-jadepuffer-azure-service-principals/) Microsoft reported, two compromised service principals were used to request storage account keys and delete most targeted storage accounts within seven minutes. Credentials for one had appeared in a public GitHub issue.
- **A standing deployment token.** In the [Binance wallet theft](https://startwithidentity.com/breaches/incidents/2026-binance-engineer-compromise-wallet-signing-service/), the attacker found a container deployment permission token on an engineer's computer and used it to deploy a container that reached the internal wallet signing service.
- **Privilege that outlives its purpose.** [Mover entitlement accumulation](https://startwithidentity.com/techniques/mover-entitlement-accumulation/) and [orphaned account abuse](https://startwithidentity.com/techniques/orphaned-account-abuse/) are both standing-privilege problems: rights granted for a past job or a departed person that nobody removed.

NIST's [Zero Trust Architecture, SP 800-207](https://csrc.nist.gov/pubs/sp/800/207/final) frames authentication and authorization as discrete functions performed before each session to a resource is established. ZSP applies the same idea to privilege: decide per task, not once at onboarding.

## Decide the model per privilege tier

Not every role needs the same treatment. Use this table to assign a pattern before you buy or configure anything.

| Privilege tier | Examples | Target model | Approval |
| --- | --- | --- | --- |
| Tenant or org control | Global Administrator, AWS management account, domain admin | Eligible only, short JIT window | Two approvers, phishing-resistant MFA |
| Production change | Prod cloud contributor, database admin, Kubernetes cluster admin | Eligible, JIT tied to ticket | One approver or change-ticket policy |
| Scoped operational | Read access to prod logs, helpdesk password reset | JIT with policy auto-approval | Auto, with MFA and justification |
| Emergency | Break-glass accounts | Permanent active, the only standing exception | None at use time; alert on every sign-in |
| Workloads | Service principals, CI/CD tokens, automation | Short-lived workload credentials, no static secrets | Policy at issuance |

## The rollout sequence

1. **Discover privileged access.** Inventory who and what holds elevated rights across cloud, SaaS, on-prem, and [non-human identities](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/). [CIEM](https://startwithidentity.com/vendors/ciem/) and [PAM](https://startwithidentity.com/vendors/pam/) tools surface effective permissions, including rights inherited through groups.
2. **Right-size first.** Remove unused and excessive entitlements before automating. JIT on top of a bloated baseline just makes the bloat time-boxed.
3. **Convert standing to eligible.** In [Microsoft Entra](https://startwithidentity.com/vendors/iam/microsoft-entra/) Privileged Identity Management, an *eligible* assignment gives exactly the same access as a permanent one once activated; the difference is that the user must activate it, by passing MFA, giving a justification, or getting approval ([Microsoft Learn: What is PIM](https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure)). PIM assignments can target users, groups, service principals, and managed identities.
4. **Set activation policy per role.** PIM role settings let you require MFA, a Conditional Access authentication context, a justification, ticket information, and approval, and set an activation maximum duration of one to 24 hours ([Microsoft Learn: PIM role settings](https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-how-to-change-default-settings)). Note that the ticket number is information only: PIM does not validate it against your ticketing system.
5. **Extend to cloud accounts.** For AWS, IAM Identity Center calls this temporary elevated access and relies on AWS Security Competency partner solutions validated against a common set of requirements. AWS lists [Apono](https://startwithidentity.com/vendors/pam/apono/), [CyberArk](https://startwithidentity.com/vendors/pam/cyberark/) Secure Cloud Access, [Okta](https://startwithidentity.com/vendors/iam/okta/) Access Requests, and [Tenable](https://startwithidentity.com/vendors/ciem/tenable-cloud-security/) ([AWS docs](https://docs.aws.amazon.com/singlesignon/latest/userguide/temporary-elevated-access.html)).
6. **Automate grant and revoke.** Requested, approved (or auto-approved by policy), granted for a fixed window, revoked automatically. Self-service with guardrails keeps it usable.
7. **Add break-glass deliberately.** Configure [break-glass accounts](https://startwithidentity.com/glossary/break-glass/) before you make every admin eligible (see below).
8. **Bring workloads in.** Replace static secrets with short-lived credentials (see [workload identity 101](https://startwithidentity.com/guides/machine-identity/workload-identity-101/) and [non-human identity security](https://startwithidentity.com/guides/machine-identity/non-human-identity-security/)). A non-expiring admin or deploy token is standing privilege, whatever the PAM dashboard says.
9. **Measure standing privilege down to near zero.** Track, per scope, the count of permanent active privileged assignments, excluding documented break-glass. Drive it toward zero over successive quarters.

## Break-glass without lockout

ZSP has one well-documented way to fail catastrophically: everyone is eligible, nobody is active, and activation needs an approver who does not exist. Microsoft warns that you will be locked out of the tenant if all Privileged Role Administrators and Global Administrators are eligible but none are active, approval is required, and no approvers are configured. Its [emergency access guidance](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access) sets the baseline:

- At least two cloud-only emergency accounts on the `.onmicrosoft.com` domain, not federated or synced.
- Phishing-resistant authentication (FIDO2 passkey recommended, or certificate-based authentication), different from what normal admins use.
- Global Administrator assigned as **permanent active**, not eligible, for these accounts.
- Excluded from Conditional Access policies that block or restrict sign-in.
- An alert on every sign-in, and validation at least every 90 days.

## Make it usable, or it fails

ZSP dies if elevation is slow; people route around it and demand standing exceptions. Fast approvals (chat-based, policy-driven auto-approval for low-risk requests), clear audit, and good defaults matter more than the product choice. One Entra detail worth knowing: MFA required at activation may not prompt again if the user already presented strong credentials earlier in the session, so for top-tier roles pair activation with an authentication context whose Conditional Access policy sets sign-in frequency to every time.

Also watch the second gap Microsoft documents: the activation requirement applies at activation only. A user can activate on a compliant device and then use the activated role from a non-compliant one. Close it with a second Conditional Access policy scoped to the directory roles themselves.

## Readiness checklist

- [ ] Privileged inventory covers cloud, SaaS, directory, on-prem, and workloads
- [ ] Unused entitlements removed before JIT goes live
- [ ] Every top-tier role is eligible only, with approval and phishing-resistant MFA
- [ ] At least two approvers per approval-gated role
- [ ] Two break-glass accounts tested, alerted, and excluded from blocking policies
- [ ] Static admin and deploy tokens inventoried with a removal date
- [ ] Standing-privilege count reported to leadership each quarter

## Common failure modes

| Failure | What it looks like | Fix |
| --- | --- | --- |
| JIT on a bloated baseline | Users activate roles far wider than the task | Right-size before converting |
| Forgotten workloads | Service principals keep owner rights (see [JadePuffer](https://startwithidentity.com/breaches/incidents/2026-jadepuffer-azure-service-principals/)) | Short-lived workload credentials, scoped roles |
| Approval lockout | All admins eligible, no approvers configured | Named approvers plus permanent-active break-glass |
| Untested break-glass | Emergency account fails during an outage | Drill at least every 90 days |
| Help desk bypass | An attacker talks staff into resetting an admin's MFA, as in the [Okta customer super admin takeovers](https://startwithidentity.com/breaches/incidents/2023-okta-customer-help-desk-super-admin-takeover/) | Harden [help desk verification](https://startwithidentity.com/techniques/help-desk-social-engineering/); require approval for admin MFA resets |
| Friction-driven exceptions | Teams request permanent access "temporarily" | Auto-approve low risk, time-box every exception |

## Related

Guides: [what is PAM](https://startwithidentity.com/guides/fundamentals/what-is-pam/), [implementing privileged access management](https://startwithidentity.com/guides/architecture/implementing-privileged-access-management/), [how to choose a PAM solution](https://startwithidentity.com/guides/buyer-guides/how-to-choose-a-pam-solution/), [zero trust rollout](https://startwithidentity.com/guides/implementation/zero-trust-rollout/). Vendors: [PAM](https://startwithidentity.com/vendors/pam/), [CIEM](https://startwithidentity.com/vendors/ciem/). Glossary: [zero standing privileges](https://startwithidentity.com/glossary/zero-standing-privileges/), [JIT access](https://startwithidentity.com/glossary/jit-access/), [least privilege](https://startwithidentity.com/glossary/least-privilege/), [break-glass](https://startwithidentity.com/glossary/break-glass/).

## SAML vs OIDC: Which SSO Protocol Should You Use in 2026?
Source: https://startwithidentity.com/guides/fundamentals/saml-vs-oidc/
Last updated: 2026-11-05

**SAML vs OIDC verdict: use OpenID Connect for new web, mobile and API sign-in, and support SAML 2.0 wherever enterprise customers or workforce SaaS require it.** Both protocols do single sign-on. SAML 2.0 is a 2005 OASIS standard that passes signed XML assertions through the browser; OIDC is a JSON and JWT identity layer on [OAuth 2.0](https://startwithidentity.com/guides/fundamentals/oauth-vs-oidc/). Most teams end up running both.

The reason both survive is market share, not taste. In SWI's [Phishing-Resistant MFA Support Matrix](https://startwithidentity.com/reports/phishing-resistant-mfa-matrix-2026/), 83 of 95 business SaaS apps (87%) offered SAML and 30 (32%) offered OpenID Connect; 58 offered SAML only and 5 OIDC only.

## SAML vs OIDC side by side

| | SAML 2.0 | OpenID Connect |
|---|---|---|
| Standards body and status (November 2026) | OASIS Standard since 2005, stable | OpenID Foundation Final, errata set 2 (December 2023); ISO/IEC 26131:2024 |
| Data format | XML assertions, XML Signature | JSON, signed [JWT](https://startwithidentity.com/glossary/jwt/) ID token |
| Transport | Browser redirects and auto-posted forms | Redirects plus back-channel token request |
| Native mobile and SPA fit | Poor | Good, with PKCE |
| API access | None; no token for APIs | Pairs with OAuth access tokens |
| Setup | Metadata XML exchange, certificate pinning | Discovery URL plus client registration |
| Typical home | Workforce SSO into SaaS, B2B federation | Consumer login, mobile, modern SaaS, AI agents |
| Common failure | Signature wrapping, parser differentials | JWT validation errors |

## SAML 2.0

SAML is an XML-based standard, deeply entrenched in **enterprise web SSO**. The identity provider authenticates the user and posts a signed assertion to the application's Assertion Consumer Service URL; the application validates it and creates a session. If you sell to enterprises, you will be asked for SAML, because that is what their identity providers and procurement checklists speak. See the [SAML 2.0 standard page](https://startwithidentity.com/standards/saml-2-0/) for an SP-initiated login step by step and the full validation checklist.

## OpenID Connect (OIDC)

OIDC is a modern identity layer built on OAuth 2.0, using JSON and JWTs. It is the better fit for **mobile apps, single-page apps, and APIs**, with simpler tokens and a cleaner developer experience. [OIDC discovery](https://startwithidentity.com/standards/openid-connect/) lets a client self-configure from one well-known URL, which is why new integrations are faster.

## How to choose

| Your situation | Use |
|---|---|
| Your own web or mobile app sign-in | OIDC |
| Your API, or AI agents calling it | OAuth 2.0 with OIDC for the user |
| Selling to enterprises that bring their own IdP | Accept SAML and OIDC as a service provider |
| Connecting workforce SaaS to your IdP | Whatever the app supports, usually SAML |
| Legacy on-premises apps | SAML, or a gateway that speaks it |

Most [CIAM](https://startwithidentity.com/vendors/ciam/) and [IAM](https://startwithidentity.com/vendors/iam/) platforms support both, so the real question is which your counterparties require.

## The security difference nobody mentions

SAML's security record is worse than OIDC's, and the reason is structural rather than reputational. Validating an XML signature correctly is hard: canonicalization, parser differentials between the library that validates and the library that reads, and assertion wrapping have produced a long run of bypasses where a service provider accepted a forged assertion as valid. The SWI [identity CVE catalog](https://startwithidentity.com/cves/) shows the pattern:

- **Parser differentials in ruby-saml.** [CVE-2025-25291](https://startwithidentity.com/cves/cve-2025-25291/) and [CVE-2025-25292](https://startwithidentity.com/cves/cve-2025-25292/) let an attacker with one valid signed assertion log in as any user. The fix did not end it: [CVE-2025-66567](https://startwithidentity.com/cves/cve-2025-66567/), disclosed December 8, 2025, still allowed forgery below ruby-saml 1.18.0.
- **Encrypted assertion paths.** [CVE-2024-4985](https://startwithidentity.com/cves/cve-2024-4985/) let a forged response through GitHub Enterprise Server when encrypted assertions were enabled.
- **Appliance SSO.** [CVE-2025-59718](https://startwithidentity.com/cves/cve-2025-59718/) let a crafted SAML message bypass FortiCloud SSO; attackers logged in as FortiGate admins and exported configurations from December 12, 2025 ([incident record](https://startwithidentity.com/breaches/incidents/2025-fortigate-forticloud-sso-saml-bypass/)). In January 2026 a follow-on flaw, [CVE-2026-24858](https://startwithidentity.com/cves/cve-2026-24858/), hit [devices already patched](https://startwithidentity.com/breaches/incidents/2026-forticloud-sso-bypass-on-patched-fortigates/).
- **Calling code that asks the wrong question.** In August 2026 attackers exploited the [miniOrange SAML plugin for WordPress](https://startwithidentity.com/blog/2026-08-25-miniorange-saml-plugin-signature-bypass-exploited/), where a loose boolean check on PHP's `openssl_verify()` read the error value -1 as success. The cryptography worked; the code did not.
- **Forging at the source.** If an attacker steals the IdP's signing key, every service provider accepts their assertions: [federation trust abuse and SAML forgery](https://startwithidentity.com/techniques/federation-trust-abuse-saml-forgery/), often called Golden SAML.

If you operate a SAML service provider: use a maintained library and patch it, compare verification results exactly, reject unexpected signature algorithms, pin the expected signing certificate from metadata, and check that the assertion is addressed to you, is recent, answers a request you sent, and has not been replayed.

OIDC is not immune. Its failures are JWT validation errors: accepting `alg: none` ([CVE-2023-29357](https://startwithidentity.com/cves/cve-2023-29357/) in SharePoint), confusing HMAC and RSA, skipping the audience check, or not checking the signature at all, as in the [SimpleHelp OIDC token forgery](https://startwithidentity.com/breaches/incidents/2026-simplehelp-oidc-token-forgery/) of 2026. A maintained JWT library with pinned algorithms closes most of them, while XML signature validation has more places to go wrong.

## Practical implementation notes

- **You will support both.** Any B2B SaaS selling upmarket needs SAML because enterprise buyers require it, and OIDC because that is what your own application uses.
- **SCIM is a separate question.** [SCIM 2.0](https://startwithidentity.com/standards/scim-2-0/) handles [provisioning](https://startwithidentity.com/glossary/provisioning/), and enterprise buyers usually ask for SSO and SCIM together.
- **Metadata and certificate rotation** are the operational tasks that break SAML integrations in production. Automate metadata refresh where the partner supports it, and calendar every signing certificate expiry.
- **Prefer SP-initiated flows.** IdP-initiated SAML has no request to match `InResponseTo` against, which widens replay and injection risk.
- **Agents and SAML.** The [ID-JAG draft](https://startwithidentity.com/standards/id-jag-cross-app-access/) lets a client exchange a SAML assertion at the IdP for OAuth tokens, so a SAML estate is not a dead end for AI agent access.

## Tools that add SAML and OIDC for you

For B2B SaaS teams, per-connection pricing dominates. On October 30, 2026 the [Identity Pricing Transparency Index](https://startwithidentity.com/reports/identity-pricing-transparency-index-2026/) read [WorkOS](https://startwithidentity.com/vendors/ciam/workos/) SSO and Directory Sync at $125 per connection, and [SSOJet](https://startwithidentity.com/vendors/ciam/ssojet/) at $59 per connection per month billed annually with a two-connection minimum. [Auth0](https://startwithidentity.com/vendors/ciam/auth0/), [FusionAuth](https://startwithidentity.com/vendors/ciam/fusionauth/) and [Keycloak](https://startwithidentity.com/vendors/open-source/keycloak/) also federate both ways; see the [best SSO and SCIM platforms for B2B SaaS](https://startwithidentity.com/rankings/best-sso-scim-platforms-b2b-saas/). On the workforce side, [Okta](https://startwithidentity.com/vendors/iam/okta/), [Microsoft Entra](https://startwithidentity.com/vendors/iam/microsoft-entra/) and [Ping Identity](https://startwithidentity.com/vendors/iam/ping-identity/) act as IdP for both protocols.

## Where to start

See the [SSO implementation guide](https://startwithidentity.com/guides/authentication/complete-guide-implementing-sso/), the [identity federation implementation guide](https://startwithidentity.com/guides/authentication/identity-federation-implementation-guide/), and [OAuth vs OIDC](https://startwithidentity.com/guides/fundamentals/oauth-vs-oidc/) for the OAuth relationship.

## SCIM Provisioning Implementation Guide
Source: https://startwithidentity.com/guides/implementation/scim-provisioning-implementation-guide/
Last updated: 2026-07-24

Manual user provisioning is a liability. When an employee joins the organization, IT manually creates accounts in 10 different applications. When they transfer departments, maybe half the access changes are made. When they leave, their accounts linger for weeks or months because nobody remembers every system they had access to. Each gap is a security risk and a compliance violation.

SCIM (System for Cross-domain Identity Management) solves this by providing a standardized protocol for automating user provisioning and deprovisioning between an Identity Provider and Service Providers. When HR creates an employee record, SCIM automatically creates accounts in downstream applications. When the employee is terminated, SCIM disables or deletes those accounts immediately.

This guide walks you through implementing SCIM-based provisioning, from protocol fundamentals to production deployment.

## What You Will Learn

- How the SCIM 2.0 protocol works (endpoints, schemas, operations)
- Setting up SCIM provisioning from your IdP to SaaS applications
- Building a SCIM server for custom applications
- Managing the complete user lifecycle (join, move, leave)
- Handling SCIM edge cases, conflicts, and failures

## Prerequisites

1. **Identity Provider with SCIM support**, Okta, Azure AD, OneLogin, Ping Identity, or another IdP that acts as a SCIM client.
2. **Target applications with SCIM support**, SaaS applications (Slack, Salesforce, GitHub, Zoom) that expose SCIM server endpoints.
3. **User directory**, An authoritative source for user attributes, typically HR or Active Directory.
4. **Network connectivity**, The IdP must reach the SCIM endpoints of each application (typically over HTTPS on port 443).
5. **Application admin access**, You need admin credentials for each target application to configure SCIM integration.

## Architecture Overview

SCIM provisioning involves two parties:

- **SCIM Client (IdP):** Initiates provisioning requests. Your IdP maintains the authoritative user list and pushes changes to applications.
- **SCIM Server (Application):** Receives provisioning requests and creates, updates, or deletes user accounts accordingly.

**SCIM protocol basics:**

SCIM 2.0 (RFC 7643, 7644) defines a REST API with standard endpoints:

| Endpoint | Method | Description |
|----------|--------|-------------|
| `/Users` | GET | List/search users |
| `/Users` | POST | Create a user |
| `/Users/{id}` | GET | Get a specific user |
| `/Users/{id}` | PUT | Replace a user |
| `/Users/{id}` | PATCH | Update specific attributes |
| `/Users/{id}` | DELETE | Delete a user |
| `/Groups` | GET | List/search groups |
| `/Groups` | POST | Create a group |
| `/Groups/{id}` | PATCH | Update group membership |

**SCIM User Schema:**

```json
{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "userName": "jsmith@example.com",
  "name": {
    "givenName": "Jane",
    "familyName": "Smith"
  },
  "emails": [
    {
      "value": "jsmith@example.com",
      "type": "work",
      "primary": true
    }
  ],
  "active": true,
  "groups": [],
  "title": "Software Engineer",
  "department": "Engineering",
  "externalId": "EMP001234"
}
```

**Provisioning flow:**

1. HR system creates a new employee record.
2. HR data syncs to the IdP (via SCIM, HRIS connector, or manual entry).
3. IdP evaluates provisioning rules and determines which applications the employee needs access to.
4. IdP sends SCIM POST requests to each application to create user accounts.
5. IdP sends SCIM PATCH requests to add the user to appropriate groups.
6. When the employee's attributes change (title, department), the IdP sends SCIM PUT/PATCH requests to update the accounts.
7. When the employee is terminated, the IdP sends SCIM PATCH (to deactivate) or DELETE requests.

## Step-by-Step Implementation

### Step 1: Configure SCIM on Target Applications

Each SaaS application has its own SCIM setup process. The general pattern is:

1. Navigate to the application's admin console.
2. Find the SCIM/provisioning settings.
3. Generate a SCIM API token (bearer token for authentication).
4. Note the SCIM base URL (e.g., `https://api.slack.com/scim/v2`).
5. Configure which attributes the application accepts.

**Example: Configuring Slack SCIM:**

```
SCIM Base URL: https://api.slack.com/scim/v2
Authentication: Bearer token (generated in Slack admin)
Supported operations: Create, Update, Deactivate (no hard delete)
Required attributes: userName, name.givenName, name.familyName, emails
Optional attributes: title, department, profileUrl
```

### Step 2: Configure SCIM on the IdP

In your IdP, create an application integration with SCIM provisioning:

**Okta example:**

1. Go to Applications > Add Application.
2. Select the target application (e.g., Slack).
3. Under the Provisioning tab, enable "API Integration."
4. Enter the SCIM base URL and API token.
5. Test the connection.
6. Enable provisioning features:
   - Create Users
   - Update User Attributes
   - Deactivate Users
7. Configure attribute mappings.

**Attribute mapping configuration:**

```yaml
attribute_mappings:
  # IdP attribute -> SCIM attribute
  - source: "user.login"
    target: "userName"
    apply_on: "create"

  - source: "user.firstName"
    target: "name.givenName"
    apply_on: "create, update"

  - source: "user.lastName"
    target: "name.familyName"
    apply_on: "create, update"

  - source: "user.email"
    target: "emails[type eq 'work'].value"
    apply_on: "create, update"

  - source: "user.title"
    target: "title"
    apply_on: "create, update"

  - source: "user.department"
    target: "department"
    apply_on: "create, update"

  - source: "user.status"
    target: "active"
    mapping:
      "ACTIVE": true
      "DEPROVISIONED": false
    apply_on: "create, update"
```

### Step 3: Configure Group Provisioning

Group provisioning allows you to manage application-level groups from the IdP:

```json
{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
  "displayName": "Engineering Team",
  "members": [
    { "value": "user-id-1", "display": "Jane Smith" },
    { "value": "user-id-2", "display": "John Doe" }
  ]
}
```

**Adding a user to a group (PATCH):**

```json
{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    {
      "op": "add",
      "path": "members",
      "value": [
        { "value": "new-user-id" }
      ]
    }
  ]
}
```

Configure the IdP to push group memberships to the application. This enables group-based access control in the target application without manual group management.

### Step 4: Build a SCIM Server for Custom Applications

For internal or custom applications that do not have built-in SCIM support, build a SCIM server:

```python
from flask import Flask, request, jsonify
import uuid

app = Flask(__name__)

# In-memory user store (replace with database in production)
users = {}

@app.route('/scim/v2/Users', methods=['POST'])
def create_user():
    """Create a new user via SCIM."""
    data = request.json

    # Validate required fields
    if not data.get('userName'):
        return scim_error("userName is required", 400)

    # Check for duplicate
    for uid, user in users.items():
        if user['userName'] == data['userName']:
            return scim_error("User already exists", 409)

    user_id = str(uuid.uuid4())
    user = {
        'id': user_id,
        'externalId': data.get('externalId'),
        'userName': data['userName'],
        'name': data.get('name', {}),
        'emails': data.get('emails', []),
        'active': data.get('active', True),
        'title': data.get('title'),
        'department': data.get('department'),
        'meta': {
            'resourceType': 'User',
            'created': datetime.utcnow().isoformat() + 'Z',
            'lastModified': datetime.utcnow().isoformat() + 'Z',
            'location': f'/scim/v2/Users/{user_id}'
        }
    }

    users[user_id] = user

    # Provision the user in the actual application
    provision_user_in_app(user)

    return jsonify({
        'schemas': ['urn:ietf:params:scim:schemas:core:2.0:User'],
        **user
    }), 201


@app.route('/scim/v2/Users/<user_id>', methods=['PATCH'])
def patch_user(user_id):
    """Update user attributes via SCIM PATCH."""
    if user_id not in users:
        return scim_error("User not found", 404)

    data = request.json
    user = users[user_id]

    for operation in data.get('Operations', []):
        op = operation['op'].lower()
        path = operation.get('path')
        value = operation.get('value')

        if op == 'replace':
            if path == 'active':
                user['active'] = value
                if not value:
                    deactivate_user_in_app(user)
                else:
                    reactivate_user_in_app(user)
            elif path:
                set_nested_value(user, path, value)

        elif op == 'add':
            if path:
                add_nested_value(user, path, value)

    user['meta']['lastModified'] = datetime.utcnow().isoformat() + 'Z'
    update_user_in_app(user)

    return jsonify({
        'schemas': ['urn:ietf:params:scim:schemas:core:2.0:User'],
        **user
    })


@app.route('/scim/v2/Users', methods=['GET'])
def list_users():
    """List or search users via SCIM."""
    filter_param = request.args.get('filter')
    start_index = int(request.args.get('startIndex', 1))
    count = int(request.args.get('count', 100))

    result_users = list(users.values())

    # Basic filter support
    if filter_param:
        result_users = apply_scim_filter(result_users, filter_param)

    total = len(result_users)
    paginated = result_users[start_index - 1:start_index - 1 + count]

    return jsonify({
        'schemas': ['urn:ietf:params:scim:api:messages:2.0:ListResponse'],
        'totalResults': total,
        'startIndex': start_index,
        'itemsPerPage': len(paginated),
        'Resources': [{
            'schemas': ['urn:ietf:params:scim:schemas:core:2.0:User'],
            **u
        } for u in paginated]
    })


def scim_error(detail, status):
    return jsonify({
        'schemas': ['urn:ietf:params:scim:api:messages:2.0:Error'],
        'detail': detail,
        'status': status
    }), status
```

### Adding SCIM to your own application

Step 4 builds the SCIM server yourself. The other option is to buy one. Several CIAM platforms expose a SCIM endpoint on behalf of your application and run the machinery around it: connectors to the common identity providers, attribute mapping, and retry and error handling. This is the B2B SaaS case rather than the workforce case the rest of this guide describes. Your customers run Okta or Microsoft Entra ID and want to provision their own employees into your product, so your application is the SCIM server.

[Auth0](https://startwithidentity.com/vendors/ciam/auth0/) offers SCIM inside a broader CIAM platform that covers both B2C and B2B login. Provisioning is not its strongest dimension: it scores 3.5 on lifecycle provisioning in our capability rubric, lighter than a dedicated workforce or IGA tool.

[WorkOS](https://startwithidentity.com/vendors/ciam/workos/) is built around Directory Sync as a core product and scores 4.5 on lifecycle provisioning, the highest of the three. One integration abstracts across dozens of customer directories.

[SSOJet](https://startwithidentity.com/vendors/ciam/ssojet/) offers SAML, OIDC, and SCIM for B2B SaaS teams that need enterprise readiness quickly, and scores 4.0. It is a 2024 entrant, so our profile rates it emerging at medium confidence: the capability is there, the reference base is still small.

Which way to go is a build-or-buy decision, and this is the buy side of it. Work the cost through with the [build vs buy calculator](https://startwithidentity.com/tools/build-vs-buy/).

### Step 5: Implement Lifecycle Management

The complete user lifecycle has three phases:

**Joiner (New hire):**

```yaml
joiner_workflow:
  trigger: "HR creates employee record"
  steps:
    1. IdP creates user account from HR data
    2. Role assignment engine determines application access
    3. SCIM provisions user in each application
    4. Group memberships are pushed via SCIM
    5. Welcome email sent with access details
  sla: "< 1 hour from HR entry to full access"
```

**Mover (Transfer/promotion):**

```yaml
mover_workflow:
  trigger: "HR updates department, title, or location"
  steps:
    1. IdP receives updated attributes
    2. Role assignment engine re-evaluates roles
    3. Roles no longer matching are removed
    4. New matching roles are assigned
    5. SCIM updates attributes in downstream applications
    6. SCIM removes user from old groups, adds to new groups
    7. Old application access is deprovisioned
    8. New application access is provisioned
  sla: "< 4 hours from HR update to access change"
```

**Leaver (Termination):**

```yaml
leaver_workflow:
  trigger: "HR marks employee as terminated"
  steps:
    1. IdP disables user account
    2. All active sessions are revoked
    3. SCIM sends PATCH {active: false} to all provisioned applications
    4. Mailbox is converted to shared (or delegated to manager)
    5. Audit log of all access is preserved
    6. After 30 days, SCIM sends DELETE to remove accounts
  sla: "< 15 minutes from termination to full access revocation"
```

### Step 6: Set Up Monitoring and Reconciliation

SCIM provisioning can fail silently. Monitor and reconcile:

```python
# Reconciliation job: runs daily
def reconcile_provisioning(app_name):
    """Compare IdP users with application users to detect drift."""
    idp_users = idp_client.list_assigned_users(app_name)
    app_users = scim_client.list_users(app_name)

    idp_usernames = {u['userName'] for u in idp_users}
    app_usernames = {u['userName'] for u in app_users}

    # Users in IdP but not in app (provisioning failure)
    missing_in_app = idp_usernames - app_usernames
    for username in missing_in_app:
        alert(f"User {username} assigned in IdP but missing in {app_name}")
        # Auto-remediate: re-trigger provisioning
        scim_client.create_user(app_name, get_user_data(username))

    # Users in app but not in IdP (orphan accounts)
    orphans = app_usernames - idp_usernames
    for username in orphans:
        alert(f"Orphan account {username} found in {app_name}")
        # Flag for review (do not auto-delete without verification)

    # Active/inactive mismatch
    for user in idp_users:
        app_user = find_in_list(app_users, user['userName'])
        if app_user and user['active'] != app_user['active']:
            alert(f"Status mismatch for {user['userName']} in {app_name}: "
                  f"IdP={user['active']}, App={app_user['active']}")
```

## Configuration Best Practices

- **Use externalId for matching.** Set the `externalId` field to the IdP's user identifier. This prevents duplicate creation when usernames change.
- **Map only necessary attributes.** Do not push every attribute to every application. Map only what the application needs and accepts.
- **Deactivate before delete.** When a user leaves, first set `active: false` to disable the account. Delete the account only after a retention period (30-90 days) to allow for audit and potential re-hire.
- **Test with a pilot group.** Enable SCIM provisioning for a small group first. Verify that accounts are created correctly before enabling for all users.
- **Handle rate limits.** Many SaaS SCIM endpoints have rate limits. Implement retry logic with exponential backoff in your provisioning pipeline.
- **Log every SCIM operation.** Record every CREATE, UPDATE, DELETE, and failed operation. This audit log is essential for troubleshooting and compliance.

## Testing and Validation

1. **Create user test:** Assign a test user to the application in the IdP. Verify that a SCIM POST is sent and the user appears in the application within minutes.
2. **Update user test:** Change the test user's title in the IdP. Verify that a SCIM PATCH is sent and the title updates in the application.
3. **Deactivate user test:** Unassign the test user from the application. Verify that a SCIM PATCH sets `active: false` and the user can no longer log in to the application.
4. **Group membership test:** Add the test user to a group in the IdP. Verify that the group membership is pushed to the application.
5. **Bulk provisioning test:** Assign 100 users simultaneously. Verify that all are provisioned without errors or rate-limiting issues.
6. **Reconciliation test:** Manually create an orphan account in the application. Run reconciliation and verify it is detected.

## Common Pitfalls and Troubleshooting

| Problem | Cause | Solution |
|---------|-------|----------|
| Duplicate users created | externalId not set or not used for matching | Configure externalId mapping and ensure the app uses it for uniqueness |
| Attributes not updating | Attribute mapping set to "create only" | Change mapping to "create and update" |
| Deprovisioning does not work | App does not support SCIM deactivation | Use the app's native API as a fallback; contact vendor for SCIM support |
| Group push fails | App does not support SCIM Group endpoint | Push group information as a user attribute instead |
| Rate limiting during bulk operations | Too many SCIM requests in short window | Implement exponential backoff; batch operations where possible |
| Schema mismatch | App expects custom attributes not in core SCIM schema | Use SCIM schema extensions (urn:ietf:params:scim:schemas:extension:enterprise:2.0:User) |

## Security Considerations

1. **Protect SCIM tokens.** The bearer token used for SCIM authentication grants full provisioning access. Store it in a secrets vault, rotate it periodically, and restrict its scope to provisioning operations only.
2. **TLS is mandatory.** SCIM operations create and modify user accounts. All SCIM traffic must be encrypted with TLS 1.2+. Never use HTTP for SCIM endpoints.
3. **Audit all provisioning events.** Every user creation, modification, and deletion must be logged with the initiator, timestamp, and changed attributes. These logs are essential for compliance and incident investigation.
4. **Rate-limit the SCIM endpoint.** If you are building a SCIM server, implement rate limiting to prevent abuse. A compromised SCIM token could be used to mass-create accounts or mass-delete users.
5. **Validate SCIM requests.** Do not blindly trust incoming SCIM requests. Validate the authentication token, check that the request conforms to the SCIM schema, and reject malformed requests.
6. **Timely deprovisioning is critical.** The window between employee termination and account deactivation is a security gap. Minimize this window by triggering deprovisioning in real-time from the HR system, not on a batch schedule.

## Conclusion

SCIM provisioning transforms user lifecycle management from a manual, error-prone process into an automated, auditable system. When an employee joins, they have access on day one. When they transfer, their access adjusts within hours. When they leave, their access is revoked within minutes.

The implementation requires careful attribute mapping, thorough testing, and ongoing monitoring through reconciliation. But the investment pays off immediately: fewer help-desk tickets, faster onboarding, cleaner offboarding, and a defensible compliance posture. Every application you connect to SCIM is one fewer manual provisioning task and one fewer orphan account risk.

## Securing AI Agent Identities: A Guide for Security Teams
Source: https://startwithidentity.com/guides/machine-identity/securing-ai-agent-identities/
Last updated: 2026-11-05

**Securing AI agent identities** means giving every AI agent its own identity that is scoped to a task, delegated from the human it acts for, logged end to end, and revocable in seconds, instead of letting it borrow a user's session or a shared service account. The 2026 verdict: treat agents as [non-human identities](https://startwithidentity.com/guides/machine-identity/non-human-identity-security/), mint short-lived audience-bound tokens per task, and enforce authorization at every tool call.

AI agents are the newest and most dynamic kind of non-human identity. An agent is not a person and not a traditional machine. It acts on behalf of a user, makes autonomous decisions, acquires permissions at runtime, calls external APIs, and can chain actions across dozens of systems in a single task. Some spawn sub-agents. That behavior breaks the assumptions our identity systems were built on.

The risk is not theoretical. In the Cloud Security Alliance's January 2026 survey, commissioned by Oasis Security, [92% of respondents](https://cloudsecurityalliance.org/press-releases/2026/01/27/79-of-it-pros-feel-ill-equipped-to-prevent-attacks-via-nhi-csa-oasis-survey-finds) were not confident their legacy IAM could manage AI and NHI risk, 79% rated their ability to prevent NHI attacks as low or moderate, and 78% had no formally adopted policy for creating or removing AI identities.

## What an agent identity needs

An AI agent needs an identity with four properties that a service account does not provide:

- **Scoped.** Least privilege per task. An agent that reads one calendar should not be able to read every calendar.
- **Delegated.** The agent acts for a user, not as itself. The identity should carry both the agent and the human who authorized it (a [delegation chain](https://startwithidentity.com/glossary/delegation-chain/)).
- **Auditable.** Every action is traceable to the agent and the delegating user.
- **Revocable.** A misbehaving agent can be killed instantly, not after a credential-rotation project.

## Why service accounts fail

The instinct is to give each agent a [service account](https://startwithidentity.com/glossary/service-account/). It fails for three reasons:

1. **Over-broad scope.** Service accounts carry standing permissions, so a compromised or confused agent can reach far beyond its task.
2. **No delegation context.** A shared service account erases the human in the loop, so the audit log cannot say who an action was really for.
3. **Slow revocation.** Rotating a service-account credential is a project. Stopping a rogue agent needs to be a button.

## The standards, and where they stand in November 2026

The emerging pattern borrows from OAuth: short-lived, narrowly scoped tokens minted per task, carrying both the agent's identity and the delegating user's, with authorization enforced at the tool and API boundary. Each piece now has a spec:

| Problem | Standard | Status (2026-11-05) |
| --- | --- | --- |
| Agent calling a tool server | [MCP authorization](https://startwithidentity.com/standards/mcp-authorization/) | Revision 2026-07-28, stable |
| One token per server, no reuse | RFC 8707 resource indicators, RFC 9728 metadata | RFCs, required by MCP |
| Enterprise IdP decides which agent reaches which app | [ID-JAG / Cross App Access](https://startwithidentity.com/standards/id-jag-cross-app-access/) | IETF draft-06, 31 October 2026 |
| Carry user and workload context through internal calls | [Transaction Tokens](https://startwithidentity.com/standards/oauth-transaction-tokens/) | IETF draft-11, IESG milestone December 2026 |
| Workload-to-workload authentication | [WIMSE](https://startwithidentity.com/standards/wimse/) | IETF drafts, no RFC yet |
| Swap a user token for a narrower agent token | [Token exchange](https://startwithidentity.com/glossary/token-exchange/), [RFC 8693](https://www.rfc-editor.org/rfc/rfc8693.html) | RFC |
| Revoke sessions everywhere on a signal | [Shared Signals Framework](https://startwithidentity.com/standards/shared-signals-framework/) | Final, August 2025 |

Under the [MCP 2026-07-28 authorization spec](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization), servers "MUST validate that access tokens were issued specifically for them", "MUST NOT accept or transit any other tokens", and clients must send the `resource` parameter in both authorization and token requests. Dynamic Client Registration is deprecated in favor of [Client ID Metadata Documents](https://startwithidentity.com/glossary/client-id-metadata-document/). ID-JAG, per its [IETF datatracker entry](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/), lets an app get a token for a third-party API through the IdP both already trust for SSO, replacing per-user consent with IdP policy. The [Agent Identity Standards Map 2026](https://startwithidentity.com/reports/agent-identity-standards-map-2026/) tracks every spec in more detail; see [agentic identity](https://startwithidentity.com/glossary/agentic-identity/) for the concept.

## Control checklist

1. **Inventory your agents.** Register each one, with an owner, in your [NHI program](https://startwithidentity.com/guides/machine-identity/non-human-identity-security/) or an [agent registry](https://startwithidentity.com/glossary/agent-registry/). Include coding assistants and local MCP servers on developer laptops.
2. **No static keys.** Replace API keys with short-lived workload credentials ([workload identity 101](https://startwithidentity.com/guides/machine-identity/workload-identity-101/)); vault anything that must stay static with [secrets management](https://startwithidentity.com/guides/fundamentals/what-is-secrets-management/) and revoke, not just delete, any key that leaks.
3. **Audience-bind every token.** One token per resource, rejected anywhere else. This blocks the confused-deputy pattern where an agent forwards a token to a server it was never meant for.
4. **Authorize at the tool call.** Check each tool and API call, not just the initial login, with a policy engine (see [best authorization tools](https://startwithidentity.com/rankings/best-authorization-tools/)) and [just-in-time access](https://startwithidentity.com/articles/top-5-just-in-time-access-tools/) for anything privileged.
5. **Log the delegation chain.** Record agent, user, task and tool on every call.
6. **Gate high-impact actions.** Require human approval or [step-up authentication](https://startwithidentity.com/glossary/step-up-auth/) for payments, deletions and permission changes.
7. **Monitor and revoke.** Watch for anomalous agent behavior with [identity threat detection](https://startwithidentity.com/guides/fundamentals/what-is-itdr/), and wire revocation to a single control.

## Failure modes already seen in incidents

- **Leaked, never-revoked admin key.** At [LiteLLM](https://startwithidentity.com/breaches/incidents/2026-litellm-leaked-admin-key-poisoned-release/), an Agent Platform admin key committed to a public repository in May was deleted but never revoked, and was used in October to publish a poisoned release. See [secrets in repositories and CI](https://startwithidentity.com/techniques/secrets-in-repositories-and-ci/) and [static API key abuse](https://startwithidentity.com/techniques/static-api-key-abuse/).
- **Third-party app tokens as the blast radius.** In the [Salesloft Drift](https://startwithidentity.com/breaches/incidents/2025-salesloft-drift-oauth-token-theft/) and [Gainsight](https://startwithidentity.com/breaches/incidents/2025-gainsight-salesforce-token-abuse/) cases, OAuth tokens held by connected apps were used to pull data from Salesforce tenants. Agents with connector tokens have the same shape; see [refresh token abuse](https://startwithidentity.com/techniques/refresh-token-abuse/).
- **AI tools turned into secret hunters.** The [Nx npm compromise](https://startwithidentity.com/breaches/incidents/2025-nx-s1ngularity-npm-compromise/) prompted installed AI command-line tools to search machines for more secrets.
- **A hijacked coding-assistant session.** Mandiant described a [SaaS provider intrusion](https://startwithidentity.com/breaches/incidents/2026-saas-provider-ai-coding-assistant-shai-hulud/) where a developer accepted poisoned software recommended through an AI coding assistant session, leading to stolen GitHub OAuth tokens.
- **Instructions hidden in content.** [Agent instruction injection](https://startwithidentity.com/techniques/agent-instruction-injection/) and [scope escalation through delegation](https://startwithidentity.com/techniques/scope-escalation-delegation/) turn an agent's own permissions against you, which is why per-call authorization matters more than prompt filtering.

## Vendors and 2026 ownership

Specialists in the [best AI agent identity tools](https://startwithidentity.com/rankings/best-ai-agent-identity-tools/) ranking include [Aembit](https://startwithidentity.com/vendors/ai-identity/aembit/), [SlashID](https://startwithidentity.com/vendors/ai-identity/slashid/), [P0 Security](https://startwithidentity.com/vendors/ai-identity/p0-security/), [Corsha](https://startwithidentity.com/vendors/ai-identity/corsha/) and [Token Security](https://startwithidentity.com/vendors/ai-identity/token-security/). Consolidation reshaped the field in 2026: [Astrix Security](https://startwithidentity.com/vendors/ai-identity/astrix-security/) is now part of Cisco (closed June 29), [Permiso Security](https://startwithidentity.com/vendors/ai-identity/permiso-security/) part of [Okta](https://startwithidentity.com/vendors/iam/okta/) (closed August 26), [Natoma](https://startwithidentity.com/vendors/ai-identity/natoma/) part of Snowflake (closed June 3), [Entro Security](https://startwithidentity.com/vendors/ai-identity/entro-security/) part of [SailPoint](https://startwithidentity.com/vendors/iga/sailpoint/) (closed June 29), and [Oasis Security](https://startwithidentity.com/vendors/ai-identity/oasis-security/) part of [Cyera](https://startwithidentity.com/vendors/ai-identity/cyera/). After an acquisition, confirm standalone availability, roadmap and contract terms before you sign. The [Identity Consolidation Report 2026](https://startwithidentity.com/reports/identity-consolidation-report-2026/) tracks every deal.

## The bottom line

Agents are identities, and they act faster and more broadly than any human user. The teams that stay ahead give agents scoped, delegated, auditable, and revocable identities from the start, inside a broader non-human identity program. For the wider picture, read the [non-human identity security guide](https://startwithidentity.com/guides/machine-identity/non-human-identity-security/) and our analysis on [agentic AI identity](https://startwithidentity.com/blog/agentic-ai-identity-the-next-frontier/).

## SOC 2 for identity: the controls that actually matter
Source: https://startwithidentity.com/guides/compliance/soc2-for-identity/
Last updated: 2026-11-05

SOC 2 tests the controls you define against the AICPA Trust Services Criteria, and for identity almost all of the testing lands in the CC6 series on logical access. The criteria are not prescriptive: they say what must be achieved (only authorized users get access, access is removed when no longer authorized, privileges follow least privilege), and your control description says how. The auditor then samples real joiners, leavers, access reviews, and admin actions to see whether you did what you wrote. This guide maps the identity criteria to concrete controls and the evidence each one needs. See [SOC 2](https://startwithidentity.com/glossary/soc2/) for the short definition.

## What the criteria are and what is changing

SOC 2 examinations report on controls relevant to security, availability, processing integrity, confidentiality, or privacy, using the [2017 Trust Services Criteria (with revised points of focus, 2022)](https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022) issued by the AICPA's Assurance Services Executive Committee. The full criteria text is a free download that requires an AICPA account. The identity controls sit in the common criteria (CC), mainly CC6.

A Type 1 report covers control design; a Type 2 report adds operating effectiveness across a review period, which means sampled evidence.

**What changed in 2026:** on October 28, 2026 the AICPA [proposed updated 2027 criteria](https://www.aicpa-cima.com/news/article/aicpa-proposes-update-of-soc-2-r-trust-services-criteria-to-enhance-the-relevance-usability-and-value-of-cpas-reports), with comments due January 15, 2027 and a proposed effective date for engagements beginning on or after December 31, 2027 (early adoption permitted). The draft consolidates duplicative concepts, removes and adds criteria, and adds points of focus on AI governance, prompt manipulation, and data poisoning. The announcement does not describe specific CC6 changes, so plan against the 2017 criteria for now.

## The identity criteria, mapped to controls

| Criterion (topic) | Control you define | Evidence the auditor samples |
|---|---|---|
| CC6.1 Logical access security over protected assets | SSO through one IdP, MFA on production and admin access, asset inventory | IdP policy export, MFA enforcement report, app inventory |
| CC6.2 Register and authorize users before issuing credentials; remove access when no longer authorized | HR-driven joiner and leaver flows, SCIM deprovisioning, defined revoke window | Joiner tickets with approval, leaver sample with time-to-revoke |
| CC6.3 Authorize, modify, remove access based on roles, least privilege, segregation of duties | Role catalog, mover workflow, SoD rules, periodic access review | Review campaigns with revocations, SoD conflict report |
| CC6.6 Protect against threats from outside system boundaries | MFA on remote access, conditional access, IP or device restrictions for admin consoles | Conditional access policies, VPN and ZTNA config |
| CC6.7 Restrict transmission and movement of information to authorized users | Scoped API tokens, OAuth app governance, data export restrictions | Token inventory, third-party app approvals |
| CC6.8 Prevent or detect unauthorized or malicious software | Endpoint controls on admin workstations | EDR coverage on privileged devices |
| CC7 monitoring (supporting) | Alerting on admin role changes, impossible travel, MFA resets | Alert rules, sample investigations |

CC6.4 and CC6.5 cover physical access and disposal of assets; they matter to identity only through badge systems and device wipe on termination.

## Decisions you have to write down

The criteria leave these to you. Whatever you choose becomes the bar the auditor tests.

| Decision | Common choice | Trade-off |
|---|---|---|
| Revoke window for terminations | Same business day for involuntary, 24 hours for voluntary | Tighter windows need HR-to-IdP automation, not tickets |
| Access review frequency | Quarterly for production and privileged, annual for the rest | More frequent reviews are only credible if tooling generates them |
| MFA scope | All workforce SSO, mandatory phishing-resistant for admins | Exceptions must be listed, justified, and reviewed |
| Privileged access model | Just-in-time elevation through [PAM](https://startwithidentity.com/vendors/pam/) | Standing admin is easier to run and harder to defend |
| Service accounts and API keys | Owner per credential, rotation schedule, inventory | Usually the weakest control in the population |

## Step-by-step: building audit-ready identity controls

1. **Consolidate authentication.** Put every in-scope app behind one IdP such as [Okta](https://startwithidentity.com/vendors/iam/okta/) or [Microsoft Entra ID](https://startwithidentity.com/vendors/iam/microsoft-entra/). Apps outside SSO need their own evidence, so the list should be short.
2. **Wire HR as the source of truth.** Joiner and leaver events from the HRIS drive account creation and disablement through [SCIM](https://startwithidentity.com/standards/scim-2-0/). Write down the revoke window.
3. **Enforce MFA and log exceptions.** Export the policy and an exceptions register with owner and expiry. Prefer [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/) for admins.
4. **Define roles and run reviews in a tool.** Use an [IGA](https://startwithidentity.com/vendors/iga/) platform such as [SailPoint](https://startwithidentity.com/vendors/iga/sailpoint/) or [ConductorOne](https://startwithidentity.com/vendors/iga/conductorone/), or your IdP's review feature. Evidence must show reviewer, decision, and the resulting revocation. See [access certification](https://startwithidentity.com/glossary/access-certification/).
5. **Remove standing admin.** Route production and cloud admin through [just-in-time access](https://startwithidentity.com/glossary/jit-access/) with approval and expiry. See [zero standing privileges](https://startwithidentity.com/guides/implementation/zero-standing-privileges-rollout/).
6. **Inventory non-human credentials.** Every API key, service account, and OAuth app gets an owner and a rotation date. See [service account](https://startwithidentity.com/glossary/service-account/).
7. **Retain logs for the full review period.** Sign-ins, admin changes, and MFA resets must be exportable for any date in the window.
8. **Document one page per control.** Name the criterion, the control, the owner, the frequency, and the evidence source.

## Common failure modes, and the incidents behind them

- **Leavers who keep access.** A former employee downloaded customer reports after leaving in the [Cash App incident](https://startwithidentity.com/breaches/incidents/2022-cash-app-former-employee/), and a departing engineer's still-valid token copied about 170 private repositories at [CrowdSec](https://startwithidentity.com/breaches/incidents/2026-crowdsec-departing-engineer-github-token/). Both are CC6.2 failures. Technique: [orphaned account abuse](https://startwithidentity.com/techniques/orphaned-account-abuse/).
- **Movers who accumulate rights.** Reviews that only confirm and never revoke miss [mover entitlement accumulation](https://startwithidentity.com/techniques/mover-entitlement-accumulation/), a CC6.3 gap.
- **MFA gaps on customer-managed accounts.** In the [Snowflake customer campaign](https://startwithidentity.com/breaches/incidents/2024-snowflake-customer-tenant-campaign/), affected accounts lacked MFA and had not rotated credentials stolen by infostealers.
- **Help desk resets as the bypass.** The [MGM Resorts](https://startwithidentity.com/breaches/incidents/2023-mgm-resorts-help-desk-ransomware/) intrusion began with a help desk call. Your MFA reset procedure is part of CC6.2. Technique: [help desk social engineering](https://startwithidentity.com/techniques/help-desk-social-engineering/).
- **Subservice and vendor access.** In the [Okta and Sitel incident](https://startwithidentity.com/breaches/incidents/2022-okta-sitel-lapsus/), access came through a support subprocessor's workstation. Carve-out subservice organizations still need complementary controls on your side.
- **Spreadsheet reviews.** Auditors cannot tie a spreadsheet to what changed in the system.
- **Static secrets.** Long-lived keys in repositories fail CC6.1 and CC6.7. Technique: [secrets in repositories and CI](https://startwithidentity.com/techniques/secrets-in-repositories-and-ci/).

## The pragmatic path for a first audit

If you are pre-SOC 2, pick an IdP and review tool that can produce the evidence above, connect HR-driven joiner and leaver flows from day one, and run a review on schedule even at 20 employees. The Type 2 sample will show whether the process holds. For the wider evidence workflow, see the [identity audit preparation guide](https://startwithidentity.com/guides/compliance/iam-audit-preparation-guide/) and, for overlapping frameworks, [identity controls for ISO 27001](https://startwithidentity.com/guides/compliance/identity-controls-for-iso-27001/).

## The Complete Guide to Implementing Single Sign-On (SSO)
Source: https://startwithidentity.com/guides/authentication/complete-guide-implementing-sso/
Last updated: 2026-11-05

Single Sign-On (SSO) is one of the most impactful identity projects an organization can undertake. It eliminates password fatigue, reduces help-desk tickets, strengthens security posture, and gives employees a smooth experience across dozens of applications. Yet many SSO rollouts stall midway because teams underestimate the planning required or pick the wrong protocol for their environment.

This guide walks you through every phase of an SSO implementation, from protocol selection through production rollout, so you can deliver a successful project on time and without surprises.

## What You Will Learn

- How to choose between SAML 2.0 and OpenID Connect (OIDC)
- Setting up an Identity Provider (IdP) and configuring Service Providers (SPs)
- Attribute mapping, group-based authorization, and session management
- Testing strategies that catch integration issues early
- A phased rollout plan that minimizes user disruption

## Prerequisites

Before you begin, make sure the following items are in place:

1. **Identity source of truth**, An authoritative user directory such as Active Directory, Microsoft Entra ID, Okta Universal Directory, or an LDAP store. All user accounts that will participate in SSO must exist here.
2. **Application inventory**, A spreadsheet listing every application you plan to federate, the protocol it supports (SAML, OIDC, or both), and the application owner's contact information.
3. **DNS and TLS**, You need control over the DNS zone where your IdP will live (e.g., `sso.yourcompany.com`) and the ability to provision TLS certificates.
4. **Network access**, Confirm that browsers can reach both the IdP and all SPs over HTTPS. If you have split-horizon DNS or strict egress rules, document them now.
5. **Executive sponsor**, SSO touches every department. Having a sponsor who can mandate adoption and resolve disputes is critical.

## Architecture Overview

At the highest level, SSO introduces a central authentication service, the Identity Provider, that all applications (Service Providers) trust. When a user tries to access an SP, the SP redirects the browser to the IdP. The IdP authenticates the user once and returns a signed assertion (SAML) or token (OIDC) to the SP. Subsequent SP requests see the existing IdP session and skip the login prompt.

**Key components:**

- **Identity Provider (IdP):** The central authentication authority. Examples include Okta, Microsoft Entra ID, Ping Identity, OneLogin, and Keycloak.
- **Service Providers (SPs):** The applications your users access, SaaS apps, internal portals, APIs.
- **User directory:** The backend store (AD, LDAP, SCIM-provisioned directory) that the IdP reads from.
- **Browser:** The user agent that carries SAML assertions or OIDC tokens between IdP and SP via redirects.
- **Metadata exchange:** Both SAML and OIDC rely on pre-shared configuration (metadata XML or discovery endpoints) so IdP and SP know each other's URLs and signing keys.

A typical flow looks like this: User visits `app.example.com` -> SP redirects to `sso.example.com/authorize` -> IdP authenticates user -> IdP redirects back to SP with assertion/token -> SP creates a local session.

## Step-by-Step Implementation

### Step 1: Choose Your Protocol

**SAML 2.0** is the mature standard. It uses XML-based assertions and HTTP-POST or HTTP-Redirect bindings. Choose SAML when:

- Your SPs are enterprise SaaS apps (Salesforce, ServiceNow, Workday) that overwhelmingly support SAML.
- You need fine-grained attribute statements (department, cost center, entitlements).
- Your IdP is an on-premises ADFS or Shibboleth server.

**OpenID Connect (OIDC)** is built on top of OAuth 2.0 and uses JSON Web Tokens. Choose OIDC when:

- Your SPs are modern web or mobile applications.
- You need lightweight token-based auth for SPAs or APIs.
- You want simpler integration with less XML configuration.

Many organizations end up supporting both protocols because their application portfolio demands it. That is perfectly fine, every major IdP supports both simultaneously.

### Step 2: Set Up the Identity Provider

For this guide, we will use a generic IdP workflow. Adjust for your specific vendor.

1. **Install or provision the IdP.** For cloud IdPs (Okta, Microsoft Entra ID), create a tenant. For on-prem (Keycloak, ADFS), deploy the server and apply TLS certificates.
2. **Connect the user directory.** Configure an AD agent or LDAP connector so the IdP can look up users. Enable delta sync so changes propagate within minutes.
3. **Define authentication policies.** Set password complexity rules, session timeouts, and MFA requirements. At minimum, require MFA for all SSO logins.
4. **Create attribute mappings.** Map directory attributes (givenName, mail, department, groups) to the claims the IdP will include in tokens/assertions.

```yaml
# Example attribute mapping (IdP config)
mappings:
  - source: user.email
    target: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
  - source: user.firstName
    target: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
  - source: user.groups
    target: http://schemas.xmlsoap.org/claims/Group
```

### Step 3: Register the First Service Provider

Start with a low-risk, high-visibility application so the team gains confidence.

**For SAML:**

1. Download the SP metadata XML from the application's admin console (or construct it from ACS URL and Entity ID).
2. Import the metadata into your IdP to create an "application" or "relying party trust."
3. Export the IdP metadata and upload it to the SP.
4. Configure attribute mapping on the SP side so it knows which SAML attribute maps to the local username field.

**For OIDC:**

1. Register a new OIDC client in the IdP. Record the `client_id` and `client_secret`.
2. Set the redirect URI to the SP's callback endpoint (e.g., `https://app.example.com/auth/callback`).
3. Configure scopes: `openid`, `profile`, `email`, and any custom scopes.
4. Provide the IdP's discovery URL (`https://sso.example.com/.well-known/openid-configuration`) to the SP.

```json
{
  "client_id": "abc123",
  "client_secret": "REDACTED",
  "redirect_uris": ["https://app.example.com/auth/callback"],
  "response_types": ["code"],
  "grant_types": ["authorization_code"],
  "scope": "openid profile email groups"
}
```

### Step 4: Configure Session Management

Session management is where many SSO projects get tricky. You need to align three separate session lifetimes:

- **IdP session:** How long the user stays authenticated at the IdP (e.g., 8 hours).
- **SP session:** Each application's local session cookie (varies per app).
- **Refresh behavior:** Whether the SP silently re-authenticates via an iframe or forces a full redirect.

A good starting configuration is an IdP session of 8 hours with a sliding window, SP sessions of 1 hour, and silent re-authentication enabled for OIDC apps. Adjust based on your security policy.

### Step 5: Implement Group-Based Authorization

SSO is not just authentication. You should also pass authorization data. Map IdP groups to application roles so that when a user logs in, the SP automatically assigns the correct permissions.

For SAML, include group memberships in the assertion's attribute statement. For OIDC, include them in the `id_token` or make them available at the `userinfo` endpoint.

```xml
<!-- SAML Attribute Statement snippet -->
<saml:Attribute Name="groups">
  <saml:AttributeValue>App-Admins</saml:AttributeValue>
  <saml:AttributeValue>Finance-ReadOnly</saml:AttributeValue>
</saml:Attribute>
```

### Step 6: Onboard Remaining Applications

After the first SP is working, create a repeatable process:

1. Application owner submits a request with protocol preference, ACS URL/redirect URI, and required attributes.
2. IAM team creates the IdP application entry and configures attribute mapping.
3. Application owner configures their side using IdP metadata or discovery URL.
4. Both teams perform a joint test.
5. IAM team enables the application for a pilot group, then expands to all users.

Document each step in a runbook so any team member can onboard a new SP in under an hour.

## Configuration Best Practices

- **Sign everything.** For SAML, sign both the assertion and the response. For OIDC, use signed JWTs and validate signatures on the SP side.
- **Encrypt SAML assertions** when the SP supports it, especially if the assertion contains sensitive attributes.
- **Use a persistent, opaque NameID** (`urn:oasis:names:tc:SAML:2.0:nameid-format:persistent`, or a pairwise `sub` in OIDC) as the user's unique identifier, and send email as a separate attribute. Email addresses change when people marry, rename, or move between domains, and an email-based NameID then breaks or mis-links the account. Use `emailAddress` only for an SP that cannot accept anything else, and document that exception. This matches the [identity federation guide](https://startwithidentity.com/guides/authentication/identity-federation-implementation-guide/).
- **Always use `response_type=code`** (authorization code flow) for OIDC. Never use the implicit flow.
- **Rotate signing certificates** before expiry. Set calendar reminders 60 days in advance.
- **Limit token lifetime.** Access tokens should live 5-15 minutes. Refresh tokens should live no longer than the IdP session.

## Testing and Validation

### Functional Testing

- **IdP-initiated SSO:** Log in at the IdP portal and click the application tile. Verify you land on the correct page, authenticated.
- **SP-initiated SSO:** Visit the application URL directly. Verify you are redirected to the IdP, authenticate, and are returned to the application.
- **Attribute assertion:** After login, inspect the SAML assertion (using a browser extension like SAML-tracer) or decode the JWT (jwt.io) to confirm all expected attributes are present.
- **Group mapping:** Log in with users from different groups and verify role assignment is correct.

### Edge-Case Testing

- **Session expiry:** Let the IdP session expire and confirm the SP forces re-authentication.
- **Single Logout (SLO):** If you implement SLO, verify that logging out of one SP terminates the IdP session and logs the user out of other SPs.
- **Clock skew:** Temporarily set a server's clock 5 minutes ahead and verify SAML assertion validation still works (most libraries allow a small tolerance).
- **Certificate rollover:** Add a new signing certificate to the IdP, keep the old one active, and verify SPs accept assertions signed with either certificate.

### Load Testing

Use a tool like k6 or Locust to simulate hundreds of concurrent SSO logins. Watch for:

- IdP response time exceeding 500ms.
- Token endpoint returning 429 (rate limit) errors.
- SP session store (Redis, database) becoming a bottleneck.

## Common Pitfalls and Troubleshooting

| Problem | Likely Cause | Fix |
|---------|-------------|-----|
| "Invalid signature" error on SP | SP has stale IdP certificate | Re-import IdP metadata on the SP |
| User authenticated but gets 403 | Group claim missing or misnamed | Check attribute mapping; inspect token |
| Redirect loop between IdP and SP | SP session cookie not being set | Check `SameSite`, `Secure`, and domain settings on the SP cookie |
| "Audience mismatch" error | Entity ID or `client_id` mismatch | Ensure the SP's Entity ID exactly matches what the IdP expects |
| Clock skew rejection | Server time drift > 5 minutes | Enable NTP on all servers; increase `NotOnOrAfter` tolerance |
| Login works in Chrome but not Safari | Safari ITP blocks third-party cookies | Use first-party cookies or implement SameSite=None with Secure |

## Security Considerations

1. **Enforce MFA at the IdP.** SSO consolidates authentication into a single point. If that point is compromised, the attacker gains access to everything. MFA is non-negotiable.
2. **Monitor for token theft.** Use sender-constrained tokens where your IdP and apps support them: [DPoP](https://startwithidentity.com/glossary/dpop/) ([RFC 9449](https://datatracker.ietf.org/doc/html/rfc9449)) binds OAuth access and refresh tokens to a key the client holds, and [Device Bound Session Credentials](https://startwithidentity.com/glossary/device-bound-session-credentials/) bind browser session cookies to a device key. Log every token issuance event and alert on anomalies (e.g., tokens used from unexpected geographies). See [token theft](https://startwithidentity.com/glossary/token-theft/).
3. **Implement SLO carefully.** Single Logout sounds appealing but is notoriously unreliable, especially across many SPs. Consider whether forced session expiry (short session + re-auth) is a more practical approach.
4. **Restrict IdP admin access.** The IdP is now the keys to the kingdom. Limit admin access to a small team, require hardware MFA for admin logins, and audit every configuration change.
5. **Plan for IdP outage.** If the IdP goes down, no one can log in to anything. Ensure your IdP has high availability (multi-region, failover), and define a break-glass procedure for critical applications.
6. **Validate redirect URIs strictly.** For OIDC, never use wildcard redirect URIs. Each SP must register the exact callback URL.

## Conclusion

Implementing SSO is a foundational project that pays dividends for years. By selecting the right protocol for each application, setting up your IdP with strong authentication policies, methodically onboarding SPs, and testing thoroughly, you can deliver a smooth experience that both strengthens security and delights users.

The key to success is treating SSO as a program, not a one-time project. Applications will continue to join (and occasionally leave) the federation. Build repeatable processes, document everything, and invest in monitoring so your SSO infrastructure remains healthy as it grows.

## User Lifecycle Management: Automating Joiner-Mover-Leaver Processes
Source: https://startwithidentity.com/guides/implementation/user-lifecycle-management-guide/
Last updated: 2026-11-05

Every identity has a lifecycle. A person joins the organization, changes roles one or more times, and eventually leaves. Each of these transitions requires precise changes to accounts, access rights, group memberships, and application entitlements. When this lifecycle is managed manually, errors compound: new hires wait days for access, role changes leave stale permissions behind, and departed employees retain active accounts for weeks or months.

User lifecycle management (ULM) automates these transitions, using authoritative data sources, typically HR systems, to drive identity changes across your entire technology stack. This guide provides a complete implementation framework.

## Prerequisites

- **Authoritative HR source**, Workday, SAP SuccessFactors, BambooHR, or similar HRIS that tracks employee status, department, title, location, and manager.
- **Identity Provider**, [Microsoft Entra ID](https://startwithidentity.com/vendors/iam/microsoft-entra/), [Okta](https://startwithidentity.com/vendors/iam/okta/), [Ping Identity](https://startwithidentity.com/vendors/iam/ping-identity/), or similar with provisioning capabilities.
- **SCIM-compatible applications**, For automated provisioning to downstream apps.
- **Defined role catalog**, A mapping of job titles/departments to application entitlements and group memberships.
- **Stakeholder alignment**, HR, IT, Security, and business unit leaders must agree on lifecycle processes.

## Architecture: The Lifecycle Framework

### The Three Lifecycle Events

**Joiner (Onboarding)**
A new employee, contractor, or partner identity enters the organization. The lifecycle engine must:
- Create accounts in the identity provider
- Assign baseline access (email, collaboration tools, intranet)
- Assign role-specific access based on department, title, and location
- Provision accounts in downstream applications
- Notify the manager and IT support
- Initiate security training enrollment

**Mover (Role Change)**
An existing identity changes departments, titles, locations, or managers. The lifecycle engine must:
- Add new entitlements required by the new role
- Remove entitlements specific to the old role
- Update group memberships
- Trigger access reviews for entitlements that span both roles
- Update manager delegation chains
- Log all changes for audit purposes

**Leaver (Offboarding)**
An identity departs the organization. The lifecycle engine must:
- Disable the account immediately (do not delete)
- Revoke all active sessions and tokens
- Remove from all groups and application assignments
- Forward email to the manager (time-limited)
- Preserve data according to retention policies
- Transfer ownership of shared resources
- Delete the account after the retention period expires

### The Authoritative Source Model

The most reliable ULM architectures follow the authoritative source model:

```
HR System (Source of Truth)
    ↓ (sync events)
Identity Governance Platform
    ↓ (provisioning)
Identity Provider (Entra ID / Okta / etc.)
    ↓ (SCIM / API / connectors)
Downstream Applications (SaaS, on-prem, cloud)
```

The HR system is the single source of truth for identity lifecycle events. When HR creates a new employee record, the identity governance platform detects the change and initiates the joiner process. When HR updates a department field, the mover process triggers. When HR sets a termination date, the leaver process executes.

## Step-by-Step Implementation

### Step 1: Map Your Authoritative Data

Before building automation, map every attribute you need from HR to identity:

| HR Attribute | Identity Attribute | Used For |
|---|---|---|
| Employee ID | employeeId | Unique correlation key |
| First Name / Last Name | displayName, givenName, surname | Account creation |
| Email | userPrincipalName, mail | Primary identifier |
| Department | department | Group membership, access rules |
| Job Title | jobTitle | Role-based access |
| Manager | manager | Delegation, approval workflows |
| Location/Office | officeLocation | Location-based policies |
| Start Date | accountEnabled date | Joiner trigger |
| Termination Date | accountDisabled date | Leaver trigger |
| Employment Status | status | Active/inactive determination |
| Employment Type | employeeType | Employee vs contractor rules |

### Step 2: Build Your Role Catalog

The role catalog maps organizational attributes to technical entitlements. This is the most labor-intensive but most critical step.

**Example role catalog entries:**

```yaml
role: "Software Engineer"
department: "Engineering"
baseline_access:
  - Microsoft 365 E5
  - Slack (Engineering workspace)
  - GitHub (organization member)
  - Jira (Engineering project)
  - AWS Console (read-only, dev account)
groups:
  - SG-Engineering-All
  - SG-GitHub-Users
  - SG-AWS-Dev-ReadOnly

role: "Sales Representative"
department: "Sales"
baseline_access:
  - Microsoft 365 E3
  - Salesforce (Sales Cloud, Standard User)
  - Slack (Sales workspace)
  - LinkedIn Sales Navigator
  - Gong (viewer)
groups:
  - SG-Sales-All
  - SG-Salesforce-Users
  - SG-LinkedIn-SalesNav
```

Build this catalog iteratively:
1. Start with the five largest departments.
2. Interview department heads about required tools.
3. Cross-reference with actual application usage data.
4. Identify birthright access (everyone gets it) vs. role-specific access.
5. Document exception processes for access not covered by the catalog.

### Step 3: Configure HR-Driven Provisioning

**For Microsoft Entra ID:**

Use Entra ID's inbound provisioning connectors:

1. Navigate to Enterprise Applications > Provisioning.
2. Configure the HR connector (Workday, SuccessFactors, or API-driven).
3. Map HR attributes to Entra user attributes.
4. Configure scoping filters (e.g., only provision employees in specific countries initially).
5. Set attribute mappings with transformation expressions where needed.
6. Enable the provisioning job in test mode first.

**For Okta:**

1. Configure the HR integration (Workday, BambooHR, etc.) in Okta.
2. Set up profile mappings from HR to Okta Universal Directory.
3. Configure group rules based on department, title, and location.
4. Enable application assignments through group membership.

### Step 4: Implement Joiner Automation

The joiner workflow should execute in stages:

**T-7 days (Pre-hire):**
- Create the account in a disabled state
- Generate temporary credentials
- Pre-provision application accounts (email, collaboration)
- Assign to appropriate groups based on role catalog
- Notify IT support and the hiring manager

**T-0 (Start date):**
- Enable the account
- Send welcome email with credential information
- Trigger MFA enrollment workflow
- Enable access to all provisioned applications

**T+1 day (Day after start):**
- Verify all provisioning completed successfully
- Check for failed application assignments
- Generate onboarding completion report

**T+30 days:**
- Trigger initial access review with the manager
- Verify the employee has not accumulated excess permissions

### Step 5: Implement Mover Automation

Mover events are the hardest to get right because they require both adding and removing access.

**Detection:** Monitor HR attribute changes daily. When department, title, location, or manager changes:

1. **Calculate the delta**, Compare old role catalog entry with new role catalog entry.
2. **Add new entitlements**, Assign groups and applications for the new role.
3. **Flag removals for review**, Do not automatically remove old access. Instead, start a grace period (typically 14-30 days).
4. **Notify the new manager**, Ask them to review and confirm the access changes.
5. **Remove old access after grace period**, If the manager has not explicitly retained any old entitlements, remove them automatically.

The grace period prevents disruption when employees need access to both old and new systems during a transition.

### Step 6: Implement Leaver Automation

The leaver process is security-critical and must execute immediately when triggered.

**Immediate actions (within minutes of HR termination):**
1. Disable the account (do not delete).
2. Revoke all refresh tokens and active sessions.
3. Reset the password to a random value.
4. Remove from all security groups and distribution lists.
5. Disable MFA methods.
6. Block sign-in to all applications.
7. Revoke OAuth consent grants.

**Same-day actions:**
1. Set out-of-office auto-reply.
2. Configure email forwarding to the manager (30-day limit).
3. Transfer OneDrive/SharePoint ownership to the manager.
4. Reassign open tickets and tasks.
5. Remove from shared mailboxes and Teams channels.

**Retention period actions (30-90 days):**
1. Convert mailbox to shared mailbox (if needed for business continuity).
2. Archive the account's data per retention policy.
3. Generate offboarding compliance report.

**Final cleanup (after retention period):**
1. Delete the account.
2. Remove all associated data per policy.
3. Log deletion for compliance records.

### Step 7: Detect and Remediate Orphan Accounts

Orphan accounts are identities that exist in systems but have no corresponding active record in the authoritative HR source. They represent significant security risk.

**Detection methods:**
- **Reconciliation reports**, Weekly comparison of all accounts in each system against the HR master list.
- **Last login analysis**, Flag accounts with no authentication activity in 60+ days.
- **Manager validation**, Quarterly campaigns asking managers to confirm all accounts reporting to them.
- **Connector health monitoring**, Detect when provisioning connectors fail, which can cause accounts to persist after termination.

**Remediation workflow:**
1. Flag the orphan account.
2. Attempt to correlate with HR data (name matching, employee ID lookup).
3. If correlated to a terminated employee, execute the leaver process immediately.
4. If uncorrelated, disable the account and notify IT security.
5. If no owner claims the account within 30 days, archive and delete.

## Best Practices

### Start with Leavers

If you can only automate one lifecycle phase initially, choose leavers. The security risk of active accounts belonging to departed employees is the most immediate and measurable. Most organizations find dozens of orphan accounts when they first run a reconciliation.

### Use Correlation Keys, Not Names

Never match HR records to identity accounts using names alone. People share names, change names, and names have encoding variations. Use a unique, immutable identifier, employee ID, as the correlation key between HR and identity systems.

### Implement a Pre-Hire Window

Creating accounts before the start date prevents day-one productivity loss. A 5-7 day pre-hire window gives provisioning time to complete across all systems, especially slow SCIM-based provisioning.

### Log Everything

Every lifecycle action must be logged with: timestamp, source event, affected account, action taken, systems modified, and success/failure status. This audit trail is critical for compliance.

### Build Exception Workflows

Not every identity fits neatly into the joiner-mover-leaver model. Build self-service request workflows for:
- Temporary project-based access
- Cross-departmental collaboration needs
- Emergency access requests
- Contractor extensions

## Testing

### Simulation Testing

Before connecting to production HR data:
1. Create test employee records with various department/title combinations.
2. Run the joiner workflow and verify all accounts and entitlements are provisioned correctly.
3. Modify test records to simulate mover events and verify delta calculations.
4. Set termination dates and verify the leaver process executes completely.
5. Intentionally create orphan scenarios and verify detection.

### Staged Rollout

1. **Phase 1:** Single department, all lifecycle events (4 weeks).
2. **Phase 2:** Three departments, monitor for edge cases (4 weeks).
3. **Phase 3:** Full organization rollout.

At each phase, measure: provisioning time, error rate, helpdesk ticket volume, and orphan account count.

## Common Pitfalls

### Deleting Instead of Disabling

Never delete accounts immediately on termination. Deleted accounts cannot be forensically examined if a security incident is later discovered. Disable first, delete after the retention period.

### Ignoring Contractors and Vendors

Many organizations build lifecycle automation only for full-time employees, leaving contractors, vendors, and partners on manual processes. These non-employee identities often have the weakest controls and highest risk. Include them in your lifecycle framework from the start.

### Hardcoding Role Mappings

If your role catalog is embedded in code or configuration files that require IT changes, it will quickly become outdated. Build a role catalog management interface that business owners can maintain.

### Not Handling HR Data Quality

HR data is often inconsistent, missing department codes, incorrect titles, delayed termination entries. Build validation rules and exception handling. If an HR record is missing required fields, quarantine the identity event for manual review rather than provisioning with incomplete data.

## Conclusion

User lifecycle management is the foundation of identity governance. When the lifecycle is automated and driven by authoritative HR data, organizations eliminate the security gaps caused by manual processes, delayed offboarding, permission accumulation, and orphan accounts. The investment in mapping roles, building catalogs, and configuring provisioning connectors pays for itself in reduced helpdesk load, faster onboarding, and dramatically improved security posture.

Start with the leaver process to address immediate security risk, then build out joiner automation for productivity gains, and finally tackle the mover process for long-term governance maturity.

## Verifiable Credentials Implementation Guide
Source: https://startwithidentity.com/guides/decentralized-identity/verifiable-credentials-implementation-guide/
Last updated: 2026-11-05

**Implementing verifiable credentials** means standing up one or more of three roles, issuer, holder (wallet) or verifier, on a fixed stack of standards: a credential format ([SD-JWT VC](https://startwithidentity.com/glossary/sd-jwt/), ISO mdoc or W3C VC 2.0), the [OpenID4VC](https://startwithidentity.com/standards/openid4vc/) 1.0 protocols for issuance and presentation, a status list for revocation, and a trust list that says which issuers count. In 2026 the pragmatic default is to start as a verifier, build to the HAIP 1.0 profile, and support SD-JWT VC and mdoc first.

This guide is for engineering teams that have decided to build. For the concept first, read [decentralized identity explained](https://startwithidentity.com/guides/decentralized-identity/decentralized-identity-explained/) and the [Verifiable Credentials standard](https://startwithidentity.com/standards/verifiable-credentials/).

## Where the standards stand (November 2026)

| Layer | Specification | Status |
| --- | --- | --- |
| Data model | [W3C VC Data Model 2.0](https://www.w3.org/TR/vc-data-model-2.0/) | W3C Recommendation, 15 May 2025 |
| Selective disclosure | [SD-JWT, RFC 9901](https://www.rfc-editor.org/rfc/rfc9901.html) | Proposed Standard, November 2025 |
| Credential format | [SD-JWT VC](https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/) | draft-24 (5 November 2026), IESG evaluation |
| Issuance and presentation | OpenID4VCI 1.0, OpenID4VP 1.0 | [Final](https://openid.net/wg/digital-credentials-protocols/specifications/) |
| Interop profile | [HAIP 1.0](https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-1_0-final.html) | Final, 24 December 2025 |
| Status (W3C) | [Bitstring Status List v1.0](https://www.w3.org/TR/vc-bitstring-status-list/) | W3C Recommendation, 15 May 2025 |
| Status (IETF) | [Token Status List](https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/) | draft-21, RFC Editor queue |
| Unlinkable proofs | [BBS cryptosuite](https://www.w3.org/TR/vc-di-bbs/) | Candidate Recommendation Draft, 10 September 2026 |

Pin versions per integration. HAIP references SD-JWT VC draft-13, so the latest draft is not automatically what production wallets expect.

## Pick your role first

You are implementing one or more of the [issuer, holder, verifier](https://startwithidentity.com/glossary/issuer-holder-verifier/) roles, and each has different work:

- **Verifier (relying party):** request and check presentations. This is the most common starting point and the lowest lift.
- **Issuer:** sign credentials and deliver them to wallets. You need signing keys, a credential type, an issuance endpoint and a status list.
- **Holder/wallet:** usually you integrate an existing wallet rather than build one, unless the wallet is your product.

Most enterprises start as a **verifier**, because you can accept credentials others issue without standing up issuance infrastructure.

## Choose a format

| Format | Choose it when | Trade-off |
| --- | --- | --- |
| SD-JWT VC | EU wallet interop, JWT tooling, general selective disclosure | Same issuer signature on every showing unless you batch-issue |
| ISO mdoc | Driver's licenses, age checks, in-person and EU PID | CBOR tooling; separate stack from JWT |
| W3C VC 2.0 with Data Integrity | JSON-LD ecosystems, education and workforce credentials | Optional in the EU wallet framework |
| W3C VC with BBS | You need unlinkable selective disclosure | Cryptosuite not yet a Recommendation |
| [AnonCreds](https://startwithidentity.com/glossary/anoncreds/) | Existing Hyperledger Indy networks | Outside the OpenID4VC and HAIP mainstream |

## Transport: OpenID4VC and HAIP

[OpenID4VCI](https://startwithidentity.com/glossary/openid4vci/) handles issuance and [OpenID4VP](https://startwithidentity.com/glossary/openid4vp/) handles presentation. Both layer on OAuth 2.0, so you extend infrastructure you already run. HAIP narrows the options to one interoperable set: the authorization code flow with [PKCE](https://startwithidentity.com/glossary/pkce/), [PAR](https://startwithidentity.com/glossary/par/), [DPoP](https://startwithidentity.com/glossary/dpop/)-bound tokens, wallet and key attestation, DCQL queries, signed requests using the `x509_hash` client identifier, encrypted responses and ES256 signatures. If you align to HAIP from day one, EU-style wallets can talk to you without custom work.

## Identifiers and keys

Verifiers need to find the issuer's signing key. Two models exist:

- **X.509 certificate chains**, which HAIP and the [EUDI Wallet](https://startwithidentity.com/standards/eidas-2-eudi-wallet/) use, with issuers carrying chains in the `x5c` header and trust anchored in trusted lists. [mDLs](https://startwithidentity.com/standards/iso-18013-5-mdl/) chain to issuing-authority roots in the same way.
- **[DIDs](https://startwithidentity.com/standards/decentralized-identifiers-did/)**, usually `did:web` anchored to a domain you control, no ledger required. [Microsoft Entra Verified ID](https://startwithidentity.com/vendors/decentralized-identity/microsoft-entra-verified-id/), for example, [supports did:web](https://learn.microsoft.com/en-us/entra/verified-id/verifiable-credentials-standards) as its only issuer and verifier identifier. See [DID methods compared](https://startwithidentity.com/guides/decentralized-identity/did-methods-compared/).

If you need EU interoperability, plan for X.509 alongside any DID. Either way, treat issuer keys like any high-value signing key: HSM-backed, rotated, with a tested compromise procedure. [Storm-0558](https://startwithidentity.com/breaches/incidents/2023-storm-0558-microsoft-signing-key-forgery/) showed what one acquired signing key enables when validation is loose.

## Revocation and status

A credential outlives its issuance, so verifiers must know whether it is still valid. Publish status through a status list rather than a per-credential lookup: the verifier fetches the whole list, so the issuer does not learn what is being checked. Bitstring Status List requires lists of at least 16KB uncompressed for that crowd effect, and recommends random index assignment. Design this before issuing your first credential; retrofitting revocation is painful.

## Trust: which issuers count

A signature proves a credential was not tampered with, not that you should trust who issued it. That is the job of a trust list or [trust registry](https://startwithidentity.com/glossary/trust-registry/) and a governance framework such as [Trust over IP](https://startwithidentity.com/glossary/trust-over-ip/). Decide how verifiers learn which issuers are authoritative for which credential types before you go past a pilot.

## Verifier checklist

1. Validate the issuer signature with a vetted library; reject `none` and unexpected algorithms. Forged tokens accepted by weak validation, as in [SimpleHelp](https://startwithidentity.com/breaches/incidents/2026-simplehelp-oidc-token-forgery/) ([CVE-2026-48558](https://startwithidentity.com/cves/cve-2026-48558/)), are the failure to avoid.
2. Check the issuer against your trust list for that credential type.
3. Verify the key binding: RFC 9901's key binding JWT carries your `nonce`, your `aud` and an `sd_hash` over the presented SD-JWT. Without it you accept copied credentials, the same flaw as [token replay against unbound endpoints](https://startwithidentity.com/techniques/token-replay-unbound-endpoint/).
4. Enforce a fresh nonce per request and reject reuse.
5. Check validity dates and the status list entry, with a defined cache window.
6. Recompute disclosure digests; reject unknown or duplicated disclosures.
7. Request only the claims you need, with DCQL.
8. Sign your requests (`x509_hash`) so wallets can show who is asking.
9. Bind the response to the originating session; relayed QR codes are a phishing path similar to an [AitM proxy](https://startwithidentity.com/techniques/aitm-phishing-proxy/).
10. Log the verification result and evidence reference, not the full credential.

Issuers have one extra rule from RFC 9901: salts need at least 128 bits of randomness, so use a maintained library rather than hand-rolled code.

## A staged rollout

These phases are planning estimates, not measured durations.

1. **Verifier pilot (about one quarter):** accept one credential type from one issuer for one flow, such as a [reusable KYC](https://startwithidentity.com/guides/decentralized-identity/reusable-identity-and-kyc-with-verifiable-credentials/) check at onboarding, with a non-credential fallback.
2. **Add issuance** if you own credentials worth making portable, with status lists and key custody in place first.
3. **Formalize trust** with a trust list and documented governance.
4. **Scale formats and wallets** as the ecosystem matures. Test against the [European Commission's open-source reference issuer, verifier and wallet libraries](https://github.com/eu-digital-identity-wallet) and at least one third-party wallet.

## Common mistakes

- Building issuance before you have a verifier that will accept the output.
- Picking a format or draft your target wallets do not support.
- Checking the signature but skipping holder binding.
- Treating revocation and trust governance as afterthoughts.
- Assuming a ledger is required. It usually is not.

## Where to go next

Vendor selection: [choosing a decentralized identity platform](https://startwithidentity.com/guides/decentralized-identity/choosing-a-decentralized-identity-platform/). KYC angle: [reusable identity and KYC](https://startwithidentity.com/guides/decentralized-identity/reusable-identity-and-kyc-with-verifiable-credentials/). Vendors: [decentralized identity directory](https://startwithidentity.com/vendors/decentralized-identity/), including open-source stacks such as [walt.id](https://startwithidentity.com/vendors/decentralized-identity/walt-id/) and [SpruceID](https://startwithidentity.com/vendors/decentralized-identity/spruce-id/), and [best platforms](https://startwithidentity.com/rankings/best-decentralized-identity-platforms/). Use cases: [verifiable credentials use cases](https://startwithidentity.com/articles/verifiable-credentials-use-cases/).

## What Is a Non-Human Identity (NHI)? NHI Management Explained
Source: https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/
Last updated: 2026-11-05

A non-human identity (NHI) is any identity that is not a person: service accounts, API keys, OAuth apps and tokens, certificates, workloads, bots and increasingly **AI agents**. NHI management is the work of finding them, giving each one an owner, scoping and shortening its credentials, and retiring it when its job ends. In most organizations NHIs outnumber human identities many times over, and they are widely under-governed.

## Why NHIs are a growing risk

NHIs often have **broad, standing privileges**, no MFA, and credentials that rarely rotate. SWI's [Identity Breach Report 2026](https://startwithidentity.com/reports/identity-breach-report-2026/) counts a non-human identity as the abused identity in 31 of 123 identity breaches disclosed from 2021 to November 2026 (25.2%), rising from 5 of 33 in 2021-2022 to 16 of 50 in 2025-2026. Exposed secrets, stolen credentials and software supply chain compromises started most of them.

## Types of non-human identity

| Type | Example | Typical credential | Where it goes wrong |
|---|---|---|---|
| Service account | AD or Microsoft 365 functional account | Password, often never rotated | Password spraying, no MFA |
| Cloud workload identity | AWS role, Azure service principal, GCP service account | Access key, client secret, federated token | Over-privilege, leaked secrets |
| API key or personal access token | GitHub PAT, SaaS admin key | Static bearer string | Committed to code, never revoked |
| Third-party OAuth app | CRM or chat integration | Refresh token | Stolen tokens used against every customer |
| Certificate | mTLS client cert, code-signing cert | Private key | Theft, expiry outages |
| AI agent | Coding assistant, MCP client | OAuth token, sometimes a static key | Over-broad scope, unclear delegation |

## Failure modes, with real incidents

- **Service accounts without MFA.** In a July to August 2026 campaign tracked by Proofpoint, [password spraying across 28 Chilean Microsoft 365 tenants](https://startwithidentity.com/breaches/incidents/2026-teamfiltration-chile-service-accounts/) compromised seven accounts, all functional or service accounts with no MFA on default or never-rotated passwords ([password spraying](https://startwithidentity.com/techniques/password-spraying/)).
- **Stolen OAuth tokens for a SaaS integration.** In August 2025 UNC6395 used [Salesloft Drift OAuth tokens](https://startwithidentity.com/breaches/incidents/2025-salesloft-drift-oauth-token-theft/) to export data from many Salesforce tenants, then searched it for AWS keys and Snowflake tokens ([refresh token abuse](https://startwithidentity.com/techniques/refresh-token-abuse/)).
- **Credentials not rotated after a known breach.** Cloudflare's 2023 intrusion used [one access token and three service account credentials](https://startwithidentity.com/breaches/incidents/2024-cloudflare-unrotated-okta-breach-credentials/) taken in the Okta support breach that it had failed to rotate.
- **A vendor's API key.** The US Treasury intrusion ran through a [stolen BeyondTrust Remote Support key](https://startwithidentity.com/breaches/incidents/2024-us-treasury-beyondtrust-api-key/) ([static API key abuse](https://startwithidentity.com/techniques/static-api-key-abuse/)).
- **Privileged automation accounts.** At Dropbox Sign, a [compromised service account](https://startwithidentity.com/breaches/incidents/2024-dropbox-sign-service-account-compromise/) in a configuration tool had rights to act in production and reached the customer database.
- **Legacy OAuth apps nobody owned.** Midnight Blizzard sprayed a test tenant account, then used a [legacy test OAuth application](https://startwithidentity.com/breaches/incidents/2024-microsoft-midnight-blizzard-password-spray/) with elevated access to Microsoft's corporate tenant ([orphaned account abuse](https://startwithidentity.com/techniques/orphaned-account-abuse/)).

## Start with ownership, not discovery

The instinct is to buy a discovery tool, and the result is an inventory of thousands of identities that nobody acts on. The prerequisite is ownership: an identity with a named human accountable for it can be reviewed, scoped, rotated and eventually retired. One without an owner cannot be touched, because nobody will accept the risk of breaking it. Read [the credentials nobody owns](https://startwithidentity.com/blog/credentials-nobody-owns/) for five September 2026 disclosures that turned on exactly this.

A workable sequence:

1. **Assign owners** to the identities that can reach production or customer data. Unowned means scheduled for removal, and that deadline is what produces owners.
2. **Set an expiry** on every credential, even if the first expiry is a year out. An identity with no expiry never gets reviewed.
3. **Scope down using usage data**, which is the only evidence an owner will accept. In cloud estates this is what [CIEM](https://startwithidentity.com/guides/fundamentals/what-is-ciem/) tools compute.
4. **Replace static credentials** with platform-attested [workload identity](https://startwithidentity.com/glossary/workload-identity/) wherever the runtime can vouch for the caller. See [what is machine identity](https://startwithidentity.com/guides/fundamentals/what-is-machine-identity/).
5. **Vault what must stay static** with [secrets management](https://startwithidentity.com/guides/fundamentals/what-is-secrets-management/), and revoke rather than delete any secret that reached a repository.
6. **Put them in access reviews.** If your quarterly certification does not list non-human identities, it is certifying a shrinking fraction of what can reach your data.

## What AI agents change

Agents are non-human identities created faster than any review cycle, and they break two assumptions: there is no interactive login, and the agent acts for a user across several systems, so the audit question becomes a delegation chain rather than a single call. When that chain crosses into another organization, [identity chaining](https://startwithidentity.com/glossary/identity-chaining/) is the IETF draft for carrying the user and the grant across the trust boundary. Watch for [scope escalation through delegation](https://startwithidentity.com/techniques/scope-escalation-delegation/) and [agent instruction injection](https://startwithidentity.com/techniques/agent-instruction-injection/).

Standards status as of November 2026: [MCP authorization](https://startwithidentity.com/standards/mcp-authorization/) revision 2026-07-28 builds on the [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/) draft (now at draft-17, with an IESG milestone of December 2026). The [identity assertion authorization grant](https://startwithidentity.com/standards/id-jag-cross-app-access/) behind Okta's [Cross App Access](https://startwithidentity.com/glossary/cross-app-access/) is at draft-06, an IETF working group document, while its MCP binding is the stable Enterprise-Managed Authorization extension. Microsoft documents [Entra Agent ID](https://learn.microsoft.com/en-us/entra/agent-id/identity-professional/microsoft-entra-agent-identities-for-ai-agents) as available to all Entra customers, with agent identity blueprints as templates. That gives agents short-lived, revocable, identity-provider-issued tokens instead of static API keys.

The governance did not move as fast. Okta's [Agent SSO announcement](https://www.okta.com/newsroom/press-releases/okta-brings-first-class-identity-to-ai-agents-with-agent-sso/) says only 34 percent of organizations apply the same security controls to AI agents as to human workers. See [agent identity just got a protocol](https://startwithidentity.com/blog/agent-identity-gets-a-protocol/) and [agentic identity](https://startwithidentity.com/glossary/agentic-identity/).

## The NHI vendor market in 2026

Most of the first wave of NHI specialists was bought this year:

- [Astrix Security](https://startwithidentity.com/vendors/ai-identity/astrix-security/): acquired by Cisco (closed 29 June 2026); standalone sales of new licenses ended on 30 June 2026.
- [Entro Security](https://startwithidentity.com/vendors/ai-identity/entro-security/): acquired by [SailPoint](https://startwithidentity.com/vendors/iga/sailpoint/) (closed 29 June 2026) for 122.6 million dollars in cash, feeding SailPoint's Agentic Fabric.
- [Natoma](https://startwithidentity.com/vendors/ai-identity/natoma/): acquired by Snowflake (closed 3 June 2026) for 128.3 million dollars.
- [Oasis Security](https://startwithidentity.com/vendors/ai-identity/oasis-security/): acquired by [Cyera](https://startwithidentity.com/vendors/ai-identity/cyera/), completion reported 8 September 2026, for about 1 billion dollars.
- [Permiso Security](https://startwithidentity.com/vendors/ai-identity/permiso-security/): acquired by [Okta](https://startwithidentity.com/vendors/iam/okta/) (closed 26 August 2026).

Still independent: [Aembit](https://startwithidentity.com/vendors/ai-identity/aembit/), [Clutch Security](https://startwithidentity.com/vendors/ai-identity/clutch-security/), [Token Security](https://startwithidentity.com/vendors/ai-identity/token-security/) and [P0 Security](https://startwithidentity.com/vendors/ai-identity/p0-security/). Pricing is mostly quoted: 11 of 14 agentic and AI identity vendors in SWI's [pricing index](https://startwithidentity.com/reports/identity-pricing-transparency-index-2026/) are quote-only. Aembit lists 20 dollars per workload per month after 10 free workloads, and P0 shows a price only on AWS Marketplace.

| If you need | Look at |
|---|---|
| Inventory and posture across SaaS, cloud and secrets | Clutch Security, Token Security, Oasis (Cyera) |
| Workload and agent access without static keys | Aembit |
| NHI inside your IGA platform | SailPoint (with Entro) |
| NHI signals inside your workforce IdP | Okta (with Permiso), Cisco Duo (with Astrix) |
| The credentials themselves | [HashiCorp Vault](https://startwithidentity.com/vendors/machine-identity/hashicorp-vault/), [Infisical](https://startwithidentity.com/vendors/secrets/infisical/) |

## Where to start

Read the [non-human identity security guide](https://startwithidentity.com/guides/machine-identity/non-human-identity-security/), [securing AI agent identities](https://startwithidentity.com/guides/machine-identity/securing-ai-agent-identities/) and the [machine identity management guide](https://startwithidentity.com/guides/machine-identity/machine-identity-management-guide/). For tools, see the [best non-human identity security platforms](https://startwithidentity.com/rankings/best-non-human-identity-security-platforms/), [best AI agent identity tools](https://startwithidentity.com/rankings/best-ai-agent-identity-tools/) and [best machine identity for enterprises](https://startwithidentity.com/rankings/best-machine-identity-for-enterprises/), and compare [Aembit vs Astrix](https://startwithidentity.com/compare/aembit-vs-astrix-security/) and [Astrix vs Entro](https://startwithidentity.com/compare/astrix-security-vs-entro-security/).

## What Is an Identity Fabric? Architecture, Layers and Solutions
Source: https://startwithidentity.com/guides/fundamentals/what-is-identity-fabric/
Last updated: 2026-11-05

An identity fabric is a composed, multi-vendor identity architecture that connects your identity provider, orchestration, governance, privileged access and analytics tools so policy, lifecycle and visibility stay consistent across every system. It is an architecture, not a single product. The term was popularized by Gartner to describe how mature organizations actually run identity: as a set of tools, services and practices woven together across distributed, multi-cloud and hybrid environments.

The idea exists because of a simple reality: almost no enterprise has a single identity system. A typical estate has Active Directory next to [Microsoft Entra](https://startwithidentity.com/vendors/iam/microsoft-entra/), [Okta](https://startwithidentity.com/vendors/iam/okta/) for cloud SSO, a separate CIAM platform for customers, [Idira (formerly CyberArk)](https://startwithidentity.com/vendors/pam/cyberark/) or [Delinea](https://startwithidentity.com/vendors/pam/delinea/) for privileged access, [SailPoint](https://startwithidentity.com/vendors/iga/sailpoint/) or [Saviynt](https://startwithidentity.com/vendors/iga/saviynt/) for governance, and legacy applications that cannot be retired. An identity fabric is the connective architecture that makes those pieces behave like one system.

## The five layers

- **Primary identity provider.** The authentication and SSO core, commonly Okta, Microsoft Entra or [Ping Identity](https://startwithidentity.com/vendors/iam/ping-identity/). See [what is IAM](https://startwithidentity.com/guides/fundamentals/what-is-iam/).
- **Orchestration.** The engine that coordinates authentication, authorization and lifecycle flows across multiple systems and translates between protocols (SAML, OIDC, Kerberos, header-based). PingOne DaVinci and Strata Maverics are the best-known examples. See [identity orchestration](https://startwithidentity.com/glossary/identity-orchestration/).
- **Governance.** Access requests, certifications and separation of duties spanning every connected system. See [what is IGA](https://startwithidentity.com/guides/fundamentals/what-is-iga/).
- **Privileged access.** Controls for administrative accounts, integrated into governance so privileged entitlements are certified too. See [what is PAM](https://startwithidentity.com/guides/fundamentals/what-is-pam/).
- **Analytics and detection.** Identity analytics and [ITDR](https://startwithidentity.com/guides/fundamentals/what-is-itdr/) that correlate events across the fabric to detect threats and surface excess access.

Many fabrics also add an **identity data layer** underneath, a virtualized view that unifies identities from many directories and databases. [Radiant Logic](https://startwithidentity.com/vendors/iga/radiant-logic/) describes its product as an identity data fabric for exactly this job.

## Identity fabric vs identity platform vs orchestration

| | Identity platform | Identity orchestration | Identity fabric |
|---|---|---|---|
| What it is | One vendor's product or suite | One layer that wires flows between systems | The whole architecture |
| Example | Okta Workforce Identity, Microsoft Entra | PingOne DaVinci, Strata Maverics | IdP plus orchestration plus IGA plus PAM plus analytics |
| You buy it | In one contract | As a component | Over several years, component by component |
| Main risk | Gaps where the suite is weak | A new critical dependency | Trust between components becomes the attack surface |
| Best when | Estate is mostly one ecosystem | Migrating or bridging legacy apps | Heterogeneity is permanent |

## The standards that hold it together

A fabric works only if its components speak the same protocols. [SAML 2.0](https://startwithidentity.com/standards/saml-2-0/) and [OpenID Connect](https://startwithidentity.com/standards/openid-connect/) carry federation. [SCIM 2.0](https://startwithidentity.com/standards/scim-2-0/) (RFC 7643 and RFC 7644, updated in 2025 and 2026) carries provisioning. The OpenID [Shared Signals Framework](https://startwithidentity.com/standards/shared-signals-framework/), with [CAEP](https://startwithidentity.com/glossary/caep/) and RISC, has been Final since 29 August 2025 and lets one component tell another that a session or account is compromised. [AuthZEN](https://startwithidentity.com/standards/authzen/) Authorization API 1.0, Final since 11 January 2026, gives applications one way to ask an external policy engine for an access decision. When you evaluate a component, ask which of these it supports in production, not on a roadmap.

## What changed in 2026

The vendors that supply fabric layers consolidated quickly this year:

- **Orchestration:** Rubrik acquired Strata Identity on 9 June 2026. Strata's orchestration now powers Rubrik Identity Continuity, which fails authentication over to a secondary identity provider when the primary one goes down (in private preview at announcement). Ping Identity, which owns [ForgeRock](https://startwithidentity.com/vendors/iam/forgerock/) and is held by Thoma Bravo, sells DaVinci.
- **Governance:** SailPoint closed its acquisition of Entro Security on 29 June 2026, adding secrets and non-human identity discovery to its Agentic Fabric. ServiceNow closed its acquisition of [Veza](https://startwithidentity.com/vendors/iga/veza/) on 2 March 2026. Omada acquired [EmpowerID](https://startwithidentity.com/vendors/iga/empowerid/) on 24 September 2026. Workday agreed to acquire [C1 (formerly ConductorOne)](https://startwithidentity.com/vendors/iga/conductorone/) on 13 October 2026, expected to close by 31 January 2027. Quest announced in June 2026 that [One Identity](https://startwithidentity.com/vendors/iga/one-identity/) would separate into an independent company.
- **Privileged access:** Palo Alto Networks closed its CyberArk acquisition on 11 February 2026 and relaunched it as Idira on 12 May 2026. Delinea closed its acquisition of [StrongDM](https://startwithidentity.com/vendors/pam/strongdm/) on 5 March 2026.
- **Detection:** Okta closed its acquisition of [Permiso Security](https://startwithidentity.com/vendors/ai-identity/permiso-security/) on 26 August 2026 to add ITDR across human, non-human and agentic identities.

Each of these changes a roadmap or a contract in somebody's fabric. Ask every component vendor who owns it, whether standalone sales continue for your term, and what happens to connectors to competitors' products.

## Failure modes: trust between components

A fabric adds connections, and every connection is a trust relationship an attacker can use:

- **A second identity provider added by an attacker.** In the 2023 [Okta help desk campaign](https://startwithidentity.com/breaches/incidents/2023-okta-customer-help-desk-super-admin-takeover/), attackers who reset super administrator MFA added an inbound federation identity provider so they could sign in as anyone ([help desk social engineering](https://startwithidentity.com/techniques/help-desk-social-engineering/)).
- **Forged federation assertions.** In December 2025 a crafted SAML message [bypassed FortiCloud SSO](https://startwithidentity.com/breaches/incidents/2025-fortigate-forticloud-sso-saml-bypass/) on FortiGate admin accounts, and a [January 2026 wave](https://startwithidentity.com/breaches/incidents/2026-forticloud-sso-bypass-on-patched-fortigates/) hit devices that were already patched ([federation trust abuse](https://startwithidentity.com/techniques/federation-trust-abuse-saml-forgery/)).
- **A signing key that every component trusts.** Storm-0558 used an acquired Microsoft signing key to [forge tokens](https://startwithidentity.com/breaches/incidents/2023-storm-0558-microsoft-signing-key-forgery/) that enterprise mailboxes accepted.
- **Delegated administration across tenants.** Nobelium targeted more than 140 resellers and service providers to [use their delegated admin privileges](https://startwithidentity.com/breaches/incidents/2021-nobelium-delegated-admin-privileges/) into customer tenants ([cross-tenant token confusion](https://startwithidentity.com/techniques/cross-tenant-token-confusion/) is the related technique for multi-tenant apps).
- **The primary identity provider goes down.** Every federated app loses new sign-ins. Plan [break-glass](https://startwithidentity.com/glossary/break-glass/) accounts and an [identity resilience](https://startwithidentity.com/glossary/identity-resilience/) path, and read the [IAM disaster recovery guide](https://startwithidentity.com/guides/implementation/iam-disaster-recovery-guide/).

## What a fabric costs

There is no fabric price, only component prices, and most of them are quoted. In SWI's [Identity Pricing Transparency Index 2026](https://startwithidentity.com/reports/identity-pricing-transparency-index-2026/), IAM platforms score 33 out of 100, PAM 16 and IGA 5 (no IGA vendor publishes a list price). The published anchors, checked on 30 October 2026: Okta Workforce Starter $6 and Essentials $17 per user per month with a $1,500 annual minimum, and Microsoft Entra ID P1 $7, P2 $10, Entra ID Governance $7 and Entra Suite $12 per user per month paid yearly. Budget integration services separately; for IGA and PAM they are a large share of first-year cost.

## How to build one

You do not buy an identity fabric in a single purchase, and you should not try to build it all at once:

1. **Map the estate**: every identity store, identity provider, governance and privileged access tool, and which apps depend on which.
2. **Pick the primary identity provider** for each population (workforce, customers, partners).
3. **Close the most pressing gap first**, usually governance of leavers or privileged access, and connect it through SCIM and shared signals.
4. **Add orchestration** where legacy apps or migrations need protocol translation.
5. **Lock down the trust paths**: who can add a federation trust, an admin role or a signing key in each component, with alerts on every change.
6. **Feed one detection layer** from every component's logs.

The architecture matters more than any one product: the value comes from the integration between specialized components, not from a single platform trying to do everything. See [identity-first architecture](https://startwithidentity.com/guides/architecture/identity-first-architecture/) for the design principles.

## Identity fabric solutions to shortlist

For the vendors that supply each layer, see the [top identity fabric solutions](https://startwithidentity.com/articles/top-7-identity-fabric-solutions/) and [identity orchestration platforms](https://startwithidentity.com/articles/top-7-identity-orchestration-platforms/), the rankings for [best IAM for enterprises](https://startwithidentity.com/rankings/best-iam-for-enterprises/), [best IGA tools](https://startwithidentity.com/rankings/best-iga-tools/), [best PAM tools](https://startwithidentity.com/rankings/best-pam-tools/) and [best ITDR tools](https://startwithidentity.com/rankings/best-itdr-tools/), and the [Okta vs Microsoft Entra](https://startwithidentity.com/compare/okta-vs-microsoft-entra/), [Okta vs Ping Identity](https://startwithidentity.com/compare/okta-vs-ping-identity/) and [SailPoint vs Saviynt](https://startwithidentity.com/compare/sailpoint-vs-saviynt/) comparisons.

## What Is CIEM (Cloud Infrastructure Entitlement Management)?
Source: https://startwithidentity.com/guides/fundamentals/what-is-ciem/
Last updated: 2026-11-05

CIEM (Cloud Infrastructure Entitlement Management) is the practice and tooling that discovers every identity in AWS, Azure and Google Cloud, computes what each one can actually do, and removes the permissions it does not use. In the cloud, permissions sprawl fast, and most identities, human and machine, end up with far more access than they use. CIEM is how you find that gap and close it.

## The problem CIEM solves

Cloud IAM systems are powerful and complex. Roles, policies and inherited permissions combine into [effective permissions](https://startwithidentity.com/glossary/entitlement/) that are hard to see. CIEM computes what an identity can actually do, then flags excessive, unused and risky access. See the [CIEM glossary entry](https://startwithidentity.com/glossary/ciem/) for the short definition.

## Core capabilities

- **Discovery** of every human and [non-human identity](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/) and its permissions, including federated users arriving from your identity provider.
- **Effective-permission analysis** across tangled policies and roles.
- **Right-sizing** toward [least privilege](https://startwithidentity.com/glossary/least-privilege/), usually by generating a smaller policy from observed usage.
- **Risk detection** for cross-account access, privilege escalation paths and toxic combinations.
- **Just-in-time access** in some products, so elevated rights exist only for an approved window ([JIT access](https://startwithidentity.com/glossary/jit-access/), [zero standing privileges](https://startwithidentity.com/glossary/zero-standing-privileges/)).

## Why cloud permissions are unreadable

The reason CIEM exists as a category is that a cloud permission is a computation rather than a lookup. In AWS alone the [policy evaluation logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) combines identity policies, resource policies, permission boundaries, service control policies, session policies and role chaining. Ask a competent engineer what a specific service principal can actually do across your accounts and, without tooling, they cannot tell you.

That is the test for whether you need CIEM. If nobody can answer that question, and nobody has removed an unused permission this quarter, the problem is real.

## CIEM vs CSPM vs IGA vs PAM

| | CIEM | CSPM | IGA | PAM |
|---|---|---|---|---|
| Question it answers | What can this cloud identity actually do? | Is this cloud resource configured safely? | Who should have access to what, and who approved it? | Who is using privileged access right now? |
| Scope | AWS, Azure, GCP (some add Oracle Cloud, Kubernetes) | Cloud resources | All systems, on-premises and SaaS | Admin accounts, servers, sessions |
| Typical output | Unused permissions, escalation paths, right-sized policies | Misconfigurations | Access reviews, provisioning, separation of duties | Vaulted credentials, recorded sessions |
| Where it ships | CNAPP suites or specialists | CNAPP suites | IGA platforms | PAM platforms |

[IGA](https://startwithidentity.com/guides/fundamentals/what-is-iga/) governs access broadly. [PAM](https://startwithidentity.com/guides/fundamentals/what-is-pam/) controls privileged sessions. CSPM finds resource misconfigurations. CIEM is specifically about cloud identities and entitlements, and it increasingly ships inside cloud security platforms (CNAPP) rather than as a standalone product.

## Most findings are not humans

The instinct is to look for over-privileged administrators. In practice the bulk of findings are non-human: service principals created for a project that ended, roles with wildcard actions granted during a deadline, and CI identities with permissions far beyond the one deploy they perform.

## Failure modes CIEM is meant to catch

- **Over-privileged service principals.** In June 2026 the operator Microsoft tracks as JadePuffer used [two compromised service principals](https://startwithidentity.com/breaches/incidents/2026-jadepuffer-azure-service-principals/) in one Azure tenant to request storage account keys and delete most targeted storage accounts within seven minutes. The blast radius was set by what those principals were allowed to do.
- **Application secrets that sign in as apps.** In November 2026 Todyl reported an actor [signing in to Entra ID as applications](https://startwithidentity.com/breaches/incidents/2026-entra-id-stolen-app-secrets-27-orgs/) with stolen client secrets, reaching 27 organizations and requesting Key Vault and Storage tokens. Unused app permissions are exactly what CIEM is built to remove ([static API key abuse](https://startwithidentity.com/techniques/static-api-key-abuse/)).
- **Over-scoped storage tokens.** A Microsoft AI research repository exposed an [Azure SAS token](https://startwithidentity.com/breaches/incidents/2023-microsoft-ai-research-sas-token-exposure/) that granted full control of a storage account, not just the models it was meant to share ([secrets in repositories](https://startwithidentity.com/techniques/secrets-in-repositories-and-ci/)).
- **Insiders with standing cloud admin.** In the [Ubiquiti case](https://startwithidentity.com/breaches/incidents/2021-ubiquiti-insider-cloud-credentials/) a developer used his own AWS and GitHub admin access to steal data. Standing privilege with no time bound is the root problem; JIT is the fix.

## Turning findings into an outcome

A raw findings list from a large tenant is unusable, so the programme matters more than the scan:

1. **Start with unused permissions on non-human identities**, which are the safest to remove and the largest in number.
2. **Use usage data as the evidence.** "This role has not used these 40 actions in 90 days" is an argument an owner will accept; "this role is over-privileged" is not. (The 90-day window is a common practitioner convention, not a standard; pick one and apply it consistently.)
3. **Right-size with a rollback path**, because the fear of breaking production is what stops removal.
4. **Move the reducible remainder to just-in-time access** rather than trying to perfect standing permissions.

Measure the count of identities holding unused high-risk permissions over time. If that number is not falling, the tool is producing reports rather than outcomes.

## Native tools first

Before buying, check what your cloud already gives you. AWS [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) has unused access analyzers that flag unused roles, access keys and passwords, and unused services and actions on active roles; it can also generate a policy from CloudTrail activity. AWS bills unused access analysis per IAM role and user analyzed per month. In Microsoft's case, the dedicated product is gone: Entra Permissions Management reached [end of support on 1 November 2025](https://startwithidentity.com/vendors/ciem/microsoft-entra-permissions/), with permissions discovery and the Permission Creep Index carried into Defender for Cloud's Defender CSPM plan and [Delinea](https://startwithidentity.com/vendors/pam/delinea/) named as migration partner.

## The CIEM market in 2026

Ownership moved this year, and it matters for roadmaps and renewals:

- [Wiz](https://startwithidentity.com/vendors/ciem/wiz/) became part of Google Cloud when Google completed its 32 billion dollar acquisition on 11 March 2026. Wiz says its products continue to work across AWS, Azure, Google Cloud and Oracle Cloud.
- Palo Alto Networks renamed Prisma Cloud as [Cortex Cloud](https://startwithidentity.com/vendors/ciem/prisma-cloud/), with CIEM as one module beside posture and runtime security.
- Tenable sells its Ermetic-based CIEM as [Tenable One Cloud Exposure](https://startwithidentity.com/vendors/ciem/tenable-cloud-security/), including a documented just-in-time access workflow.
- [Veza](https://startwithidentity.com/vendors/iga/veza/), an effective-permissions graph often evaluated against CIEM, was acquired by ServiceNow (closed 2 March 2026).

Pricing is mostly hidden. In SWI's [Identity Pricing Transparency Index 2026](https://startwithidentity.com/reports/identity-pricing-transparency-index-2026/), CIEM scores 28 out of 100 and six of nine vendors are quote-only. The exceptions, checked on 5 November 2026: [Sonrai Security](https://startwithidentity.com/vendors/ciem/sonrai-security/) lists a 15,000 dollar a year Startup tier and 150 dollars per cloud account per month for 10 to 50 accounts; [Uptycs](https://startwithidentity.com/vendors/ciem/uptycs/) starts at 3 dollars per workload per month with a 12,000 dollar yearly minimum; and [Britive](https://startwithidentity.com/vendors/ciem/britive/) shows 12-month packages from 70,000 dollars only on AWS Marketplace.

## CIEM shortlist by situation

| Your situation | Start with |
|---|---|
| Already buying a CNAPP and want identity findings in the same graph | Wiz, Cortex Cloud, [Orca Security](https://startwithidentity.com/vendors/ciem/orca-security/), Tenable One Cloud Exposure |
| Want unused permissions removed and enforced, not just reported | Sonrai Security |
| Want standing cloud admin replaced by just-in-time grants | Britive, Tenable JIT |
| Single cloud, small team, limited budget | Native tools such as IAM Access Analyzer first |
| Former Entra Permissions Management customer | Defender CSPM for discovery, plus a specialist for enforcement |

For the ranked view, see [best CIEM for enterprises](https://startwithidentity.com/rankings/best-ciem-for-enterprises/) and [best CIEM for multi-cloud](https://startwithidentity.com/rankings/best-ciem-for-multi-cloud/), the [top CIEM platforms](https://startwithidentity.com/articles/top-5-cloud-infrastructure-entitlement-management/) and [open-source CIEM tools](https://startwithidentity.com/articles/top-7-open-source-cloud-entitlement-ciem-tools/). Compare [Wiz vs Sonrai](https://startwithidentity.com/compare/wiz-vs-sonrai-security/), [Wiz vs Orca](https://startwithidentity.com/compare/wiz-vs-orca-security/) and [Britive vs Sonrai](https://startwithidentity.com/compare/britive-vs-sonrai-security/), or browse all [CIEM vendors](https://startwithidentity.com/vendors/ciem/).

## What Is Customer Identity and Access Management (CIAM)?
Source: https://startwithidentity.com/guides/fundamentals/what-is-ciam/
Last updated: 2026-11-05

CIAM (customer identity and access management) is the identity layer that handles sign-up, login, profiles, consent and access for an application's customers and consumers, not its employees. It is built for consumer scale and conversion, with self-service registration, social and passkey login, and account recovery. It is not workforce [IAM](https://startwithidentity.com/guides/fundamentals/what-is-iam/), identity governance, or document-and-selfie identity verification, though it often calls verification vendors at sign-up.

**Verdict as of November 2026:** buy CIAM rather than build it, choose on standards support, recovery and fraud controls and the pricing unit (MAU, retained users or SSO connections), and make passkeys the default sign-in. For a shortlist, see [best CIAM platforms](https://startwithidentity.com/rankings/best-ciam-platforms/); for the one-line definition, the [CIAM glossary entry](https://startwithidentity.com/glossary/ciam/).

## How CIAM differs from workforce IAM

Workforce IAM optimizes for control and governance. CIAM optimizes for **conversion, scale and experience**: every extra field or friction point in a signup flow costs revenue. CIAM systems also carry privacy and consent obligations that internal systems usually do not. Our [CIAM vs IAM](https://startwithidentity.com/articles/ciam-vs-iam/) article goes deeper.

| | Workforce IAM | CIAM |
|---|---|---|
| Users | Employees and contractors, known in advance via HR | Customers who register themselves |
| Scale | Thousands to hundreds of thousands | Up to tens of millions, with spiky traffic |
| Friction tolerance | High: login is part of the job | Low: users abandon |
| Core features | SSO to internal apps, governance, access reviews | Registration, social and passkey login, consent, recovery, fraud defense |
| Typical pricing | Per employee per month | Per monthly active user, or per enterprise connection in B2B |
| Main threat | Phishing of staff, privilege misuse | [Credential stuffing](https://startwithidentity.com/glossary/credential-stuffing/), [account takeover](https://startwithidentity.com/glossary/account-takeover/), fake sign-ups |

## B2C vs B2B CIAM

- **B2C** serves individual consumers: high volume, social login, [progressive profiling](https://startwithidentity.com/glossary/progressive-profiling/), fraud and bot defense.
- **B2B / SaaS** serves organizations: tenants, enterprise SSO and SCIM for your customers, and delegated administration. Many developer-first platforms specialize here. See [B2B vs B2C CIAM](https://startwithidentity.com/articles/b2b-vs-b2c-ciam/) and [best CIAM for B2B SaaS](https://startwithidentity.com/rankings/best-ciam-for-b2b-saas/).

## The standards underneath

A CIAM platform should speak open protocols so you can change vendors later:

- **[OpenID Connect](https://startwithidentity.com/standards/openid-connect/)** and **[OAuth 2.0](https://startwithidentity.com/standards/oauth-2-0/)** (moving to [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/)) for sign-in and API access tokens.
- **[WebAuthn and FIDO2](https://startwithidentity.com/standards/webauthn-fido2/)** for [passkeys](https://startwithidentity.com/glossary/passkey/).
- **[SAML 2.0](https://startwithidentity.com/standards/saml-2-0/)** and **[SCIM 2.0](https://startwithidentity.com/standards/scim-2-0/)** in B2B, where your customers bring their own IdP and expect automated provisioning.
- **[FAPI](https://startwithidentity.com/standards/fapi/)** for banking and other high-value APIs.

## Common capabilities

Passwordless and [passkeys](https://startwithidentity.com/guides/authentication/passkeys-101/), social login, [MFA](https://startwithidentity.com/glossary/mfa/), bot and account-takeover defense, consent capture, hosted or embeddable login UI, user migration tools, and APIs and SDKs for developers.

## What makes CIAM hard

The hard problems are not login. They are the ones that only appear at consumer scale:

- **Fraud and account takeover.** Consumer accounts are attacked continuously with credential stuffing from unrelated breaches and real-time relay kits that capture a valid session. Rate limiting alone will not stop distributed attempts from residential proxies. See [CIAM account takeover prevention](https://startwithidentity.com/articles/ciam-account-takeover-prevention/).
- **Recovery at scale.** Every recovery path is an attack path. Email-based reset makes the account exactly as strong as the mailbox, and knowledge-based questions are answerable from public data.
- **Consent as a data problem.** Regulators ask what a specific user was shown and agreed to at a specific moment. That needs versioned consent records tied to policy text, not a boolean column. See [consent management](https://startwithidentity.com/glossary/consent-management/).
- **Migration.** Moving an existing user base means transferring password hashes, invalidating sessions and re-enrolling MFA, usually with a dual-run period rather than a switch. See the [CIAM migration guide](https://startwithidentity.com/articles/ciam-migration-guide/).
- **Cost curves.** Per-MAU pricing that is reasonable at 50,000 users can dominate unit economics at 5 million.

## What CIAM costs in 2026

CIAM is one of the more transparent identity categories. In our [Identity Pricing Transparency Index](https://startwithidentity.com/reports/identity-pricing-transparency-index-2026/), 55.2% of the 29 CIAM vendors publish a paid price and 24.1% are quote-only. Free tiers checked live on 30 October 2026:

| Vendor | Free tier | Paid entry point |
|---|---|---|
| [WorkOS](https://startwithidentity.com/vendors/ciam/workos/) AuthKit | 1,000,000 MAU | $125 per SSO or Directory Sync connection (1 to 15) |
| [Clerk](https://startwithidentity.com/vendors/ciam/clerk/) | 50,000 monthly retained users per app | Pro $25/month |
| [Microsoft Entra External ID](https://startwithidentity.com/vendors/ciam/microsoft-entra-external-id/) | 50,000 MAU | Pay-as-you-go |
| [Auth0](https://startwithidentity.com/vendors/ciam/auth0/) (Okta) | 25,000 MAU | Essentials from $35/month (B2C) or $150/month (B2B) |
| [Amazon Cognito](https://startwithidentity.com/vendors/ciam/amazon-cognito/) | 10,000 MAU | Essentials $0.015 per MAU |
| [Stytch](https://startwithidentity.com/vendors/ciam/stytch/) (Twilio) | 10,000 MAU | Pay as you go |

Two traps: "active user" is defined differently by each vendor (Clerk counts retained users, Stytch counts AI agents alongside users), and in B2B the per-connection SSO and SCIM fees can exceed the user fees. Enterprise-focused vendors such as [Transmit Security](https://startwithidentity.com/vendors/ciam/transmit-security/) are quote-only. See [CIAM pricing models explained](https://startwithidentity.com/articles/ciam-pricing-models-explained/).

## Compliance: what to ask for

Certifications belong to the vendor's service, not your deployment. Ask for the current SOC 2 Type II report, the ISO/IEC 27001 certificate and its edition, and, if you handle US health data, a signed HIPAA business associate agreement. As one example, [Auth0's compliance documentation](https://auth0.com/docs/secure/data-privacy-and-compliance), checked 5 November 2026, lists an annual SOC 2 Type 2 audit, ISO 27001, 27017 and 27018 certification, and a BAA on request for covered entities. Our [compliant CIAM platforms](https://startwithidentity.com/rankings/best-compliant-ciam-platforms/) and [CIAM for healthcare](https://startwithidentity.com/rankings/best-ciam-for-healthcare/) rankings track this per vendor.

## Where CIAM is heading

Two shifts are visible in 2026. First, passkeys are mainstream in consumer sign-in. The FIDO Alliance's [Passkey Index 2026](https://fidoalliance.org/passkey-index-2026/) reports that 36% of successful sign-ins at participating services now use a passkey, up from 26% in 2025, and that passkey sign-ins succeed 93% of the time against 78% for traditional MFA. Amazon [said on 20 October 2026](https://www.aboutamazon.com/news/retail/amazon-passwordless-sign-in-passkey) that more than 500 million customers have enabled passkeys. The gain only holds once the password fallback and weak recovery go.

Second, regulation is pushing toward holder-presented credentials. Under [eIDAS 2.0](https://startwithidentity.com/standards/eidas-2-eudi-wallet/), EU member states must offer an [EUDI Wallet](https://startwithidentity.com/glossary/eudi-wallet/) by the end of 2026, and private relying parties that are legally or contractually required to use strong user authentication, including banks, must accept it on user request within 36 months of the December 2024 implementing acts. That changes identity verification at the front of the funnel; it does not replace the customer account.

## Where to start

Compare [CIAM vendors](https://startwithidentity.com/vendors/ciam/), read [how to evaluate CIAM](https://startwithidentity.com/guides/buyer-guides/how-to-evaluate-ciam/), check segment rankings such as [best CIAM for startups](https://startwithidentity.com/rankings/best-ciam-for-startups/) and [best CIAM for enterprises](https://startwithidentity.com/rankings/best-ciam-for-enterprises/), or see head-to-head [comparisons](https://startwithidentity.com/compare/) like [Auth0 vs Clerk](https://startwithidentity.com/compare/auth0-vs-clerk/).

## What Is Decentralized Identity?
Source: https://startwithidentity.com/guides/fundamentals/what-is-decentralized-identity/
Last updated: 2026-11-05

---

Decentralized identity is a model where individuals and organizations hold their own verifiable credentials in a digital wallet and present them directly to whoever needs to check them, without a central identity provider brokering every interaction. It is often called **[self-sovereign identity (SSI)](https://startwithidentity.com/glossary/self-sovereign-identity/)** because the holder, not a platform, controls the credential.

**Where it stands as of November 2026:** the core standards are finished (OpenID4VCI 1.0, OpenID4VP 1.0 and HAIP 1.0 are Final, W3C VC 2.0 is a Recommendation, SD-JWT is RFC 9901), and EU member states must offer a digital identity wallet by the end of 2026. Decentralized identity is production-ready for government ID, mobile driver's licenses and reusable KYC; it is not a replacement for enterprise SSO.

This is a shift away from the [federated model](https://startwithidentity.com/guides/fundamentals/saml-vs-oidc/) most workforce and consumer login runs on today, where an [identity provider](https://startwithidentity.com/glossary/identity-provider/) authenticates you and vouches for you to each application.

## The three roles: issuer, holder, verifier

Every decentralized identity interaction has the same three parties, known as the **trust triangle**:

- **Issuer** signs and gives out a credential (a university issues a degree, a government issues an ID, an employer issues a proof of employment).
- **Holder** stores the credential in a [wallet](https://startwithidentity.com/glossary/digital-wallet/) and decides when and to whom to present it.
- **Verifier** receives a presentation and checks the signature, the issuer, and the status, without needing to call the issuer in real time.

Because the credential is cryptographically signed, the verifier trusts the math and the issuer's public key rather than a live connection to the issuer. See [issuer, holder, verifier](https://startwithidentity.com/glossary/issuer-holder-verifier/) for the model in detail.

## The building blocks and their status

| Layer | Standard | Status, November 2026 |
|---|---|---|
| Credential data model | [W3C Verifiable Credentials](https://startwithidentity.com/standards/verifiable-credentials/) Data Model 2.0 | W3C Recommendation, 15 May 2025 |
| Selective disclosure format | [SD-JWT](https://startwithidentity.com/glossary/sd-jwt/) (RFC 9901) and SD-JWT VC | RFC 9901 published; SD-JWT VC in IESG evaluation |
| Mobile ID format | [ISO/IEC 18013-5 mdoc](https://startwithidentity.com/standards/iso-18013-5-mdl/) | Published 2021; revision in progress |
| Identifiers | [W3C DID Core](https://startwithidentity.com/standards/decentralized-identifiers-did/) | 1.0 Recommendation since 2022; 1.1 Candidate Recommendation |
| Issuance | [OpenID4VCI 1.0](https://startwithidentity.com/standards/openid4vc/) | Final, 16 September 2025 |
| Presentation | OpenID4VP 1.0 | Final, 9 July 2025 |
| Interoperability profile | HAIP 1.0 | Final, 24 December 2025 |

Each row links to a standards page with the primary sources. In short: **[Decentralized Identifiers](https://startwithidentity.com/glossary/decentralized-identifier/)** are identifiers the subject controls, resolvable to a [DID document](https://startwithidentity.com/glossary/did-document/) of public keys. **[Verifiable Credentials](https://startwithidentity.com/glossary/verifiable-credential/)** are tamper-evident signed claims. **OpenID for Verifiable Credentials** moves credentials between issuers, wallets and verifiers over OAuth 2.0, and HAIP narrows it to one interoperable set of choices: SD-JWT VC or mdoc, ES256 signatures and DCQL queries.

One practical consequence: the two largest deployments, the EU wallet and US mobile driver's licenses, anchor trust in **X.509 certificate chains** and trusted lists, not DIDs. If you need EU interoperability, plan for X.509 alongside DIDs.

## Privacy: selective disclosure and zero-knowledge proofs

Holders can reveal the minimum needed. With [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/) and SD-JWT, the issuer signs digests of each claim and the holder reveals only the claims a verifier asks for, so you can prove you are over 18 without showing your birth date. [Zero-knowledge proofs](https://startwithidentity.com/glossary/zero-knowledge-proof/) and [BBS signatures](https://startwithidentity.com/glossary/bbs-signature/) go further and make repeated presentations unlinkable; the W3C BBS cryptosuite is still a Candidate Recommendation. The EU framework handles unlinkability differently, by issuing batches of single-use credentials.

## Is decentralized identity blockchain-based?

Not necessarily. "Blockchain-based identity" is one branch of the field, not its definition.

- **Ledger-anchored:** [Hyperledger Indy](https://startwithidentity.com/vendors/decentralized-identity/hyperledger-indy-aries/) runs a ledger for DIDs and pioneered [AnonCreds](https://startwithidentity.com/glossary/anoncreds/) zero-knowledge credentials. [Dock](https://startwithidentity.com/vendors/decentralized-identity/dock/) anchors credentials to a blockchain and in 2025 [merged its token and network into cheqd](https://www.dock.io/post/dock-and-cheqd-form-alliance-to-accelerate-global-adoption-of-decentralized-id). [cheqd](https://startwithidentity.com/vendors/decentralized-identity/cheqd/) adds payment rails and trust registries on its network. [Privado ID](https://startwithidentity.com/vendors/decentralized-identity/privado-id/) (formerly Polygon ID) and [Civic](https://startwithidentity.com/vendors/decentralized-identity/civic/) serve Web3 and on-chain apps.
- **Ledger-free:** `did:web` uses ordinary domains and TLS, and the EUDI Wallet and mDL use certificate chains. [DID methods compared](https://startwithidentity.com/guides/decentralized-identity/did-methods-compared/) covers the trade-offs.

For regulated enterprise buyers, a token or ledger dependency is a procurement question in its own right; most production deployments in 2026 do not need one.

## Where it is being used

- **Government and cross-border ID:** under [eIDAS 2.0](https://startwithidentity.com/standards/eidas-2-eudi-wallet/) (Regulation (EU) 2024/1183), every member state must offer an [EUDI Wallet](https://startwithidentity.com/glossary/eudi-wallet/) by the end of 2026, and public authorities must accept it. The technical framework is the Architecture and Reference Framework, at v3.0.0 since 23 July 2026. Regulated private relying parties such as banks must accept the wallet on user request within 36 months of the December 2024 implementing acts.
- **Mobile driver's licenses:** [mDLs](https://startwithidentity.com/glossary/mobile-drivers-license/) (ISO/IEC 18013-5) are issued by individual US states, and Google's developer documentation says Google Wallet accepts mdoc IDs online over OpenID4VP 1.0. See [digital IDs by country](https://startwithidentity.com/digital-ids/).
- **Reusable identity verification and KYC:** verify once, reuse the credential, instead of repeating document checks. See [reusable identity and KYC](https://startwithidentity.com/guides/decentralized-identity/reusable-identity-and-kyc-with-verifiable-credentials/) and the [identity verification](https://startwithidentity.com/vendors/identity-verification/) market.
- **Workforce:** [Microsoft Entra Verified ID](https://startwithidentity.com/vendors/decentralized-identity/microsoft-entra-verified-id/) made Entra account recovery with Verified ID generally available in May 2026, replacing helpdesk identity checks with a credential presentation.

## Decentralized vs federated identity

| | Federated ([SAML](https://startwithidentity.com/standards/saml-2-0/), [OIDC](https://startwithidentity.com/standards/openid-connect/)) | Decentralized |
|---|---|---|
| Who vouches at login | The IdP, live, every time | The issuer, once, by signing a credential |
| Runtime dependency | IdP must be up | Verifier needs the issuer's key and status list, not the issuer |
| Privacy | IdP sees every sign-in | Issuer does not learn where the credential is used |
| Maturity | Mature, universal for SSO | Standards final 2025; wallet adoption in progress |
| Best for | Workforce SSO, app login | Proving attributes across organizations |

The two will coexist: expect [identity fabrics](https://startwithidentity.com/guides/fundamentals/what-is-identity-fabric/) to bridge federated and decentralized credentials. See [decentralized vs federated identity](https://startwithidentity.com/guides/decentralized-identity/decentralized-identity-vs-federated-identity/).

## Where to start

Read [what is self-sovereign identity](https://startwithidentity.com/guides/fundamentals/what-is-self-sovereign-identity/) for the philosophy and history and [decentralized identity explained](https://startwithidentity.com/guides/decentralized-identity/decentralized-identity-explained/) for formats, trust and a pilot plan. Compare tools in [top decentralized identity platforms](https://startwithidentity.com/articles/top-5-decentralized-identity-platforms/) and the [decentralized identity vendor directory](https://startwithidentity.com/vendors/decentralized-identity/). When you are ready to choose, see [best decentralized identity platforms](https://startwithidentity.com/rankings/best-decentralized-identity-platforms/), [decentralized identity for enterprises](https://startwithidentity.com/rankings/best-decentralized-identity-for-enterprises/) or [decentralized identity for KYC](https://startwithidentity.com/rankings/best-decentralized-identity-for-kyc/).

## What Is IDaaS (Identity-as-a-Service)?
Source: https://startwithidentity.com/guides/fundamentals/what-is-idaas/
Last updated: 2026-11-05

IDaaS (Identity-as-a-Service) is identity and access management delivered from the cloud as a
subscription, in which a provider runs authentication, single sign-on, multi-factor authentication,
and user provisioning so you do not operate identity servers in your own data center. It is the cloud-delivery model of [IAM](https://startwithidentity.com/guides/fundamentals/what-is-iam/). You still own the configuration: who can sign in, with which factors, to which apps, and what happens when someone leaves.

## What IDaaS includes

- **Authentication and SSO.** One login for many applications, using standards like
  [SAML](https://startwithidentity.com/standards/saml-2-0/) and [OpenID Connect](https://startwithidentity.com/standards/openid-connect/).
- **Multi-factor authentication.** Push, one-time codes, and phishing-resistant [passkeys](https://startwithidentity.com/glossary/passkey/) built on [WebAuthn](https://startwithidentity.com/standards/webauthn-fido2/).
- **Lifecycle provisioning.** Creating, updating, and removing accounts across connected apps,
  usually via [SCIM](https://startwithidentity.com/standards/scim-2-0/).
- **Directory services.** A cloud directory of users and groups, or synchronization with an
  existing one such as [Active Directory](https://startwithidentity.com/glossary/active-directory/).
- **Access policies.** [Conditional](https://startwithidentity.com/glossary/conditional-access/) and [risk-based](https://startwithidentity.com/glossary/risk-based-auth/) rules that decide when to allow, challenge, or
  block access.
- **Logs and signals.** Sign-in and admin audit logs, and increasingly event streams to other tools through the [Shared Signals Framework](https://startwithidentity.com/standards/shared-signals-framework/).

## How it differs from on-premises IAM

The capabilities are similar; the operating model is not. With on-premises IAM you own the servers,
the patching, the scaling, and the disaster recovery. With IDaaS the provider runs all of that, and
you consume identity through APIs and standard protocols. That shifts effort from infrastructure
maintenance to configuration and integration, and it scales elastically as you add users and apps.

| Question | On-premises IAM (for example AD FS, self-hosted Keycloak) | IDaaS |
|---|---|---|
| Who patches the identity servers | You | The provider |
| Who holds the token-signing keys | You, on servers you must protect | The provider, in its infrastructure |
| How new features arrive | Upgrade projects | Continuous releases, some you must opt into |
| Availability | Whatever you build and test | The provider's SLA and architecture, plus your fallback plan |
| Cost shape | Licences or none, plus servers and staff | Subscription per user or per active user |
| Data location | Your data centers | Provider regions; check residency options |

Self-hosting is still a real choice. Open-source servers such as [Keycloak](https://startwithidentity.com/vendors/open-source/keycloak/) or [Zitadel](https://startwithidentity.com/vendors/open-source/zitadel/) give full control at the cost of running them. Teams retiring on-premises federation can follow our [AD FS to Entra ID migration guide](https://startwithidentity.com/guides/implementation/adfs-to-entra-migration/).

## Workforce vs customer IDaaS

IDaaS comes in two flavors that are bought by different teams and priced differently.

| | Workforce IDaaS | Customer IDaaS (CIAM) |
|---|---|---|
| Users | Employees, contractors, partners | Consumers or business customers |
| Typical scale | Hundreds to hundreds of thousands | Thousands to hundreds of millions |
| What matters most | App catalog, provisioning, governance, device trust | Sign-up conversion, social login, consent, branding, fraud |
| Pricing unit | Per user per month | Per monthly active user, often with a free tier |
| Examples | [Okta](https://startwithidentity.com/vendors/iam/okta/), [Microsoft Entra ID](https://startwithidentity.com/vendors/iam/microsoft-entra/), [Ping Identity](https://startwithidentity.com/vendors/iam/ping-identity/), [OneLogin](https://startwithidentity.com/vendors/iam/onelogin/), [JumpCloud](https://startwithidentity.com/vendors/iam/jumpcloud/) | [Auth0](https://startwithidentity.com/vendors/ciam/auth0/), [Microsoft Entra External ID](https://startwithidentity.com/vendors/ciam/microsoft-entra-external-id/), [Amazon Cognito](https://startwithidentity.com/vendors/ciam/amazon-cognito/), [Descope](https://startwithidentity.com/vendors/ciam/descope/) |

**Workforce IDaaS** secures employees and contractors (see [what is workforce identity](https://startwithidentity.com/guides/fundamentals/what-is-workforce-identity/)), emphasizing
governance, provisioning, and integration breadth. **Customer IDaaS**, usually called [CIAM](https://startwithidentity.com/guides/fundamentals/what-is-ciam/), secures external
users at much larger scale and prioritizes frictionless registration, consent, and privacy.

Published prices show the gap. In the [Identity Pricing Transparency Index 2026](https://startwithidentity.com/reports/identity-pricing-transparency-index-2026/), SWI read Okta Workforce Starter at $6 and Essentials at $17 per user per month (with a $1,500 annual minimum) and Microsoft Entra ID P1 at $7 and P2 at $10 per user per month, paid yearly, on October 30, 2026. CIAM free tiers checked the same day ran from 5,000 to 1,000,000 monthly active users depending on the vendor. Watch for the [SSO tax](https://startwithidentity.com/glossary/sso-tax/) on the apps you connect: many SaaS products charge extra before they will federate with your IDaaS at all.

## The shared responsibility line

The provider secures its platform. You secure your tenant. The incidents that hit IDaaS customers mostly sit on your side of that line.

| Responsibility | Provider | Customer |
|---|---|---|
| Platform availability, patching, signing keys | Yes | Plan for its failure |
| Which factors are allowed, MFA coverage, exemptions | Offers options | Configures and enforces |
| Admin roles, help desk reset rules | Offers controls | Decides who can do what |
| App onboarding and deprovisioning | Offers SCIM and connectors | Connects every app and owns the leaver process |
| Monitoring tenant logs | Provides logs | Collects, alerts and responds |

## Failure modes to plan for

- **Accounts without MFA on a cloud platform.** Snowflake is a data platform rather than an IDaaS, but the pattern applies to any cloud tenant. In the [2024 Snowflake customer campaign](https://startwithidentity.com/breaches/incidents/2024-snowflake-customer-tenant-campaign/), about 165 customers were hit with credentials from [infostealer malware](https://startwithidentity.com/techniques/infostealer-credential-harvesting/) against accounts with no MFA. The fix was tenant policy, not provider code. See the [teardown](https://startwithidentity.com/breaches/snowflake-2024-credential-attacks/).
- **Help desk resets of admin MFA.** In 2023 Okta warned that attackers were calling customers' service desks to reset super administrator factors, compromising [four customers](https://startwithidentity.com/breaches/incidents/2023-okta-customer-help-desk-super-admin-takeover/). The defense is a reset process that verifies identity and limits who can reset admins ([help desk social engineering](https://startwithidentity.com/techniques/help-desk-social-engineering/)).
- **Provider-side compromise.** The provider's own support systems are part of your attack surface. In the [2022 Sitel incident](https://startwithidentity.com/breaches/incidents/2022-okta-sitel-lapsus/) a subprocessor's support workstation was used to reach two Okta customer tenants, and in the [2023 support system breach](https://startwithidentity.com/breaches/incidents/2023-okta-support-system-har-session-tokens/) session tokens in uploaded HAR files were taken from 134 customers' case files ([session cookie theft](https://startwithidentity.com/techniques/session-cookie-theft/), [teardown](https://startwithidentity.com/breaches/okta-2023-support-system-breach/)). Scrub HAR files before sharing and bind admin sessions where the provider allows it.
- **Provider outage.** When the IDaaS is down, so is every federated login. Microsoft [publishes monthly Entra ID availability](https://learn.microsoft.com/en-us/entra/identity/monitoring-health/reference-sla-performance), measured as successful user sign-in minutes; its lowest published month since 2021 was March 2021 at 99.568%, and it says it plans no downtime for maintenance. Ask every provider for the equivalent history, and keep [break-glass accounts](https://startwithidentity.com/glossary/break-glass/) and an [identity resilience](https://startwithidentity.com/glossary/identity-resilience/) plan for the apps that cannot wait.

## How to adopt IDaaS: a short checklist

1. **Pick the population first.** Workforce and customer identity are different products; do not force one to serve both without testing.
2. **Inventory applications** and how each authenticates (SAML, OIDC, LDAP, header-based, or local passwords). Legacy protocols decide how much bridging you need.
3. **Decide the source of truth** for people: the HR system, an existing directory, or the IDaaS directory itself.
4. **Set MFA policy before migration**, with phishing-resistant factors for admins. Compare options with the [MFA matrix](https://startwithidentity.com/tools/mfa-matrix/).
5. **Connect provisioning (SCIM) for the top apps** so deprovisioning is automatic, not a ticket.
6. **Lock down admin and help desk paths**: few super admins, verified resets, alerts on factor changes.
7. **Stream logs** to your SIEM or [ITDR](https://startwithidentity.com/guides/fundamentals/what-is-itdr/) tool and test an alert end to end.
8. **Test the outage plan**: break-glass accounts, offline access to critical systems, and who decides to fail open or closed.

## When IDaaS is the right choice

IDaaS suits almost any organization that wants to avoid running identity infrastructure, needs to
connect cloud applications quickly, or wants strong security without a large identity operations
team. It is a weaker fit when regulation or contracts require identity data to stay in a location no provider serves, or when air-gapped systems cannot reach a cloud service. Very large enterprises with complex legacy estates often combine IDaaS with other components
into an [identity fabric](https://startwithidentity.com/guides/fundamentals/what-is-identity-fabric/) rather than relying on a
single platform. For a comparison of the leading platforms, see our analysis of the
[top IDaaS platforms](https://startwithidentity.com/articles/top-5-identity-as-a-service-platforms/) and
[workforce identity platforms](https://startwithidentity.com/articles/top-6-workforce-identity-platforms/), the [Okta vs Microsoft Entra](https://startwithidentity.com/compare/okta-vs-microsoft-entra/) comparison, and the [how to choose an IAM platform](https://startwithidentity.com/guides/buyer-guides/how-to-choose-an-iam-platform/) buyer guide.

## What Is Identity and Access Management (IAM)?
Source: https://startwithidentity.com/guides/fundamentals/what-is-iam/
Last updated: 2026-11-05

Identity and access management (IAM) is the discipline of making sure the right people and systems have the right access to the right resources, at the right time, and for the right reasons. IAM covers how identities are created, authenticated, authorized, governed, and eventually removed, for employees, contractors, customers and machines. It is the control most breaches test first, because a valid login is the cheapest way in.

## The core building blocks

| Component | What it does | Standard underneath (status, November 2026) |
|---|---|---|
| **Authentication** | Proves who someone is: passwords, [MFA](https://startwithidentity.com/glossary/mfa/), passkeys | [WebAuthn](https://startwithidentity.com/standards/webauthn-fido2/) Level 3, W3C Recommendation 25 August 2026 |
| **Federation and SSO** | Lets one identity work across many applications | [OpenID Connect](https://startwithidentity.com/standards/openid-connect/) Core 1.0 (also ISO/IEC 26131:2024); [SAML 2.0](https://startwithidentity.com/standards/saml-2-0/), OASIS Standard since 2005 |
| **Authorization** | Decides what an authenticated identity may do | [OAuth 2.0](https://startwithidentity.com/standards/oauth-2-0/) (RFC 6749, hardened by the RFC 9700 security BCP in 2025); [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/) still an IETF draft; [AuthZEN](https://startwithidentity.com/standards/authzen/) 1.0 Final January 2026 |
| **Lifecycle and provisioning** | Creates, updates and removes accounts, ideally driven by the HR record | [SCIM 2.0](https://startwithidentity.com/standards/scim-2-0/) (RFC 7643 and 7644, updated by RFC 9865 and RFC 9967) |
| **Governance** | Reviews and certifies access so it does not drift | Policy and audit, not a protocol; see [IGA](https://startwithidentity.com/guides/fundamentals/what-is-iga/) |
| **Signals and response** | Shares risk events and revokes sessions across tools | [Shared Signals Framework](https://startwithidentity.com/standards/shared-signals-framework/), CAEP and RISC, Final since 29 August 2025 |

See [authentication vs authorization](https://startwithidentity.com/guides/fundamentals/authentication-vs-authorization/) and [OAuth vs OIDC](https://startwithidentity.com/guides/fundamentals/oauth-vs-oidc/) for the distinctions people most often mix up.

## IAM and its neighbours

IAM is the umbrella. The adjacent disciplines are bought separately, so it helps to know where the lines fall.

| Discipline | Who it covers | Main job | Read more |
|---|---|---|---|
| Workforce IAM | Employees, contractors, partners | SSO, MFA, lifecycle | [What is workforce identity](https://startwithidentity.com/guides/fundamentals/what-is-workforce-identity/) |
| CIAM | Customers and business users of your product | Sign-up, login, consent at large scale | [What is CIAM](https://startwithidentity.com/guides/fundamentals/what-is-ciam/), [CIAM vs IAM](https://startwithidentity.com/articles/ciam-vs-iam/) |
| IGA | Everyone with access | Requests, certifications, segregation of duties | [What is IGA](https://startwithidentity.com/guides/fundamentals/what-is-iga/) |
| PAM | Administrators and privileged accounts | Vaulting, session control, just-in-time access | [What is PAM](https://startwithidentity.com/guides/fundamentals/what-is-pam/) |
| Non-human identity | Service accounts, API keys, workloads, AI agents | Inventory, ownership, rotation | [What is NHI](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/) |
| ITDR | Identity infrastructure | Detecting and responding to identity attacks | [What is ITDR](https://startwithidentity.com/guides/fundamentals/what-is-itdr/) |

In cloud consoles, "IAM" also names a specific permissions service, such as AWS Identity and Access Management. That is one cloud's authorization layer; managing permissions across clouds is covered in [what is CIEM](https://startwithidentity.com/guides/fundamentals/what-is-ciem/).

Delivered as a cloud subscription, IAM is called [IDaaS](https://startwithidentity.com/guides/fundamentals/what-is-idaas/). The [Zero Trust explainer](https://startwithidentity.com/guides/fundamentals/what-is-zero-trust/) covers the architecture that puts identity at the center.

## The IAM market in 2026

Ownership moved fast this year, and it affects roadmaps and renewals. Palo Alto Networks closed its acquisition of CyberArk on 11 February 2026 and rebranded it [Idira (formerly CyberArk)](https://startwithidentity.com/vendors/pam/cyberark/) on 12 May 2026. ServiceNow closed [Veza](https://startwithidentity.com/vendors/iga/veza/) on 2 March 2026. [Okta](https://startwithidentity.com/vendors/iam/okta/) bought Axiom Security in 2025 and [Permiso Security](https://startwithidentity.com/vendors/ai-identity/permiso-security/) (closed 26 August 2026). Rubrik acquired Strata Identity on 9 June 2026 for identity failover, and Workday's agreement to acquire [C1](https://startwithidentity.com/vendors/iga/conductorone/) (announced 13 October 2026) was still pending. The full list is in [identity acquisitions](https://startwithidentity.com/acquisitions/) and the [Identity Consolidation Report 2026](https://startwithidentity.com/reports/identity-consolidation-report-2026/).

On price, workforce IAM is partly public. On 30 October 2026 SWI read Okta Workforce Starter at $6 and Essentials at $17 per user per month with a $1,500 annual minimum, Microsoft Entra ID P1 at $7 and P2 at $10 per user per month paid yearly, and [JumpCloud](https://startwithidentity.com/vendors/iam/jumpcloud/) SSO at $11 per user per month annually. Across all 20 IAM platform vendors in the [Identity Pricing Transparency Index 2026](https://startwithidentity.com/reports/identity-pricing-transparency-index-2026/), 65% are quote-only.

### Shortlist by situation

| Situation | Start with | Ranking |
|---|---|---|
| Large enterprise, many SaaS apps | Okta, [Microsoft Entra ID](https://startwithidentity.com/vendors/iam/microsoft-entra/), [Ping Identity](https://startwithidentity.com/vendors/iam/ping-identity/) | [Best IAM for enterprises](https://startwithidentity.com/rankings/best-iam-for-enterprises/) |
| Microsoft 365 shop | Microsoft Entra ID | [Okta vs Microsoft Entra](https://startwithidentity.com/compare/okta-vs-microsoft-entra/) |
| Complex hybrid or self-hosted federation | Ping Identity, [ForgeRock](https://startwithidentity.com/vendors/iam/forgerock/) (part of Ping) | [Okta vs Ping Identity](https://startwithidentity.com/compare/okta-vs-ping-identity/) |
| Small or mid-sized business | JumpCloud (directory plus device management), [OneLogin](https://startwithidentity.com/vendors/iam/onelogin/) | [Best IAM for SMB](https://startwithidentity.com/rankings/best-iam-for-smb/) |
| Want to self-host, no licence fee | [Keycloak](https://startwithidentity.com/vendors/open-source/keycloak/), [Zitadel](https://startwithidentity.com/vendors/open-source/zitadel/), [Authentik](https://startwithidentity.com/vendors/open-source/authentik/) | [Top open-source IAM solutions](https://startwithidentity.com/articles/top-10-open-source-iam-solutions/) |

For the scored field see the [best IAM platforms](https://startwithidentity.com/rankings/best-iam-platforms/), and for a decision framework, [how to choose an IAM platform](https://startwithidentity.com/guides/buyer-guides/how-to-choose-an-iam-platform/).

## What actually goes wrong

IAM programs rarely fail at the login screen. They fail in five places, and each has a breach on record:

- **Movers and leavers.** Internal transfers accumulate entitlements from every role a person has held, and leavers keep access when deprovisioning misses a system. A [former Cash App Investing employee](https://startwithidentity.com/breaches/incidents/2022-cash-app-former-employee/) downloaded reports on about 8.2 million customers after their employment ended ([orphaned account abuse](https://startwithidentity.com/techniques/orphaned-account-abuse/)).
- **Accounts outside SSO.** Local admin accounts, vendor logins, legacy VPN profiles and test tenants never enter the identity provider. Colonial Pipeline was entered through a [legacy VPN profile](https://startwithidentity.com/breaches/incidents/2021-colonial-pipeline-legacy-vpn/) with only a password, and Midnight Blizzard sprayed a [legacy test tenant account without MFA](https://startwithidentity.com/breaches/incidents/2024-microsoft-midnight-blizzard-password-spray/).
- **The help desk.** At MGM Resorts a [call to the IT help desk](https://startwithidentity.com/breaches/incidents/2023-mgm-resorts-help-desk-ransomware/) led to control of Okta super administrator accounts; MGM estimated a $100 million hit ([help desk social engineering](https://startwithidentity.com/techniques/help-desk-social-engineering/)).
- **Non-human identities.** Service accounts, [API keys](https://startwithidentity.com/glossary/api-key/) and workloads typically have no owner, no expiry and no place in any review. In SWI's [Identity Breach Report 2026](https://startwithidentity.com/reports/identity-breach-report-2026/), the share of breaches abusing a non-human identity rose in each two-year period from 2021 to 2026.
- **Session and token lifetime.** Once [SSO](https://startwithidentity.com/glossary/sso/) concentrates authentication, a stolen session is worth as much as a password and survives a reset. In 2026 one actor [replayed stolen Microsoft 365 tokens into 79 organizations](https://startwithidentity.com/breaches/incidents/2026-microsoft-365-token-replay-79-orgs/) ([session cookie theft](https://startwithidentity.com/techniques/session-cookie-theft/)).

## IAM maturity model, roughly

1. **Directory only.** Accounts exist, provisioning is manual, no consistent MFA.
2. **SSO deployed.** One identity provider fronts most applications, MFA enforced with exemptions.
3. **Lifecycle automated.** HR events drive [provisioning](https://startwithidentity.com/glossary/provisioning/) and deprovisioning through SCIM; the exemption list is short and reviewed.
4. **Governed.** Access certification runs with real revocation rates, [segregation of duties](https://startwithidentity.com/glossary/sod/) rules are enforced at request time, non-human identities have owners.
5. **Continuous.** [Phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/) everywhere, standing privilege near zero, identity threat detection in place.

Most organizations are at stage two and describe themselves as stage four. The honest test is whether you can answer, right now, who has access to your most sensitive system and why. For a fuller self-assessment, use the [IAM maturity model framework](https://startwithidentity.com/articles/iam-maturity-model-assessment-framework/) or the [maturity assessment tool](https://startwithidentity.com/tools/maturity-assessment/).

## What to do first

The order that produces the most risk reduction per unit of effort, as a practitioner estimate rather than a measured result: enforce phishing-resistant MFA and shrink the exemption list, automate [joiner-mover-leaver](https://startwithidentity.com/glossary/joiner-mover-leaver/) from the HR record, inventory accounts that live outside SSO, lock down help desk resets, then start certification on the systems that matter rather than on everything. Narrow a shortlist with the [vendor selector](https://startwithidentity.com/tools/vendor-selector/) and browse [workforce IAM platforms](https://startwithidentity.com/vendors/iam/).

## What Is IGA (Identity Governance and Administration)?
Source: https://startwithidentity.com/guides/fundamentals/what-is-iga/
Last updated: 2026-11-05

IGA (identity governance and administration) is the discipline and software that decides who should have access to what, grants and removes that access across systems, and proves it to auditors. An IGA platform answers four questions: who has access, who approved it, is it still needed, and does any combination of it break policy. [IAM](https://startwithidentity.com/guides/fundamentals/what-is-iam/) enforces access at login; IGA governs whether that access should exist.

## What an IGA platform does

- **Lifecycle provisioning.** Reads joiners, movers and leavers from the HR system and creates, changes or removes accounts in connected applications, often over [SCIM](https://startwithidentity.com/guides/fundamentals/what-is-scim/) or vendor connectors. See [joiner-mover-leaver](https://startwithidentity.com/glossary/joiner-mover-leaver/).
- **Access requests and approvals.** A catalog where people ask for access, with approval routing and a recorded trail.
- **Access certifications.** Periodic reviews in which managers or application owners confirm or revoke each grant. See [access certification](https://startwithidentity.com/glossary/access-certification/).
- **Separation of duties (SoD).** Rules that block toxic combinations, such as creating a vendor and approving its payment. See [SoD](https://startwithidentity.com/glossary/sod/).
- **Role management.** Grouping [entitlements](https://startwithidentity.com/glossary/entitlement/) into roles so access is understandable; [role mining](https://startwithidentity.com/glossary/role-mining/) proposes roles from existing grants.
- **Audit evidence.** Reports that show auditors who had access, who approved it and when it was reviewed. See the [audit preparation guide](https://startwithidentity.com/guides/compliance/iam-audit-preparation-guide/).

## IGA vs IAM vs PAM vs CIEM

Buyers confuse these four because the vendors overlap. The split that matters is which question each answers.

| Category | Question it answers | Typical controls | Example vendors |
|---|---|---|---|
| IAM / access management | Can this person sign in right now? | SSO, MFA, conditional access | Okta, Microsoft Entra ID |
| IGA | Should this person have this access at all, and can we prove it? | Provisioning, requests, certifications, SoD | SailPoint, Saviynt, Omada |
| PAM | How is powerful access used? | Vaulting, session recording, just-in-time elevation | Idira (formerly CyberArk), Delinea, BeyondTrust |
| CIEM | Which cloud permissions are excessive? | Effective-permission analysis, right-sizing | Wiz, Tenable Cloud Security |

IGA and IAM are usually separate products: [SailPoint](https://startwithidentity.com/vendors/iga/sailpoint/) is not an identity provider, so it sits beside [Okta](https://startwithidentity.com/vendors/iam/okta/) or [Microsoft Entra ID](https://startwithidentity.com/vendors/iam/microsoft-entra/). Read more in [what is PAM](https://startwithidentity.com/guides/fundamentals/what-is-pam/) and [what is CIEM](https://startwithidentity.com/guides/fundamentals/what-is-ciem/).

## Why it matters

Access accumulates. People change roles, projects end, contractors leave, and permissions linger. That drift is a standing audit finding and a breach path, which is why IGA is central to SOX, SOC 2 and ISO 27001 evidence. The breach record shows what happens when nobody governs the lifecycle:

- **Leavers who keep access.** A former Cash App employee [downloaded customer brokerage reports](https://startwithidentity.com/breaches/incidents/2022-cash-app-former-employee/) after their employment ended. At CrowdSec, a departing engineer's GitHub account was [left open to finish some work](https://startwithidentity.com/breaches/incidents/2026-crowdsec-departing-engineer-github-token/), and its still-valid OAuth token was used to copy about 170 private repositories. See [orphaned account abuse](https://startwithidentity.com/techniques/orphaned-account-abuse/).
- **Accounts nobody believes exist.** Colonial Pipeline was entered through a [legacy VPN profile](https://startwithidentity.com/breaches/incidents/2021-colonial-pipeline-legacy-vpn/) the company thought was no longer in use, protected by a single password.
- **Insiders with excess standing access.** A senior Ubiquiti developer [used his own administrative access](https://startwithidentity.com/breaches/incidents/2021-ubiquiti-insider-cloud-credentials/) to AWS and GitHub to steal data, then posed as an outside attacker.
- **Machine accounts outside review.** In 2026 a password-spraying campaign against Chilean Microsoft 365 tenants [compromised seven accounts](https://startwithidentity.com/breaches/incidents/2026-teamfiltration-chile-service-accounts/), all functional or service accounts with no MFA and default or never-rotated passwords.

## Why IGA programs stall

The uncomfortable pattern is that governance failures are almost never product failures:

- **Identity data quality.** The HR system, the directory and the applications disagree about who exists and which accounts belong to whom. Reconciliation is a project in its own right and it happens whether or not you budget for it.
- **Connector coverage for the long tail.** Governance demos well against Active Directory. It struggles against the mainframe, the ERP with no modern API, and the homegrown application whose owner left.
- **Rubber-stamped certification.** Show a manager `APP_FIN_GL_RW_PROD` and they approve it. Campaigns that produce real revocations translate entitlements into business language and show usage data alongside the grant.
- **Movers.** Joiners and leavers are handled; internal transfers accumulate entitlements from every role a person has ever held. See [mover entitlement accumulation](https://startwithidentity.com/techniques/mover-entitlement-accumulation/).

## What good looks like

A working governance program can answer four questions without a project: who has access to this system and why, what changed in the last 30 days, which entitlements have gone unused for six months, and who owns this [service account](https://startwithidentity.com/glossary/service-account/). Measure campaigns on revocation rate rather than completion rate, because completion measures compliance theatre and revocation measures risk reduction.

## The non-human gap

[Service accounts](https://startwithidentity.com/glossary/service-account/), workloads and now AI agents outnumber employees in most environments and appear in almost no certification campaign, because there is no manager to attest for them. Ownership assignment is the prerequisite, and it is where the category is expanding. See [what is non-human identity](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/).

## IGA tools in 2026: who owns what

Governance is the most acquisitive corner of identity. As of November 5, 2026, per the vendor profiles and the [acquisitions tracker](https://startwithidentity.com/acquisitions/):

- **[SailPoint](https://startwithidentity.com/vendors/iga/sailpoint/)** is public (NASDAQ: SAIL) and majority-held by Thoma Bravo. It closed its acquisition of Entro Security on 29 June 2026 to govern non-human identities.
- **[Saviynt](https://startwithidentity.com/vendors/iga/saviynt/)** is private and raised 700 million dollars in a KKR-led round in December 2025.
- **[Veza](https://startwithidentity.com/vendors/iga/veza/)** was acquired by ServiceNow, closing on 2 March 2026 for about 1.2 billion dollars.
- **[C1 (formerly ConductorOne)](https://startwithidentity.com/vendors/iga/conductorone/)** renamed itself in April 2026, and Workday agreed on 13 October 2026 to acquire it, with closing expected by 31 January 2027.
- **[Zilla Security](https://startwithidentity.com/vendors/iga/zilla-security/)** was bought by CyberArk in February 2025 and is now part of the Palo Alto Networks Idira portfolio.
- **[Omada](https://startwithidentity.com/vendors/iga/omada/)** acquired [EmpowerID](https://startwithidentity.com/vendors/iga/empowerid/) on 24 September 2026, terms undisclosed.
- **[Zluri](https://startwithidentity.com/vendors/iga/zluri/)** was acquired by Infotech, closing on 14 October 2026.
- **[One Identity](https://startwithidentity.com/vendors/iga/one-identity/)** announced on 24 June 2026 that it will become an independent company; SWI could not confirm the separation has closed.
- **[Lumos](https://startwithidentity.com/vendors/iga/lumos/)** remains private and SaaS-focused. **[midPoint by Evolveum](https://startwithidentity.com/vendors/iga/evolveum/)** is the leading open source option.

Prices are rarely public. In the [Identity Pricing Transparency Index 2026](https://startwithidentity.com/reports/identity-pricing-transparency-index-2026/), IGA scored 5 out of 100, the lowest of 17 categories: none of 20 vendors published a paid price. One anchor does exist: Microsoft listed Entra ID Governance at 7 dollars per user per month, paid yearly, when SWI checked on October 30, 2026.

## Where to start

Compare the field in the [best IGA tools](https://startwithidentity.com/rankings/best-iga-tools/) ranking, the [compliant IGA platforms](https://startwithidentity.com/rankings/best-compliant-iga-platforms/) list and the [top 7 identity governance platforms](https://startwithidentity.com/articles/top-7-identity-governance-platforms/). For head-to-heads, read [SailPoint vs Saviynt](https://startwithidentity.com/compare/sailpoint-vs-saviynt/), [Veza vs SailPoint](https://startwithidentity.com/compare/veza-vs-sailpoint/) and [C1 vs Lumos](https://startwithidentity.com/compare/conductorone-vs-lumos/). Self-hosting? See the [top open source IGA tools](https://startwithidentity.com/articles/top-5-open-source-iga-tools/). When you are ready to buy, follow [how to choose an IGA platform](https://startwithidentity.com/guides/buyer-guides/how-to-choose-an-iga-platform/) and run better campaigns with [access review best practices](https://startwithidentity.com/articles/access-review-certification-best-practices/).

## What Is ITDR (Identity Threat Detection and Response)?
Source: https://startwithidentity.com/guides/fundamentals/what-is-itdr/
Last updated: 2026-11-05

ITDR (identity threat detection and response) is the tooling and practice for detecting and containing attacks that use identity itself: stolen passwords and session tokens, MFA manipulation, privilege escalation in Active Directory and Entra ID, and lateral movement through trusted accounts. It exists because attackers now log in rather than break in, and a valid login with a stolen token looks normal to every prevention control.

## Why prevention is not enough

Strong [authentication](https://startwithidentity.com/guides/fundamentals/authentication-vs-authorization/) and least privilege reduce risk, but attackers still get in through phishing, [infostealers](https://startwithidentity.com/glossary/infostealer/), help desk social engineering and [session hijacking](https://startwithidentity.com/glossary/session-hijacking/). ITDR assumes breach and watches for the behaviors that follow the first sign-in.

The 2026 record makes the point. Huntress reported on October 22, 2026 that one actor [replayed stolen Microsoft 365 tokens into 79 organizations](https://startwithidentity.com/breaches/incidents/2026-microsoft-365-token-replay-79-orgs/), registered at least 48 rogue Entra devices and replaced victims' MFA methods, in 19 organizations within three hours of the first sign-in, so access survived password resets. On November 3, 2026 Todyl described an operator [signing in to Entra ID as applications](https://startwithidentity.com/breaches/incidents/2026-entra-id-stolen-app-secrets-27-orgs/) with stolen client secrets, reaching 27 organizations. Neither involved malware.

## What ITDR covers

- **Directory protection** for Active Directory and Entra ID: misconfiguration detection, change tracking and fast recovery.
- **Runtime detection** of anomalous authentication and [account takeover](https://startwithidentity.com/glossary/account-takeover/) using behavioral analytics ([UEBA](https://startwithidentity.com/glossary/ueba/)).
- **Attack-path analysis** to find how an attacker could escalate or move laterally ([attack path](https://startwithidentity.com/glossary/attack-path/)).
- **SaaS and browser identity risk**: OAuth grants, session use after MFA, phishing pages.
- **Exposure intelligence**: credentials and cookies found in breach and infostealer data.

## ITDR vs ISPM vs CIEM vs EDR

| Tool | When it acts | What it watches | Example question |
|---|---|---|---|
| [ISPM](https://startwithidentity.com/glossary/ispm/) | Before an attack | Identity configuration | Which accounts have no MFA? |
| [CIEM](https://startwithidentity.com/guides/fundamentals/what-is-ciem/) | Before an attack | Cloud permissions | Which roles are over-permissioned? |
| ITDR | During an attack | Sign-ins, sessions, directory changes | Is this session stolen? |
| EDR | During an attack | Endpoint processes | Is this process malicious? |
| AD recovery | After an attack | Directory backups | Can we rebuild a clean forest? |

Mature programs use posture, detection and recovery together. Many ITDR products now bundle posture; few bundle forest recovery.

## What ITDR detects that nothing else does

The defining property of an identity attack is that nothing looks broken. Detections that earn their place are behavioral and identity-specific:

- Sign-ins that satisfy [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/) policy but come from a session the user did not start, for example Windows Hello authentications with an empty device ID.
- [Device code](https://startwithidentity.com/glossary/device-code-flow/) grants from clients that have no business using them ([device code phishing](https://startwithidentity.com/techniques/device-code-phishing/)).
- New OAuth consent grants to unfamiliar applications ([OAuth consent phishing](https://startwithidentity.com/techniques/oauth-consent-phishing/)).
- MFA methods removed and replaced, or new devices registered, shortly after a sign-in from a new location.
- A first-time privileged action by an identity that has never performed one.
- Directory changes that create an escalation path: certificate template permissions, group nesting, delegation rights ([AD CS template abuse](https://startwithidentity.com/techniques/adcs-certificate-template-abuse/), [Kerberoasting](https://startwithidentity.com/techniques/kerberoasting/)).

## Hybrid is where attacks live

Attackers pivot between on-premises Active Directory and the cloud identity provider, because the trust between them is the point of the architecture. ITDR that watches one and not the other misses the path. Microsoft described on October 30, 2026 intrusions where [fake Teams help desk contacts led to AD CS certificates](https://startwithidentity.com/breaches/incidents/2026-teams-help-desk-impersonation-adcs-esc1-esc8/) for 11 privileged accounts and a DCSync within seconds. In 2023 a help desk call gave attackers [control of MGM Resorts' Okta super administrators](https://startwithidentity.com/breaches/incidents/2023-mgm-resorts-help-desk-ransomware/) before ransomware hit ESXi hosts ([help desk social engineering](https://startwithidentity.com/techniques/help-desk-social-engineering/)). Restoring a compromised forest from ordinary backups can restore the attacker's persistence too; see [Silverfort vs Semperis](https://startwithidentity.com/compare/silverfort-vs-semperis/).

## Response is the harder half

Detection without a response playbook produces alerts. Identity containment differs from endpoint response:

1. Revoke [refresh tokens](https://startwithidentity.com/glossary/refresh-token/) and active sessions, not only the password, because a reset leaves a stolen session alive ([token replay](https://startwithidentity.com/techniques/token-replay-unbound-endpoint/)).
2. Remove attacker-added authentication methods and registered devices.
3. Rotate secrets and certificates for any [service principal](https://startwithidentity.com/glossary/service-principal/) involved.
4. Check for new OAuth grants, mailbox rules and federation changes.
5. Share the event with other systems. The OpenID [Shared Signals Framework](https://startwithidentity.com/standards/shared-signals-framework/), with [CAEP](https://startwithidentity.com/glossary/caep/) and RISC, has been a Final Specification since 29 August 2025, so an ITDR alert can tell connected apps to end a session.

See [token theft](https://startwithidentity.com/glossary/token-theft/) and the [infostealer session hijacking teardown](https://startwithidentity.com/breaches/infostealer-session-hijacking/).

## Who needs ITDR first

Prioritize it if you run hybrid Active Directory and a cloud identity provider, rely on help desk resets, have service accounts that cannot use MFA, or have already had a session-theft incident. A small cloud-only company on one IdP may get enough from that IdP's own risk detections plus strict session and MFA policy, and should spend first on [phishing-resistant MFA](https://startwithidentity.com/guides/fundamentals/what-is-passwordless/).

## ITDR vendors in 2026

The category is consolidating into identity and XDR platforms. As of November 5, 2026, per the profiles: [Okta](https://startwithidentity.com/vendors/iam/okta/) closed its acquisition of [Permiso Security](https://startwithidentity.com/vendors/ai-identity/permiso-security/) on 26 August 2026 to become the Okta Platform's ITDR layer; [Silverfort](https://startwithidentity.com/vendors/itdr/silverfort/) bought Fabrix Security on 28 April 2026 after Rezonate in 2024; and [CrowdStrike Falcon Identity Protection](https://startwithidentity.com/vendors/itdr/crowdstrike-falcon-identity/) added SGNL's continuous access evaluation when that deal closed on 20 February 2026. [Microsoft Defender for Identity](https://startwithidentity.com/vendors/itdr/microsoft-defender-identity/) is included in Microsoft 365 E5. [Semperis](https://startwithidentity.com/vendors/itdr/semperis/) leads on Active Directory recovery, and [Push Security](https://startwithidentity.com/vendors/itdr/push-security/) and [Obsidian Security](https://startwithidentity.com/vendors/itdr/obsidian-security/) watch the browser and SaaS sessions.

Pricing is mostly hidden: ITDR scored 14 out of 100 in the [Identity Pricing Transparency Index 2026](https://startwithidentity.com/reports/identity-pricing-transparency-index-2026/), and 16 of 21 vendors were quote-only on October 30, 2026.

## Where to start

Compare the [best ITDR tools](https://startwithidentity.com/rankings/best-itdr-tools/), [best ITDR for Active Directory](https://startwithidentity.com/rankings/best-itdr-for-active-directory/) and [top identity threat detection platforms](https://startwithidentity.com/articles/top-5-identity-threat-detection-platforms/), read [CrowdStrike vs Microsoft Defender for Identity](https://startwithidentity.com/compare/crowdstrike-falcon-identity-vs-microsoft-defender-identity/), and follow [how to choose an ITDR solution](https://startwithidentity.com/guides/buyer-guides/how-to-choose-an-itdr-solution/).

## What Is Machine Identity? Machine Identity Management Explained
Source: https://startwithidentity.com/guides/fundamentals/what-is-machine-identity/
Last updated: 2026-11-05

Machine identity is how non-human actors (workloads, services, containers and devices) prove who they are to each other, using certificates, keys and tokens instead of passwords. Machine identity management is the work of issuing, rotating, scoping and retiring those credentials. As architectures shift to microservices, Kubernetes and multi-cloud, the number of machine identities has exploded, and securing them is now as important as securing human logins.

## Why it is hard

Machines authenticate constantly and at scale, often with long-lived [secrets](https://startwithidentity.com/guides/fundamentals/what-is-secrets-management/) or certificates that rarely rotate. A single leaked workload credential can open a path across an environment, and unlike a person, a workload cannot answer an MFA prompt.

## The building blocks

- **Workload identity** standards like [SPIFFE](https://startwithidentity.com/glossary/spiffe/) issue short-lived, verifiable identities (SVIDs) to workloads.
- **mTLS** ([mutual TLS](https://startwithidentity.com/glossary/mtls/)) authenticates both sides of a service-to-service call.
- **[PKI](https://startwithidentity.com/glossary/pki/) and [certificate lifecycle](https://startwithidentity.com/glossary/certificate-lifecycle/)** issue and rotate the certificates that back machine trust.
- **[Secrets management](https://startwithidentity.com/guides/fundamentals/what-is-secrets-management/)** handles the keys and tokens workloads still need.
- **[Workload identity federation](https://startwithidentity.com/glossary/workload-identity-federation/)** lets a workload trade a platform-issued token for cloud access without a stored key.

## Credential types compared

| Credential | Typical lifetime | Who issues it | Main risk | Better pattern |
|---|---|---|---|---|
| Public TLS certificate | 200 days maximum since March 15, 2026 | Public CA | Expiry outage | ACME automation, inventory |
| Private (internal) certificate | Whatever your CA sets | Internal CA | Unknown certs, weak templates | Short-lived certs from a managed CA |
| SSH key | Often never expires | Engineers | Copied keys, no owner | SSH certificates, short-lived |
| Cloud access key or API key | Until someone revokes it | Cloud or SaaS console | Leaks into code and CI | Workload identity federation |
| Token signing key | Years | Identity provider | Forged tokens for everyone | HSM-held keys, rotation, validation |
| SPIFFE SVID or federated token | Minutes to hours | Platform | Misconfigured trust domain | The default for new workloads |

## Certificate lifetimes are shrinking

The CA/Browser Forum approved [Ballot SC-081v3](https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/) in April 2025. The maximum validity of a publicly trusted TLS certificate is 200 days for certificates issued from March 15, 2026, then 100 days from March 15, 2027 and 47 days from March 15, 2029. At 47 days, a team renewing by hand from a spreadsheet will miss one. Read [shorter certificate lifetimes: automate now](https://startwithidentity.com/blog/shorter-certificate-lifetimes-automate-now/) and the [certificate lifecycle management guide](https://startwithidentity.com/guides/machine-identity/certificate-lifecycle-management-guide/).

## The failure modes in practice

Machine identity incidents cluster in five places:

- **Expired certificates.** The one machine identity failure that causes a visible outage rather than a quiet compromise, which is why it gets budget.
- **Stolen or forged signing material.** Storm-0558 used an acquired Microsoft consumer signing key to [forge tokens](https://startwithidentity.com/breaches/incidents/2023-storm-0558-microsoft-signing-key-forgery/) accepted for enterprise Exchange Online mailboxes. In 2021 attackers took the [Mimecast certificate](https://startwithidentity.com/breaches/incidents/2021-mimecast-certificate-compromise/) that authenticated its products to Microsoft 365. GitHub revoked code-signing certificates after a [machine account token](https://startwithidentity.com/breaches/incidents/2023-github-machine-account-token-code-signing/) was used to clone the repositories that held them.
- **Credentials in repositories.** GitGuardian found [4,576 n8n API tokens](https://startwithidentity.com/blog/2026-08-05-leaked-n8n-api-tokens-expose-connected-credentials/) in public GitHub commits in August 2026, and about 36 percent of the reachable instances it tested accepted at least one. See [secrets in repositories and CI](https://startwithidentity.com/techniques/secrets-in-repositories-and-ci/).
- **Tokens that never expire.** Zeabur's October 2026 breach began with an internal AWS key and a [shared-cluster admin token with no expiry](https://startwithidentity.com/breaches/incidents/2026-zeabur-plaintext-admin-token/), both in plaintext in a private repository. LiteLLM's poisoned release traced to an admin key that was [deleted from a public repository but never revoked](https://startwithidentity.com/breaches/incidents/2026-litellm-leaked-admin-key-poisoned-release/) ([static API key abuse](https://startwithidentity.com/techniques/static-api-key-abuse/)).
- **Compromised build systems.** A CI runner holds registry tokens, cloud credentials and signing keys. In the August 2026 [poisoned Rust crates](https://startwithidentity.com/blog/2026-08-21-poisoned-rust-crates-steal-developer-credentials/) case the malicious releases were live for 86 to 107 minutes, long enough for any pipeline resolving fresh dependencies to pull them.

Unowned [service accounts](https://startwithidentity.com/glossary/service-account/) sit behind several of these: no owner means no rotation, no review and no MFA.

## What actually fixes it

The durable answer is to stop having a credential to steal. Platform-attested [workload identity](https://startwithidentity.com/glossary/workload-identity/), where the runtime proves what the workload is and a short-lived token is issued on that basis, removes the secret from the threat model rather than protecting it better. Cloud providers implement this through workload identity federation, Kubernetes through projected service account tokens, and SPIFFE as the vendor-neutral abstraction across both.

Standards work is still moving. The IETF [WIMSE](https://startwithidentity.com/standards/wimse/) working group, which covers workload identity in multi-system environments, has no RFC yet: as of November 2026 its HTTP signature draft has gone to the IESG and its workload identity practices draft is in IETF Last Call until 13 November 2026. [OAuth transaction tokens](https://startwithidentity.com/standards/oauth-transaction-tokens/), for carrying caller context between services, are at draft-11 with an IESG milestone of December 2026.

Where a static credential is unavoidable, the controls that matter are ownership, scope, and a rotation path you have actually tested. Rotation on a calendar is weaker than rotation on an event, and both are weaker than not having a long-lived secret.

## The frontier: AI agents

[Agentic identity](https://startwithidentity.com/glossary/agentic-identity/) extends machine identity to AI agents that act for users, needing scoped, delegated, revocable credentials. See [what is a non-human identity](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/) and [securing AI agent identities](https://startwithidentity.com/guides/machine-identity/securing-ai-agent-identities/).

## Machine identity platforms in 2026

Consolidation reshaped this market:

- Palo Alto Networks closed its acquisition of CyberArk on 11 February 2026. Venafi, which CyberArk had bought, is now sold as [Palo Alto Networks Next-Gen Trust Security (formerly Venafi)](https://startwithidentity.com/vendors/machine-identity/venafi/), and Conjur as [Idira Secrets Manager](https://startwithidentity.com/vendors/secrets/cyberark-conjur/), both since 12 May 2026.
- [Keyfactor](https://startwithidentity.com/vendors/pki/keyfactor/) acquired InfoSec Global and CipherInsights in May 2025, adding cryptographic discovery for post-quantum planning.
- Sectigo bought Entrust's public certificate business in January 2025.
- [HashiCorp Vault](https://startwithidentity.com/vendors/machine-identity/hashicorp-vault/) is an IBM subsidiary.

| Need | Start with |
|---|---|
| Enterprise certificate inventory and renewal | Palo Alto Networks Next-Gen Trust Security (formerly Venafi), Keyfactor, [AppViewX](https://startwithidentity.com/vendors/pki/appviewx/) |
| Internal CA and short-lived certs for engineers and devices | [Smallstep](https://startwithidentity.com/vendors/pki/smallstep/), [EJBCA](https://startwithidentity.com/vendors/pki/ejbca/) |
| Secrets and dynamic credentials | HashiCorp Vault, [Akeyless](https://startwithidentity.com/vendors/machine-identity/akeyless/), [Infisical](https://startwithidentity.com/vendors/secrets/infisical/) |
| Vendor-neutral workload identity | [SPIFFE/SPIRE](https://startwithidentity.com/vendors/machine-identity/spiffe-spire/), [Defakto (formerly SPIRL)](https://startwithidentity.com/vendors/machine-identity/spirl/) |
| Workload-to-SaaS and agent access without static keys | [Aembit](https://startwithidentity.com/vendors/ai-identity/aembit/) |

Pricing is mostly by quote. In SWI's [pricing index](https://startwithidentity.com/reports/identity-pricing-transparency-index-2026/), no machine identity vendor publishes a paid list price; the category scores 40 out of 100 only because Vault Community and SPIFFE/SPIRE are free to run and Akeyless has a free tier. Aembit lists 20 dollars per workload per month after a free tier of 10 workloads.

## Where to start

1. **Inventory certificates and keys**, including who owns each and when it expires.
2. **Automate public certificate renewal** before the 100-day limit arrives in March 2027.
3. **Move new workloads to federated or SPIFFE identity** instead of issuing keys.
4. **Revoke, do not just delete**, any credential that has touched a repository.

Then compare [Keyfactor vs Venafi](https://startwithidentity.com/compare/keyfactor-vs-venafi/) and [SPIFFE/SPIRE vs HashiCorp Vault](https://startwithidentity.com/compare/spiffe-spire-vs-hashicorp-vault/), read the [top machine identity management platforms](https://startwithidentity.com/articles/top-5-machine-identity-management-platforms/), the [machine identity management guide](https://startwithidentity.com/guides/machine-identity/machine-identity-management-guide/) and [workload identity 101](https://startwithidentity.com/guides/machine-identity/workload-identity-101/), and see the rankings for [machine identity for enterprises](https://startwithidentity.com/rankings/best-machine-identity-for-enterprises/) and [for startups](https://startwithidentity.com/rankings/best-machine-identity-for-startups/).

## What Is Passwordless Authentication? Methods and Providers
Source: https://startwithidentity.com/guides/fundamentals/what-is-passwordless/
Last updated: 2026-11-05

Passwordless authentication verifies a user without a password or other shared secret they must remember: the user proves identity with something they have (a phone, laptop or security key) confirmed by something they are (a biometric) or know (a local PIN). The strongest form is the [passkey](https://startwithidentity.com/glossary/passkey/), built on [WebAuthn and FIDO2](https://startwithidentity.com/standards/webauthn-fido2/). Not every passwordless method resists phishing, and that distinction decides most buying choices.

## Why move off passwords

Passwords are reused, phished, guessed and leaked, which feeds [credential stuffing](https://startwithidentity.com/techniques/credential-stuffing/) and [password spraying](https://startwithidentity.com/techniques/password-spraying/). The pattern is constant in SWI's breach database: about 14,000 [23andMe accounts](https://startwithidentity.com/breaches/incidents/2023-23andme-credential-stuffing-dna-relatives/) opened with reused passwords exposed profile data on about 6.9 million people, and [Roku](https://startwithidentity.com/breaches/incidents/2024-roku-credential-stuffing/) lost about 591,000 accounts to stuffing in two waves in 2024. Removing the shared secret removes the thing attackers collect.

Adoption is no longer the blocker. The FIDO Alliance [said on 15 October 2026](https://fidoalliance.org/7-billion-passkeys-and-counting-the-next-chapter-of-passwordless-authentication/) that about 7 billion passkeys are in circulation, that more than a third of successful sign-ins at the 15 services in its Passkey Index now use a passkey, and that passkey sign-ins are nearly three times faster than passwords. Our [Passkey Index analysis](https://startwithidentity.com/blog/passkey-index-2026-what-it-means-for-your-rollout/) covers what that means for a rollout.

## The passwordless spectrum

Passwordless is a user experience claim, not a security claim. [Magic links](https://startwithidentity.com/glossary/magic-link/) and emailed one-time codes remove the password and keep the phishability: a real-time relay kit captures the code the user types as easily as it captures a password. Only origin-bound credentials, passkeys and FIDO2 security keys, remove both, because the authenticator refuses to sign for a domain other than the one that registered it.

| Method | Removes password | Phishing-resistant | Main weakness |
|---|---|---|---|
| Magic link | Yes | No | Email account takeover, link forwarding |
| Email or SMS one-time code | Yes | No | [OTP relay](https://startwithidentity.com/techniques/otp-relay-social-engineering/), [SIM swap](https://startwithidentity.com/glossary/sim-swap/) |
| Authenticator app code ([TOTP](https://startwithidentity.com/glossary/totp/)) | Only with a second factor | No | Relay, cloud-synced seeds |
| Push approval | Only with a second factor | No | [Push bombing](https://startwithidentity.com/techniques/mfa-fatigue-push-bombing/); [number matching](https://startwithidentity.com/glossary/number-matching/) reduces it |
| [Synced passkey](https://startwithidentity.com/glossary/synced-passkey/) | Yes | Yes | Security of the sync account and recovery |
| Device-bound passkey or security key | Yes | Yes | Cost and lost-key logistics |

NIST draws the same line. In [SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html), authenticators that involve manual entry of an output, which includes OTP and out-of-band codes, are not phishing resistant; verifiers must offer at least one phishing-resistant option at AAL2; and AAL3 requires a non-exportable private key, so synced passkeys do not qualify at that level.

## What changed in 2025-2026

- **Standards.** WebAuthn Level 3 became a W3C Recommendation on 25 August 2026, and CTAP 2.3 became a FIDO Proposed Standard in February 2026 (see the [WebAuthn and FIDO2 standard page](https://startwithidentity.com/standards/webauthn-fido2/)).
- **Platform defaults.** Passkeys became the Microsoft Entra ID default on 1 September 2026, and Microsoft stops delivering SMS and voice codes in Entra ID on 1 February 2027 for most users ([the SMS off-ramp](https://startwithidentity.com/blog/sms-mfa-off-ramp-2027/)).
- **Ownership.** [Stytch](https://startwithidentity.com/vendors/ciam/stytch/) has been part of Twilio since November 2025. Ping Identity [signed a definitive agreement to acquire Keyless](https://press.pingidentity.com/2025-10-30-Ping-Identity-Strengthens-Defense-Against-AI-Driven-Impersonation-with-Privacy-Preserving-Biometrics), a privacy-preserving biometric authentication company, on 30 October 2025. Vercel acquired [Better Auth](https://startwithidentity.com/vendors/open-source/better-auth/) on 7 July 2026; the library stays MIT licensed. See [identity acquisitions](https://startwithidentity.com/acquisitions/).
- **Attacks moved around the cryptography.** Three research teams published passkey attacks in August 2026 that targeted event logs, sync key custody and in-session key reuse, all from malware already on the endpoint ([passkeys had a hard month](https://startwithidentity.com/blog/passkeys-first-hard-month/), [credential manager key extraction](https://startwithidentity.com/techniques/credential-manager-key-extraction/)).

## Passwordless authentication providers

| Use case | Providers to shortlist | Pricing signal (checked October 2026) |
|---|---|---|
| Workforce, already on Microsoft | [Microsoft Entra](https://startwithidentity.com/vendors/iam/microsoft-entra/) with [Microsoft Authenticator](https://startwithidentity.com/vendors/mfa/microsoft-authenticator/) | Entra ID P1 $7, P2 $10 per user per month, paid yearly |
| Workforce, any IdP | [Okta](https://startwithidentity.com/vendors/iam/okta/), [Duo](https://startwithidentity.com/vendors/mfa/duo/), [HYPR](https://startwithidentity.com/vendors/mfa/hypr/), [Beyond Identity](https://startwithidentity.com/vendors/mfa/beyond-identity/), [1Kosmos](https://startwithidentity.com/vendors/mfa/1kosmos/) | Duo free to 10 users, then $3, $6, $9; Okta Starter $6; others quote |
| Hardware for admins | [Yubico](https://startwithidentity.com/vendors/mfa/yubico/) | Published per-key prices |
| Customer apps, developer-led | [Auth0](https://startwithidentity.com/vendors/ciam/auth0/), Stytch, [Descope](https://startwithidentity.com/vendors/ciam/descope/), [Clerk](https://startwithidentity.com/vendors/ciam/clerk/) | Free tiers from 7,500 to 50,000 users |
| Customer apps, enterprise fraud focus | [Transmit Security](https://startwithidentity.com/vendors/ciam/transmit-security/), [Ping Identity](https://startwithidentity.com/vendors/iam/ping-identity/) | Quote-based |
| Add passkeys to an existing login | [Corbado](https://startwithidentity.com/vendors/ciam/corbado/), [Hanko](https://startwithidentity.com/vendors/open-source/hanko/) | Hanko free to 10,000 MAU, Pro $29/month |

Prices come from the [Identity Pricing Transparency Index 2026](https://startwithidentity.com/reports/identity-pricing-transparency-index-2026/). For scored comparisons, see the [best passwordless CIAM providers](https://startwithidentity.com/rankings/best-passwordless-ciam-providers/), [best phishing-resistant MFA](https://startwithidentity.com/rankings/best-phishing-resistant-mfa/), the [top passwordless authentication platforms](https://startwithidentity.com/articles/top-7-passwordless-authentication-platforms/) and [Duo vs Microsoft Authenticator](https://startwithidentity.com/compare/duo-vs-microsoft-authenticator/).

## Recovery is the other half of the project

Deleting the password also deletes the fallback everyone quietly relied on, and an insecure recovery path becomes the new weakest link. An account protected by a passkey with SMS recovery is protected by SMS. Coinbase customers learned this in 2021 when attackers abused an [SMS account recovery flaw](https://startwithidentity.com/breaches/incidents/2021-coinbase-sms-recovery-flaw/) to take over at least 6,000 accounts. At Retool in 2023, Google Authenticator had [synced an employee's MFA seeds to a Google account](https://startwithidentity.com/breaches/incidents/2023-retool-sms-phishing-authenticator-sync/), so one phished account yielded the other factors too.

Three rules hold up: enrol at least two credentials per account, prompt for the second at the first successful sign-in rather than at registration, and be explicit in the UI about what happens when every registered device is gone. For consumer products that usually means [identity verification](https://startwithidentity.com/glossary/idv/); for workforce it means a help desk process that does not rely on caller-supplied facts ([help desk social engineering](https://startwithidentity.com/techniques/help-desk-social-engineering/)). See [account recovery](https://startwithidentity.com/glossary/account-recovery/).

## Where to start

1. Tier users: synced passkeys for the general population, device-bound keys for administrators and production access.
2. Offer passkeys at sign-in and after recovery, not only in account settings.
3. Remove the password and SMS fallback for accounts that have two passkeys, rather than leaving them beside the passkey.
4. Measure passkey sign-in share and recovery volume monthly.

Read [Passkeys 101](https://startwithidentity.com/guides/authentication/passkeys-101/), the [passwordless implementation guide](https://startwithidentity.com/guides/authentication/passwordless-authentication-implementation-guide/) and the [passwordless strategy guide](https://startwithidentity.com/guides/authentication/passwordless-strategy/), check SaaS support in the [MFA matrix](https://startwithidentity.com/tools/mfa-matrix/), and choose a vendor with [how to choose an MFA solution](https://startwithidentity.com/guides/buyer-guides/how-to-choose-an-mfa-solution/).

## What Is Privileged Access Management (PAM)? PAM Solutions Explained
Source: https://startwithidentity.com/guides/fundamentals/what-is-pam/
Last updated: 2026-11-05

A PAM solution is software that controls the use of privileged accounts (administrator, root and service accounts) by vaulting their credentials, brokering and recording privileged sessions, and granting elevated rights only when needed.

Privileged Access Management (PAM) is the discipline behind it: securing the most powerful accounts in an organization, meaning administrators, root, service accounts, and anything that can change systems or read sensitive data. These accounts are the prize attackers want most, so they get dedicated controls.

## What PAM does

- **Vaulting** stores and rotates privileged credentials so humans never know the raw password.
- **Session management** brokers, monitors, and records privileged sessions.
- **Just-in-time (JIT) access** grants elevated rights only for as long as they are needed, moving toward [zero standing privileges](https://startwithidentity.com/glossary/zero-standing-privileges/). See the [best just-in-time access tools](https://startwithidentity.com/articles/top-5-just-in-time-access-tools/).
- **Discovery** finds unmanaged privileged accounts before attackers do.

## Two kinds of PAM solution

PAM products split into two families, and most buying mistakes come from picking the wrong one.

| | Vault-first PAM | Infrastructure-access PAM |
|---|---|---|
| Assumes | Privileged accounts exist and must be controlled | Standing credentials should not exist |
| Core mechanism | Credential vault, rotation, session isolation and recording | Short-lived certificates or injected credentials tied to SSO identity |
| Typical users | IT admins, third-party vendors, auditors | Engineers reaching servers, Kubernetes, databases |
| Examples (Nov 2026) | [Idira (formerly CyberArk)](https://startwithidentity.com/vendors/pam/cyberark/), [BeyondTrust](https://startwithidentity.com/vendors/pam/beyondtrust/), [Delinea](https://startwithidentity.com/vendors/pam/delinea/) | [Teleport](https://startwithidentity.com/vendors/pam/teleport/), [HashiCorp Boundary](https://startwithidentity.com/vendors/pam/hashicorp-boundary/), [StrongDM](https://startwithidentity.com/vendors/pam/strongdm/) |
| Weak spot | Operational weight, slow access paths | Legacy Windows password vaulting |

Large estates usually run both. For scored shortlists, see the [best PAM tools](https://startwithidentity.com/rankings/best-pam-tools/) and the [top 10 PAM solutions in 2026](https://startwithidentity.com/articles/top-10-pam-solutions-2026/), or by segment: [enterprise](https://startwithidentity.com/rankings/best-pam-for-enterprises/), [small business](https://startwithidentity.com/rankings/best-pam-for-smb/) and [DevOps](https://startwithidentity.com/rankings/best-pam-for-devops/).

## The PAM market in 2026

The vendor map changed more in 2026 than in the previous five years. Palo Alto Networks closed its acquisition of CyberArk on 11 February 2026 and rebranded it Idira on 12 May. Delinea closed its acquisition of StrongDM on 5 March. 1Password acquired the just-in-time vendor [Apono](https://startwithidentity.com/vendors/pam/apono/) in June, and HashiCorp, including Boundary, has been part of IBM since February 2025. The [acquisitions tracker](https://startwithidentity.com/acquisitions/) has the full list, and [CyberArk alternatives](https://startwithidentity.com/articles/cyberark-alternatives/) covers what the Idira change means for renewals.

Remote-access components are also the part of PAM most often attacked. [CVE-2026-102764](https://startwithidentity.com/cves/cve-2026-102764/), a zero-day in self-hosted BeyondTrust Remote Support, was exploited from 29 August 2026 to export the appliance's vaulted administrator credentials. A PAM appliance is tier-zero infrastructure and needs the fastest patch cycle you run.

## Why it is separate from IAM

Standard [IAM](https://startwithidentity.com/guides/fundamentals/what-is-iam/) governs everyday access. PAM adds a hardened layer for high-blast-radius accounts, with stronger isolation, recording, and approval workflows. It overlaps with [secrets management](https://startwithidentity.com/vendors/secrets/) for application credentials and increasingly with [non-human identity](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/).

## Where PAM programs go wrong

Three failure modes recur, and none of them are product problems:

- **Vaulting the problem instead of removing it.** A vault protecting 400 permanent administrator accounts is a smaller win than eliminating 300 of them. Count [standing privilege](https://startwithidentity.com/glossary/zero-standing-privileges/) first; the number tells you how much of the programme is avoidable.
- **A privileged path slower than the workaround.** If checking out a credential takes ten minutes and the incident is on fire, engineers keep a personal admin account. Adoption is the whole game, so measure the percentage of privileged sessions that actually go through the tool.
- **Break-glass accounts that do not work.** The emergency account excluded from conditional access is either untested (and fails during the outage it exists for) or unmonitored (and becomes a standing backdoor). Test it on a schedule and alert on every use. See [break-glass](https://startwithidentity.com/glossary/break-glass/).

## Human privilege is only half of it

The privileged accounts that cause incidents are increasingly not people. [Service accounts](https://startwithidentity.com/glossary/service-account/) with domain rights, CI/CD runners holding cloud credentials, and management platforms with agents on every endpoint are all privileged access by any reasonable definition, and most PAM programs scope them out.

The August 2026 N-able N-central compromise is the pattern: an authentication bypass on a remote monitoring platform gave attackers administrative control, and they used its own remote session feature to reach every managed customer network. Treat management platforms, CI systems, and secrets stores as tier-zero privileged infrastructure, not as IT tooling.

## How this relates to secrets and machine identity

There is real overlap and it is worth being deliberate. [Secrets management](https://startwithidentity.com/guides/fundamentals/what-is-secrets-management/) covers credentials applications use, ideally issued short-lived and on demand. [Machine identity](https://startwithidentity.com/guides/fundamentals/what-is-machine-identity/) covers cryptographic identity for workloads. PAM covers privileged access by humans and the shared accounts they use. Most organizations need all three, and the boundary that matters is who or what holds the credential, not which vendor sells it.

## Where to start

Browse [PAM vendors](https://startwithidentity.com/vendors/pam/), compare leaders like [CyberArk vs Delinea](https://startwithidentity.com/compare/cyberark-vs-delinea/), or read [how to choose a PAM solution](https://startwithidentity.com/guides/buyer-guides/how-to-choose-a-pam-solution/). Short definitions: [PAM](https://startwithidentity.com/glossary/pam/) and [just-in-time access](https://startwithidentity.com/glossary/jit-access/).

## What Is SCIM? SCIM Provisioning and SCIM 2.0 Explained
Source: https://startwithidentity.com/guides/fundamentals/what-is-scim/
Last updated: 2026-11-05

SCIM (System for Cross-domain Identity Management) is the open IETF standard for SCIM provisioning: an identity provider uses it to create, update and remove user accounts and groups in applications automatically. SCIM 2.0 is defined by RFC 7643 (the schema) and RFC 7644 (the REST protocol). When HR adds an employee or an admin assigns an app, SCIM pushes the change, and when someone leaves, it disables the account without a ticket.

## Why it matters

Manual account management is slow and leaky. The biggest risk is [deprovisioning](https://startwithidentity.com/glossary/deprovisioning/): accounts that linger after someone leaves become [orphaned accounts](https://startwithidentity.com/glossary/orphaned-account/) and attacker targets ([orphaned account abuse](https://startwithidentity.com/techniques/orphaned-account-abuse/)). A former Cash App employee [downloaded customer reports after leaving](https://startwithidentity.com/breaches/incidents/2022-cash-app-former-employee/); Colonial Pipeline was entered through a [legacy VPN account](https://startwithidentity.com/breaches/incidents/2021-colonial-pipeline-legacy-vpn/) the company believed was unused. SCIM closes that gap by automating the [joiner-mover-leaver](https://startwithidentity.com/glossary/joiner-mover-leaver/) lifecycle for every application that supports it.

## How SCIM works

The identity provider is the SCIM client. The application exposes a SCIM server endpoint and accepts JSON over HTTPS.

| Operation | HTTP request | Typical trigger |
|---|---|---|
| Create user | `POST /Users` | User assigned to the app |
| Look up before create | `GET /Users?filter=userName eq "..."` | Matching to avoid duplicates |
| Update attributes | `PATCH /Users/{id}` | Department, manager or name change |
| Disable user | `PATCH` with `active: false` | Leaver, unassignment, out of scope |
| Delete user | `DELETE /Users/{id}` | Hard delete in the source |
| Manage group membership | `PATCH /Groups/{id}` | Group add or remove |
| Discover features | `GET /ServiceProviderConfig`, `/Schemas`, `/ResourceTypes` | Setup |

[Microsoft Entra ID's provisioning service](https://learn.microsoft.com/en-us/entra/identity/app-provisioning/how-provisioning-works) is a good worked example. It runs an initial cycle and then back-to-back incremental cycles. When a user is unassigned, disabled or soft-deleted, it sends an update setting `active` to false; Entra hard-deletes users 30 days after a soft delete, and only then sends a DELETE. It cannot read nested groups, only direct members of an assigned group. If most calls fail, for example because the app's credentials expired, the job enters quarantine, cycles slow to once a day, and after four weeks the job is disabled. Each of those behaviors is a place where a leaver can keep access.

## Standard status in 2026

SCIM 2.0 has been stable since 2015 and there is no SCIM 3.0. The IETF has extended it rather than replaced it: [RFC 9865](https://datatracker.ietf.org/doc/rfc9865/) (October 2025) adds cursor-based pagination for large directories, and [RFC 9967](https://datatracker.ietf.org/doc/rfc9967/) (May 2026) adds a SCIM profile for security event tokens. See the [SCIM 2.0 standard page](https://startwithidentity.com/standards/scim-2-0/) and the [SCIM glossary entry](https://startwithidentity.com/glossary/scim/).

## SCIM vs SAML vs OIDC vs JIT provisioning

| | SCIM | SAML / OIDC | Just-in-time (JIT) provisioning |
|---|---|---|---|
| Job | Account lifecycle | Sign-in | Create account at first sign-in |
| Creates accounts before first login | Yes | No | No |
| Updates attributes and groups | Yes, anytime | Only at sign-in | Only at sign-in |
| Deprovisions leavers | Yes | No | No |
| Standard | RFC 7643, RFC 7644 | [SAML 2.0](https://startwithidentity.com/standards/saml-2-0/), [OpenID Connect](https://startwithidentity.com/standards/openid-connect/) | Vendor-specific |

JIT provisioning is often sold as an alternative to SCIM. It is not one, because it never removes anyone.

## Where SCIM implementations break

The standard is straightforward; implementations vary enough that "supports SCIM 2.0" tells you less than it should:

- **Deactivation versus deletion.** RFC 7644 lets a server choose not to permanently delete a resource as long as it returns 404 afterwards, and some apps ignore `active: false`. Test that a disabled leaver cannot sign in.
- **Sessions and tokens survive.** Disabling the account may not revoke API tokens or OAuth grants. At CrowdSec, a departing engineer's account was [left open and its OAuth token later used](https://startwithidentity.com/breaches/incidents/2026-crowdsec-departing-engineer-github-token/) to copy about 170 private repositories.
- **Group handling.** Group sync is the least consistent part. Check whether groups push at all, whether nested groups flatten, and what happens on rename.
- **PATCH support.** Apps that only accept full PUT replacement drop attributes the IdP did not send.
- **Pagination and filtering.** Fine at 500 users, a real problem at 50,000; RFC 9865 cursors help where implemented.
- **Attribute mapping.** Custom attributes and enterprise extensions are where most integration time goes.
- **Silent failure.** A quarantined or disabled provisioning job stops deprovisioning without anyone noticing. Alert on it.

## The long tail is the real work

SCIM covers the applications that support it. The residual is the on-premises tool, the appliance with a local user database, the SaaS product bought on a corporate card. Those are where orphaned accounts accumulate; an [IGA platform](https://startwithidentity.com/guides/fundamentals/what-is-iga/) or regular reconciliation covers them. Reconcile every account against an authoritative owner at least once, and use the [secure offboarding checklist](https://startwithidentity.com/templates/secure-offboarding-checklist/). Many vendors also gate SCIM behind enterprise tiers, the [SSO tax](https://startwithidentity.com/glossary/sso-tax/).

## If you sell B2B SaaS

SCIM plus SAML is a procurement gate above a certain deal size. Self-serve configuration matters as much as the protocol: every connection your support team configures by hand is a cost that scales with your customer count. Published pricing for adding it, from the [Identity Pricing Transparency Index 2026](https://startwithidentity.com/reports/identity-pricing-transparency-index-2026/), checked October 30, 2026:

| Vendor | SSO and SCIM pricing |
|---|---|
| [WorkOS](https://startwithidentity.com/vendors/ciam/workos/) | 125 dollars per connection (1 to 15) |
| [Stytch](https://startwithidentity.com/vendors/ciam/stytch/) (Twilio since November 2025) | 125 dollars per connection beyond 5 |
| [SSOJet](https://startwithidentity.com/vendors/ciam/ssojet/) | 59 dollars per connection per month annual, two-connection minimum; SSO and SCIM count as two |
| [Frontegg](https://startwithidentity.com/vendors/ciam/frontegg/) | Free tier includes 5 SSO/SCIM connections |

Compare the field in [best SSO and SCIM platforms for B2B SaaS](https://startwithidentity.com/rankings/best-sso-scim-platforms-b2b-saas/) and the [top SCIM provisioning tools](https://startwithidentity.com/articles/top-7-scim-provisioning-tools/), alongside [Auth0](https://startwithidentity.com/vendors/ciam/auth0/), [FusionAuth](https://startwithidentity.com/vendors/ciam/fusionauth/) and [Keycloak](https://startwithidentity.com/vendors/open-source/keycloak/).

## Where to start

Workforce teams: SCIM is usually configured in [Okta](https://startwithidentity.com/vendors/iam/okta/), [Microsoft Entra ID](https://startwithidentity.com/vendors/iam/microsoft-entra/) or [JumpCloud](https://startwithidentity.com/vendors/iam/jumpcloud/); start with the [SCIM provisioning implementation guide](https://startwithidentity.com/guides/implementation/scim-provisioning-implementation-guide/) and browse [IGA platforms](https://startwithidentity.com/vendors/iga/) and [workforce IAM](https://startwithidentity.com/vendors/iam/).

## What Is Secrets Management? Tools, Open Source and Pricing
Source: https://startwithidentity.com/guides/fundamentals/what-is-secrets-management/
Last updated: 2026-11-05

Secrets management is how you store, distribute, rotate and audit the credentials that applications and infrastructure use: API keys, database passwords, tokens and certificates. A secrets manager keeps them in one controlled place and hands them to workloads at runtime, so they never sit in source code or configuration files. These are [non-human identity](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/) credentials, and leaked ones are a leading cause of cloud breaches.

## The problem

Secrets end up hardcoded in source, baked into images and pasted into config. Once leaked, many stay valid for a long time. GitGuardian found [4,576 n8n API tokens](https://startwithidentity.com/blog/2026-08-05-leaked-n8n-api-tokens-expose-connected-credentials/) in public GitHub commits in August 2026, and about 36 percent of the reachable instances it tested still accepted at least one. Exposed secrets were the most common starting point of the non-human identity breaches in SWI's [Identity Breach Report 2026](https://startwithidentity.com/reports/identity-breach-report-2026/).

## What good looks like

- **Central vault** instead of secrets scattered across repos and pipelines.
- **Dynamic, short-lived secrets** issued on demand rather than long-lived static keys.
- **Automated [rotation](https://startwithidentity.com/glossary/secrets-rotation/)** so exposure windows stay small.
- **Detection** of secrets that leak into code, logs and tickets.
- **Audit** of who and what read each secret, and when.
- **Workload authentication to the vault** that is not itself a static secret, such as cloud IAM roles or Kubernetes service account tokens.

## Types of secrets management tools

| Type | Examples | Best when | Limits |
|---|---|---|---|
| Cloud-native secret store | [AWS Secrets Manager](https://startwithidentity.com/vendors/secrets/aws-secrets-manager/), [Azure Key Vault](https://startwithidentity.com/vendors/secrets/azure-key-vault/), [Google Cloud Secret Manager](https://startwithidentity.com/vendors/secrets/google-cloud-secret-manager/) | One main cloud, workloads already use its IAM | Each cloud is a separate island |
| Cross-cloud vault with dynamic secrets | [HashiCorp Vault](https://startwithidentity.com/vendors/machine-identity/hashicorp-vault/), [Akeyless](https://startwithidentity.com/vendors/machine-identity/akeyless/), [Idira Secrets Manager](https://startwithidentity.com/vendors/secrets/cyberark-conjur/) | Multi-cloud, on-premises, database credentials on demand | Operating effort (self-hosted Vault) or quote-based pricing |
| Developer-first secrets platform | [Infisical](https://startwithidentity.com/vendors/secrets/infisical/), [Doppler](https://startwithidentity.com/vendors/secrets/doppler/), [1Password Secrets Automation](https://startwithidentity.com/vendors/secrets/1password-secrets/) | Syncing app config to CI and many environments | Fewer dynamic secret engines |
| PAM-adjacent DevOps vault | [Delinea DevOps Secrets Vault](https://startwithidentity.com/vendors/secrets/delinea-devops-secrets-vault/) | Teams already on Delinea PAM | Tied to that ecosystem |
| Secrets detection | [GitGuardian](https://startwithidentity.com/vendors/secrets/gitguardian/) | Finding what already leaked | Does not store secrets |

## Open source secrets managers

Searches for an open source secrets manager usually lead to five options:

- **Vault Community** is free to self-host, but HashiCorp moved Vault to the Business Source License on 10 August 2023, which is not an OSI-approved licence. Vault is now an IBM subsidiary.
- **OpenBao** is the fork created after that change, governed under the Linux Foundation and, since June 2025, OpenSSF.
- **Infisical** is MIT licensed outside its enterprise directories, with no user cap.
- **Conjur Open Source** is free to self-operate; the commercial product is now sold as Idira Secrets Manager after Palo Alto Networks' acquisition of CyberArk (closed 11 February 2026, rebranded 12 May 2026).
- **SOPS** encrypts secrets in files kept in Git.

Self-hosting moves the cost from licence to engineering time: unsealing, upgrades, backups and high availability. See the [top open source secrets management tools](https://startwithidentity.com/articles/top-6-open-source-secrets-management/) and [HashiCorp Vault alternatives](https://startwithidentity.com/articles/hashicorp-vault-alternatives/).

## What secrets managers cost

Secrets management scores 78 out of 100 in SWI's [Identity Pricing Transparency Index 2026](https://startwithidentity.com/reports/identity-pricing-transparency-index-2026/), behind only password managers (93) and open-source IAM (80): two thirds of secrets vendors publish a paid price. Checked on 5 November 2026 unless noted:

| Product | Free entry | Paid price | Billing unit |
|---|---|---|---|
| AWS Secrets Manager | No separate trial (general AWS Free Tier credits) | $0.40 per secret per month, plus $0.05 per 10,000 API calls | Secret and API call |
| Google Cloud Secret Manager | 6 versions and 10,000 accesses a month | About $0.06 per active version per month per location, $0.03 per 10,000 operations | Version and operation |
| Azure Key Vault | Not listed | $0.03 per 10,000 operations (East US retail list) | Operation |
| Doppler | Free for 3 users | Team $21 per user per month | User |
| Infisical | Free for 5 identities | Pro $20, Advanced $40 per identity per month, billed annually | Identity |
| Akeyless | 5 clients, 500 static secrets | Enterprise quote | Clients, transactions |
| Delinea DSV | 250 secrets, 20,000 API calls a month | Quote | Secrets, API calls |
| HashiCorp Vault | Community, self-hosted | HCP Vault Dedicated per cluster-hour and per client, no list price | Cluster and client |

Note that HCP Vault Secrets, HashiCorp's lighter hosted product, reached end of life on 1 July 2026. Read the billing unit before you compare: a per-secret price favours few large secrets, a per-user or per-identity price favours many secrets per app.

## Failure modes, with real incidents

- **CI secrets dumped by a poisoned dependency.** The March 2025 [tj-actions/changed-files compromise](https://startwithidentity.com/breaches/incidents/2025-tj-actions-changed-files-ci-secrets/) printed CI runner secrets into workflow logs that anyone could read on public repositories. The [Shai-Hulud 2.0 worm](https://startwithidentity.com/breaches/incidents/2025-shai-hulud-2-npm-worm/) harvested credentials from local files, environment variables and cloud secret managers on developer machines ([secrets in repositories and CI](https://startwithidentity.com/techniques/secrets-in-repositories-and-ci/)).
- **A credential extracted from a build image.** In the [Codecov case](https://startwithidentity.com/breaches/incidents/2021-codecov-bash-uploader/) a storage credential pulled from a Docker image let an attacker modify a script that sent customers' CI environment variables out.
- **One token, all the code.** The New York Times lost about 273 GB of source code through a [GitHub credential exposed in January 2024](https://startwithidentity.com/breaches/incidents/2024-new-york-times-exposed-github-token/).
- **The secrets platform holds the keys too.** CircleCI's attacker [stole customer environment variables and the encryption keys](https://startwithidentity.com/breaches/incidents/2023-circleci-engineer-session-token-theft/) needed to read them, from an engineer's session.
- **Deleted is not revoked.** LiteLLM's [poisoned release](https://startwithidentity.com/breaches/incidents/2026-litellm-leaked-admin-key-poisoned-release/) traced to an admin key removed from a public repository but never revoked ([static API key abuse](https://startwithidentity.com/techniques/static-api-key-abuse/)).

## The measure that matters

The useful metric is not how many secrets are in the vault. It is how many exist outside it. A vault full of static database passwords improves auditability and changes very little about blast radius; generating a short-lived credential on demand removes the asset entirely.

That is why the maturity order is: get secrets out of source and configuration, into a vault, then replace vaulted static secrets with dynamic ones, then replace dynamic secrets with platform-attested [workload identity](https://startwithidentity.com/glossary/workload-identity/) wherever the runtime can vouch for the caller.

## Why teams do not rotate

Ask why a credential has not been rotated in three years and the answer is almost never policy. It is that nobody is certain what breaks. That uncertainty is itself the finding: it means the secret has been copied rather than referenced, and its consumers are unknown. A single source of truth, references instead of copies and a tested rotation runbook matter more than the interval you choose.

## Automation platforms are credential concentrators

Workflow and automation tools exist to hold connections to databases, repositories, cloud accounts, AI services and support platforms, which makes a single token for the orchestrator worth more than any credential it stores. With a leaked n8n API token, an attacker does not need to read a stored secret: they can build a workflow that uses the credential to call their own endpoint. The same reasoning applies to CI systems and to MCP servers brokering agent access.

## Where to start

Read the [best secrets management tools](https://startwithidentity.com/rankings/best-secrets-management-tools/) ranking and the [top secrets management tools](https://startwithidentity.com/articles/top-8-secrets-management-tools/), then compare [Doppler vs Infisical](https://startwithidentity.com/compare/doppler-vs-infisical/), [AWS Secrets Manager vs HashiCorp Vault](https://startwithidentity.com/compare/aws-secrets-manager-vs-hashicorp-vault/), [Akeyless vs HashiCorp Vault](https://startwithidentity.com/compare/akeyless-vs-hashicorp-vault/) and [Vault vs Conjur](https://startwithidentity.com/compare/hashicorp-vault-vs-cyberark-conjur/). Browse all [secrets management vendors](https://startwithidentity.com/vendors/secrets/) and follow the [API key rotation guide](https://startwithidentity.com/guides/machine-identity/api-key-rotation-automation-guide/).

## What Is Self-Sovereign Identity (SSI)?
Source: https://startwithidentity.com/guides/fundamentals/what-is-self-sovereign-identity/
Last updated: 2026-11-05

Self-sovereign identity (SSI) is a model in which individuals and organizations hold and control
their own digital identity and credentials directly, rather than renting that control from
platforms, identity providers, or governments. You keep signed credentials in a wallet you control
and present them straight to whoever needs to check them, without a central provider in the middle
of each transaction. It is the guiding principle behind
[decentralized identity](https://startwithidentity.com/guides/fundamentals/what-is-decentralized-identity/), and in 2026 it is
moving from pilots to population-scale deployment through government wallet programs.

## The problem SSI answers

Most digital identity today lives in accounts you do not control. A provider can lock you out,
change its terms, see every service you log into, or shut down. Each new service asks you to prove
the same facts again, and each copy of your data is another breach waiting to happen. SSI flips
the model: an issuer signs a claim about you once, you hold it, and you choose when and to whom to
present it. The verifier checks the issuer's signature without contacting the issuer, so the
issuer does not learn where you used it.

## Where the idea came from

The modern framing comes from [Christopher Allen](https://startwithidentity.com/experts/christopher-allen/)'s essay
[The Path to Self-Sovereign Identity](https://www.lifewithalacrity.com/article/the-path-to-self-soverereign-identity/),
published on 26 April 2016. Allen describes four stages of online identity:

1. **Centralized:** a single authority issues and verifies identity.
2. **Federated:** several authorities share identity across sites, but each still holds control.
   This is the world of [SAML and OIDC](https://startwithidentity.com/guides/fundamentals/saml-vs-oidc/).
3. **User-centric:** the user is at the center, with consent and interoperability, but the
   registering entities still own the identity.
4. **Self-sovereign:** individuals control their own identities across any number of authorities.

## The ten principles

| Principle | What it asks for | How current systems deliver it |
|---|---|---|
| Existence | A person exists independently of their digital identity | A design stance, not a feature |
| Control | The user is the final authority over their identity | Keys held in the user's wallet |
| Access | Users can retrieve all their own data | Credentials stored by the holder |
| Transparency | Systems and algorithms are open | Open W3C, OpenID, and IETF standards |
| Persistence | Identity lasts as long as the user wishes | Long-lived DIDs; weak in practice if keys are lost |
| Portability | No single party holds the identity | Standard formats across wallets |
| Interoperability | Identity works across services and borders | OpenID4VC protocols, EU-wide wallet acceptance |
| Consent | Sharing requires deliberate agreement | Wallet prompts before each presentation |
| Minimalization | Disclose only what is needed | [Selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/), [zero-knowledge proofs](https://startwithidentity.com/glossary/zero-knowledge-proof/) |
| Protection | Individual rights win when they conflict with the network | Governance and regulation, the least mature area |

In practice these reduce to three demands: the user controls the identity, the identity is portable
across providers, and disclosure is minimized to what a transaction needs.

## How SSI works in practice

SSI is built from the same components as decentralized identity:

- **[Decentralized Identifiers (DIDs)](https://startwithidentity.com/glossary/decentralized-identifier/)** that the subject controls,
  defined by [W3C DID Core](https://www.w3.org/TR/did-core/), a Recommendation since 19 July 2022.
  See [DID methods compared](https://startwithidentity.com/guides/decentralized-identity/did-methods-compared/) for how they differ.
- **[Verifiable Credentials](https://startwithidentity.com/standards/verifiable-credentials/)** under the W3C
  [Verifiable Credentials Data Model 2.0](https://www.w3.org/TR/vc-data-model-2.0/), a Recommendation
  since 15 May 2025, issued, held, and presented within the
  [issuer, holder, verifier](https://startwithidentity.com/glossary/issuer-holder-verifier/) triangle.
- **Exchange protocols:** [OpenID for Verifiable Credential Issuance 1.0](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html)
  (final 16 September 2025) and [OpenID for Verifiable Presentations 1.0](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html)
  (final 9 July 2025), which support [SD-JWT](https://startwithidentity.com/glossary/sd-jwt/) VC and ISO mdoc formats. See
  [OpenID4VC](https://startwithidentity.com/standards/openid4vc/).
- **Governance and [trust registries](https://startwithidentity.com/glossary/trust-registry/)** so verifiers know which issuers to
  trust. The [Trust over IP](https://startwithidentity.com/glossary/trust-over-ip/) model separates technical and governance layers.

## A worked example: proving age without sharing a birth date

1. A government issuer gives you a person identification credential in your wallet, signed with
   its key.
2. A website asks for proof you are over 18 using an OpenID4VP request.
3. Your wallet shows you exactly what is requested; you consent.
4. The wallet presents only the "age over 18" claim, using selective disclosure, with a proof that
   it came from the issuer's credential.
5. The website verifies the issuer's signature and checks that the credential is not revoked. It
   never learns your name or birth date, and the issuer never learns which site you visited.

That last property is the practical difference from federated login, where the identity provider
is involved in every sign-in. See [decentralized vs federated identity](https://startwithidentity.com/guides/decentralized-identity/decentralized-identity-vs-federated-identity/)
and [age verification](https://startwithidentity.com/glossary/age-verification/).

## Where SSI meets the real world in 2026

- **EU Digital Identity Wallets.** Under [Regulation (EU) 2024/1183](https://startwithidentity.com/standards/eidas-2-eudi-wallet/),
  the European Commission says member states must provide
  [EU Digital Identity Wallets to citizens by the end of 2026](https://digital-strategy.ec.europa.eu/en/policies/eudi-regulation),
  and service providers legally required to identify customers will be obliged to accept the wallet
  for authentication. See [EUDI Wallet](https://startwithidentity.com/glossary/eudi-wallet/).
- **Mobile driver's licenses** under [ISO 18013-5](https://startwithidentity.com/standards/iso-18013-5-mdl/) are in phone wallets.
  See [mobile driver's license](https://startwithidentity.com/glossary/mobile-drivers-license/).
- **Reusable identity verification** turns one KYC check into a credential the customer can present
  again. See [reusable identity and KYC](https://startwithidentity.com/guides/decentralized-identity/reusable-identity-and-kyc-with-verifiable-credentials/)
  and the [identity verification vendors](https://startwithidentity.com/vendors/identity-verification/).

Track national schemes in the [digital IDs directory](https://startwithidentity.com/digital-ids/).

## Is a government wallet self-sovereign?

This is the live debate. State wallets adopt the SSI mechanics (holder-held credentials, direct
presentation, selective disclosure), which is a large privacy gain over federated login. But the
state certifies the wallet and defines the trust framework, so the individual does not decide which
identities exist or which issuers count. A fair summary is that 2026 deployments deliver Allen's
control, consent, and minimalization principles much better than his protection and persistence
principles. Practitioners should describe them accurately rather than claim full sovereignty.

## The honest tradeoffs

- **Recovery.** If the keys live on a lost phone, what then? Even large vendors are still working
  this out: Microsoft's [Entra Verified ID FAQ](https://learn.microsoft.com/en-us/entra/verified-id/verifiable-credentials-faq)
  says it is "currently evaluating options" for recovery.
- **Revocation without tracking.** Checking whether a credential is revoked can reveal its use. The
  W3C [Bitstring Status List](https://www.w3.org/TR/vc-bitstring-status-list/) addresses this by
  hiding each credential among at least 131,072 entries.
- **Verifier adoption.** A credential is only useful where it is accepted. Regulation is now forcing
  that in the EU; elsewhere it depends on network effects.
- **Governance.** Someone still decides which issuers are trusted. SSI moves that decision, it does
  not remove it.

For most enterprises the near-term reality is hybrid: [federated identity](https://startwithidentity.com/guides/fundamentals/saml-vs-oidc/)
for existing SSO, verifiable credentials for reusable verification and portable proofs, stitched
together by an [identity fabric](https://startwithidentity.com/guides/fundamentals/what-is-identity-fabric/).

## Where to start

Read [what is decentralized identity](https://startwithidentity.com/guides/fundamentals/what-is-decentralized-identity/) for the
architecture, the [Verifiable Credentials standard](https://startwithidentity.com/standards/verifiable-credentials/) for the data
model, and the [verifiable credentials implementation guide](https://startwithidentity.com/guides/decentralized-identity/verifiable-credentials-implementation-guide/)
to build. Listen to the [verifiable credentials podcast path](https://startwithidentity.com/podcasts/learn/verifiable-credentials/),
and browse the [decentralized identity vendor directory](https://startwithidentity.com/vendors/decentralized-identity/) to see who
is building it.

## What Is Workforce Identity? Workforce Identity Management Explained
Source: https://startwithidentity.com/guides/fundamentals/what-is-workforce-identity/
Last updated: 2026-10-17

Workforce identity is the set of digital identities belonging to the people who work for or with an organization: employees, contractors, and partners. **Workforce identity management** (workforce IAM) is how those identities are created, authenticated, granted access to company systems, reviewed, and removed. In practice it means one directory as the source of truth, single sign-on with strong MFA in front of every application, and access that follows the HR record from first day to last.

## How workforce identity differs from customer and non-human identity

Identity programs usually split into three populations, and each is built differently.

- **Workforce identity** covers people the organization employs or contracts. The goal is control: access is granted because of a job, MFA is mandatory, and auditors expect evidence of who had access and why.
- **Customer identity** ([CIAM](https://startwithidentity.com/guides/fundamentals/what-is-ciam/)) covers the people who use a product. The goal is conversion at consumer scale, with self-service registration, consent records, and fraud defense. A workforce user completes whatever login you require; a customer abandons.
- **Non-human identity** ([NHI](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/)) covers service accounts, API keys, workloads, and AI agents. These have no HR record and no manager, which is why they need their own ownership and rotation model.

Unqualified, "IAM" usually means the workforce slice. Our [what is IAM](https://startwithidentity.com/guides/fundamentals/what-is-iam/) guide covers the wider discipline.

## Core components of workforce IAM

- **Directory and identity provider.** The authoritative record of users and groups, often still [Active Directory](https://startwithidentity.com/glossary/active-directory/) on-premises synchronized to a cloud [identity provider](https://startwithidentity.com/glossary/identity-provider/) such as [Microsoft Entra ID](https://startwithidentity.com/vendors/iam/microsoft-entra/) or [Okta](https://startwithidentity.com/vendors/iam/okta/).
- **SSO and federation.** One login for every application, using [SAML 2.0](https://startwithidentity.com/standards/saml-2-0/) or [OpenID Connect](https://startwithidentity.com/standards/openid-connect/). [Federation](https://startwithidentity.com/glossary/federation/) extends the same identity to partners and clouds.
- **MFA, moving to phishing-resistant.** [NIST SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html) requires verifiers to offer at least one phishing-resistant option at AAL2 and requires phishing resistance at AAL3. For workforce that means [passkeys](https://startwithidentity.com/glossary/passkey/), FIDO2 security keys, or smart cards rather than SMS codes. See [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/).
- **Lifecycle and provisioning.** HR events drive [joiner-mover-leaver](https://startwithidentity.com/glossary/joiner-mover-leaver/) changes, pushed to applications through [SCIM 2.0](https://startwithidentity.com/standards/scim-2-0/) ([RFC 7644](https://www.rfc-editor.org/rfc/rfc7644)). The leaver step is where programs fail: in a [FIDO Alliance and HID survey](https://startwithidentity.com/blog/2026-06-15-fido-hid-study-finds-a-24-hour-access-revocation-gap/) of 500 IT and security leaders, 94 percent said they could revoke access within 24 hours, yet 35 percent had experienced delays or failures revoking access in the past two years.
- **Governance.** [Access certification](https://startwithidentity.com/glossary/access-certification/), access requests, and [segregation of duties](https://startwithidentity.com/glossary/sod/) keep access correct over time. This is [IGA](https://startwithidentity.com/guides/fundamentals/what-is-iga/), typically a product such as [SailPoint](https://startwithidentity.com/vendors/iga/sailpoint/) beside the identity provider.
- **Privileged access.** Administrators get vaulted credentials, session recording, and [just-in-time access](https://startwithidentity.com/glossary/jit-access/) through [PAM](https://startwithidentity.com/guides/fundamentals/what-is-pam/), for example [CyberArk](https://startwithidentity.com/vendors/pam/cyberark/) (now Idira, part of Palo Alto Networks).
- **Identity threat detection and response.** [ITDR](https://startwithidentity.com/guides/fundamentals/what-is-itdr/) watches the directory and identity provider for attacks such as token theft and privilege escalation; [Microsoft Defender for Identity](https://startwithidentity.com/vendors/itdr/microsoft-defender-identity/) is a common starting point in Microsoft estates.

## Common architecture

Most organizations land on the same shape:

1. **HR system as source of truth.** Hires, transfers, and terminations start here.
2. **Directory and cloud identity provider.** HR events create and change accounts; the IdP holds group membership and authentication policy.
3. **SSO and conditional access in front of applications.** Every SaaS and internal app trusts the IdP over SAML or OIDC, and [conditional access](https://startwithidentity.com/glossary/conditional-access/) checks device and risk at sign-in.
4. **SCIM provisioning outward.** The IdP creates and disables accounts in each application so removal in one place removes access everywhere.
5. **Governance, PAM, and ITDR as layers.** Governance reviews what the IdP granted, PAM controls admin paths the IdP does not, and ITDR watches both.

The gaps are predictable: applications that do not support SCIM, local admin accounts that never enter SSO, and SaaS bought outside procurement. Large estates with several directories often join them with an [identity fabric](https://startwithidentity.com/guides/fundamentals/what-is-identity-fabric/) rather than a single platform.

## What changed in 2026

- **Passkeys for workforce are mainstream intent, not yet mainstream deployment.** The same FIDO Alliance and HID study found 93 percent of organizations somewhere in a passkey rollout but only 13 percent deployed at scale.
- **Microsoft Entra ID is retiring the SMS and voice MFA it delivers.** Passkeys became the default on September 1, 2026, and Microsoft-delivered SMS and voice end on February 1, 2027 for most users, per Microsoft's [retirement guide](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement). Our [SMS off-ramp plan](https://startwithidentity.com/blog/sms-mfa-off-ramp-2027/) covers the migration.
- **AI agents act for employees.** An agent that reads mail or files tickets on a user's behalf needs delegated, scoped, short-lived access tied to that user, not a shared API key. OAuth [token exchange](https://startwithidentity.com/glossary/token-exchange/) ([RFC 8693](https://www.rfc-editor.org/rfc/rfc8693)) defines an `act` claim for exactly this delegation. See [securing AI agent identities](https://startwithidentity.com/guides/machine-identity/securing-ai-agent-identities/) and [agentic identity](https://startwithidentity.com/glossary/agentic-identity/).

## How to choose a workforce identity platform

Start from what you already license and run. Microsoft 365 estates usually begin with Entra ID; organizations that want a neutral identity provider across Microsoft, Google, and AWS often choose Okta or [Ping Identity](https://startwithidentity.com/vendors/iam/ping-identity/); smaller teams that also need device management often look at [JumpCloud](https://startwithidentity.com/vendors/iam/jumpcloud/). Then check four things in order: SCIM coverage for your top applications, phishing-resistant MFA for every user including admins, deployment constraints (cloud only, or hybrid with on-premises AD), and whether governance and PAM come from the same vendor or separate ones.

Most workforce platforms are delivered as [IDaaS](https://startwithidentity.com/guides/fundamentals/what-is-idaas/). For scored shortlists, see [IAM platforms compared](https://startwithidentity.com/rankings/best-iam-platforms/), [best IAM for enterprises](https://startwithidentity.com/rankings/best-iam-for-enterprises/), [best IAM for small business](https://startwithidentity.com/rankings/best-iam-for-smb/), and our [top workforce identity platforms](https://startwithidentity.com/articles/top-6-workforce-identity-platforms/), or browse all [workforce IAM vendors](https://startwithidentity.com/vendors/iam/).

## Workforce identity federation, the term and the Google Cloud product

"Workforce identity federation" describes a pattern: employees sign in with the identity provider they already have to reach another organization's or a cloud's resources, over SAML or OIDC. Google Cloud also uses **Workforce Identity Federation** as a product name. Per [Google Cloud's documentation](https://docs.cloud.google.com/iam/docs/workforce-identity-federation), it lets users in an external IdP that supports OIDC or SAML 2.0, such as Entra ID or Okta, use SSO to access Google Cloud resources, and it is sync-less: user accounts are not copied into Google. Do not confuse it with [workload identity federation](https://startwithidentity.com/glossary/workload-identity-federation/), which gives software, not people, short-lived cloud credentials.

## What Is Zero Trust? Principles, ZTNA and Vendors
Source: https://startwithidentity.com/guides/fundamentals/what-is-zero-trust/
Last updated: 2026-11-05

Zero trust is a security model in which no user, device, or network location is trusted by default: every access request is verified explicitly on identity, device posture, and context, and granted with the least privilege needed for that one resource. It replaces the old perimeter model, where anything inside the corporate network was trusted. Identity is its foundation, because once the network stops being the boundary, the login is.

## Where the definition comes from

Three U.S. government documents shape how the term is used, and they are worth knowing because vendors quote them:

- **[NIST SP 800-207](https://csrc.nist.gov/pubs/sp/800/207/final)** (August 2020) defines zero trust architecture: protection moves from static network boundaries to users, assets and resources, with a policy decision point that evaluates each request.
- **[OMB M-22-09](https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf)** (26 January 2022) ordered U.S. federal agencies to meet zero trust goals by the end of fiscal year 2024. It organizes them using CISA's model of five pillars (Identity, Devices, Networks, Applications and Workloads, and Data) and states that "for agency staff, contractors, and partners, phishing-resistant MFA is required."
- **[NIST SP 1800-35](https://csrc.nist.gov/pubs/sp/1800/35/final)** (final June 2025) documents 19 example zero trust implementations that NIST's NCCoE built with 24 collaborators, which makes it the most practical of the three.

## The core principles

- **Verify explicitly:** authenticate and authorize every request on signals like identity, device health, location, and risk.
- **Least privilege:** grant the minimum access needed, ideally [just in time](https://startwithidentity.com/glossary/jit-access/) (see [what is PAM](https://startwithidentity.com/guides/fundamentals/what-is-pam/)).
- **Assume breach:** segment, monitor, and limit blast radius as if an attacker is already inside, using [microsegmentation](https://startwithidentity.com/glossary/microsegmentation/) where networks still matter.

## Why identity is the foundation

Once the network is no longer the perimeter, **identity becomes the perimeter**. That is why zero trust programs lean on strong [authentication](https://startwithidentity.com/guides/fundamentals/authentication-vs-authorization/), phishing-resistant [MFA](https://startwithidentity.com/guides/buyer-guides/how-to-choose-an-mfa-solution/), continuous [authorization](https://startwithidentity.com/guides/fundamentals/rbac-vs-abac-vs-rebac/), and [identity threat detection](https://startwithidentity.com/guides/fundamentals/what-is-itdr/).

The breach record shows why the authentication step alone is not enough. In SWI's [Identity Breach Report 2026](https://startwithidentity.com/reports/identity-breach-report-2026/), among the 41 breaches where the record states whether MFA protected the abused account, MFA was bypassed in 25 and absent in 16. Attackers who meet MFA mostly get around it, through relayed codes, approved pushes and stolen sessions, rather than stopping.

## Zero trust vs VPN

| Question | Traditional VPN | Zero trust access (ZTNA) |
|---|---|---|
| What the user reaches | A network segment | One application at a time |
| When trust is decided | At connection | On every request, with re-checks during the session |
| Device signal | Often none | Posture from MDM or EDR feeds the decision |
| Exposure to the internet | A listening gateway | Usually outbound-only connectors, no open inbound port |
| Lateral movement after compromise | Easy | Limited to what the user is entitled to |
| Typical failure | Legacy profiles, single-factor accounts, unpatched appliances | Policy exclusions, apps left on the old path |

## Zero trust network access and the 2026 vendor market

[ZTNA](https://startwithidentity.com/glossary/ztna/) is the access-layer implementation that replaces VPNs with identity-aware, per-application access. Vendors split into two architectures: cloud proxies that route traffic through their edge, and overlay or mesh networks that connect devices directly.

| Need | Zero trust vendors to shortlist | Ownership and pricing notes (checked November 2026) |
|---|---|---|
| Large global SSE consolidation | [Zscaler](https://startwithidentity.com/vendors/zero-trust/zscaler/), [Netskope](https://startwithidentity.com/vendors/zero-trust/netskope/), [Palo Alto Prisma Access](https://startwithidentity.com/vendors/zero-trust/palo-alto/) | All public companies; all quote-based by user and module |
| Value and developer-friendly SSE | [Cloudflare](https://startwithidentity.com/vendors/zero-trust/cloudflare/) | Public (NYSE: NET); free tier for small teams, per-user paid plans |
| SASE with SD-WAN | [Cato Networks](https://startwithidentity.com/vendors/zero-trust/cato-networks/) | Quote-based |
| Fast VPN replacement for a remote team | [Twingate](https://startwithidentity.com/vendors/zero-trust/twingate/), [Check Point SASE](https://startwithidentity.com/vendors/zero-trust/perimeter-81/) | Twingate free for 5 users, then $5 and $10 per user per month (read 2026-10-31); Check Point removed Perimeter 81's public prices |
| Developer and infrastructure mesh | [Tailscale](https://startwithidentity.com/vendors/zero-trust/tailscale/) | Published per-user tiers with a free option |
| Traffic must stay on your infrastructure | [Appgate](https://startwithidentity.com/vendors/zero-trust/appgate/) | Private since a 2024 recapitalization; quote-based |
| Posture-gated infrastructure access | [SonicWall Cloud Secure Edge](https://startwithidentity.com/vendors/zero-trust/banyan-security/) | Formerly Banyan Security, acquired by SonicWall in 2023 |

Consolidation is still running: on 12 October 2026 IonQ [announced an agreement to acquire Elisity](https://www.ionq.com/news/ionq-to-acquire-elisity-to-accelerate-zero-trust-for-the-quantum-era), a microsegmentation vendor, and the deal was pending at the time of writing (see [identity acquisitions](https://startwithidentity.com/acquisitions/)). Expect a quote: in SWI's [Identity Pricing Transparency Index 2026](https://startwithidentity.com/reports/identity-pricing-transparency-index-2026/), 76.9% of zero trust vendors are quote-only and the category scores 23 out of 100 for price transparency.

For scored comparisons see the [best zero trust tools](https://startwithidentity.com/rankings/best-zero-trust-tools/) ranking, the [top zero trust network access tools](https://startwithidentity.com/articles/top-8-zero-trust-network-access-tools/), [Cloudflare vs Zscaler](https://startwithidentity.com/compare/cloudflare-vs-zscaler/), [Zscaler vs Netskope](https://startwithidentity.com/compare/zscaler-vs-netskope/) and [Tailscale vs Cloudflare](https://startwithidentity.com/compare/tailscale-vs-cloudflare/). Teams that want to self-host can start from the [open-source zero trust tools](https://startwithidentity.com/articles/top-7-open-source-zero-trust-tools/) list.

## What "implementing zero trust" actually means

In practice a zero trust program is four workstreams:

1. **Strong authentication everywhere.** [Phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/) with a short exemption list that is reviewed, not inherited. Policies that require "MFA" generically are satisfied by methods that relay kits defeat daily. Passkeys rest on [WebAuthn](https://startwithidentity.com/standards/webauthn-fido2/), which became a Level 3 W3C Recommendation on 25 August 2026.
2. **Device signal in the access decision.** [Device posture](https://startwithidentity.com/glossary/device-posture/) from MDM or EDR, feeding [conditional access](https://startwithidentity.com/glossary/conditional-access/). This is the workstream most often skipped because it requires enrolment on every endpoint.
3. **Per-application authorization.** ZTNA replacing flat network access, so a compromised endpoint reaches only what its user is entitled to.
4. **Continuous evaluation.** Re-checking during a session rather than only at the gate, because a session stolen after login satisfied every policy at issuance. The [Shared Signals Framework](https://startwithidentity.com/standards/shared-signals-framework/), including [CAEP](https://startwithidentity.com/glossary/caep/), became Final OpenID specifications on 29 August 2025, so identity providers and access tools can now tell each other to revoke a session in a standard format.

## Where zero trust fails in practice

- **The forgotten remote access path.** Colonial Pipeline was entered through a [legacy VPN profile](https://startwithidentity.com/breaches/incidents/2021-colonial-pipeline-legacy-vpn/) with single-factor authentication, Medibank through a [contractor's saved credentials on a VPN without MFA](https://startwithidentity.com/breaches/incidents/2022-medibank-contractor-credentials-vpn/), and Change Healthcare through a [Citrix portal without MFA](https://startwithidentity.com/breaches/incidents/2024-change-healthcare-citrix-no-mfa/). A zero trust program that covers the new path but leaves the old one open has not changed the risk.
- **The gateway itself.** Remote access appliances are identity infrastructure. In 2026 a [PAN-OS GlobalProtect authentication bypass](https://startwithidentity.com/breaches/incidents/2026-pan-os-globalprotect-auth-bypass-ransomware/) ([CVE-2026-0257](https://startwithidentity.com/cves/cve-2026-0257/)) gave ransomware operators VPN sessions without valid credentials.
- **Stolen sessions.** Between July and September 2026 one actor [replayed stolen Microsoft 365 tokens into 79 organizations](https://startwithidentity.com/breaches/incidents/2026-microsoft-365-token-replay-79-orgs/), using [adversary-in-the-middle phishing](https://startwithidentity.com/techniques/aitm-phishing-proxy/) and [token replay](https://startwithidentity.com/techniques/token-replay-unbound-endpoint/). Only continuous evaluation and device-bound sessions catch this.
- **Exclusions.** Every deployment accumulates exemptions for a migration, a vendor, or a legacy app. Midnight Blizzard [password-sprayed a legacy test tenant account with no MFA](https://startwithidentity.com/breaches/incidents/2024-microsoft-midnight-blizzard-password-spray/) and reached Microsoft's corporate mail ([password spraying](https://startwithidentity.com/techniques/password-spraying/)). Audit the exclusion list more often than the policy list.

## The honest limits

Device posture is self-reported by software on a machine an attacker may already control, so it is strong against commodity attacks and weak against a determined intruder holding the device. And the hardest part of most ZTNA migrations is not technology: it is producing an inventory of every internal application, who should reach it, and which ones depend on flat network access today.

## Where to start

1. Enforce phishing-resistant MFA for administrators and remote access first, and shrink the exemption list.
2. Inventory every remote access path, including legacy VPN profiles and vendor support logins.
3. Move the highest-risk internal applications behind ZTNA, then retire the VPN route to them.
4. Add device posture and session revocation once the first apps are stable.

As a practitioner estimate, not a measured figure, steps 1 and 2 take a mid-sized organization weeks, while full VPN retirement takes quarters. Read the [zero trust architecture guide](https://startwithidentity.com/guides/architecture/zero-trust-architecture-implementation-guide/) and the [zero trust rollout guide](https://startwithidentity.com/guides/implementation/zero-trust-rollout/), and map your identity stack with [what is IAM](https://startwithidentity.com/guides/fundamentals/what-is-iam/).

## Workload identity 101: replacing long-lived secrets
Source: https://startwithidentity.com/guides/machine-identity/workload-identity-101/
Last updated: 2026-11-05

Workload identity replaces long-lived secrets (API keys, client secrets, service account passwords) with short-lived credentials that the platform issues to a workload after verifying what it is. Instead of "here is my API key," the workload presents "here is a credential, valid for minutes, proving I am the payments service in the production cluster." Nothing long-lived is stored, so there is nothing to commit to git, paste into a CI variable, or forget to rotate. Use [SPIFFE/SPIRE](https://startwithidentity.com/vendors/machine-identity/spiffe-spire/) when you need one identity across platforms, and your cloud's native mechanism when the workload only talks to that cloud.

This guide is for platform and security engineers retiring static secrets. For the wider context, see [what is machine identity](https://startwithidentity.com/guides/fundamentals/what-is-machine-identity/) and [non-human identity security](https://startwithidentity.com/guides/machine-identity/non-human-identity-security/).

## Why static secrets keep failing

A static secret authenticates whoever holds it, from anywhere, until someone rotates it. The breach record is consistent about what follows:

- A credential extracted from a Docker image let attackers modify Codecov's Bash Uploader and collect CI secrets from customer pipelines ([Codecov, 2021](https://startwithidentity.com/breaches/incidents/2021-codecov-bash-uploader/)).
- A compromised GitHub Action printed runner secrets into workflow logs ([tj-actions/changed-files, 2025](https://startwithidentity.com/breaches/incidents/2025-tj-actions-changed-files-ci-secrets/)).
- An admin token created with no expiry and stored in plaintext in a config repository opened a shared cluster ([Zeabur, 2026](https://startwithidentity.com/breaches/incidents/2026-zeabur-plaintext-admin-token/)).
- An operator signed in to Microsoft Entra ID as applications using stolen client secrets across dozens of organizations ([Entra app secrets, 2026](https://startwithidentity.com/breaches/incidents/2026-entra-id-stolen-app-secrets-27-orgs/)).

The techniques behind these are documented in [static API key abuse](https://startwithidentity.com/techniques/static-api-key-abuse/) and [secrets in repositories and CI](https://startwithidentity.com/techniques/secrets-in-repositories-and-ci/).

## How workload identity works

1. **Attest.** The platform proves what the workload is. In [SPIRE](https://spiffe.io/docs/latest/spire-about/spire-concepts/), an agent on each node first proves the node's identity to the server (for example with an AWS EC2 instance identity document or a Kubernetes service account token), then attests each local process using selectors such as Kubernetes namespace and service account, or Unix uid, gid and path.
2. **Issue.** The identity authority issues a short-lived credential bound to that identity.
3. **Present.** The workload uses it to call another service or exchanges it for a cloud access token.
4. **Verify.** The receiver validates it against a trust bundle or the issuer's published signing keys.
5. **Renew.** The credential expires and the workload gets a fresh one without human involvement.

## The building blocks

**SPIFFE.** The [SPIFFE concepts](https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/) define a [SPIFFE ID](https://startwithidentity.com/glossary/spiffe/) as a `spiffe://` URI made of a trust domain and a workload path, for example `spiffe://prod.example.com/ns/payments/sa/api`. The credential is an SVID in one of two formats, an X.509 certificate or a JWT. The Workload API delivers SVIDs to the workload, and it "does not require that a calling workload have any knowledge of its own identity." A trust bundle is the set of CA root certificates used to verify other workloads' SVIDs. The project's guidance is to "use X.509-SVIDs whenever possible," since JWTs are replayable if intercepted; JWT-SVIDs fit when an L7 proxy sits between workloads.

**Kubernetes projected service account tokens.** Legacy auto-mounted service account tokens did not expire. Per [AWS's IRSA documentation](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html), Kubernetes 1.12 added projected service account tokens: OIDC JWTs with the service account identity and a configurable audience, which external systems can validate through the cluster's OIDC discovery endpoint.

**Cloud [workload identity federation](https://startwithidentity.com/glossary/workload-identity-federation/).** Each major cloud accepts external tokens and returns short-lived cloud credentials.

## Cloud-native options compared

| Mechanism | How trust is set up | What the workload gets | Watch for |
|---|---|---|---|
| AWS IRSA | IAM OIDC provider per cluster; role trust policy on the token | Temporary credentials via STS `AssumeRoleWithWebIdentity` | EKS rotates the OIDC signing key every 7 days; external validators must refresh keys |
| AWS EKS Pod Identity | Association of role to service account in EKS; trust principal `pods.eks.amazonaws.com` | Credentials from the node's Pod Identity Agent | Up to 5,000 associations per cluster; Linux EC2 nodes only, not Fargate; associations are eventually consistent |
| Google Cloud WIF | Workload identity pool and provider; attribute mapping and conditions in CEL | Federated token from STS (RFC 8693), then a short-lived access token | Granting a whole pool "can incur risk"; restrict with attribute conditions |
| Microsoft Entra WIF | Federated identity credential on an app or user-assigned managed identity | Access token via client credentials with the external JWT | `issuer`, `subject` and `audience` must match case-sensitively; only the first 100 IdP signing keys are stored |
| SPIFFE/SPIRE | SPIRE server per trust domain; federation between domains | X.509-SVID or JWT-SVID | You operate the server, its datastore and signing keys |

Sources: [EKS Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html), [Google Cloud Workload Identity Federation](https://docs.cloud.google.com/iam/docs/workload-identity-federation), [Microsoft Entra workload identity federation](https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation).

The options compose. Entra accepts SPIFFE IDs as federated credentials, and Google Cloud lists AWS, Entra ID, GitHub, GitLab, Kubernetes and any OIDC or SAML 2.0 provider as pool providers. A common pattern is SPIFFE inside the mesh and federation at the cloud edge, so a workload holds one identity and exchanges it where needed.

## Choosing a starting point

| Your situation | Start with |
|---|---|
| Kubernetes on EKS calling AWS only | EKS Pod Identity (IRSA where Pod Identity is not supported) |
| CI pipelines deploying to cloud | The CI platform's OIDC token plus cloud federation; delete stored cloud keys |
| Service-to-service across clusters or clouds | SPIFFE/SPIRE with mutual TLS |
| Workloads outside any cloud calling Azure or Google | Federation from your own OIDC issuer or SPIRE |
| Legacy app that only accepts a password | Keep it in a [secrets manager](https://startwithidentity.com/guides/fundamentals/what-is-secrets-management/) with automated [rotation](https://startwithidentity.com/glossary/secrets-rotation/) until it can be replaced |

## Rollout checklist

1. **Inventory static credentials** by owner, scope, age and where they are stored. Scanners in the [secrets](https://startwithidentity.com/vendors/secrets/) category help.
2. **Pick the first target**: CI-to-cloud deploy keys are usually the highest-risk, lowest-effort win.
3. **Scope the new identity tightly.** Write the trust condition on the exact repository, branch, namespace or service account, never the whole issuer or pool.
4. **Right-size permissions** instead of copying the old key's grants.
5. **Run both in parallel**, confirm the workload uses the new credential (cloud audit logs show the federated principal), then revoke the static secret.
6. **Monitor** for any use of revoked keys and for new static keys being created.
7. **Repeat** per workload class.

## What it does not replace

- **Authorization.** Workload identity says which service is calling, not whether the call is allowed. Pair it with policy; see [RBAC to ReBAC](https://startwithidentity.com/guides/authorization/rbac-to-rebac/).
- **End-user identity.** Requests that originate from a person still need delegated user context, for example through [token exchange](https://startwithidentity.com/glossary/token-exchange/).
- **Isolation.** AWS states plainly that "containers are not a security boundary." If the node's [instance metadata service](https://startwithidentity.com/glossary/instance-metadata-service/) is not restricted, pods may reach the node role's credentials.

## Standards to watch: WIMSE

The IETF [WIMSE](https://startwithidentity.com/glossary/wimse/) working group is standardizing how workload identity travels across multi-system call chains, building on SPIFFE concepts. Per the [WIMSE document list](https://datatracker.ietf.org/wg/wimse/documents/), as of November 2026 the HTTP signatures document has been submitted to the IESG as a Proposed Standard, the workload identity practices document is in IETF Last Call, and the architecture, workload identifier, mutual TLS, workload credentials and workload proof token documents are working-group drafts. None is an RFC yet.

## Common failure modes

| Failure | Consequence | Fix |
|---|---|---|
| Trust condition on the whole issuer | Any repo or tenant on a shared issuer can assume the role | Condition on subject and audience; use attribute conditions |
| Skipping attestation | The workload's self-claim becomes its identity | Use node and workload attestors, rather than trusting what the workload says about itself |
| Over-privileged federated role | Same blast radius as the old key, as in the [JadePuffer service principal attacks](https://startwithidentity.com/breaches/incidents/2026-jadepuffer-azure-service-principals/) | Least privilege per workload |
| Static key left in place after migration | Attackers use the old path | Revoke and alert on use |
| Unrestricted IMDS on nodes | Pods borrow the node role | Block pod access to the node IMDS |

## Related

Guides: [Kubernetes identity security](https://startwithidentity.com/guides/machine-identity/kubernetes-identity-security-guide/), [API key rotation automation](https://startwithidentity.com/guides/machine-identity/api-key-rotation-automation-guide/), [certificate lifecycle management](https://startwithidentity.com/guides/machine-identity/certificate-lifecycle-management-guide/). Glossary: [workload identity](https://startwithidentity.com/glossary/workload-identity/), [mTLS](https://startwithidentity.com/glossary/mtls/), [service account](https://startwithidentity.com/glossary/service-account/), [NHI](https://startwithidentity.com/glossary/nhi/). Vendors: [machine identity](https://startwithidentity.com/vendors/machine-identity/), [HashiCorp Vault](https://startwithidentity.com/vendors/machine-identity/hashicorp-vault/).

## Zero Trust Architecture Implementation Guide
Source: https://startwithidentity.com/guides/architecture/zero-trust-architecture-implementation-guide/
Last updated: 2026-11-05

The traditional perimeter-based security model assumed that everything inside the corporate network was trustworthy. That assumption has been thoroughly dismantled by cloud migration, remote work, supply chain attacks, and lateral movement techniques that let adversaries roam freely once they breach the perimeter. Zero trust architecture (ZTA) replaces implicit trust with continuous verification: never trust, always verify.

This guide provides a practical implementation roadmap for zero trust, with identity as the cornerstone. You will learn how to design, deploy, and operate a zero trust environment that protects your organization regardless of where users, devices, and workloads reside.

## What You Will Learn

- Core zero trust principles and how they translate into technical controls
- How to design identity-centric access policies
- Network segmentation and microsegmentation strategies
- Implementing least privilege across users, devices, and workloads
- Continuous monitoring and adaptive access decisions

## Prerequisites

1. **Mature identity foundation**, A centralized Identity Provider (IdP) with MFA enforcement and SSO. Zero trust cannot work without strong identity.
2. **Device inventory**, An MDM or endpoint management solution that can attest device health (OS patch level, encryption status, EDR presence).
3. **Application catalog**, A complete list of applications, their network dependencies, and the user groups that need access.
4. **Network visibility**, Firewall logs, DNS logs, and flow data so you can understand current traffic patterns before segmenting.
5. **Executive buy-in**, Zero trust is a multi-year program that touches networking, security, identity, and application teams. Executive sponsorship is essential.

## Architecture Overview

Zero trust architecture is not a single product. It is a design philosophy implemented through the coordinated deployment of several components:

- **Policy Decision Point (PDP):** The brain of zero trust. It evaluates every access request against policy (user identity, device health, resource sensitivity, behavior risk) and returns allow or deny.
- **Policy Enforcement Point (PEP):** The gateway that enforces PDP decisions. This can be a reverse proxy, a ZTNA connector, a service mesh sidecar, or a cloud-native firewall.
- **Identity Provider:** Authenticates users and devices. Provides the identity context (user, groups, roles) that policies evaluate.
- **Device Trust Engine:** Evaluates device posture, is the OS patched, is disk encryption enabled, is the EDR agent running?
- **Continuous Monitoring:** SIEM, UEBA, and ITDR systems that detect anomalies and feed risk signals back into the PDP for adaptive access.
- **Data Classification:** Tags resources by sensitivity so policies can enforce tighter controls on high-value assets.

The access flow works as follows: a user on a device requests access to a resource. The PEP intercepts the request and queries the PDP. The PDP evaluates the user's identity (from the IdP), the device's posture (from the trust engine), the resource's sensitivity (from classification), and any real-time risk signals (from monitoring). If all checks pass, the PDP issues a time-limited, scope-limited authorization. The PEP grants access. Every subsequent request is re-evaluated.

## Step-by-Step Implementation

### Step 1: Define Your Protect Surfaces

Rather than trying to secure everything at once, identify your most critical assets, the "protect surfaces." These are the data, applications, assets, and services (DAAS) that your business cannot afford to lose.

Examples:
- Customer PII database
- Financial reporting application
- Source code repositories
- CI/CD pipelines
- Executive email

For each protect surface, document:
- What it is and where it lives (cloud, on-prem, SaaS)
- Who needs access (user groups, service accounts)
- How they access it (protocols, ports, APIs)
- When they access it (business hours, 24/7)

### Step 2: Map Transaction Flows

Before you can enforce policy, you need to understand how traffic flows. For each protect surface, map every legitimate transaction:

```
User (Sales team) -> HTTPS -> CRM Application -> TCP 5432 -> Customer Database
Service (ETL pipeline) -> HTTPS -> Data Warehouse API -> TCP 443 -> S3 Bucket
```

Use network flow logs, application dependency mapping tools, and interviews with application owners to build these maps. This step is tedious but essential, you cannot write good policies without understanding normal behavior.

### Step 3: Build Identity-Centric Policies

Zero trust policies are written in terms of identity, not IP address. Replace firewall rules like "allow 10.0.1.0/24 to 10.0.2.5:443" with policies like "allow members of the Sales group on compliant devices to access the CRM application during business hours."

Policy structure:

```yaml
policy:
  name: "CRM Access - Sales Team"
  subjects:
    - group: "Sales"
    - group: "Sales-Managers"
  resource: "crm.internal.example.com"
  conditions:
    device_compliance: required
    mfa_completed: true
    risk_score: low | medium
    time_window: "Mon-Fri 06:00-22:00 UTC"
  actions:
    allow:
      - "HTTPS"
    deny:
      - "SSH"
      - "RDP"
  session:
    max_duration: "4h"
    reauthentication_interval: "1h"
```

Write policies for every protect surface. Start permissive (log-only mode) and tighten over time as you validate that legitimate access is not blocked.

### Step 4: Implement Network Segmentation

Segment your network so that compromising one zone does not grant access to others. At a minimum, create separate segments for:

- User endpoints
- Production servers
- Development/staging environments
- Management plane (domain controllers, jump hosts)
- IoT and OT devices

Use VLANs, cloud VPCs, or software-defined networking to enforce segmentation. Default-deny all inter-segment traffic, then allow only the specific flows identified in Step 2.

### Step 5: Deploy Microsegmentation

Network segmentation operates at the zone level. Microsegmentation goes further, controlling traffic between individual workloads within the same zone.

Options for microsegmentation:

- **Host-based firewalls:** Configure iptables or Windows Firewall rules on every server. This is simple but hard to manage at scale.
- **Service mesh:** For containerized workloads, deploy a service mesh (Istio, Linkerd) that enforces mTLS and authorization policies between services.
- **Agent-based microsegmentation:** Products like Illumio, Guardicore (now Akamai), or Zscaler Workload Segmentation deploy agents on each workload and enforce policies centrally.

```yaml
# Istio AuthorizationPolicy example
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: payment-service-policy
  namespace: production
spec:
  selector:
    matchLabels:
      app: payment-service
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/production/sa/order-service"]
      to:
        - operation:
            methods: ["POST"]
            paths: ["/api/v1/payments"]
```

### Step 6: Implement Device Trust

Users are only half the equation. The device they use is equally important. A legitimate user on a compromised device is still a threat.

Deploy a device trust solution that evaluates:

- OS version and patch level
- Disk encryption status (FileVault, BitLocker)
- EDR agent presence and health
- Screen lock configuration
- Jailbreak/root detection (mobile)

Integrate device posture into your PDP so that access decisions consider both identity and device health. A user on a non-compliant device should be blocked or redirected to a remediation page.

### Step 7: Enable Continuous Verification

Traditional access control is a gate: once you pass, you are in. Zero trust is a continuous checkpoint. Implement:

- **Session re-evaluation:** Periodically re-check device posture and risk signals during an active session. If the device becomes non-compliant (e.g., EDR agent stops), revoke the session.
- **Step-up authentication:** For sensitive operations (accessing PII, modifying financial records), require additional authentication even within an active session.
- **Behavioral analytics:** Use UEBA to detect anomalies such as impossible travel, unusual data access volumes, or access at unusual times. Feed these risk signals into the PDP.

### Step 8: Extend to Workload Identity

Zero trust is not limited to human users. Machine-to-machine communication must also be authenticated and authorized.

- Use mTLS with short-lived certificates (SPIFFE/SPIRE) for service-to-service authentication.
- Replace long-lived API keys with OAuth 2.0 client credentials grants and short-lived tokens.
- Apply the same least-privilege policies to service accounts that you apply to human users.

## Configuration Best Practices

- **Start with visibility, then enforcement.** Deploy policies in log-only mode for 2-4 weeks before switching to enforcement. This lets you catch legitimate traffic that would be blocked.
- **Use deny-by-default.** Every policy framework should default to deny. Explicitly allow only the access that is needed.
- **Automate policy deployment.** Store policies as code in a Git repository. Use CI/CD pipelines to deploy policy changes after peer review.
- **Keep sessions short.** Access tokens and session cookies should expire frequently (15-60 minutes). Re-authentication should be smooth when the IdP session is still active. Where apps support it, subscribe to CAEP session-revoked events, delivered as [Security Event Tokens](https://startwithidentity.com/glossary/security-event-token/), so a revocation takes effect before the token expires.
- **Tag everything.** Label users, devices, applications, and data with metadata (sensitivity, environment, business unit). Policies written against tags are far more maintainable than policies written against specific identifiers.

## Testing and Validation

1. **Policy simulation:** Most zero trust platforms offer a simulation mode. Run your policies against recorded traffic to predict what would be allowed and denied.
2. **Red team exercises:** Engage a red team to test lateral movement. Can they move from a compromised endpoint to a protect surface? If yes, your segmentation or policies have gaps.
3. **Break-glass testing:** Verify that emergency access procedures work. Can the on-call engineer reach critical systems when the PDP is unavailable?
4. **User acceptance testing:** Have a pilot group use the new access model for 2 weeks. Collect feedback on any legitimate access that is blocked or workflows that are disrupted.
5. **Failover testing:** Simulate PDP outage. Verify that the PEP fails closed (blocks access) rather than fails open (allows everything).

## Common Pitfalls and Troubleshooting

| Pitfall | Impact | Mitigation |
|---------|--------|------------|
| Boiling the ocean | Project stalls, no progress | Start with 3-5 protect surfaces, not the entire organization |
| Ignoring legacy applications | Legacy apps cannot participate in zero trust | Use a reverse proxy or ZTNA connector to front legacy apps |
| Treating zero trust as a product purchase | Vendor solution does not cover all use cases | Zero trust is an architecture; you will need multiple tools |
| Overlooking service accounts | Machine identities bypass policies | Inventory all service accounts and apply policies to them |
| Failing to communicate with users | Users perceive zero trust as an obstacle | Explain the "why," provide self-service remediation, and keep help-desk staffed during rollout |
| No break-glass procedure | Outage during PDP failure locks everyone out | Define and test emergency access before enforcement begins |

## Security Considerations

1. **The PDP is a high-value target.** If an attacker compromises the PDP, they can authorize themselves to access anything. Harden the PDP infrastructure with the same rigor you apply to domain controllers.
2. **Encrypted traffic inspection creates risk.** If you inspect TLS traffic for policy enforcement, you are introducing a man-in-the-middle. Ensure the inspection infrastructure is hardened and the decrypted traffic is never logged or stored.
3. **Insider threats remain.** Zero trust significantly reduces the blast radius of compromised credentials, but a legitimate user with legitimate access can still exfiltrate data. Pair zero trust with DLP and behavioral analytics.
4. **Supply chain risk.** Your [zero trust vendors](https://startwithidentity.com/rankings/best-zero-trust-tools/) become part of your trust chain. Evaluate their security posture rigorously.
5. **Over-permissive policies negate zero trust.** If you allow "all users" to access "all resources" with "any device," you have rebuilt the flat network. Audit policies quarterly and remove unused access.

## Conclusion

Zero trust is a journey, not a destination. No organization achieves perfect zero trust overnight, and the definition of "done" evolves as new threats emerge and the business changes. The key is to start with your most critical assets, build identity-centric policies, segment aggressively, and invest in continuous monitoring.

By following the step-by-step approach outlined here, starting with protect surfaces, mapping flows, writing policies, segmenting, and then enforcing, you can deliver incremental security improvements at each phase rather than waiting years for a big-bang deployment. Each protect surface you secure is a measurable reduction in risk.

## Zero Trust rollout: from VPN replacement to mature program
Source: https://startwithidentity.com/guides/implementation/zero-trust-rollout/
Last updated: 2026-11-05

A Zero Trust rollout is a 12 to 24 month program (a practitioner estimate) that moves access decisions from network location to verified identity, device, and context: modernize identity first, pilot [ZTNA](https://startwithidentity.com/glossary/ztna/) on one application, expand and switch off the VPN, then add [microsegmentation](https://startwithidentity.com/glossary/microsegmentation/) and SaaS data controls. This guide is for IAM, network, and security architects who need a sequence that survives contact with a real estate, not a product brochure.

## What Zero Trust actually is

[NIST SP 800-207](https://csrc.nist.gov/pubs/sp/800/207/final) (August 2020) defines Zero Trust as granting no implicit trust to assets or user accounts based solely on their physical or network location, and protecting resources rather than network segments. The product category that delivers most of it is Zero Trust Network Access, which brokers access to individual applications instead of dropping a connected user onto a flat internal network. For the concept in plain terms, see [what is Zero Trust](https://startwithidentity.com/guides/fundamentals/what-is-zero-trust/).

Two newer public references are worth using as scaffolding:

- **[CISA Zero Trust Maturity Model 2.0](https://learn.microsoft.com/en-us/security/zero-trust/cisa-zero-trust-maturity-model-intro)** (April 2023) scores five pillars (Identity, Devices, Networks, Applications and Workloads, Data) across four stages: Traditional, Initial, Advanced, Optimal. Three cross-cutting capabilities sit across every pillar: visibility and analytics, automation and orchestration, and governance.
- **[NIST SP 1800-35](https://csrc.nist.gov/pubs/sp/1800/35/final)** (final June 2025), "Implementing a Zero Trust Architecture," documents 19 example implementations built with 24 collaborators from commercially available products. It is the closest thing to a public reference build.

## Why the order matters: what skipped steps cost

The recurring entry point in identity breaches is remote access that trusted a password or an appliance instead of a verified identity:

- **No MFA on a forgotten VPN profile.** [Colonial Pipeline](https://startwithidentity.com/breaches/incidents/2021-colonial-pipeline-legacy-vpn/) was entered through a legacy VPN profile the company believed was unused, protected by a single password.
- **No MFA on a remote access portal.** [Change Healthcare](https://startwithidentity.com/breaches/incidents/2024-change-healthcare-citrix-no-mfa/) attackers logged into a Citrix portal without MFA using compromised credentials, then moved laterally and deployed ransomware.
- **The VPN appliance itself.** [MITRE's NERVE network](https://startwithidentity.com/breaches/incidents/2024-mitre-nerve-ivanti-session-hijack/) was breached through two Ivanti Connect Secure zero-days ([CVE-2023-46805](https://startwithidentity.com/cves/cve-2023-46805/)) and hijacked VPN sessions that got past MFA. In 2026 the pattern continued: a [GlobalProtect authentication bypass](https://startwithidentity.com/breaches/incidents/2026-pan-os-globalprotect-auth-bypass-ransomware/) ([CVE-2026-0257](https://startwithidentity.com/cves/cve-2026-0257/)) served as a ransomware front door, an [Ivanti header-spoofing bypass](https://startwithidentity.com/breaches/incidents/2026-ivanti-connect-secure-uta0576/) ([CVE-2026-104935](https://startwithidentity.com/cves/cve-2026-104935/)) was used to harvest Active Directory credentials, and the [k0t access broker](https://startwithidentity.com/breaches/incidents/2026-k0t-edge-device-access-broker/) sold access gained through edge devices.

Identity hygiene closes the first two. Retiring the internet-facing VPN closes the third. That is why identity comes first and the VPN sunset is not optional.

## The honest sequence

**Quarter 1: Foundation.** Modernize identity first. Single sign-on covering the large majority of applications. MFA enforced for all users, [phishing-resistant](https://startwithidentity.com/glossary/phishing-resistant-mfa/) for admins, because [AiTM phishing proxies](https://startwithidentity.com/techniques/aitm-phishing-proxy/) and [MFA fatigue](https://startwithidentity.com/techniques/mfa-fatigue-push-bombing/) defeat push and OTP. [Conditional access](https://startwithidentity.com/guides/implementation/conditional-access-policies-guide/) policies written and tested in report-only mode before enforcement. Find and disable every legacy VPN profile and local account. This quarter determines whether everything after it works.

**Quarter 2: ZTNA pilot.** Pick one critical internal application. Replace VPN access to it with a ZTNA gateway. Verify the user experience end to end, confirm audit visibility, and prove that access now depends on identity and [device posture](https://startwithidentity.com/glossary/device-posture/) rather than network position.

**Quarters 3-4: ZTNA expansion.** Onboard the next tranche of applications, roughly twenty at a time (an estimate; size batches to your support capacity). Sunset the corresponding VPN tunnels as each application moves, because the security benefit comes from retiring the old path, not from adding a new one beside it. Make device posture a required input to access decisions.

**Year 2: Microsegmentation and continuous monitoring.** Add east-west controls so a foothold in one segment does not become free [lateral movement](https://startwithidentity.com/glossary/lateral-movement/) across the estate. Feed identity telemetry to the SOC and adopt the [Shared Signals Framework](https://startwithidentity.com/standards/shared-signals-framework/) (CAEP and RISC, Final since August 2025) where your IdP and SaaS apps support it, so a revoked session or risky user propagates without waiting for token expiry. Defend against [session cookie theft](https://startwithidentity.com/techniques/session-cookie-theft/) and [token replay](https://startwithidentity.com/techniques/token-replay-unbound-endpoint/), which bypass login-time checks entirely.

**Year 2 ongoing: SaaS data controls.** Extend policy to SaaS traffic with a secure service edge or cloud access broker, inline data loss prevention, and browser isolation for risky destinations. This closes the gap between "the network is controlled" and "the data is controlled."

## Phase exit checklist

| Phase | Do not start the next phase until | CISA ZTMM pillar |
| --- | --- | --- |
| Foundation | MFA on 100% of remote access paths; legacy VPN profiles disabled; admins on phishing-resistant MFA | Identity |
| ZTNA pilot | One critical app reachable only through ZTNA; posture check enforced; logs in the SIEM | Networks, Devices |
| Expansion | VPN tunnels retired at the same pace apps move; exception list with owners and end dates | Networks, Applications and Workloads |
| Microsegmentation | Posture and identity signals flowing; east-west policy in monitor mode first | Networks |
| SaaS and data | Inline DLP on sanctioned SaaS; session revocation tested end to end | Data |

## Metrics to track

- Percentage of applications behind SSO and behind ZTNA, trending up each quarter
- Percentage of VPN tunnels retired, which should track ZTNA expansion, not lag it
- MFA coverage and phishing-resistant coverage for privileged accounts
- Mean time to revoke access for a departed user or compromised device
- Access decisions denied on posture, a sign the posture signals are actually being used

## Vendor decisions

The ZTNA layer is the high-use decision. [Cloudflare](https://startwithidentity.com/vendors/zero-trust/cloudflare/), [Zscaler](https://startwithidentity.com/vendors/zero-trust/zscaler/), [Netskope](https://startwithidentity.com/vendors/zero-trust/netskope/), [Palo Alto Prisma Access](https://startwithidentity.com/vendors/zero-trust/palo-alto/), [Cisco Secure Access](https://startwithidentity.com/vendors/zero-trust/cisco-secure-access/), [Twingate](https://startwithidentity.com/vendors/zero-trust/twingate/), and [Tailscale](https://startwithidentity.com/vendors/zero-trust/tailscale/) represent different price-performance points; compare them in the [best Zero Trust tools](https://startwithidentity.com/rankings/best-zero-trust-tools/) ranking, the [top ZTNA tools](https://startwithidentity.com/articles/top-8-zero-trust-network-access-tools/) article, and [open source Zero Trust tools](https://startwithidentity.com/articles/top-7-open-source-zero-trust-tools/). Note the 2026 consolidation: Palo Alto Networks closed its acquisition of [Idira (formerly CyberArk)](https://startwithidentity.com/vendors/pam/cyberark/) on 2026-02-11, so one vendor now sells both ZTNA and PAM; evaluate the privileged access tier on its own merits rather than as a bundle add-on. Microsegmentation is a separate purchase ([Illumio](https://startwithidentity.com/vendors/zero-trust/illumio/), [Zero Networks](https://startwithidentity.com/vendors/zero-trust/zero-networks/), or native cloud controls). For the architectural underpinnings, see the [Zero Trust architecture implementation guide](https://startwithidentity.com/guides/architecture/zero-trust-architecture-implementation-guide/) and [identity-first architecture](https://startwithidentity.com/guides/architecture/identity-first-architecture/).

## Common pitfalls

- Buying ZTNA before identity hygiene is complete, which produces garbage-in, garbage-out access decisions
- Treating Zero Trust as a single project instead of a multi-year program with a roadmap and owners
- Skipping the VPN sunset, so both systems run indefinitely and the concentrator stays internet-facing
- Leaving service accounts and break-glass paths outside the model; pair the rollout with [zero standing privileges](https://startwithidentity.com/guides/implementation/zero-standing-privileges-rollout/)
- Underestimating change management for users moving from VPN to ZTNA, which drives support load and shadow workarounds
- Buying microsegmentation before basic posture signals are flowing, so the controls have no context to act on

Sequenced this way, Zero Trust stops being a slogan and becomes a measurable reduction in standing access and blast radius, one quarter at a time.

# Standards

## AuthZEN Authorization API
Source: https://startwithidentity.com/standards/authzen/
Last updated: 2026-11-05

## What it is

AuthZEN is the OpenID Foundation's standard for the conversation between the place where access is enforced and the place where it is decided. The [Authorization API 1.0](https://openid.net/specs/authorization-api-1_0.html) lets a **Policy Enforcement Point (PEP)**, such as an application, API gateway, service mesh sidecar or MCP server, ask a **Policy Decision Point (PDP)** a structured question and get a decision back, "without requiring knowledge of each other's inner workings", in the specification's words. The PEP and PDP terms come from XACML and [NIST SP 800-162](https://startwithidentity.com/glossary/abac/), and the problem is old: every authorization product has its own API, so moving from one policy engine to another means rewriting every integration.

AuthZEN fixes the wire format, not the policy model. Behind the API, the PDP can evaluate [RBAC](https://startwithidentity.com/glossary/rbac/), [ABAC](https://startwithidentity.com/glossary/abac/) or [ReBAC](https://startwithidentity.com/glossary/rebac/) policy in any language. The short definition is in the [AuthZEN glossary entry](https://startwithidentity.com/glossary/authzen/), and the broader category is [fine-grained authorization](https://startwithidentity.com/glossary/fga/).

## Status (November 2026)

The Authorization API 1.0 is an **OpenID Final Specification**, published 11 January 2026. The Foundation [announced approval](https://openid.net/authorization-api-1-0-final-specification-approved/) on 12 January 2026 (81 approve, 1 object, 25 abstain). A Final Specification is not revised further. The editors are Omri Gazitt ([Aserto](https://startwithidentity.com/vendors/authorization/aserto/)), David Brossard (Axiomatics) and [Atul Tulshibagwale](https://startwithidentity.com/experts/atul-tulshibagwale/) (then [SGNL](https://startwithidentity.com/vendors/authorization/sgnl/)).

Agent-focused work continues as **working-group drafts**, per the [AuthZEN specifications page](https://openid.net/wg/authzen/specifications/) read on 5 November 2026:

- **COAZ Framework 1.0** and the **[COAZ-MCP Binding](https://openid.github.io/authzen/authzen-coaz-mcp-binding-1_0.html)** (Draft 1, published 13 February 2026), which map arbitrary protocols, and MCP specifically, into AuthZEN requests.
- **[AuthZEN Access Request and Approval Profile](https://openid.github.io/authzen/authzen-access-request-approval-profile-1_0.html)** (Draft 1; the editor's copy is dated 5 November 2026), for what happens after a "requestable" denial: submit an access request, track it, and re-evaluate after approval.

The Foundation [announced both as working-group drafts](https://openid.net/openid-foundation-advances-authorization-for-the-agent-era-with-new-authzen-working-group-drafts/) on 15 June 2026. Neither is final.

## How it works

The information model has five entities: **Subject** (user or machine principal, with `type` and `id`), **Action** (with `name`), **Resource** (with `type` and `id`), **Context** (environment, time, risk) and **Decision**. Each can carry `properties`.

A concrete check, an MCP gateway asking whether an agent may refund an order for a user:

```http
POST /access/v1/evaluation HTTP/1.1
Host: pdp.example.com
Authorization: Bearer <PEP credential>
Content-Type: application/json
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716

{
  "subject":  { "type": "agent", "id": "support-agent-7",
                "properties": { "on_behalf_of": "ada@example.com" } },
  "action":   { "name": "refund.issue" },
  "resource": { "type": "order", "id": "A-1009",
                "properties": { "amount": 480 } },
  "context":  { "time": "2026-11-05T14:02:00Z" }
}
```

The PDP answers `{"decision": true}` or `{"decision": false, "context": {...}}`. The context can carry reasons for admins and users, or a hint such as a step-up requirement, and the PEP must deny when the decision is false.

Around that core:

- **Access Evaluations** sends many checks in one call (an `evaluations` array), with three semantics: execute all, deny on first denial, or permit on first permit. This is how a UI or agent planner checks twenty tools at once.
- **Search APIs** for subject, resource and action answer "which documents can this user read" or "what can this agent do on this record", with pagination.
- **Discovery** at `/.well-known/authzen-configuration` lists `access_evaluation_endpoint` and any optional endpoints, and the PDP's `policy_decision_point` identifier, which must match to prevent mix-up attacks.
- **Transport** is an HTTPS JSON binding. Authentication of the PEP to the PDP is out of scope, with OAuth 2.0 recommended.

## What it solves for AI agents and SaaS

For SaaS, AuthZEN separates authorization from application code. A product can ship one PEP integration and let enterprise customers bring their own PDP, or swap from a homegrown engine to a commercial one, without touching every endpoint.

For AI agents, the problem is granularity. OAuth scopes are coarse and fixed at consent time; an agent's risk is per call ("refund 480, not 48,000"). SWI's [Agent Identity Standards Map 2026](https://startwithidentity.com/reports/agent-identity-standards-map-2026/) lists AuthZEN 1.0 alongside [Rich Authorization Requests (RFC 9396)](https://startwithidentity.com/glossary/rich-authorization-requests/) as the published options for per-call authorization. The pattern: the MCP server or gateway authenticates the agent with [MCP authorization](https://startwithidentity.com/standards/mcp-authorization/), then asks a PDP about each tool call using subject, action, resource and the actual arguments. COAZ-MCP standardizes that mapping, and the access request profile adds the "ask a human" step for actions that need approval, a gap the standards map scores as only drafted.

## Adoption signals (verified)

- **Interop, May 2024.** The OpenID Foundation [reported](https://openid.net/authorization-interop-results/) that 3Edges, Aserto, Axiomatics, [Cerbos](https://startwithidentity.com/vendors/authorization/cerbos/), [Permit.io](https://startwithidentity.com/vendors/authorization/permit-io/), Rock Solid Knowledge, SGNL, Strata Identity and Thales achieved conformance with the AuthZEN request and response protocol. That was before 1.0 Final.
- **Authorship.** COAZ-MCP is written by Atul Tulshibagwale (CrowdStrike) and Alex Olivier (Cerbos), per the draft.
- **Certification.** The working group page says a conformance certification program for the Authorization API is in development. We did not find a published list of certified PDPs on 5 November 2026.

The standards map found no verified production agent deployment of AuthZEN as of 30 October 2026, and we found none since.

## How to implement or evaluate

1. **Find your PEPs.** API gateways, MCP servers and service middleware are the natural places. Put one AuthZEN client library in each.
2. **Model actions as verbs on resources** (`refund.issue` on `order`), not as API paths. That keeps policy readable and portable.
3. **Pass real arguments in `properties`** for agent tool calls, so policy can bound amounts, recipients and record counts.
4. **Use batch evaluation for planning** and single evaluation at execution time, so an agent's plan does not outlive the policy that approved it.
5. **Ask PDP vendors** which AuthZEN version they implement (pre-Final interop or 1.0 Final), whether they support the evaluations and search endpoints and the metadata document, and their p99 decision latency.
6. **Fail closed.** If the PDP is unreachable, deny. Cache only with short lifetimes.

## Pitfalls

- **Treating the API as the policy.** AuthZEN moves decisions out of code; you still need good policy, review and testing.
- **Trusting the subject the agent claims.** The PEP must fill `subject` from authenticated tokens, not from model output.
- **Latency per tool call.** Measure it. A slow PDP pushes teams to cache decisions for too long.

## Related

[MCP authorization](https://startwithidentity.com/standards/mcp-authorization/), [Shared Signals Framework](https://startwithidentity.com/standards/shared-signals-framework/), [ID-JAG and Cross App Access](https://startwithidentity.com/standards/id-jag-cross-app-access/), [RBAC vs ABAC vs ReBAC](https://startwithidentity.com/guides/fundamentals/rbac-vs-abac-vs-rebac/), the [authorization tools ranking](https://startwithidentity.com/rankings/best-authorization-tools/), [authorization vendors](https://startwithidentity.com/vendors/authorization/), and the [securing AI agent identities](https://startwithidentity.com/guides/machine-identity/securing-ai-agent-identities/) guide. Glossary: [least privilege](https://startwithidentity.com/glossary/least-privilege/), [scope](https://startwithidentity.com/glossary/scope/), [delegation chain](https://startwithidentity.com/glossary/delegation-chain/).

## Who wrote it

The Authorization API is edited by Omri Gazitt, David Brossard and [Atul Tulshibagwale](https://startwithidentity.com/experts/atul-tulshibagwale/). More in the [experts directory](https://startwithidentity.com/experts/).

## Decentralized Identifiers (DID)
Source: https://startwithidentity.com/standards/decentralized-identifiers-did/
Last updated: 2026-11-05

## What it is

A Decentralized Identifier (DID) is a globally unique identifier that its subject controls directly, without a central registration authority. It is the addressing layer of [decentralized identity](https://startwithidentity.com/guides/fundamentals/what-is-decentralized-identity/): where a URL points to a web page, a DID points to a [DID document](https://startwithidentity.com/glossary/did-document/) holding the public keys and service endpoints needed to interact with the subject, whether a person, an organization or a device.

A DID looks like `did:method:identifier`, for example `did:web:example.com` or `did:key:z6Mk...`. It is standardized by [W3C DID Core 1.0](https://www.w3.org/TR/did/). In practice, DIDs matter most as **issuer identifiers**: they let a verifier find the key that signed a [verifiable credential](https://startwithidentity.com/standards/verifiable-credentials/) without a central directory.

## Status (November 2026)

| Document | Status | Date |
|---|---|---|
| [DIDs v1.0](https://www.w3.org/TR/did-core/) | W3C Recommendation | 19 July 2022 |
| [DIDs v1.1](https://www.w3.org/TR/did-1.1/) | Candidate Recommendation Snapshot | 5 March 2026 |
| [DID Resolution v1](https://www.w3.org/TR/did-resolution/) | Candidate Recommendation Draft | 3 November 2026 |
| [Controlled Identifiers v1.0](https://www.w3.org/TR/cid-1.0/) | W3C Recommendation (DID 1.1 builds on it) | 15 May 2025 |
| [DID Extensions registry](https://w3c.github.io/did-extensions/) | Working Group registry, not a standard | Updated continuously |

The [DID Working Group](https://www.w3.org/groups/wg/did/) is chartered until 31 January 2027. DID 1.1 states it cannot exit Candidate Recommendation until DID Resolution meets its own exit criteria, so the two are coupled. Per its revision history, DID 1.1 refactors the spec onto Controlled Identifiers, moves resolution out, consolidates media types into `application/did`, and adds a v1.1 JSON-LD context. For implementers, 1.0 DID documents remain the baseline; 1.1 mainly changes how the spec is layered.

## How it works

A verifier receives a credential signed by `did:web:university.example`:

1. **Parse.** The method is `web`, so the identifier maps to `https://university.example/.well-known/did.json`.
2. **Resolve.** A resolver applies the method's rules and returns the DID document plus resolution metadata. DID Resolution standardizes that interface.
3. **Select a key.** The credential's proof names a verification method such as `did:web:university.example#key-1`. Fragment dereferencing finds it in the document.
4. **Check the relationship.** The key must be listed under the right verification relationship (for credentials, `assertionMethod`), not just present.
5. **Verify.** The verifier checks the signature, then decides whether it trusts that DID as an issuer, typically through a [trust registry](https://startwithidentity.com/glossary/trust-registry/) or allowlist.

Step 5 is the one teams skip. A valid signature from a DID only proves control of a key, not that the controller is a real university.

## DID methods

The method determines how a DID is created, updated and resolved. The [W3C DID Extensions registry](https://github.com/w3c/did-extensions) listed **275 methods** on 5 November 2026 (272 registered, 3 deprecated). New entries are a JSON file in a pull request that passes automated validation, an AI-based preliminary spec review, and at least two maintainer reviews. That is a listing process, not a security audit. Our [DID methods compared](https://startwithidentity.com/guides/decentralized-identity/did-methods-compared/) guide covers the trade-offs in depth.

| Method | Anchored in | Good for | Watch out for |
|---|---|---|---|
| `did:web` | A domain over HTTPS ([CCG spec](https://w3c-ccg.github.io/did-method-web/)) | Enterprise issuers and verifiers | DNS spoofing, hosting compromise, no history |
| `did:webvh` | Web plus a verifiable history log ([DIF spec](https://identity.foundation/didwebvh/)) | did:web with an audit trail | Newer, fewer resolvers |
| `did:key`, `did:jwk` | The key itself | Holder keys, tests, short-lived use | No rotation: new key, new DID |
| `did:peer` | Shared only between parties | Pairwise connections | Not publicly resolvable by design |
| `did:ion`, `did:ethr`, `did:indy`, `did:cheqd` | Bitcoin, Ethereum, Indy ledgers, cheqd network | Ecosystems already on that ledger | Ledger governance, fees, resolver dependency |

See also the [DID method](https://startwithidentity.com/glossary/did-method/) glossary entry.

## Who implements it

- **[Microsoft Entra Verified ID](https://startwithidentity.com/vendors/decentralized-identity/microsoft-entra-verified-id/):** its [standards page](https://learn.microsoft.com/en-us/entra/verified-id/verifiable-credentials-standards) lists `did:web` as the only entity identifier method, with DIF Well Known DID Configuration to tie a DID to a domain.
- **[Procivis](https://startwithidentity.com/vendors/decentralized-identity/procivis/):** [supports](https://docs.procivis.ch/standards) `did:key`, `did:web`, `did:jwk` and `did:webvh`.
- **[cheqd](https://startwithidentity.com/vendors/decentralized-identity/cheqd/):** `did:cheqd` is in the registry, pointing to [cheqd's method spec](https://docs.cheqd.io/identity/architecture/adr-list/adr-001-cheqd-did-method).
- **[Hyperledger Indy, Aries and AnonCreds](https://startwithidentity.com/vendors/decentralized-identity/hyperledger-indy-aries/):** `did:indy` is registered for "any Hyperledger Indy ledger".

Compare platforms in [best decentralized identity platforms](https://startwithidentity.com/rankings/best-decentralized-identity-platforms/).

## Security and privacy pitfalls

DID 1.1 and the did:web spec spell out the risks:

- **Key loss and compromise.** DID 1.1 says cryptography alone cannot show whether a key is compromised, so relying systems should periodically confirm the controller still has control. Plan rotation and recovery before launch, and never reuse recovery keys for other purposes.
- **did:web inherits the web's weaknesses.** Without DNSSEC or DNS over HTTPS, an attacker can serve a fake DID document. A compromised web server can rewrite `did.json`. There is no built-in history, so keep the document in version control.
- **Resolution leaks.** The DNS provider and web host can see who resolves a `did:web`, which tells them who is verifying whose credentials. Cache documents or use a trusted resolver.
- **Correlation.** A long-lived public DID for a person is a global tracking identifier. DID 1.1 warns against correlatable identifiers and data in DID documents. Use pairwise or ephemeral identifiers for holders.
- **Method sprawl.** Supporting many methods means trusting many resolvers. Pick two or three.
- **Mistaking identifiers for trust.** A DID is not an identity claim. Trust still comes from the credentials issued and the [trust registries](https://startwithidentity.com/glossary/trust-registry/) that vouch for issuers.

## How it fits with the other standards

[VC Data Model 2.0](https://startwithidentity.com/standards/verifiable-credentials/) credentials commonly name a DID as `issuer`, and Data Integrity proofs reference DID verification methods. [OpenID4VP](https://startwithidentity.com/standards/openid4vc/) defines a `decentralized_identifier` client identifier prefix and OpenID4VCI's proofs can bind a credential to a holder key. The two largest government deployments use certificates instead: [mDL](https://startwithidentity.com/standards/iso-18013-5-mdl/) chains to IACA roots, and [HAIP and the EUDI Wallet](https://startwithidentity.com/standards/eidas-2-eudi-wallet/) use X.509 chains and trusted lists. If you need EU interoperability, plan for X.509 alongside DIDs.

## Related

Guides: [what is decentralized identity](https://startwithidentity.com/guides/fundamentals/what-is-decentralized-identity/), [what is self-sovereign identity](https://startwithidentity.com/guides/fundamentals/what-is-self-sovereign-identity/), [DID methods compared](https://startwithidentity.com/guides/decentralized-identity/did-methods-compared/), [decentralized identity vs federated identity](https://startwithidentity.com/guides/decentralized-identity/decentralized-identity-vs-federated-identity/). Standards: [Verifiable Credentials](https://startwithidentity.com/standards/verifiable-credentials/), [OpenID4VC](https://startwithidentity.com/standards/openid4vc/), [eIDAS 2 / EUDI Wallet](https://startwithidentity.com/standards/eidas-2-eudi-wallet/), [mDL](https://startwithidentity.com/standards/iso-18013-5-mdl/). Glossary: [DID](https://startwithidentity.com/glossary/decentralized-identifier/), [DID document](https://startwithidentity.com/glossary/did-document/), [DID method](https://startwithidentity.com/glossary/did-method/), [self-sovereign identity](https://startwithidentity.com/glossary/self-sovereign-identity/). Vendors: [decentralized identity](https://startwithidentity.com/vendors/decentralized-identity/). Directory: [digital IDs by country](https://startwithidentity.com/digital-ids/).

## Who wrote it

The DID 1.0 specification was co-edited by [Drummond Reed](https://startwithidentity.com/experts/drummond-reed/), [Manu Sporny](https://startwithidentity.com/experts/manu-sporny/), and [Christopher Allen](https://startwithidentity.com/experts/christopher-allen/), who also co-authored TLS 1.0 and named self-sovereign identity. [Samuel M. Smith](https://startwithidentity.com/experts/sam-smith/) argues the ledger-less case with KERI. More in the [experts directory](https://startwithidentity.com/experts/).

## eIDAS 2.0 & the EU Digital Identity Wallet
Source: https://startwithidentity.com/standards/eidas-2-eudi-wallet/
Last updated: 2026-11-05

## What it is

eIDAS 2.0 is the revised electronic identification, authentication and trust services regulation, [Regulation (EU) 2024/1183](https://eur-lex.europa.eu/eli/reg/2024/1183/oj) of 11 April 2024, which amends Regulation (EU) No 910/2014. Its headline requirement: every EU member state must offer citizens, residents and businesses a **European Digital Identity Wallet (EUDI Wallet)**, a state-recognized [digital identity wallet](https://startwithidentity.com/glossary/digital-wallet/) for holding and presenting identity data and [verifiable credentials](https://startwithidentity.com/standards/verifiable-credentials/). It is the single largest program turning [decentralized identity](https://startwithidentity.com/guides/fundamentals/what-is-decentralized-identity/) from pilots into population-scale infrastructure.

Three layers decide what you build: the **regulation** sets obligations and dates, the **implementing acts** set legally binding technical rules, and the **[ARF](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework)** describes the architecture and points at standards. For the legal picture, see [eIDAS 2 in the regulations hub](https://startwithidentity.com/regulations/european-union/eidas-2/) and the [compliance calendar](https://startwithidentity.com/regulations/calendar/).

## Timeline (official sources)

| Date | Milestone | Source |
|---|---|---|
| 30 April 2024 | Regulation published in the Official Journal | [Commission](https://ec.europa.eu/digital-building-blocks/sites/spaces/EUDIGITALIDENTITYWALLET/pages/915931903/The%2Blegal%2Band%2Btechnical%2Broad%2Bto%2BEU%2BDigital%2BIdentity%2BWallets) |
| 20 May 2024 | Regulation enters into force | [Commission](https://ec.europa.eu/digital-building-blocks/sites/display/EUDIGITALIDENTITYWALLET/The+Digital+Identity+Regulation+Enters+into+Force) |
| 4 December 2024 | Five implementing regulations published (2024/2977, 2024/2979, 2024/2980, 2024/2981, 2024/2982); in force 20 days later | [Commission](https://ec.europa.eu/digital-building-blocks/sites/spaces/EUDIGITALIDENTITYWALLET/pages/844759146/EU+Digital+Identity+Wallet+milestone+reached+as+Commission+adopts+implementing+regulations) |
| 23 July 2026 | ARF v3.0.0 released | [GitHub](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/releases) |
| End of 2026 | Member states must offer at least one wallet; public authorities must accept it | [Commission](https://digital-strategy.ec.europa.eu/en/policies/eudi-regulation) |
| 36 months after the implementing acts | Regulated private relying parties and very large online platforms must accept the wallet on user request | Article 5f(2) and 5f(3), as quoted in the ARF |

The five December 2024 acts cover PID and electronic attestations of attributes (2024/2977), integrity and core functions (2024/2979), notifications (2024/2980), certification (2024/2981) and protocols and interfaces (2024/2982). The Commission's implementing acts page now lists about 30 adopted acts, including relying-party registration rules updated by Implementing Regulation (EU) 2026/1730 and amendments to several of the 2024 acts in 2026/1731. Two practical consequences recorded in the ARF: the `portrait` attribute in the PID becomes mandatory only 24 months after the regulation amending 2024/2977 enters into force, and wallets must check relying-party registration certificates only 24 months after the regulation amending 2024/2982.

## How it works

- **PID and attestations.** The member state's PID provider issues a Person Identification Data credential to the wallet. Other providers issue electronic attestations of attributes (EAAs): diplomas, licenses, payment mandates. Qualified EAAs and attestations from public authentic sources carry legal weight. See [EUDI Wallet](https://startwithidentity.com/glossary/eudi-wallet/).
- **Formats.** The ARF names **ISO/IEC 18013-5 mdoc** ([mDL](https://startwithidentity.com/standards/iso-18013-5-mdl/)) and **SD-JWT VC**. It allows W3C VC Data Model 2.0 for some non-qualified EAAs but does not require it.
- **Protocols.** Issuance runs on [OpenID4VCI](https://startwithidentity.com/standards/openid4vc/). For remote presentation the ARF lists OpenID4VP with the W3C Digital Credentials API, ISO/IEC 18013-7 with the Digital Credentials API, and OpenID4VP with a custom URI scheme. In-person presentation uses ISO/IEC 18013-5.
- **Relying parties.** Services register with a Registrar in the member state where they are established, declaring each intended use and the data it will request. They present access and registration certificates, and each registration certificate carries exactly one intended use.
- **Trust.** ARF v3.0.0 added requirements for retrieving trust anchors from both Trusted Lists and Lists of Trusted Entities.

A worked example: a Dutch bank onboarding a customer from Spain sends an OpenID4VP request for family name, given name, birth date and nationality from the PID. The customer's Spanish wallet checks the bank's access certificate and registration certificate, shows the customer who is asking, and returns an SD-JWT VC presentation disclosing only those four claims. The bank validates the PID provider's signature against the trust anchors it retrieved, and checks the credential's status.

## Security and privacy design

- **Unlinkability.** The regulation requires privacy-preserving techniques that ensure unlinkability where attestations do not require identifying the user. The ARF implements this with batch issuance: **once-only attestations** (Method A, each copy used once) with a fallback to **limited-time attestations** (Method B).
- **Pseudonyms.** The ARF requires pseudonym implementations to enable unlinkability between transactions and relying parties. Article 5f(3) protects the right of users to freely chosen pseudonyms on very large online platforms.
- **Minimization.** The recitals require only the minimal necessary data be transferred to authorised relying parties.
- **Free signatures.** Wallets must offer natural persons qualified electronic signatures by default and free of charge, quoted in the ARF.
- **Proofs of age and personhood.** The ARF discusses zero-knowledge proof schemes, for example for proof of personhood, but the formats named today are mdoc and SD-JWT VC. Showing the same issued copy twice reveals the same issuer signature, which is why the batch methods above matter. See [zero-knowledge proof](https://startwithidentity.com/glossary/zero-knowledge-proof/).

## Who implements it

The Commission publishes open-source reference components on the [EU Digital Identity Wallet GitHub](https://github.com/eu-digital-identity-wallet), including a PID issuer and verifier endpoints. Vendors aligned with the program include [Talao](https://startwithidentity.com/vendors/decentralized-identity/talao/), which [describes](https://www.talao.io/) "the complete EUDI Wallet solution for enterprises and governments"; [Gataca](https://startwithidentity.com/vendors/decentralized-identity/gataca/), which says its platform is [aligned with the ARF](https://gataca.io/); [Procivis](https://startwithidentity.com/vendors/decentralized-identity/procivis/), whose [docs](https://docs.procivis.ch/) target eIDAS 2.0 and the Swiss e-ID; and [walt.id](https://startwithidentity.com/vendors/decentralized-identity/walt-id/), whose [feature list](https://docs.walt.id/feature-list) covers the mdoc and SD-JWT VC formats the ARF names. For a shortlist, see [best decentralized identity platforms](https://startwithidentity.com/rankings/best-decentralized-identity-platforms/).

## Pitfalls

- **Building to the ARF alone.** The implementing acts are the binding text, and they are being amended. Track the act numbers, not just ARF releases.
- **Assuming one wallet.** Each member state certifies its own, and national rollout readiness varies. Test against several, plus the reference implementation.
- **Over-requesting.** Your registration certificate declares what you may ask for. Once wallets are required to verify registration certificates, a request that goes beyond what you registered is exactly what they are built to catch.
- **Ignoring status.** Check revocation status on every PID presentation; HAIP uses Token Status List for SD-JWT VC.
- **Timeline optimism.** Treat "end of 2026" as the legal deadline for availability, not proof that your customers' wallets are ready. Keep existing [KYC](https://startwithidentity.com/guides/decentralized-identity/reusable-identity-and-kyc-with-verifiable-credentials/) paths.

## How it connects

eIDAS 2 is where the other standards meet: [OpenID4VC](https://startwithidentity.com/standards/openid4vc/) for transport, [SD-JWT VC](https://startwithidentity.com/standards/verifiable-credentials/) and [mdoc](https://startwithidentity.com/standards/iso-18013-5-mdl/) for formats, X.509 trust lists rather than [DIDs](https://startwithidentity.com/standards/decentralized-identifiers-did/) for issuer trust. The [European Union digital ID page](https://startwithidentity.com/digital-ids/european-union/) tracks the wallet as a scheme, alongside national eIDs in [digital IDs by country](https://startwithidentity.com/digital-ids/).

## Related

Guides: [what is decentralized identity](https://startwithidentity.com/guides/fundamentals/what-is-decentralized-identity/), [reusable identity and KYC with verifiable credentials](https://startwithidentity.com/guides/decentralized-identity/reusable-identity-and-kyc-with-verifiable-credentials/), [customer identity verification guide](https://startwithidentity.com/guides/compliance/customer-identity-verification-guide/). Standards: [OpenID4VC](https://startwithidentity.com/standards/openid4vc/), [Verifiable Credentials](https://startwithidentity.com/standards/verifiable-credentials/), [mDL](https://startwithidentity.com/standards/iso-18013-5-mdl/), [DIDs](https://startwithidentity.com/standards/decentralized-identifiers-did/). Directories: [regulations by country](https://startwithidentity.com/regulations/), [European Union regulations](https://startwithidentity.com/regulations/european-union/), [digital IDs by country](https://startwithidentity.com/digital-ids/). Glossary: [EUDI Wallet](https://startwithidentity.com/glossary/eudi-wallet/), [eIDAS](https://startwithidentity.com/glossary/eidas/), [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/), [relying party](https://startwithidentity.com/glossary/relying-party/).

## Who wrote it

The wallet architecture draws on the OpenID4VC work of [Kristina Yasuda](https://startwithidentity.com/experts/kristina-yasuda/) and [Torsten Lodderstedt](https://startwithidentity.com/experts/torsten-lodderstedt/), who leads Germany's wallet project at SPRIND, and on SD-JWT VC from [Daniel Fett](https://startwithidentity.com/experts/daniel-fett/). More in the [experts directory](https://startwithidentity.com/experts/).

## FAPI (Financial-grade API)
Source: https://startwithidentity.com/standards/fapi/
Last updated: 2026-11-05

## What it is

FAPI, the Financial-grade API profile from the OpenID Foundation, is a tightened security profile layered on [OAuth 2.0](https://startwithidentity.com/standards/oauth-2-0/) and [OpenID Connect](https://startwithidentity.com/standards/openid-connect/). It exists because plain OAuth, while flexible, leaves choices that are unsafe for high-value APIs like banking and payments. FAPI removes that ambiguity and mandates the strong options.

## How it works

FAPI raises the bar with requirements such as:

- **Sender-constrained tokens** (mutual TLS or [DPoP](https://startwithidentity.com/glossary/dpop/)) so a stolen token cannot be replayed by another client.
- **[Pushed Authorization Requests](https://startwithidentity.com/glossary/par/) (PAR)** so request parameters are sent over a back channel and cannot be tampered with.
- **Strong client authentication** and signed request objects.

## What FAPI 2.0 actually requires

The [FAPI 2.0 Security Profile](https://openid.net/specs/fapi-security-profile-2_0-final.html) turns OAuth's options into rules. For authorization servers it says, among other requirements:

- **Confidential clients only.** Public clients are not supported.
- **Sender-constrained access tokens only**, using either mutual TLS ([RFC 8705](https://www.rfc-editor.org/rfc/rfc8705.html)) or DPoP ([RFC 9449](https://www.rfc-editor.org/rfc/rfc9449.html)).
- **Strong client authentication**: mutual TLS or `private_key_jwt`. Shared client secrets are out.
- **Pushed authorization requests required** ([RFC 9126](https://www.rfc-editor.org/rfc/rfc9126.html)): the server rejects authorization requests that were not pushed, and rejects pushed requests without client authentication.
- **Code flow only, with PKCE S256**, and the `redirect_uri` required in the pushed request.
- **Issuer identification** in the authorization response ([RFC 9207](https://www.rfc-editor.org/rfc/rfc9207.html)), to stop mix-up attacks.
- **Authorization codes valid for at most 60 seconds.**
- **No resource owner password grant**, and no refresh token rotation except in extraordinary circumstances. The profile notes that rotation adds no security for confidential clients with sender-constrained tokens and causes failures whenever a client misses the new refresh token.
- **No `http` redirect URIs**: authorization responses must not travel over unencrypted connections.

The profile is formally analysed against a published [FAPI 2.0 Attacker Model](https://openid.net/specs/fapi-attacker-model-2_0-final.html), and it states that a profile built on top must not remove or override mandatory behavior, since that could invalidate the security analysis. It also follows the [OAuth 2.0 Security BCP (RFC 9700)](https://www.rfc-editor.org/rfc/rfc9700.html).

[FAPI 2.0 Message Signing](https://openid.net/specs/fapi-message-signing-2_0-final.html) adds signing of authorization requests, authorization responses, introspection responses and ID tokens for ecosystems that need non-repudiation, for example to prove later exactly what a payment instruction said.

## Status

As of 5 November 2026, per the [FAPI working group's specifications page](https://openid.net/wg/fapi/specifications/):

| Specification | Status | Published |
|---|---|---|
| FAPI 2.0 Security Profile | Final | 22 February 2025 |
| FAPI 2.0 Attacker Model | Final | 22 February 2025 |
| FAPI 2.0 Message Signing | Final | 25 September 2025 |
| FAPI 1.0 Part 1 (Baseline) and Part 2 (Advanced), JARM | Final | Earlier |
| FAPI CIBA profile, Grant Management for OAuth 2.0 | Implementer's Drafts | |

The working group "strongly recommends that all new ecosystems adopt FAPI 2.0" and that existing FAPI 1.0 ecosystems plan a transition. FAPI 1.0 is widely deployed in open banking regimes (UK, Brazil, Australia and others). FAPI 2.0 is simpler to implement than FAPI 1.0 Advanced and is the current target for new implementations.

## FAPI, OAuth 2.1 and AI agents

FAPI 2.0 is roughly what OAuth 2.1 would look like with every option set to the strict choice. [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/) requires PKCE and drops the implicit and password grants; FAPI 2.0 additionally requires PAR, sender-constrained tokens and asymmetric client authentication. That is relevant beyond banking. Agents that move money or touch regulated data are high-value clients holding tokens in processes that read untrusted input, the exact case where a stolen [bearer token](https://startwithidentity.com/glossary/bearer-token/) is worst. Neither MCP nor A2A requires sender-constrained tokens today, as SWI's [Agent Identity Standards Map 2026](https://startwithidentity.com/reports/agent-identity-standards-map-2026/) records, so a FAPI 2.0 authorization server is one of the few ways to get DPoP or mTLS binding enforced by policy rather than by client goodwill.

## When to use it

When you expose APIs that move money or highly sensitive data, or when a regulator or open-banking scheme requires it. For ordinary consumer login, standard OIDC is sufficient.

## Pitfalls

- FAPI is demanding to implement correctly; use a certified provider rather than building it yourself.
- Conformance matters: look for [OpenID Foundation certification](https://openid.net/certification/) against the FAPI 2.0 test plans on any platform you rely on, and confirm which profile (FAPI 1.0 Advanced or FAPI 2.0) and which sender-constraining method (mTLS or DPoP) it was certified for.
- Ecosystem profiles narrow the choices further. A national open banking profile may require mTLS where FAPI 2.0 allows DPoP, so read the ecosystem profile, not only the base specification.
- Clock skew: FAPI 2.0 tells servers to accept JWTs with `iat` or `nbf` up to 10 seconds in the future and to reject them beyond 60 seconds, and it suggests clients on user devices use the server's HTTP `Date` header to correct their clocks.

## Related

Glossary: [FAPI](https://startwithidentity.com/glossary/fapi/), [PAR](https://startwithidentity.com/glossary/par/), [DPoP](https://startwithidentity.com/glossary/dpop/). Standards: [OAuth 2.0](https://startwithidentity.com/standards/oauth-2-0/), [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/), [OpenID Connect](https://startwithidentity.com/standards/openid-connect/), [MCP authorization](https://startwithidentity.com/standards/mcp-authorization/). Glossary: [proof of possession](https://startwithidentity.com/glossary/proof-of-possession/), [mTLS](https://startwithidentity.com/glossary/mtls/), [PSD2](https://startwithidentity.com/glossary/psd2/).

## Who wrote it

FAPI came out of the OpenID Foundation working group with [Torsten Lodderstedt](https://startwithidentity.com/experts/torsten-lodderstedt/), and [Daniel Fett](https://startwithidentity.com/experts/daniel-fett/) led its formal security analysis. [Nat Sakimura](https://startwithidentity.com/experts/nat-sakimura/) chairs the OpenID Foundation. More in the [experts directory](https://startwithidentity.com/experts/).

## ID-JAG and Cross App Access (XAA)
Source: https://startwithidentity.com/standards/id-jag-cross-app-access/
Last updated: 2026-11-05

## What it is

The Identity Assertion JWT Authorization Grant (ID-JAG) is an IETF OAuth draft that lets an application get an access token for another application's API, on a user's behalf, by going through the enterprise identity provider (IdP) that both applications already trust for single sign-on. Its abstract says the pattern "is informally referred to as Cross-App Access (XAA)". The point is to move the "should app A reach app B's data for this user" decision away from an end-user consent screen and into IdP policy that an administrator controls, can audit, and can revoke centrally.

ID-JAG combines two published RFCs. [OAuth 2.0 Token Exchange (RFC 8693)](https://www.rfc-editor.org/rfc/rfc8693.html) is used to get the grant from the IdP, and the [JWT Profile for OAuth 2.0 Authorization Grants (RFC 7523)](https://www.rfc-editor.org/rfc/rfc7523.html) is used to redeem it at the target. The token is a signed JWT with the header `typ` value `oauth-id-jag+jwt`, so it cannot be confused with an ID token. For the short definition see the glossary entries for [ID-JAG](https://startwithidentity.com/glossary/id-jag/) and [Cross App Access](https://startwithidentity.com/glossary/cross-app-access/).

## Status (November 2026)

The latest revision is [draft-ietf-oauth-identity-assertion-authz-grant-06](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/), dated 31 October 2026, read from the IETF datatracker on 5 November 2026. Its stream state is **WG Document**: the OAuth Working Group has adopted it, but it has not been through working-group last call, IESG review, or publication. The intended status is Standards Track. The editors are Aaron Parecki ([Okta](https://startwithidentity.com/vendors/iam/okta/)), Karl McGuinness (independent) and [Brian Campbell](https://startwithidentity.com/experts/brian-campbell/) ([Ping Identity](https://startwithidentity.com/vendors/iam/ping-identity/)).

The work started as the individual draft draft-parecki-oauth-identity-assertion-authz-grant and was replaced by the working-group draft in August 2025, as recorded in SWI's [Agent Identity Standards Map 2026](https://startwithidentity.com/reports/agent-identity-standards-map-2026/). Treat it as a pinned dependency: field names and processing rules can still change. The MCP extension that uses it, for example, still links to revision -04.

## How it works

The draft names four roles: the **client** (the requesting app or agent host), the **IdP Authorization Server** (the enterprise IdP), the **Resource Authorization Server** (the target app's OAuth server) and the **resource server** (the target API). A concrete flow, using a chat app that wants to read a user's tickets in a ticketing app:

1. **SSO.** The user signs in to the chat app through the corporate IdP with [OpenID Connect](https://startwithidentity.com/standards/openid-connect/) or [SAML](https://startwithidentity.com/standards/saml-2-0/). The chat app now holds an ID token (or, for SAML, exchanges the assertion for a refresh token first).
2. **Token exchange at the IdP.** The chat app calls the IdP's token endpoint with `grant_type=urn:ietf:params:oauth:grant-type:token-exchange`, `requested_token_type=urn:ietf:params:oauth:token-type:id-jag`, the ticketing app's authorization server as the single `audience`, the ticketing API as `resource` ([RFC 8707](https://startwithidentity.com/glossary/resource-indicators/)), the wanted `scope`, and the ID token as `subject_token`. The client authenticates itself, for example with a JWT client assertion.
3. **IdP policy.** The IdP checks whether this client may act for this user at this audience with these scopes. If yes, it returns a short-lived ID-JAG. The MCP profile's example response has `expires_in` of 300 seconds.
4. **Redeem at the target.** The chat app posts the ID-JAG to the ticketing app's token endpoint with `grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer` and authenticates with its credentials at that server.
5. **Local policy and token.** The ticketing app's authorization server validates the signature against the IdP's published keys, checks `aud`, `exp`, `jti` and `client_id`, maps `sub` to a local user through its existing SSO relationship, applies its own policy, and issues an access token.

The ID-JAG claims set is small. Required: `iss`, `sub`, `aud`, `client_id`, `jti`, `exp`, `iat`. Optional: `resource`, `scope`, `authorization_details` ([Rich Authorization Requests](https://startwithidentity.com/glossary/rich-authorization-requests/)), `act` (the RFC 8693 actor claim), `tenant`, `auth_time`, `acr` and `amr`. Note that `client_id` is the client's identifier at the target, which may differ from its identifier at the IdP.

Discovery is metadata-driven. An IdP advertises support by listing `urn:ietf:params:oauth:token-type:id-jag` in `identity_chaining_requested_token_types_supported`, a parameter defined by the [Identity Chaining](https://startwithidentity.com/glossary/identity-chaining/) draft, and may publish `id_jag_signing_alg_values_supported`. A target authorization server lists `urn:ietf:params:oauth:grant-profile:id-jag` in `authorization_grant_profiles_supported`. Revision -06 also adds sections on DPoP key binding, so an ID-JAG can carry a `cnf` claim and be redeemed only by the holder of that key.

## What it solves for AI agents and SaaS

For SaaS, the problem is consent sprawl. Every "connect app" click creates a long-lived OAuth grant that the identity team cannot see in one place and cannot revoke when someone leaves. With ID-JAG, the IdP sits in the middle of every connection, so admins can allow, deny and log app-to-app access the same way they manage SSO assignments.

For AI agents the effect is larger. An agent that uses ten tools would otherwise ask the user to approve ten consent screens and then keep ten refresh tokens. Under ID-JAG the agent host asks the IdP for a grant per target as needed, gets short-lived tokens, and loses access when the IdP policy or the user's account changes. That is why the [MCP authorization](https://startwithidentity.com/standards/mcp-authorization/) ecosystem adopted it as the Enterprise-Managed Authorization extension.

What it does not solve: agents acting as themselves (use client credentials or [workload identity](https://startwithidentity.com/glossary/workload-identity/)), access between organizations that do not share an IdP, and enforced multi-hop [delegation chains](https://startwithidentity.com/glossary/delegation-chain/). The `act` claim can name the agent, but neither ID-JAG nor RFC 8693 makes prior actors enforceable.

## Adoption signals (verified)

- **Okta Agent SSO.** Okta [announced general availability](https://www.okta.com/newsroom/press-releases/okta-brings-first-class-identity-to-ai-agents-with-agent-sso/) on 24 August 2026, describing it as bringing "the open Cross App Access standard" into Okta SSO at no extra cost, with prebuilt support for apps including Anthropic's Claude, Atlassian, Notion and Slack.
- **MCP Enterprise-Managed Authorization.** A [stable extension](https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/stable/enterprise-managed-authorization/2026-07-28/enterprise-managed-authorization.mdx) for MCP revision 2026-07-28 that applies ID-JAG to MCP clients and servers.
- **Official MCP TypeScript SDK.** The client package's [auth extensions](https://github.com/modelcontextprotocol/typescript-sdk/blob/main/packages/client/src/client/authExtensions.ts) include a provider that exchanges an ID token for an ID-JAG via RFC 8693, checked on 5 November 2026.

We found no other IdP with documented general availability as of this review. Absence here means "not verified", not "not shipped".

## How to implement or evaluate

- **If you run the IdP:** confirm your vendor supports issuing ID-JAGs through token exchange, and how policy is expressed (per client, per audience, per scope, per group). Ask whether issued grants are logged with the user, client and target, and whether revoking the user's session stops new grants.
- **If you build a SaaS app (the target):** accept the `jwt-bearer` grant with the ID-JAG profile, require client authentication (the draft says the server must reject requests with neither client authentication nor a sender-constrained grant), validate `aud` against your own issuer identifier exactly, enforce single use of `jti`, and issue short-lived access tokens. Keep your own policy: the draft is explicit that the target still decides.
- **If you build an agent or MCP client:** store the user's ID token or refresh token as a high-value secret, request one audience per exchange, pass the `resource` value from the target's [protected resource metadata](https://startwithidentity.com/glossary/protected-resource-metadata/) unchanged, and ask for the narrowest scope.
- **Pin and test.** Record which revision you implement. The MCP extension links -04 while the current text is -06, so check processing rules against the revision your counterparties use.

## Pitfalls

- **The IdP becomes a single point of authorization.** A compromised IdP admin or a broad policy ("any app may reach any app") recreates the sprawl you were trying to remove, centrally. Review policies like privileged access.
- **Subject mapping errors.** The target must map `sub` (or a SAML NameID in `sub_id`) to the same user its SSO already resolves, including tenant. Mismatches can grant access to the wrong account in multi-tenant setups.
- **Stored subject tokens.** Holding ID tokens or refresh tokens in an agent runtime that reads untrusted input is a real exposure, covered in our [agent instruction injection](https://startwithidentity.com/techniques/agent-instruction-injection/) technique brief.

## Related

[MCP authorization](https://startwithidentity.com/standards/mcp-authorization/), [OAuth Transaction Tokens](https://startwithidentity.com/standards/oauth-transaction-tokens/), [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/), the [Agent Identity Standards Map 2026](https://startwithidentity.com/reports/agent-identity-standards-map-2026/), the [securing AI agent identities](https://startwithidentity.com/guides/machine-identity/securing-ai-agent-identities/) guide, and our analysis [agent identity just got a protocol](https://startwithidentity.com/blog/agent-identity-gets-a-protocol/). Glossary: [token exchange](https://startwithidentity.com/glossary/token-exchange/), [identity chaining](https://startwithidentity.com/glossary/identity-chaining/), [agentic identity](https://startwithidentity.com/glossary/agentic-identity/), [credential brokering](https://startwithidentity.com/glossary/credential-brokering/).

## Who wrote it

The draft is edited by [Aaron Parecki](https://startwithidentity.com/experts/aaron-parecki/), Karl McGuinness and [Brian Campbell](https://startwithidentity.com/experts/brian-campbell/). More in the [experts directory](https://startwithidentity.com/experts/).

## ISO/IEC 18013-5 Mobile Driver's License (mDL)
Source: https://startwithidentity.com/standards/iso-18013-5-mdl/
Last updated: 2026-11-05

## What it is

ISO/IEC 18013-5 defines the **mobile driver's license (mDL)**: a driver's license or state ID issued to a phone wallet in a standardized, cryptographically verifiable format. A verifier can check it offline against the issuing authority's public key and receive only the fields it asked for. It is one of the most widely deployed [verifiable credential](https://startwithidentity.com/standards/verifiable-credentials/) formats because governments are shipping it into consumer wallets. The companion technical specification **ISO/IEC TS 18013-7** extends presentation to websites and apps.

The data structure is called an **mdoc**, and it is not limited to licenses. The same format carries the EU's PID in the [EUDI Wallet](https://startwithidentity.com/standards/eidas-2-eudi-wallet/), and [OpenID4VC](https://startwithidentity.com/standards/openid4vc/) uses the identifier `mso_mdoc` for it.

## Status (November 2026)

| Document | Status | Date |
|---|---|---|
| ISO/IEC 18013-5:2021, edition 1 | Published; stage 90.92 "to be revised" since 10 December 2024 | Published 30 September 2021 |
| ISO/IEC DIS 18013-5 | Draft International Standard, under development | ISO says it is expected to replace the 2021 edition "within the coming months" |
| ISO/IEC TS 18013-7:2024, edition 1 | Withdrawn 29 May 2025 | Published 7 October 2024 |
| ISO/IEC TS 18013-7:2025, edition 2 | Published; stage 90.92 since 25 July 2025, to be replaced by a CD TS | 29 May 2025 |

Sources: the ISO catalogue pages for [18013-5](https://www.iso.org/standard/69084.html) and [TS 18013-7](https://www.iso.org/standard/91154.html). Note that 18013-7 is a **Technical Specification**, not a full International Standard, which is why it can be revised quickly.

In the United States, [AAMVA](https://www.aamva.org/) published version 1.6 of its [mDL Implementation Guidelines](https://aamva.org/publications-news/aamva-news/now-available-aamva%E2%80%99s-mobile-driver-license-(mdl)-implementation-guidelines-v1-6) on 30 June 2026, revising its over-the-internet appendix and its revocation guidance. AAMVA's [Digital Trust Service](https://aamva.org/identity/mobile-driver-license-digital-trust-service) (DTS) [went live](https://aamva.org/publications-news/aamva-news/aamva-s-mobile-driver-license-digital-trust-service-is-now-live) on 15 April 2024 with Utah and Maryland. It publishes a Verified Issuer Certificate Authority List (VICAL) that relying parties download before they read an mDL; the version at [vical.dts.aamva.org](https://vical.dts.aamva.org/) was dated 5 November 2026 when we checked. AAMVA's public pages do not list participating jurisdictions, and we could not fetch TSA's checkpoint list directly, so see the [United States digital ID page](https://startwithidentity.com/digital-ids/united-states/) for the current state-by-state picture.

## How it works

An in-person mDL transaction at a pharmacy counter:

1. **Device engagement.** The holder taps the phone (NFC) or shows a QR code. AAMVA notes these mechanisms were chosen because they only work at close range.
2. **Session setup.** Reader and phone derive an ephemeral session key, and data moves over a short-range transport such as BLE.
3. **Request.** The reader sends a `DeviceRequest` naming specific data elements, for example `portrait` and `age_over_21`. It can sign the request with a reader certificate (**mdoc reader authentication**) so the wallet knows who is asking. AAMVA forbids wallets from demanding reader authentication before releasing the mandatory elements.
4. **Consent and response.** The holder approves. The phone returns a `DeviceResponse` with the elements plus the **mobile security object (MSO)**: a structure signed with the issuer's document signer certificate that holds a digest of every element and a validity period.
5. **Verification.** The reader chains the document signer to the issuer's IACA root certificate (from the VICAL in the US), recomputes the digests, and checks that the response was produced by the device the credential is bound to. AAMVA explains that 18013-5 requires each mDL to be cryptographically bound to the device it was provisioned on, and the reading protocol terminates if it is not, which stops copied mDLs.

Selective disclosure is built in because each element is hashed separately. AAMVA's guidelines require issuers to include an `age_over_NN` statement for every age question common in their jurisdiction, so a 20-year-old's mDL carries `age_over_18=True` and `age_over_21=False` and a bar learns nothing else. See [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/) and [age verification](https://startwithidentity.com/glossary/age-verification/).

**Device retrieval versus server retrieval.** 18013-5 requires device retrieval (data on the phone, works offline) and allows server retrieval (the reader fetches data live from the issuer). AAMVA's guidelines **prohibit server retrieval** in support of their no-tracking rule.

## Online presentation (ISO/IEC TS 18013-7)

According to AAMVA's v1.6 Appendix C, the second edition of 18013-7 contains three protocols:

| Annex | Mechanism | Notes |
|---|---|---|
| A | Device retrieval to a website (sometimes called the REST API) | ISO-native |
| B | Retrieval over [OpenID4VP](https://startwithidentity.com/standards/openid4vc/) | Built on OpenID4VP draft 18; OpenID4VP 1.0 is not backwards compatible, and migration was under way |
| C | Retrieval through an API such as the W3C Digital Credentials API | AAMVA recommends jurisdictions consider this first |

AAMVA also records work on an Annex D based on OpenID4VP 1.0 plus HAIP, and joint ISO and OpenID work toward a common internet protocol, with no timeline. The W3C [Digital Credentials](https://www.w3.org/TR/digital-credentials/) draft (Working Draft, 5 November 2026) registers both `org-iso-mdoc` (18013-7 Annex C) and the OpenID4VP 1.0 protocol identifiers, so a browser can broker either.

## Who implements it

- **Google Wallet:** Google's [developer documentation](https://developers.google.com/wallet/identity/verify/accepting-ids-from-wallet-online) says it "supports ISO mdoc based Digital IDs over OpenID4VP (Version 1.0)" through the Digital Credentials API in Chrome.
- **[MATTR](https://startwithidentity.com/vendors/decentralized-identity/mattr/):** its [remote web verifier quickstart](https://learn.mattr.global/docs/verification/remote-web-verifiers/quickstart) follows "OID4VP and ISO/IEC 18013-7:2025".
- **[Procivis](https://startwithidentity.com/vendors/decentralized-identity/procivis/):** its [standards page](https://docs.procivis.ch/standards) lists ISO/IEC 18013-5 proximity (NFC or QR engagement, BLE retrieval) and 18013-7 Annex B.
- **[walt.id](https://startwithidentity.com/vendors/decentralized-identity/walt-id/):** its [feature list](https://docs.walt.id/feature-list) covers `mso_mdoc` and 18013-7 remote flows.
- **[SpruceID](https://startwithidentity.com/vendors/decentralized-identity/spruce-id/):** its open-source [SpruceKit Mobile](https://github.com/spruceid/sprucekit-mobile) libraries target mDL and verifiable credentials in mobile apps.

For verifier-side checks bundled into KYC, see [identity verification vendors](https://startwithidentity.com/vendors/identity-verification/) and the [customer identity verification guide](https://startwithidentity.com/guides/compliance/customer-identity-verification-guide/).

## Security and privacy pitfalls

- **Skipping the device binding check.** Checking only the issuer signature accepts a replayed copy of the data. Verify that the response is bound to the device key and the current session every time.
- **Relayed online requests.** For app-to-app and online sharing, AAMVA requires protection against an attacker forwarding engagement or request data to a victim's wallet, by binding the presentment to the originating request channel (18013-7 clause 6.5). Prefer a protocol designed for it, such as 18013-7 Annex C over the Digital Credentials API, which the EU ARF credits with clear origin verification, over a custom deep link.
- **Stale trust lists.** Refresh the VICAL on a schedule; an unknown IACA should fail closed.
- **Ignoring `validUntil`.** AAMVA notes the MSO validity is what authenticates the mDL, separate from the license's printed expiry. Revocation handling changed in v1.6, so read that chapter.
- **Linkability.** AAMVA warns that long-lived metadata (hardware addresses, long-term public keys, session tokens) lets verifiers link transactions. The portrait is always shared in matched transactions, so anonymity there is limited.
- **Over-asking.** Requesting the full element set when `age_over_21` would do defeats the design and raises your retention risk.
- **Protocol drift online.** 18013-7 Annex B is pinned to an old OpenID4VP draft. Test with the wallets you expect, and keep a fallback to [document scan verification](https://startwithidentity.com/guides/decentralized-identity/reusable-identity-and-kyc-with-verifiable-credentials/).

## How it fits with the other standards

mDL and [SD-JWT VC](https://startwithidentity.com/standards/verifiable-credentials/) are the two credential formats the EU [ARF](https://startwithidentity.com/standards/eidas-2-eudi-wallet/) names for the EUDI Wallet. [OpenID4VCI](https://startwithidentity.com/standards/openid4vc/) can issue an mdoc and OpenID4VP can present one, and [HAIP](https://startwithidentity.com/standards/openid4vc/) profiles both. mdoc does **not** use [DIDs](https://startwithidentity.com/standards/decentralized-identifiers-did/): trust comes from X.509 certificate chains ([PKI](https://startwithidentity.com/glossary/pki/)) anchored in issuer lists like the VICAL or EU trusted lists.

## Related

Guides: [reusable identity and KYC with verifiable credentials](https://startwithidentity.com/guides/decentralized-identity/reusable-identity-and-kyc-with-verifiable-credentials/), [verifiable credentials implementation guide](https://startwithidentity.com/guides/decentralized-identity/verifiable-credentials-implementation-guide/). Directories: [digital IDs by country](https://startwithidentity.com/digital-ids/), [United States](https://startwithidentity.com/digital-ids/united-states/), [European Union](https://startwithidentity.com/digital-ids/european-union/), [identity verification vendors](https://startwithidentity.com/vendors/identity-verification/). Standards: [Verifiable Credentials](https://startwithidentity.com/standards/verifiable-credentials/), [OpenID4VC](https://startwithidentity.com/standards/openid4vc/), [eIDAS 2 / EUDI Wallet](https://startwithidentity.com/standards/eidas-2-eudi-wallet/), [DIDs](https://startwithidentity.com/standards/decentralized-identifiers-did/). Glossary: [mobile driver's license](https://startwithidentity.com/glossary/mobile-drivers-license/), [digital identity wallet](https://startwithidentity.com/glossary/digital-wallet/), [x.509](https://startwithidentity.com/glossary/x509/), [KYC](https://startwithidentity.com/glossary/kyc/). Ranking: [best identity verification for enterprises](https://startwithidentity.com/rankings/best-identity-verification-for-enterprises/).

## Who wrote it

Browser-side presentation of mobile driving licences runs through the W3C Digital Credentials API, edited by [Tim Cappalli](https://startwithidentity.com/experts/tim-cappalli/). [Wayne Chang](https://startwithidentity.com/experts/wayne-chang/) worked on the California DMV programme that deployed one. More in the [experts directory](https://startwithidentity.com/experts/).

## Kerberos V5
Source: https://startwithidentity.com/standards/kerberos/
Last updated: 2026-11-05

## What it is

Kerberos V5 is a network authentication protocol built on a trusted third party, the **Key Distribution Center (KDC)**, that shares a secret key with every user and service in its **realm**. The KDC hands out encrypted, time-limited **tickets**; a client proves who it is to a service by presenting a ticket the service can decrypt, plus a fresh authenticator only the legitimate client could produce. Passwords never cross the network, and users sign in once per session.

The protocol is [RFC 4120](https://www.rfc-editor.org/rfc/rfc4120) (July 2005), written by C. Neuman (USC-ISI) with T. Yu, S. Hartman and K. Raeburn (MIT); it obsoletes RFC 1510. The GSS-API mechanism that applications actually call is [RFC 4121](https://www.rfc-editor.org/rfc/rfc4121). Every Active Directory domain controller is a KDC, and Windows adds its own extensions in [MS-KILE](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/2a32282e-dd48-4ad9-a542-609804b02cc9) and the authorization data format [MS-PAC](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/166d8064-c863-41e1-9c23-edaaa5f36962). On Linux, MIT Kerberos and Heimdal are the main implementations; [FreeIPA](https://startwithidentity.com/vendors/open-source/freeipa/) bundles MIT Kerberos, and [Keycloak](https://startwithidentity.com/vendors/open-source/keycloak/) documents a Kerberos bridge for desktop SSO (both checked on the project sites, 5 November 2026).

## Status (November 2026)

| Item | Status |
| --- | --- |
| RFC 4120 | Proposed Standard, July 2005. Updated by RFC 4537, 5021, 5896, 6111, 6112, 6113, 6649, 6806, 7751, 8062, 8129, 8429 and 8553 (per the [RFC Editor](https://www.rfc-editor.org/info/rfc4120)) |
| Pre-authentication framework and FAST | [RFC 6113](https://www.rfc-editor.org/rfc/rfc6113) |
| Certificate logon (PKINIT) | [RFC 4556](https://www.rfc-editor.org/rfc/rfc4556), Proposed Standard, June 2006 |
| Encryption types | AES with HMAC-SHA1 ([RFC 3962](https://www.rfc-editor.org/rfc/rfc3962), etypes 17 and 18) and AES with HMAC-SHA2 ([RFC 8009](https://www.rfc-editor.org/rfc/rfc8009), etypes 19 and 20). DES deprecated by [RFC 6649](https://www.rfc-editor.org/rfc/rfc6649) (BCP 179, July 2012); RC4-HMAC (23) and 3DES by [RFC 8429](https://www.rfc-editor.org/rfc/rfc8429) (BCP 218, October 2018), which also moved RFC 4757 to Historic |
| Ports | 88/tcp and 88/udp `kerberos`, 464 `kpasswd` ([IANA](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml)) |

Kerberos is not being replaced in Windows networks any time soon, but its configuration is changing underneath: the RC4 default for service tickets in Active Directory was the subject of [CVE-2026-20833](https://startwithidentity.com/cves/cve-2026-20833/), and PAC validation enforcement has been tightened in stages since 2022 (see [CVE-2024-26248](https://startwithidentity.com/cves/cve-2024-26248/)).

## How it works

Three exchanges, each defined in RFC 4120 §3:

1. **AS exchange** ([§3.1](https://www.rfc-editor.org/rfc/rfc4120#section-3.1)). The client sends `AS-REQ` naming itself and the ticket-granting service `krbtgt/REALM`. With pre-authentication, it includes a timestamp encrypted with its long-term key (`PA-ENC-TIMESTAMP`, §5.2.7.2). The KDC replies with `AS-REP`: a **ticket-granting ticket (TGT)** encrypted with the `krbtgt` key, and a session key encrypted with the client's key.
2. **TGS exchange** ([§3.3](https://www.rfc-editor.org/rfc/rfc4120#section-3.3)). For each service, the client sends `TGS-REQ` with the TGT and an authenticator, naming a **service principal** such as `HTTP/app.example.com`. The KDC returns a **service ticket** encrypted with that service's key.
3. **AP exchange** ([§3.2](https://www.rfc-editor.org/rfc/rfc4120#section-3.2)). The client sends `AP-REQ` to the service, carried inside the application protocol (SMB, LDAP SASL `GSSAPI`, or HTTP `Negotiate` per [RFC 4559](https://www.rfc-editor.org/rfc/rfc4559)). The service decrypts the ticket with its own key, checks the authenticator, and optionally answers with `AP-REP` for mutual authentication.

Time matters: authenticators are rejected outside an allowable clock skew (RFC 4120 gives 5 minutes as the example), and servers keep a replay cache for that window. The field-by-field version of all three exchanges is in [how Kerberos works, message by message](https://startwithidentity.com/guides/protocols/kerberos-message-flow/).

## Active Directory specifics that change the security picture

- **The PAC.** Domain controllers put a Privilege Attribute Certificate in the ticket's authorization data with the user's SIDs and group memberships, signed by the KDC ([MS-PAC](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-pac/166d8064-c863-41e1-9c23-edaaa5f36962)). Services authorize from it, so PAC forgery or skipped PAC validation means privilege escalation.
- **Service keys come from passwords.** A service principal registered on a user account has a key derived from that account's password. Any domain user can request a ticket for it, and a weak password can be cracked offline: [Kerberoasting](https://startwithidentity.com/techniques/kerberoasting/).
- **Delegation.** Unconstrained, constrained and resource-based constrained delegation (S4U2self and S4U2proxy in MS-SFU) let services act as users; misconfigured delegation is a domain-compromise path: [Kerberos delegation abuse](https://startwithidentity.com/techniques/kerberos-delegation-abuse/).
- **Certificate logon.** PKINIT ties Kerberos to AD Certificate Services, so certificate template mistakes become Kerberos logons as other users: [AD CS certificate template abuse](https://startwithidentity.com/techniques/adcs-certificate-template-abuse/).
- **The krbtgt key.** Whoever holds it can mint TGTs for anyone, so a suspected domain compromise includes rotating it.

## Where Kerberos breaks in practice

On 5 November 2026 the SWI [identity CVE catalog](https://startwithidentity.com/cves/) held 14 entries tagged Kerberos and Active Directory. The recurring classes:

- **PAC and identity validation gaps:** [CVE-2024-26248](https://startwithidentity.com/cves/cve-2024-26248/), [CVE-2024-29056](https://startwithidentity.com/cves/cve-2024-29056/) (cross-forest), [CVE-2026-27912](https://startwithidentity.com/cves/cve-2026-27912/) (kpasswd ignoring `PAC_REQUESTOR_SID`).
- **Protocol extension logic:** [CVE-2025-60704](https://startwithidentity.com/cves/cve-2025-60704/) (S4U missing a cryptographic step), [CVE-2025-26647](https://startwithidentity.com/cves/cve-2025-26647/) (PKINIT and NTAuth), [CVE-2022-26923](https://startwithidentity.com/cves/cve-2022-26923/) (Certifried).
- **KDC impersonation and reflection:** [CVE-2024-20674](https://startwithidentity.com/cves/cve-2024-20674/), [CVE-2025-33073](https://startwithidentity.com/cves/cve-2025-33073/) and [CVE-2025-58726](https://startwithidentity.com/cves/cve-2025-58726/) (Kerberos reflection over SMB).
- **Weak defaults and naming:** [CVE-2026-20833](https://startwithidentity.com/cves/cve-2026-20833/) (RC4 service tickets), [CVE-2026-25177](https://startwithidentity.com/cves/cve-2026-25177/) (look-alike SPNs with invisible Unicode).

## When to use it

Kerberos is the right protocol for authentication **inside a managed network**: Windows domains, Linux hosts joined to a realm, file and database services, and LDAP binds via SASL `GSSAPI`. It is a poor fit across the internet or into SaaS, where it needs direct reachability to the KDC; [SAML 2.0](https://startwithidentity.com/standards/saml-2-0/) and [OpenID Connect](https://startwithidentity.com/standards/openid-connect/) federate from the same directory instead. Where an application can do Kerberos, prefer it over NTLM and over [LDAP](https://startwithidentity.com/standards/ldap/) simple binds with passwords.

## Pitfalls

- Service accounts with SPNs, weak passwords and RC4 still enabled.
- Unconstrained delegation on servers that are not domain controllers.
- Clock drift between clients, servers and KDCs, which breaks logons and tempts admins to widen the skew.
- Clients connecting by IP address or a name with no matching service principal, which can fall back to NTLM without anyone noticing.
- Treating a decrypted ticket as authorization. RFC 4120 §3.2.3 says passing the checks "provides only authentication of the named principal"; the application must still decide what that principal may do.

## How it works, message by message

The [Kerberos message-flow walkthrough](https://startwithidentity.com/guides/protocols/kerberos-message-flow/) decodes AS-REQ with pre-authentication, AS-REP, TGS-REQ, TGS-REP and AP-REQ field by field, shows what is inside a ticket and an authenticator, ties every field to RFC 4120 section 5, and lists the checks the client, the KDC and the service must each run.

## Related

Walkthrough: [how Kerberos works, message by message](https://startwithidentity.com/guides/protocols/kerberos-message-flow/). Standards: [LDAP](https://startwithidentity.com/standards/ldap/), [RADIUS](https://startwithidentity.com/standards/radius/). Glossary: [Kerberos](https://startwithidentity.com/glossary/kerberos/), [NTLM](https://startwithidentity.com/glossary/ntlm/), [Active Directory](https://startwithidentity.com/glossary/active-directory/). Guides: [what is ITDR](https://startwithidentity.com/guides/fundamentals/what-is-itdr/), [identity threat detection and response](https://startwithidentity.com/guides/security/identity-threat-detection-response-guide/).

## LDAP (Lightweight Directory Access Protocol)
Source: https://startwithidentity.com/standards/ldap/
Last updated: 2026-11-05

## What it is

LDAP (Lightweight Directory Access Protocol) is the IETF protocol for talking to a **directory**: a tree of entries for people, groups, computers and services, each with attributes. Version 3 is specified as a set of RFCs published in June 2006, listed in the [RFC 4510 road map](https://www.rfc-editor.org/rfc/rfc4510): the protocol itself in [RFC 4511](https://www.rfc-editor.org/rfc/rfc4511), authentication and security in [RFC 4513](https://www.rfc-editor.org/rfc/rfc4513), string forms of names in RFC 4514, search filters in [RFC 4515](https://www.rfc-editor.org/rfc/rfc4515), URLs in RFC 4516, and syntaxes and schema in RFC 4517 to RFC 4519.

LDAP sits under most enterprise identity even when nobody calls it by name. Active Directory domain controllers answer LDAP, open-source directories such as OpenLDAP and 389 Directory Server are LDAP servers, and identity platforms import users from LDAP: [Keycloak](https://startwithidentity.com/vendors/open-source/keycloak/) documents user federation from LDAP and Active Directory, [FreeIPA](https://startwithidentity.com/vendors/open-source/freeipa/) is built on 389 Directory Server with MIT Kerberos, and [JumpCloud](https://startwithidentity.com/vendors/iam/jumpcloud/) sells a cloud LDAP service (each checked on the vendor's site on 5 November 2026).

## Status (November 2026)

| Item | Status |
| --- | --- |
| RFC 4511, LDAP: The Protocol | Proposed Standard, June 2006; obsoletes RFC 2251, RFC 2830 and RFC 3771; no later RFC updates it |
| RFC 4513, Authentication Methods and Security Mechanisms | Proposed Standard, June 2006 |
| Ports | 389/tcp `ldap` and 636/tcp `ldaps` in the [IANA registry](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml); RFC 4511 §5.2 names 389 |

LDAPv3 is stable: there is no LDAPv4 effort, and changes arrive as controls, extended operations and schema. The editor of RFC 4511 was J. Sermersheim (Novell); RFC 4513 was edited by R. Harrison (Novell).

## How it works

Every entry has a **distinguished name** (DN) such as `uid=ada,ou=people,dc=example,dc=com`, read right to left from the root. A client opens a TCP connection, optionally upgrades it to TLS, **binds** (authenticates), then sends operations: Search, Compare, Add, Modify, Delete, Modify DN, and Extended operations. Each request and response is an `LDAPMessage` with a `messageID`, encoded in ASN.1 BER ([RFC 4511 §4.1.1, §5.1](https://www.rfc-editor.org/rfc/rfc4511#section-4.1.1)). Requests can be pipelined; the `messageID` ties responses back to them.

The two operations that matter for identity:

- **Bind** ([§4.2](https://www.rfc-editor.org/rfc/rfc4511#section-4.2)): a DN plus password ("simple"), or a SASL mechanism such as `GSSAPI` (Kerberos) or `EXTERNAL` (the TLS client certificate). The result code says whether it worked: `0` success, `49` invalidCredentials.
- **Search** ([§4.5](https://www.rfc-editor.org/rfc/rfc4511#section-4.5)): a base DN, a scope (base, one level, whole subtree), a filter such as `(&(objectClass=person)(mail=ada@example.com))`, and the attributes to return. Applications use it to find a user's DN and group memberships.

The classic application pattern is "search then bind": a service account binds, searches for the user's DN by username, then binds again as that DN with the password the user typed. The full message sequence, with each field annotated, is in [how LDAP works, message by message](https://startwithidentity.com/guides/protocols/ldap-message-flow/).

## Security model

LDAP leaves almost all security to configuration. The three settings that decide whether a deployment is safe:

1. **Confidentiality before credentials.** A simple bind carries the password as an OCTET STRING, and RFC 4513 §5.1.3 says plainly that it "is not suitable for authentication in environments without confidentiality protection." Use StartTLS ([RFC 4511 §4.14](https://www.rfc-editor.org/rfc/rfc4511#section-4.14), [RFC 4513 §3](https://www.rfc-editor.org/rfc/rfc4513#section-3)) or LDAPS, and verify the server certificate per RFC 4513 §3.1.3. Servers can refuse with `confidentialityRequired` (13) or `strongerAuthRequired` (8).
2. **No unauthenticated binds.** A bind with a DN and an empty password produces an anonymous session, and the DN must not be treated as authenticated ([RFC 4513 §5.1.2](https://www.rfc-editor.org/rfc/rfc4513#section-5.1.2)). Servers SHOULD reject these by default with `unwillingToPerform` (53); clients SHOULD refuse empty passwords. Applications that treat "bind succeeded" as "password correct" are exactly the misuse RFC 4513 §6.3.1 describes.
3. **Escape filter input.** Filters built by string concatenation are injectable. RFC 4515 §3 requires `*`, `(`, `)`, `\` and NUL to be escaped as a backslash and two hex digits.

Access control inside the directory (who may read `userPassword`, who may write group membership) is not standardized by the LDAPv3 RFCs; every server has its own ACL model, and misconfigured ACLs are a recurring source of privilege escalation.

## Where LDAP breaks in practice

From the SWI [identity CVE catalog](https://startwithidentity.com/cves/):

- **Client and server parsing bugs on domain controllers.** [CVE-2024-49113](https://startwithidentity.com/cves/cve-2024-49113/) (LDAPNightmare) crashes the Windows LDAP client with a crafted response, and its critical sibling [CVE-2024-49112](https://startwithidentity.com/cves/cve-2024-49112/) is remote code execution class.
- **Directory ACLs that let the wrong client write.** [CVE-2026-76578](https://startwithidentity.com/cves/cve-2026-76578/): a FreeIPA ACI let an anonymous LDAP client create an entry that ended up as an attacker-owned Kerberos principal in the admins group.
- **LDAP-backed login in other products.** HashiCorp Vault's LDAP auth method leaked user existence through error differences ([CVE-2023-3462](https://startwithidentity.com/cves/cve-2023-3462/)) and let case permutations reset lockout ([CVE-2025-6004](https://startwithidentity.com/cves/cve-2025-6004/)), which turns LDAP into a [password spraying](https://startwithidentity.com/techniques/password-spraying/) target.

Directories are also the reconnaissance source for most Active Directory attacks: [Kerberoasting](https://startwithidentity.com/techniques/kerberoasting/) starts with an LDAP search for accounts that have a `servicePrincipalName`.

## When to use it

Use LDAP to **read and manage directory data**: provisioning and sync, group lookups, Linux and network device integration, and applications that genuinely cannot speak anything newer. Do not make it the login protocol for new web applications. Binding with the user's password means your application sees and handles that password, cannot participate in MFA or phishing-resistant authentication, and has to manage directory credentials. Use [SAML 2.0](https://startwithidentity.com/standards/saml-2-0/) or [OpenID Connect](https://startwithidentity.com/standards/openid-connect/) for web sign-on and [SCIM 2.0](https://startwithidentity.com/standards/scim-2-0/) for pushing users into SaaS applications. For Windows and Unix single sign-on on a network, LDAP works alongside [Kerberos](https://startwithidentity.com/standards/kerberos/), which carries the actual authentication.

## Pitfalls

- Binding in cleartext on 389 "just inside the network", or skipping certificate verification on 636.
- Accepting an empty password as a successful login (unauthenticated bind).
- Service accounts with domain-wide read and a password that never rotates.
- Unescaped filter input, and searches with no size or time limits.
- Treating `mail` or `uid` as a permanent identifier; use the server's stable entry identifier (for example `entryUUID` in RFC 4530, or `objectGUID` in Active Directory).

## How it works, message by message

The [LDAP message-flow walkthrough](https://startwithidentity.com/guides/protocols/ldap-message-flow/) decodes the search-then-bind login used by most applications: StartTLS, the service-account bind, the user search, the user bind and its result codes, with every `LDAPMessage` field tied to RFC 4511 or RFC 4513 and eight checks an LDAP-authenticating application must run.

## Related

Walkthrough: [how LDAP works, message by message](https://startwithidentity.com/guides/protocols/ldap-message-flow/). Standards: [Kerberos](https://startwithidentity.com/standards/kerberos/), [RADIUS](https://startwithidentity.com/standards/radius/), [SCIM 2.0](https://startwithidentity.com/standards/scim-2-0/). Glossary: [LDAP](https://startwithidentity.com/glossary/ldap/), [directory service](https://startwithidentity.com/glossary/directory-service/), [Active Directory](https://startwithidentity.com/glossary/active-directory/). Guides: [what is ITDR](https://startwithidentity.com/guides/fundamentals/what-is-itdr/), for detecting directory reconnaissance and abuse.

## MCP Authorization
Source: https://startwithidentity.com/standards/mcp-authorization/
Last updated: 2026-11-05

## What it is

MCP authorization is the part of the [Model Context Protocol](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization) that says how an AI client (an agent, IDE or chat app) gets permission to call a remote MCP server on a user's behalf. The answer is plain OAuth, profiled tightly: the **MCP server** is an OAuth 2.1 resource server, the **MCP client** is an OAuth 2.1 client, and a separate **authorization server** issues tokens. The specification picks "a selected subset" of existing standards rather than inventing new ones.

That choice matters for practitioners. Securing MCP is mostly about running OAuth correctly, and the [MCP authorization glossary entry](https://startwithidentity.com/glossary/mcp-authorization/) gives the one-paragraph version. This page covers what the current revision requires and what it leaves to you.

## Status (November 2026)

The current MCP protocol version is **2026-07-28**, per the [MCP versioning page](https://modelcontextprotocol.io/specification/versioning) read on 5 November 2026. Earlier revisions are 2025-11-25, 2025-06-18, 2025-03-26 and 2024-11-05. MCP is hosted by the Linux Foundation's Agentic AI Foundation, to which Anthropic [donated it](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation) in December 2025. "Stable" here means a released protocol revision, not an IETF or OpenID standard.

The revision depends on two moving IETF drafts. It cites **OAuth 2.1 draft-13**, while the draft has reached [-17](https://startwithidentity.com/standards/oauth-2-1/) (31 October 2026). It makes **Client ID Metadata Documents** the preferred registration method and cites revision -00, while the [OAuth working-group draft](https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/) is at -03 (2 November 2026, WG Document). Everything else it relies on is a published RFC.

Two authorization extensions are stable for 2026-07-28, in the [ext-auth repository](https://github.com/modelcontextprotocol/ext-auth): **OAuth Client Credentials** (agents acting as themselves) and **Enterprise-Managed Authorization** (ID-JAG). The DPoP profile, [SEP-1932](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1932), is open.

## How it works

A concrete flow, a coding agent connecting to `https://mcp.example.com/mcp` for the first time:

1. **Challenge.** The client sends an MCP request without a token. The server answers `401` with `WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource", scope="files:read"`.
2. **Resource metadata ([RFC 9728](https://www.rfc-editor.org/rfc/rfc9728.html)).** The client fetches that document, which names one or more authorization servers. Servers must implement RFC 9728; if the header is missing, clients probe the well-known path for the MCP endpoint and then the root.
3. **Authorization server metadata.** The client tries RFC 8414 and OpenID Connect discovery URLs in a set order, and must reject a document whose `issuer` does not match the URL it constructed.
4. **Registration.** Clients use this priority: a pre-registered client ID if one exists; a **Client ID Metadata Document** if the server sets `client_id_metadata_document_supported: true`; Dynamic Client Registration ([RFC 7591](https://www.rfc-editor.org/rfc/rfc7591.html)) as a deprecated fallback; finally, asking the user. With CIMD, the `client_id` is an HTTPS URL with a path (for example `https://app.example.com/oauth/client-metadata.json`) and the server fetches it to check `client_name` and `redirect_uris`.
5. **Authorization request.** The client opens the browser with an authorization code request carrying a [PKCE](https://startwithidentity.com/glossary/pkce/) challenge, the scope from the challenge, and `resource=https://mcp.example.com/mcp`. [RFC 8707 resource indicators](https://startwithidentity.com/glossary/resource-indicators/) are mandatory in both the authorization and the token request, and the client must send them even if the server ignores them.
6. **Issuer check.** On the redirect, the client compares the `iss` parameter with the issuer it recorded ([RFC 9207](https://www.rfc-editor.org/rfc/rfc9207.html)) before sending the code anywhere, which blocks mix-up attacks.
7. **Token and calls.** The client redeems the code with the PKCE verifier and `resource`, then sends `Authorization: Bearer` on every HTTP request.
8. **Step-up.** If a later tool call needs more, the server returns `403` with `error="insufficient_scope"` and the full set of required scopes. The client re-authorizes with the union of old and new scopes.

The server-side rules are short and strict: validate every token, accept only tokens issued for this server as audience, and **never pass a received token through** to an upstream API. If the MCP server calls another API, it is an OAuth client there and gets its own token.

## Enterprise-managed authorization

The per-server consent flow above works for individuals and breaks down in companies, where an employee might connect an agent to dozens of MCP servers and each grant is invisible to IT. The [Enterprise-Managed Authorization extension](https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/stable/enterprise-managed-authorization/2026-07-28/enterprise-managed-authorization.mdx) replaces it with [ID-JAG](https://startwithidentity.com/standards/id-jag-cross-app-access/): the client signs the user in through the corporate IdP, exchanges the ID token at the IdP for an ID-JAG whose audience is the MCP server's authorization server, and redeems that for an access token. The IdP evaluates admin policy at the exchange, so the enterprise decides which clients may reach which MCP servers.

## What it solves for AI agents and SaaS

For SaaS vendors exposing an MCP server, the profile gives a known shape for security review: an OAuth resource server with audience-bound tokens, discoverable metadata and per-operation scopes. For agent builders, it removes the worst early practices: API keys pasted into config files, tokens valid at any server, and proxies that forward a user's token upstream. SWI's [Agent Identity Standards Map 2026](https://startwithidentity.com/reports/agent-identity-standards-map-2026/) scores token audience binding and client registration at 5 of 5, largely because MCP requires them.

What it leaves open: tokens are bearer tokens held by a process that reads untrusted input, so a [prompt-injected](https://startwithidentity.com/techniques/agent-instruction-injection/) agent can be steered into misusing a valid token. Scopes are coarse, so per-call limits need a policy engine such as [AuthZEN](https://startwithidentity.com/standards/authzen/). Revocation mid-task needs short lifetimes and [Shared Signals](https://startwithidentity.com/standards/shared-signals-framework/).

## Adoption signals (verified)

- **Official MCP TypeScript SDK.** The [client auth module](https://github.com/modelcontextprotocol/typescript-sdk/blob/main/packages/client/src/client/auth.ts) checks `client_id_metadata_document_supported`, and the [auth extensions module](https://github.com/modelcontextprotocol/typescript-sdk/blob/main/packages/client/src/client/authExtensions.ts) implements the ID-JAG exchange, checked 5 November 2026.
- **Okta Agent SSO**, generally available since 24 August 2026, [describes](https://www.okta.com/newsroom/press-releases/okta-brings-first-class-identity-to-ai-agents-with-agent-sso/) connecting Cross App Access agents to enterprise applications "and MCP servers".

## How to implement or evaluate

- **Building an MCP server:** publish RFC 9728 metadata, return precise `scope` in challenges, validate `aud` against your canonical URI, reject everything else, and keep `offline_access` out of your advertised scopes.
- **Running the authorization server:** support CIMD with a domain trust policy, PKCE with S256, the `iss` response parameter, short access-token lifetimes, and refresh-token rotation for public clients. Consider [DPoP](https://startwithidentity.com/glossary/dpop/) where clients support it.
- **Deploying in an enterprise:** prefer pre-registration or Enterprise-Managed Authorization over open registration, and inventory which agents hold refresh tokens for which servers.
- **Reviewing a vendor:** ask which MCP revision they implement, whether they still rely on DCR, and whether their server forwards tokens upstream.

## Pitfalls

- **Token passthrough.** Forbidden by the spec and still common in quick proxies.
- **Trusting the `resource` parameter alone.** If the authorization server ignores RFC 8707, the token may lack a narrow audience. Servers must still check it.
- **Localhost redirect URIs in CIMD.** The security considerations warn about localhost redirect risks; restrict which domains' metadata documents you accept.

## Related

[ID-JAG and Cross App Access](https://startwithidentity.com/standards/id-jag-cross-app-access/), [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/), [OAuth Transaction Tokens](https://startwithidentity.com/standards/oauth-transaction-tokens/), [AuthZEN](https://startwithidentity.com/standards/authzen/), the [securing AI agent identities](https://startwithidentity.com/guides/machine-identity/securing-ai-agent-identities/) guide and the [AI agent identity tools ranking](https://startwithidentity.com/rankings/best-ai-agent-identity-tools/). Glossary: [Client ID Metadata Document](https://startwithidentity.com/glossary/client-id-metadata-document/), [protected resource metadata](https://startwithidentity.com/glossary/protected-resource-metadata/), [dynamic client registration](https://startwithidentity.com/glossary/dynamic-client-registration/), [agent registry](https://startwithidentity.com/glossary/agent-registry/), [credential brokering](https://startwithidentity.com/glossary/credential-brokering/).

## OAuth 2.0
Source: https://startwithidentity.com/standards/oauth-2-0/
Last updated: 2026-11-05

## What it is

OAuth 2.0 ([RFC 6749](https://www.rfc-editor.org/rfc/rfc6749.html)) is the [authorization](https://startwithidentity.com/glossary/authorization/) framework behind "Connect your account" buttons, API access for third-party apps, and most machine-to-machine API calls. It lets a user grant an application limited, scoped access to their resources at another service without sharing a password. OAuth is about [authorization](https://startwithidentity.com/guides/fundamentals/authentication-vs-authorization/), not authentication: it answers "what may this app do," not "who is this user." Using an access token as proof of login is the classic OAuth mistake, which is what [OpenID Connect](https://startwithidentity.com/standards/openid-connect/) exists to fix.

RFC 6749 was published in October 2012, edited by Dick Hardt, and obsoleted OAuth 1.0 (RFC 5849). Its companion [RFC 6750](https://www.rfc-editor.org/rfc/rfc6750.html) defines how [bearer tokens](https://startwithidentity.com/glossary/bearer-token/) are sent to APIs.

## Status (November 2026)

| Document | What it is | Status |
| --- | --- | --- |
| RFC 6749 | The framework: roles, grants, endpoints | Proposed Standard (October 2012) |
| RFC 6750 | Bearer token usage | Proposed Standard |
| [RFC 9700](https://www.rfc-editor.org/rfc/rfc9700.html) | OAuth 2.0 Security Best Current Practice, BCP 240 | Published January 2025; updates RFC 6749, 6750 and 6819 |
| [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/) | Consolidation into one document | IETF draft -17 (31 October 2026) |

The [datatracker record for RFC 6749](https://datatracker.ietf.org/doc/rfc6749/) lists three updating documents: RFC 8252 (native apps), RFC 8996 (deprecating TLS 1.0 and 1.1) and RFC 9700. In practice "OAuth 2.0" in 2026 means RFC 6749 as amended by RFC 9700. The 2012 text alone still permits patterns the working group now forbids.

## The four roles and four grants

RFC 6749 defines four roles: the **resource owner** (usually the user), the **client** (the app), the **authorization server** (issues tokens) and the **resource server** (the API). It defines four grants:

| Grant | Use in 2026 |
| --- | --- |
| Authorization code | The default for anything with a user, always with [PKCE](https://startwithidentity.com/glossary/pkce/) |
| Client credentials | Machine-to-machine, where the client acts as itself ([client credentials](https://startwithidentity.com/glossary/client-credentials/)) |
| Implicit | Do not use. RFC 9700 says clients should not use it; OAuth 2.1 removes it |
| Resource owner password credentials | Do not use. RFC 9700: it "MUST NOT be used" |

Later RFCs add grants: the [device authorization grant](https://startwithidentity.com/glossary/device-code-flow/) (RFC 8628) for TVs and CLIs, [token exchange](https://startwithidentity.com/glossary/token-exchange/) (RFC 8693), and JWT bearer assertions (RFC 7523).

## How the authorization code flow works

Section 4.1 of RFC 6749, with the PKCE and RFC 9700 requirements folded in:

1. The client creates a random `code_verifier` and derives `code_challenge` with `S256`.
2. The client redirects the user's browser to the authorization endpoint with `response_type=code`, `client_id`, `redirect_uri`, `scope`, `state` and `code_challenge`.
3. The authorization server authenticates the user and asks for consent to the requested [scopes](https://startwithidentity.com/glossary/scope/).
4. The server redirects back to the exactly registered `redirect_uri` with an authorization code and `state` (and, per RFC 9207, an `iss` parameter that defends against mix-up attacks).
5. The client checks `state` (and `iss`), then sends the code and `code_verifier` to the token endpoint, authenticating itself if confidential.
6. The server verifies the code, the client and the PKCE verifier, then returns an [access token](https://startwithidentity.com/glossary/access-token/) and optionally a [refresh token](https://startwithidentity.com/glossary/refresh-token/).
7. The client calls the API with `Authorization: Bearer <token>`. The resource server validates the token locally (a JWT access token per RFC 9068) or via [introspection](https://startwithidentity.com/glossary/token-introspection/) (RFC 7662).

## What RFC 9700 changed

RFC 9700, by Torsten Lodderstedt, John Bradley, Andrey Labunets and Daniel Fett, is the most important OAuth document since 2012. Its section 2 summary, in short:

- **Exact string matching** of redirect URIs is a MUST, with one exception for the port of native-app `localhost` URIs.
- **PKCE** is a MUST for public clients and RECOMMENDED for confidential clients. Authorization servers must support it and must prevent PKCE downgrade. Only `S256` qualifies as a method that does not expose the verifier.
- **No open redirectors**, at the client or the authorization server.
- **CSRF protection** is a MUST, via PKCE, or `state` / `nonce` where PKCE is not supported.
- **Mix-up defense** is a MUST for clients that talk to more than one authorization server.
- **Sender-constrained access tokens** SHOULD be used, via [mutual TLS](https://startwithidentity.com/glossary/mtls/) (RFC 8705) or [DPoP](https://startwithidentity.com/glossary/dpop/) (RFC 9449). Public-client refresh tokens MUST be sender-constrained or rotated.
- **Least privilege and audience restriction** for access tokens, for example with [resource indicators](https://startwithidentity.com/glossary/resource-indicators/) (RFC 8707).
- **Asymmetric client authentication** (such as `private_key_jwt` or mTLS) is RECOMMENDED, and authorization server metadata (RFC 8414) publication is RECOMMENDED.

## Common implementation mistakes and attacks

RFC 9700 section 4 catalogs 17 attack classes. The ones that recur in our breach and CVE catalogs:

| Attack | Mechanism | In our catalog |
| --- | --- | --- |
| Stolen token replay | Bearer tokens work for whoever holds them | Stolen OAuth tokens for [Heroku and Travis CI](https://startwithidentity.com/breaches/incidents/2022-github-heroku-travis-oauth-tokens/) (2022), [Salesloft Drift](https://startwithidentity.com/breaches/incidents/2025-salesloft-drift-oauth-token-theft/) (2025) and [Gainsight](https://startwithidentity.com/breaches/incidents/2025-gainsight-salesforce-token-abuse/) apps; technique [refresh token abuse](https://startwithidentity.com/techniques/refresh-token-abuse/) |
| Consent phishing | User is tricked into granting a malicious app real scopes | [Cyberhaven Chrome extension](https://startwithidentity.com/breaches/incidents/2024-cyberhaven-chrome-extension-oauth-consent-phishing/); technique [OAuth consent phishing](https://startwithidentity.com/techniques/oauth-consent-phishing/) |
| Device code phishing | Attacker starts a device flow and sends the user the code | Technique [device code phishing](https://startwithidentity.com/techniques/device-code-phishing/) |
| Assertion audience ambiguity | A `private_key_jwt` assertion is accepted by the wrong server | [CVE-2025-27371](https://startwithidentity.com/cves/cve-2025-27371/) |
| Token mix-ups in client libraries | Tokens for one user or resource returned for another | [CVE-2025-26620](https://startwithidentity.com/cves/cve-2025-26620/) (Duende) |
| Authorization server policy bugs | Scope or client policy not enforced | [CVE-2025-14778](https://startwithidentity.com/cves/cve-2025-14778/) and [CVE-2026-18207](https://startwithidentity.com/cves/cve-2026-18207/) (Keycloak), [CVE-2025-12466](https://startwithidentity.com/cves/cve-2025-12466/) (Drupal Simple OAuth) |
| Proxy route matching | Unauthenticated paths match more than intended | [CVE-2025-54576](https://startwithidentity.com/cves/cve-2025-54576/) (OAuth2-Proxy) |
| Scope creep in delegation | Downstream calls get more authority than the user granted | Technique [scope escalation through delegation](https://startwithidentity.com/techniques/scope-escalation-delegation/) |

The common thread in the breach rows is that the attackers held valid tokens. Nothing in the protocol failed: a bearer token works for whoever presents it. Sender-constraining, short lifetimes, narrow scopes, rotation and per-app monitoring are the controls that limit what a stolen token is worth.

## Related standards

[OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/) (consolidation), [OpenID Connect](https://startwithidentity.com/standards/openid-connect/) (authentication), [FAPI 2.0](https://startwithidentity.com/standards/fapi/) (high-security profile), [MCP authorization](https://startwithidentity.com/standards/mcp-authorization/) (OAuth for AI agents), [OAuth Transaction Tokens](https://startwithidentity.com/standards/oauth-transaction-tokens/) (internal call chains), [ID-JAG](https://startwithidentity.com/standards/id-jag-cross-app-access/) (enterprise-brokered cross-app access) and [WIMSE](https://startwithidentity.com/standards/wimse/) (workload-to-workload authentication). Glossary: [PAR](https://startwithidentity.com/glossary/par/) (RFC 9126), [rich authorization requests](https://startwithidentity.com/glossary/rich-authorization-requests/) (RFC 9396), [protected resource metadata](https://startwithidentity.com/glossary/protected-resource-metadata/) (RFC 9728), [dynamic client registration](https://startwithidentity.com/glossary/dynamic-client-registration/) (RFC 7591).

## Who implements it

Every OpenID Provider is also an OAuth 2.0 authorization server, so the OpenID Foundation's [certified implementations list](https://openid.net/developers/certified-openid-connect-implementations/) is a reasonable starting point; see [OpenID Connect](https://startwithidentity.com/standards/openid-connect/) for the names we checked. Authorization servers come from workforce IAM ([IAM vendors](https://startwithidentity.com/vendors/iam/)), CIAM platforms ([CIAM vendors](https://startwithidentity.com/vendors/ciam/)) and open source projects such as [Keycloak](https://startwithidentity.com/vendors/open-source/keycloak/) and [ZITADEL](https://startwithidentity.com/vendors/open-source/zitadel/). When evaluating one, ask specifically about PKCE enforcement for every client type, exact redirect matching, DPoP or mTLS token binding, refresh token rotation with reuse detection, and RFC 9207 `iss` in responses.

## How to check an implementation

1. Request `response_type=token`. The server should refuse it for new clients.
2. Send a code request without `code_challenge` from a public client. It must fail.
3. Register `https://app.example.com/cb` and request `https://app.example.com/cb/x`. Rejected.
4. Redeem the same authorization code twice. The second attempt fails, and ideally revokes tokens issued from the first.
5. Replay a rotated refresh token. It fails and revokes the token family.
6. Send a token in `?access_token=` to your API. Refuse it.

## How it works, message by message

The [OAuth message-flow walkthrough](https://startwithidentity.com/guides/protocols/oauth-message-flow/) annotates every request and response: authorization, code exchange, client credentials, refresh with rotation, the API call, JWT access token validation under RFC 9068, introspection and DPoP proofs, with the OAuth 2.0 and OAuth 2.1 section numbers side by side.

## Related

Glossary: [OAuth](https://startwithidentity.com/glossary/oauth/), [authorization server](https://startwithidentity.com/glossary/authorization-server/), [scopes and claims](https://startwithidentity.com/glossary/claims/), [token theft](https://startwithidentity.com/glossary/token-theft/). Guides: [OAuth vs OIDC](https://startwithidentity.com/guides/fundamentals/oauth-vs-oidc/) and the [implementation guide](https://startwithidentity.com/guides/implementation/oauth-2-openid-connect-implementation/).

## Who wrote it

RFC 6749 was edited by [Dick Hardt](https://startwithidentity.com/experts/dick-hardt/). The security guidance that hardened it since is largely the work of [Torsten Lodderstedt](https://startwithidentity.com/experts/torsten-lodderstedt/) and [Daniel Fett](https://startwithidentity.com/experts/daniel-fett/), and [Aaron Parecki](https://startwithidentity.com/experts/aaron-parecki/) maintains the documentation most developers learn it from. [Hannes Tschofenig](https://startwithidentity.com/experts/hannes-tschofenig/) co-chaired the IETF working group that produced it. More in the [experts directory](https://startwithidentity.com/experts/).

## OAuth 2.1
Source: https://startwithidentity.com/standards/oauth-2-1/
Last updated: 2026-11-05

## What it is

OAuth 2.1 is not a new protocol but a cleanup: it folds [OAuth 2.0](https://startwithidentity.com/standards/oauth-2-0/), PKCE, and the OAuth Security Best Current Practice into one document and removes the parts that proved unsafe. The goal is that a developer who follows OAuth 2.1 gets a secure result by default, without having to read a dozen RFCs and errata.

## What changes from OAuth 2.0

- **PKCE is required** for all authorization code flows, not just public clients.
- **The implicit grant is removed.** Tokens are no longer returned in the front channel.
- **The resource owner password credentials grant is removed.**
- **Exact redirect URI matching** is mandated.
- **Refresh token handling is tightened**, with rotation or sender-constraining for public clients.

The full list, from section 10 of [draft-17](https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/), adds five changes that catch implementers out:

- **No bearer tokens in query strings.** Only the `Authorization` header (or form body) is allowed, following [RFC 9700](https://www.rfc-editor.org/rfc/rfc9700.html) section 4.3.2.
- **The PKCE `plain` method is removed.** Only `S256` remains in practice.
- **The token request no longer carries `redirect_uri`.** PKCE does the job the parameter was meant to do.
- **Authorization servers must accept client credentials in the request body**, not only via HTTP Basic.
- **Browser-based apps** get additional refresh token lifetime limits from [RFC 10017](https://www.rfc-editor.org/rfc/rfc10017.html), OAuth 2.0 for Browser-Based Applications, published as a Best Current Practice in August 2026.

The draft is explicit about compatibility: an OAuth 2.0 client that skips PKCE, relies on redirect URI pattern matching, or uses the implicit or password grants "will not interoperate" with an authorization server that enforces OAuth 2.1 for that client.

## What it consolidates

Draft-17 lists the documents it folds in: [OAuth 2.0 (RFC 6749)](https://startwithidentity.com/standards/oauth-2-0/), Bearer Token Usage (RFC 6750), OAuth 2.0 for Native Apps (RFC 8252), PKCE (RFC 7636), the OAuth 2.0 Security Best Current Practice (RFC 9700, January 2025) and OAuth 2.0 for Browser-Based Applications (RFC 10017). If approved it obsoletes RFC 6749 and RFC 6750. Extensions such as [token exchange](https://startwithidentity.com/glossary/token-exchange/), [DPoP](https://startwithidentity.com/glossary/dpop/), [PAR](https://startwithidentity.com/glossary/par/) and [resource indicators](https://startwithidentity.com/glossary/resource-indicators/) stay separate RFCs that OAuth 2.1 deployments add as needed.

## How it works

The model is the same as OAuth 2.0: clients obtain scoped access tokens from an authorization server. In practice OAuth 2.1 means: use the [authorization code flow](https://startwithidentity.com/glossary/authorization-code-flow/) with [PKCE](https://startwithidentity.com/glossary/pkce/) for anything with a user, the [client credentials grant](https://startwithidentity.com/glossary/client-credentials/) for machine-to-machine, and the [device authorization grant](https://startwithidentity.com/glossary/device-code-flow/) for input-constrained devices.

## Status

OAuth 2.1 is an active IETF draft. Revision -17 is dated 31 October 2026, and its datatracker state, read 5 November 2026, is **WG Document** in the OAuth Working Group: adopted, not yet through working-group last call. The [OAuth WG milestones](https://datatracker.ietf.org/wg/oauth/about/) list "Submit OAuth 2.1 Authorization Framework to IESG" for December 2026. The editors are Dick Hardt (Hellō), Aaron Parecki ([Okta](https://startwithidentity.com/vendors/iam/okta/)) and Torsten Lodderstedt (SPRIND).

Most modern identity platforms already implement its recommendations, so adopting it today is mostly about avoiding the removed flows rather than waiting for a final RFC.

## Why it matters for AI agents

The [Model Context Protocol](https://startwithidentity.com/standards/mcp-authorization/) requires its authorization servers to "implement OAuth 2.1", and its revision 2026-07-28 cites draft-13 of this document while the draft itself has moved to -17. In practice that makes OAuth 2.1 the baseline for every remote MCP server: authorization code with PKCE for agents acting for a user, client credentials for agents acting as themselves, and short-lived tokens with rotated refresh tokens for public clients such as desktop agents and IDE plugins. SWI's [Agent Identity Standards Map 2026](https://startwithidentity.com/reports/agent-identity-standards-map-2026/) tracks the draft as one of two moving dependencies under MCP. The OAuth 2.1 rules are necessary but not sufficient for agents; the [securing AI agent identities](https://startwithidentity.com/guides/machine-identity/securing-ai-agent-identities/) guide covers audience binding, delegation and revocation on top.

## How to check an implementation

1. Send an authorization request with `response_type=token`. An OAuth 2.1 server rejects it.
2. Send a code request without `code_challenge`. It should fail for every client type.
3. Register `https://app.example.com/callback` and request `https://app.example.com/callback/extra`. Exact matching rejects it.
4. Send an access token as `?access_token=` in a resource request. It should be refused.
5. For a public client, redeem a refresh token twice. Rotation means the second attempt fails, and ideally revokes the token family.

## Pitfalls

- Legacy apps using the implicit or password grants need migration before they can claim OAuth 2.1 compliance.
- "OAuth 2.1 support" from a vendor usually means PKCE-by-default and dropped legacy grants; confirm the specifics.

## How it works, message by message

The [OAuth message-flow walkthrough](https://startwithidentity.com/guides/protocols/oauth-message-flow/) shows each OAuth 2.1 message next to its OAuth 2.0 equivalent, with section numbers from draft-17, so you can see exactly where PKCE, exact redirect matching, the removed grants and the dropped `redirect_uri` in the code exchange change the wire format.

## Related

[OAuth 2.0](https://startwithidentity.com/standards/oauth-2-0/), [OpenID Connect](https://startwithidentity.com/standards/openid-connect/), [MCP authorization](https://startwithidentity.com/standards/mcp-authorization/), [ID-JAG and Cross App Access](https://startwithidentity.com/standards/id-jag-cross-app-access/), and the guide [OAuth vs OIDC](https://startwithidentity.com/guides/fundamentals/oauth-vs-oidc/). Glossary: [PKCE](https://startwithidentity.com/glossary/pkce/), [refresh token](https://startwithidentity.com/glossary/refresh-token/), [bearer token](https://startwithidentity.com/glossary/bearer-token/).

## Who wrote it

The consolidation is co-edited by [Aaron Parecki](https://startwithidentity.com/experts/aaron-parecki/), and it folds in the OAuth 2.0 Security Best Current Practice edited by [Torsten Lodderstedt](https://startwithidentity.com/experts/torsten-lodderstedt/) with [Daniel Fett](https://startwithidentity.com/experts/daniel-fett/). More in the [experts directory](https://startwithidentity.com/experts/).

## OAuth Transaction Tokens (Txn-Tokens)
Source: https://startwithidentity.com/standards/oauth-transaction-tokens/
Last updated: 2026-11-05

## What it is

Transaction Tokens (Txn-Tokens) are short-lived, signed JWTs that "maintain and propagate user identity, workload identity and authorization context throughout the Call Chain within a trusted domain", in the words of the [IETF draft](https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/). A Transaction Token Service (TTS) mints one when a request enters the domain, typically at an API gateway, and every internal service that handles the request verifies it rather than receiving the caller's original access token.

The problem is the internal call chain. An external request arrives with an OAuth access token and then touches five, ten or fifty microservices. Most architectures either forward the external token downstream (any service that logs or leaks it hands an attacker a replayable credential with the full external scope) or drop it and rely on network location (no service past the gateway knows which user the work is for). Txn-Tokens replace both with a token scoped to one transaction, lasting minutes. The [glossary entry](https://startwithidentity.com/glossary/transaction-tokens/) has the one-paragraph version.

## Status (November 2026)

The latest revision is draft-11, dated 30 July 2026, read from the IETF datatracker on 5 November 2026. Its working-group state is **WG Consensus: Waiting for Write-Up**: the OAuth Working Group agrees on the text and the shepherd write-up is pending before it goes to the IESG. The [OAuth WG milestones](https://datatracker.ietf.org/wg/oauth/about/) list "Submit Transaction Tokens to the IESG" for December 2026. It is Standards Track, not an RFC. The authors are Atul Tulshibagwale ([CrowdStrike](https://startwithidentity.com/vendors/itdr/crowdstrike-falcon-identity/)), [George Fletcher](https://startwithidentity.com/experts/george-fletcher/) (Practical Identity LLC) and Pieter Kasselman (Defakto Security).

Consensus means the design is unlikely to change shape, but claim details can still move during IESG review. Pin the revision.

## How it works

A concrete flow for an order placed through a public API:

1. **External call.** A client calls `POST /orders` at the gateway with an OAuth access token for the user.
2. **Token request.** The gateway calls the TTS using [token exchange (RFC 8693)](https://startwithidentity.com/glossary/token-exchange/): `grant_type=urn:ietf:params:oauth:grant-type:token-exchange`, `requested_token_type=urn:ietf:params:oauth:token-type:txn_token`, `audience` set to the trust domain name, `scope` set to the narrow purpose (for example `orders.create`), and the external access token as `subject_token`. The gateway authenticates to the TTS as a workload, for example with mutual TLS or a [SPIFFE](https://startwithidentity.com/glossary/spiffe/) credential.
3. **Mint.** The TTS checks the subject token is unexpired and its own issuance policy, then returns a Txn-Token.
4. **Propagate.** The gateway calls the orders service with the Txn-Token in the `Txn-Token` HTTP header. The orders service calls inventory and payments with the same Txn-Token. The draft forbids carrying it in the `Authorization` header, because that header may already hold the caller's workload credential.
5. **Verify at each hop.** Each service checks the signature, that `aud` is its own trust domain, that `exp` has not passed, and that `scope` and the context permit the action it is about to take.

The JWT header must carry `typ` `txntoken+jwt`. Body claims:

| Claim | Requirement | Meaning |
|---|---|---|
| `aud` | Required | The trust domain where the token is valid; must not be accepted elsewhere |
| `iat`, `exp` | Required | Issue and expiry times, expected to be minutes or less |
| `txn` | Required | Unique transaction identifier (as in RFC 8417) |
| `sub` | Required | The principal, unique within the trust domain |
| `scope` | Required | The purpose of this transaction, chosen by the TTS and possibly narrower than the external scope |
| `req_wl` | Required | The workload that requested the token |
| `tctx` | Recommended | Transaction context that stays immutable along the chain, such as an order amount |
| `rctx` | Recommended | Request context such as the original IP address or authentication method |
| `iss` | Optional | Often omitted, because keys are known within one domain |

Two rules in the draft are worth memorizing. A Txn-Token is **not an authentication credential**: a workload must not use it to prove its own identity. And it is **not an access token**: it records the context of one transaction, not a grant to a client. Services still authenticate each other with workload identity ([WIMSE](https://startwithidentity.com/glossary/wimse/), mTLS or SPIFFE) and use the Txn-Token for the authorization decision.

For scheduled or internally started work with no inbound token, the requesting service may present a self-signed JWT as the subject token. That path deserves the strictest TTS policy, since it is where a compromised internal service could mint context for any user.

## What it solves for AI agents and SaaS

For SaaS platforms built from many services, Txn-Tokens give least privilege inside the perimeter. A stolen Txn-Token is valid in one trust domain, for one purpose, for minutes. Signed `tctx` means a downstream service can trust that the order amount it sees is the amount the user submitted, not a value changed by a compromised hop. Every service logs the same `txn`, so incident responders can follow one request end to end.

For AI agents, the internal call chain is the tool chain. An agent platform that receives a user request and calls retrieval, code execution, ticketing and email tools can mint a Txn-Token that names the user, the agent workload in `req_wl` and a narrow purpose, and require every internal tool service to check it. The IETF WIMSE working group's [AIMS draft](https://datatracker.ietf.org/doc/draft-ietf-wimse-aims/) (revision -01, 2 November 2026) lists Transaction Tokens among the existing standards it maps agents onto, and SWI's [Agent Identity Standards Map 2026](https://startwithidentity.com/reports/agent-identity-standards-map-2026/) places them under chained delegation and audit.

Limits: one trust domain only, and the draft does not define how an agent's natural-language task becomes a `scope`. That translation step, where [prompt injection](https://startwithidentity.com/glossary/prompt-injection/) becomes over-broad access, is still undefined by any standard.

## Adoption signals (verified)

We found no vendor documentation, as of 5 November 2026, that announces general availability of a Transaction Token Service built to this draft. The verifiable signals are standards-track: working-group consensus, the December 2026 IESG milestone, and citation in the AIMS draft. Authors from CrowdStrike, Practical Identity and Defakto Security indicate where implementations are likely to appear first, but that is a signal, not a deployment.

## How to implement or evaluate

- **Start at the gateway.** Run the TTS as a small internal service next to your API gateway or service mesh ingress. Only the gateway, and a short allowlist of internal schedulers, should be able to request tokens.
- **Design purposes, not scopes.** Define `scope` values per business transaction (`orders.create`, `refund.issue`), not per API. The draft lets the TTS choose a value narrower than the external scope.
- **Keep lifetimes in minutes.** Long-running jobs should request new tokens per step rather than one long-lived token.
- **Verify everywhere.** A service that does not check the Txn-Token turns the whole design back into network trust. Build verification into a shared middleware.
- **Separate authentication.** Pair Txn-Tokens with workload identity for service-to-service authentication; see [workload identity 101](https://startwithidentity.com/guides/machine-identity/workload-identity-101/).
- **Log `txn`, `sub` and `req_wl`** on every call. That gives you the audit trail agent deployments otherwise lack.

## Pitfalls

- **Treating it as a bearer access token** and accepting it at external APIs. The draft forbids both.
- **A TTS that mints for anyone.** If any workload can request a token for any subject, the TTS becomes a privilege escalation service. Restrict requesters and log issuance.
- **Copying the whole external scope.** That keeps replay value high and defeats the design.

## Related

[WIMSE](https://startwithidentity.com/standards/wimse/) (workload-to-workload authentication; its Workload Proof Token binds a Txn-Token with the `tth` claim), [ID-JAG and Cross App Access](https://startwithidentity.com/standards/id-jag-cross-app-access/), [MCP authorization](https://startwithidentity.com/standards/mcp-authorization/), [Shared Signals Framework](https://startwithidentity.com/standards/shared-signals-framework/), the [securing AI agent identities](https://startwithidentity.com/guides/machine-identity/securing-ai-agent-identities/) guide, and the [Agent Identity Standards Map 2026](https://startwithidentity.com/reports/agent-identity-standards-map-2026/). Glossary: [workload identity](https://startwithidentity.com/glossary/workload-identity/), [delegation chain](https://startwithidentity.com/glossary/delegation-chain/), [identity chaining](https://startwithidentity.com/glossary/identity-chaining/), [access token](https://startwithidentity.com/glossary/access-token/), [token theft](https://startwithidentity.com/glossary/token-theft/).

## Who wrote it

The draft is by [Atul Tulshibagwale](https://startwithidentity.com/experts/atul-tulshibagwale/), [George Fletcher](https://startwithidentity.com/experts/george-fletcher/) and Pieter Kasselman. More in the [experts directory](https://startwithidentity.com/experts/).

## OpenID Connect (OIDC)
Source: https://startwithidentity.com/standards/openid-connect/
Last updated: 2026-11-05

## What it is

OpenID Connect (OIDC) is a thin identity layer built on top of [OAuth 2.0](https://startwithidentity.com/standards/oauth-2-0/). Where OAuth gives an app delegated access, OIDC adds standardized authentication: it tells the app that a user logged in, when, how, and who they are. The core artifact is the **ID token**, a signed [JWT](https://startwithidentity.com/glossary/jwt/) the app validates locally. OIDC is the default protocol for modern [single sign-on](https://startwithidentity.com/glossary/sso/) across consumer apps, mobile, SaaS, and workforce identity providers.

The normative text is [OpenID Connect Core 1.0 incorporating errata set 2](https://openid.net/specs/openid-connect-core-1_0.html), dated 15 December 2023, by Nat Sakimura, John Bradley, Mike Jones, Breno de Medeiros and Chuck Mortimore.

## Status (November 2026)

| Item | Status |
| --- | --- |
| OpenID Connect Core 1.0 | Final, incorporating errata set 2 (15 December 2023) |
| ISO/IEC 26131:2024 | Core published as an ISO/IEC International Standard, October 2024 ([OpenID Foundation](https://openid.net/10-years-on-openidconnect-published-as-iso-spec/)) |
| ITU-T X.1285 | "OpenID Connect Core 1.0 - Errata Set 2", approved 29 May 2025, in force ([ITU](https://www.itu.int/rec/T-REC-X.1285-202505-I/en)) |
| Companion specs | Discovery, Dynamic Client Registration and the logout specs are separate OpenID Foundation documents, several also published as ISO/IEC standards |

The ISO and ITU publications do not change the protocol. They matter for procurement and regulation in jurisdictions that require specifications from treaty-recognized standards bodies, which is the reason the OpenID Foundation gave for pursuing them. The OpenID Foundation's [specifications page](https://openid.net/developers/specs/) is the place to check which companion specs have ISO numbers.

## How it works: the Authorization Code Flow

OIDC Core defines three flows. The Authorization Code Flow (`response_type=code`) is the one to use. Section 3.1 of the spec, in practice:

1. **Discovery.** The client (the "relying party") fetches the provider's metadata from `/.well-known/openid-configuration` to learn the authorization endpoint, token endpoint, userinfo endpoint, supported algorithms and the [JWKS](https://startwithidentity.com/glossary/jwks/) URI.
2. **Authentication request.** The client redirects the browser to the authorization endpoint with `response_type=code`, `scope` containing `openid`, `client_id`, an exactly registered `redirect_uri`, a `state` value, a `nonce`, and a [PKCE](https://startwithidentity.com/glossary/pkce/) `code_challenge`.
3. **User authentication.** The OpenID Provider authenticates the user (password, passkey, federation, whatever its policy demands) and obtains consent if needed.
4. **Callback.** The provider redirects back with a short-lived authorization code and the `state`.
5. **Token request.** The client sends the code and the PKCE `code_verifier` to the token endpoint over TLS, authenticating itself if it is a confidential client.
6. **Tokens returned.** The response carries an **ID token**, an [access token](https://startwithidentity.com/glossary/access-token/), and optionally a [refresh token](https://startwithidentity.com/glossary/refresh-token/).
7. **Validation.** The client validates the ID token (next section) and establishes its own session.
8. **Userinfo (optional).** The client calls the userinfo endpoint with the access token for additional profile claims.

The **Implicit Flow** (`id_token` or `id_token token`) returns tokens directly from the authorization endpoint, and the **Hybrid Flow** (`code id_token`, `code token`, `code id_token token`) returns some tokens there and some from the token endpoint. Both predate PKCE. The [OAuth 2.0 Security BCP (RFC 9700)](https://www.rfc-editor.org/rfc/rfc9700.html) says clients should not use response types that issue access tokens in the authorization response, and [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/) removes the implicit grant.

## The ID token, and how to validate it

Required claims are `iss`, `sub`, `aud`, `exp` and `iat`. `auth_time` is required when `max_age` was requested, `nonce` is required when the request contained one, and `acr`, `amr` and `azp` are optional. The identity key is the pair `iss` plus `sub`, never email, which can change or be reassigned.

Section 3.1.3.7 lists the validation steps. The ones that matter most:

- `iss` must exactly match the issuer identifier from discovery.
- `aud` must contain your `client_id`; reject tokens listing audiences you do not trust.
- Verify the signature with the issuer's keys. The default `alg` is RS256 unless you registered another. A token received directly from the token endpoint over TLS may rely on TLS for issuer authentication, but most libraries verify the signature anyway, and you should too.
- `exp` must be in the future, and `iat` within your acceptable window.
- If you sent a `nonce`, the claim must be present and match.
- Check `acr` and `auth_time` when you asked for a level of assurance or a maximum age.

## Common implementation mistakes and attacks

| Mistake | What goes wrong | Example in our catalog |
| --- | --- | --- |
| Not verifying the signature, or accepting `alg: none` | Anyone can forge an ID token and log in as anyone | [CVE-2026-48558](https://startwithidentity.com/cves/cve-2026-48558/): SimpleHelp accepted unsigned OIDC tokens, skipping MFA; exploited, see [the incident](https://startwithidentity.com/breaches/incidents/2026-simplehelp-oidc-token-forgery/) |
| Accepting algorithms you did not configure | Key confusion lets an attacker sign with a key you never meant to trust | [CVE-2026-5430](https://startwithidentity.com/cves/cve-2026-5430/) (WSO2 API Manager), [CVE-2023-29357](https://startwithidentity.com/cves/cve-2023-29357/) (SharePoint) |
| Loose audience on client assertions | A `private_key_jwt` assertion meant for one server is replayed at another | [CVE-2025-27370](https://startwithidentity.com/cves/cve-2025-27370/), technique [token replay at an unbound endpoint](https://startwithidentity.com/techniques/token-replay-unbound-endpoint/) |
| Trusting tokens across tenants of a multi-tenant IdP | Any tenant's user is accepted | [cross-tenant token confusion](https://startwithidentity.com/techniques/cross-tenant-token-confusion/) |
| Keying accounts on email instead of `iss` + `sub` | Account takeover when a provider lets users set an unverified email | Pattern, not a single CVE |
| Skipping `state`, `nonce` or PKCE | Login CSRF and authorization code injection | RFC 9700 sections 4.5 and 4.7 |
| Using the ID token to call APIs | APIs accept a token whose audience is the client, not the API | Use the access token |

OIDC does not protect a user who completes a real login on a proxy: [adversary-in-the-middle phishing](https://startwithidentity.com/techniques/aitm-phishing-proxy/) captures the resulting session cookie regardless of protocol. That is an authenticator problem, solved by [phishing-resistant MFA](https://startwithidentity.com/standards/webauthn-fido2/) at the provider.

## When to use it

Any time you need to log a user in. Reach for OIDC over raw OAuth for authentication, and over [SAML](https://startwithidentity.com/standards/saml-2-0/) when building modern web, mobile, or API-centric apps. SAML still wins where an enterprise customer's IdP only speaks SAML, which is why B2B products often support both.

## Related standards

- [OAuth 2.0](https://startwithidentity.com/standards/oauth-2-0/) and [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/): the authorization layer OIDC sits on.
- [FAPI 2.0](https://startwithidentity.com/standards/fapi/): a security profile of OAuth and OIDC for open banking and other high-value APIs.
- [Shared Signals Framework](https://startwithidentity.com/standards/shared-signals-framework/): pushes session-revoked and account-disabled events between providers and apps after login.
- [OpenID for Verifiable Credentials](https://startwithidentity.com/standards/openid4vc/): issuance and presentation of credentials built on the same family.
- [CIBA](https://startwithidentity.com/glossary/ciba/): decoupled authentication, where the user approves on another device.
- [ID-JAG and Cross App Access](https://startwithidentity.com/standards/id-jag-cross-app-access/): exchanges an OIDC ID token for access to another app's API.

## Who implements it

Almost every identity provider and CIAM platform ships an OIDC provider. The OpenID Foundation runs a [certification program](https://openid.net/developers/certified-openid-connect-implementations/); certified OpenID Provider entries we saw on 5 November 2026 include [Auth0](https://startwithidentity.com/vendors/ciam/auth0/), [ForgeRock](https://startwithidentity.com/vendors/iam/forgerock/), [Keycloak](https://startwithidentity.com/vendors/open-source/keycloak/), [Curity](https://startwithidentity.com/vendors/ciam/curity/), [Gluu](https://startwithidentity.com/vendors/open-source/gluu/), [authentik](https://startwithidentity.com/vendors/open-source/authentik/) and [Akamai Identity Cloud](https://startwithidentity.com/vendors/ciam/akamai-identity-cloud/). Certification is per product version, so check the list for the release you run. For choosing a provider, see the [CIAM buyer guide](https://startwithidentity.com/guides/buyer-guides/how-to-choose-a-ciam-platform/) and the [IAM buyer guide](https://startwithidentity.com/guides/buyer-guides/how-to-choose-an-iam-platform/).

## How to check an implementation

1. Decode a real ID token with the [JWT decoder](https://startwithidentity.com/tools/jwt-decoder/) and confirm `iss`, `aud`, `exp` and `nonce` are what you expect.
2. Change one byte of the signature and replay it. Your app must reject it.
3. Re-sign the header as `"alg": "none"` with an empty signature. Rejected.
4. Send a token issued for another client ID. Rejected on `aud`.
5. Omit `nonce` from a callback where you sent one. Rejected.

## How it works, message by message

The [OIDC message-flow walkthrough](https://startwithidentity.com/guides/protocols/oidc-message-flow/) shows each HTTP exchange of the authorization code flow with annotated values: discovery, the authentication request, the callback, the token request with PKCE, the token response and a decoded ID token, with every parameter tied to its OIDC Core or RFC section. Check a provider's metadata with the [OIDC discovery checker](https://startwithidentity.com/tools/oidc-discovery-checker/).

## Related

Guides: [OAuth vs OIDC](https://startwithidentity.com/guides/fundamentals/oauth-vs-oidc/), [SAML vs OIDC](https://startwithidentity.com/guides/fundamentals/saml-vs-oidc/), [implementing OAuth 2.0 and OpenID Connect](https://startwithidentity.com/guides/implementation/oauth-2-openid-connect-implementation/), [implementing SSO](https://startwithidentity.com/guides/authentication/complete-guide-implementing-sso/). Glossary: [OIDC](https://startwithidentity.com/glossary/oidc/), [ID token](https://startwithidentity.com/glossary/id-token/), [claims](https://startwithidentity.com/glossary/claims/), [identity provider](https://startwithidentity.com/glossary/identity-provider/), [relying party](https://startwithidentity.com/glossary/relying-party/).

## Who wrote it

OpenID Connect was authored by a group including [Nat Sakimura](https://startwithidentity.com/experts/nat-sakimura/), [Mike Jones](https://startwithidentity.com/experts/mike-jones/), and [John Bradley](https://startwithidentity.com/experts/john-bradley/). [Vittorio Bertocci](https://startwithidentity.com/experts/vittorio-bertocci/) did much of the work of explaining it to developers, and [Filip Skokan](https://startwithidentity.com/experts/filip-skokan/) and [Roland Hedberg](https://startwithidentity.com/experts/roland-hedberg/) maintain certified implementations. More in the [experts directory](https://startwithidentity.com/experts/).

## OpenID for Verifiable Credentials (OpenID4VC)
Source: https://startwithidentity.com/standards/openid4vc/
Last updated: 2026-11-05

## What it is

OpenID for Verifiable Credentials (OpenID4VC) is a family of [OpenID Foundation](https://openid.net/wg/digital-credentials-protocols/specifications/) protocols that move [verifiable credentials](https://startwithidentity.com/standards/verifiable-credentials/) between issuers, wallets, and verifiers. If [DIDs](https://startwithidentity.com/standards/decentralized-identifiers-did/) and the VC data model are the nouns of [decentralized identity](https://startwithidentity.com/guides/fundamentals/what-is-decentralized-identity/), OpenID4VC is the verbs: how a credential gets issued to a wallet and later presented to a verifier. It builds on [OAuth 2.0](https://startwithidentity.com/standards/oauth-2-0/) and [OpenID Connect](https://startwithidentity.com/standards/openid-connect/), so identity teams reuse authorization servers, libraries and threat models they already know.

The core decision for practitioners in 2026 is simple: implement the **1.0 Final** specs profiled by **HAIP**, not the dozens of earlier drafts that early wallets shipped.

## Status (November 2026)

| Specification | Status | Date |
|---|---|---|
| [OpenID4VP 1.0](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html) | Final | 9 July 2025 |
| [OpenID4VCI 1.0](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-final.html) | Final | 16 September 2025 |
| [HAIP 1.0](https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-1_0-final.html) | Final | 24 December 2025 |
| Security and Trust in OpenID4VC | Working Group Draft | |
| OpenID4VP over BLE | Draft | |
| [SIOPv2](https://openid.net/sg/openid4vc/specifications/) | Implementer's Draft (Connect WG) | |

The Digital Credentials Protocols working group lists formal security analyses of OpenID4VP (July 2025) and of OpenID4VCI and OpenID4VP (October 2023). The OpenID Foundation publishes errata-corrected text at the base URL and keeps the approved text at the `-final` URL.

## How issuance works (OpenID4VCI 1.0)

The wallet is an OAuth client; the **credential issuer** is a resource server that may also run the authorization server.

1. **Credential offer.** The issuer gives the wallet an offer by value (in a URI or QR code) or by reference (an HTTPS URL the wallet fetches). It lists credential configuration IDs and the grants available.
2. **Authorization.** Either the **authorization code flow** (a normal OAuth request, optionally with [PKCE](https://startwithidentity.com/glossary/pkce/), [PAR](https://startwithidentity.com/glossary/par/) and an `issuer_state` linking it to the offer) or the **pre-authorized code flow**, where the issuer already authenticated the user out of band and hands over a short-lived single-use code. An optional transaction code (`tx_code`) sent through a second channel limits the damage of a leaked offer.
3. **Proof of possession.** The wallet gets a fresh `c_nonce` from the nonce endpoint and signs it with the key the credential will be bound to. Proof types are `jwt`, `di_vp` and `attestation` (a key attestation).
4. **Credential endpoint.** The wallet calls it with the access token and proof and receives one or more credentials. **Batch issuance** returns several copies with different keys so each presentation can use a fresh one. Deferred and notification endpoints handle slow issuance and lifecycle feedback.

Appendix A covers W3C VCs (JWT and Data Integrity variants), ISO mdoc ([ISO/IEC 18013-5](https://startwithidentity.com/standards/iso-18013-5-mdl/)) and IETF SD-JWT VC.

## How presentation works (OpenID4VP 1.0)

A verifier, say a bank onboarding a customer, sends an authorization request with `response_type=vp_token`, a mandatory `nonce`, and a **DCQL** query listing the credentials and claims it needs and, optionally, `trusted_authorities` naming acceptable issuers. The verifier identifies itself with a **client identifier prefix**: `redirect_uri`, `x509_san_dns`, `x509_hash`, `verifier_attestation`, `openid_federation` or `decentralized_identifier`, with `origin` reserved for the Digital Credentials API.

- **Same device:** redirects, with the response in the fragment by default.
- **Cross device:** a QR code carries a request URI; the wallet fetches the signed request and posts the response with `direct_post`, or encrypted with `direct_post.jwt`.
- **Browser:** Appendix A runs the same request through the W3C [Digital Credentials API](https://www.w3.org/TR/digital-credentials/), which registers `openid4vp-v1-unsigned`, `-signed` and `-multisigned` protocol identifiers.

The wallet returns presentations bound to the nonce, with [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/) so only the requested claims leave the device.

## What HAIP pins down

[HAIP 1.0](https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-1_0-final.html) turns options into rules:

| Area | HAIP requirement |
|---|---|
| Formats | SD-JWT VC (`dc+sd-jwt`) or ISO mdoc (`mso_mdoc`); ecosystems pick |
| Crypto | ES256 mandatory; SHA-256 digests; ECDH-ES P-256 with A128GCM or A256GCM for response encryption |
| Issuance | Authorization code flow, [FAPI 2.0](https://startwithidentity.com/standards/fapi/) security (PKCE S256, PAR, RFC 9207 `iss`), [DPoP](https://startwithidentity.com/glossary/dpop/)-bound tokens, wallet attestation at PAR and token endpoints, key attestations |
| Presentation | DCQL; signed requests with `x509_hash`; `direct_post.jwt` or `dc_api.jwt`; key binding JWT on every holder-bound SD-JWT VC |
| Revocation | Token Status List for SD-JWT VC, unique unpredictable index per credential |

Two caveats from the profile itself: it references pre-final drafts (SD-JWT VC draft-13, Token Status List draft-14) on purpose, and conforming to it is not enough on its own to reach eIDAS level of assurance high; additional measures outside its scope are needed.

## Who implements it

- **[walt.id](https://startwithidentity.com/vendors/decentralized-identity/walt-id/):** [feature list](https://docs.walt.id/feature-list) shows OID4VCI 1.0 and OID4VP 1.0, with deprecated services still covering OID4VCI drafts 11 and 13 and OID4VP drafts 14 and 20.
- **[Procivis](https://startwithidentity.com/vendors/decentralized-identity/procivis/):** [standards page](https://docs.procivis.ch/standards) lists OpenID4VCI 1.0, OpenID4VP 1.0, OpenID4VP over BLE, and a proprietary OpenID4VP-over-MQTT adaptation.
- **[MATTR](https://startwithidentity.com/vendors/decentralized-identity/mattr/):** [docs](https://learn.mattr.global/) start with the OID4VCI pre-authorized code flow and remote verification over OID4VP.
- **[Microsoft Entra Verified ID](https://startwithidentity.com/vendors/decentralized-identity/microsoft-entra-verified-id/):** its [standards page](https://learn.microsoft.com/en-us/entra/verified-id/verifiable-credentials-standards) links OpenID4VCI draft 11, SIOPv2 and DIF Presentation Exchange v2.0.0, which predates the 1.0 and HAIP choices.
- **Google Wallet:** [accepts](https://developers.google.com/wallet/identity/verify/accepting-ids-from-wallet-online) mdoc IDs over OpenID4VP 1.0.

- **[Talao](https://startwithidentity.com/vendors/decentralized-identity/talao/):** its [site](https://www.talao.io/) describes issuance and presentation "through OID4VCI and OID4VP" for SD-JWT VC, mdoc and W3C credentials; it does not state a version.

Compare options in [best verifiable credential platforms](https://startwithidentity.com/rankings/best-verifiable-credential-platforms/).

## Security and privacy pitfalls

- **Draft drift.** "Supports OID4VP" can mean draft 14, draft 20 or 1.0, and they do not interoperate. Ask for the version and the HAIP conformance result.
- **Pre-authorized code theft.** Anyone holding the offer can redeem the code. Require `tx_code` for anything sensitive and keep code lifetimes short.
- **Cross-device phishing.** A QR code can be relayed from an attacker's session to a victim. HAIP makes same-device redirects mandatory and says verifiers must reject presentations when the wallet does not return to the original session; the Digital Credentials API adds origin information the wallet can show.
- **Unauthenticated verifiers.** `redirect_uri` client IDs prove nothing about who is asking. Use signed requests with `x509_hash` or a verifier attestation so the wallet can display and enforce who receives data.
- **Replay and linkability.** Enforce the `nonce`, reject reused key binding, and use batch-issued credentials once each so verifiers cannot correlate users by a stable signature or key.
- **Treating SIOPv2 as done.** It is still an Implementer's Draft; few production wallets depend on it.

## How it connects

OpenID4VC carries [SD-JWT VC and W3C VCs](https://startwithidentity.com/standards/verifiable-credentials/) and [mDLs](https://startwithidentity.com/standards/iso-18013-5-mdl/). Issuer and verifier identifiers can be X.509 certificates or [DIDs](https://startwithidentity.com/standards/decentralized-identifiers-did/). The EU [Architecture and Reference Framework](https://startwithidentity.com/standards/eidas-2-eudi-wallet/) names OpenID4VP over the Digital Credentials API, ISO/IEC 18013-7 over the API, and OpenID4VP with a custom URI scheme as presentation options for the [EUDI Wallet](https://startwithidentity.com/digital-ids/european-union/).

## Related

Guides: [verifiable credentials implementation guide](https://startwithidentity.com/guides/decentralized-identity/verifiable-credentials-implementation-guide/), [choosing a decentralized identity platform](https://startwithidentity.com/guides/decentralized-identity/choosing-a-decentralized-identity-platform/), [what is decentralized identity](https://startwithidentity.com/guides/fundamentals/what-is-decentralized-identity/). Standards: [Verifiable Credentials](https://startwithidentity.com/standards/verifiable-credentials/), [DID](https://startwithidentity.com/standards/decentralized-identifiers-did/), [mDL](https://startwithidentity.com/standards/iso-18013-5-mdl/), [eIDAS 2 / EUDI Wallet](https://startwithidentity.com/standards/eidas-2-eudi-wallet/), [FAPI](https://startwithidentity.com/standards/fapi/), [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/). Glossary: [OpenID4VCI](https://startwithidentity.com/glossary/openid4vci/), [OpenID4VP](https://startwithidentity.com/glossary/openid4vp/), [verifiable presentation](https://startwithidentity.com/glossary/verifiable-presentation/), [SD-JWT](https://startwithidentity.com/glossary/sd-jwt/). Vendors: [decentralized identity](https://startwithidentity.com/vendors/decentralized-identity/).

## Who wrote it

OpenID4VP and OpenID4VCI are edited by [Kristina Yasuda](https://startwithidentity.com/experts/kristina-yasuda/), [Torsten Lodderstedt](https://startwithidentity.com/experts/torsten-lodderstedt/), and [Tobias Looker](https://startwithidentity.com/experts/tobias-looker/). More in the [experts directory](https://startwithidentity.com/experts/).

## RADIUS
Source: https://startwithidentity.com/standards/radius/
Last updated: 2026-11-05

## What it is

RADIUS (Remote Authentication Dial In User Service) is a client and server protocol for network access. The **client** is a network access server (NAS) such as a VPN gateway, wireless controller or switch; the **server** checks credentials against a directory or MFA service and answers with one of three packets: Access-Accept, Access-Reject or Access-Challenge. The protocol is [RFC 2865](https://www.rfc-editor.org/rfc/rfc2865) (June 2000) by C. Rigney, S. Willens, A. Rubens and W. Simpson; accounting is [RFC 2866](https://www.rfc-editor.org/rfc/rfc2866). EAP for 802.1X Wi-Fi and wired authentication rides inside it as defined in [RFC 3579](https://www.rfc-editor.org/rfc/rfc3579).

RADIUS is old, but it is where a lot of identity meets the network: enterprise Wi-Fi, VPN logins, device administration and many MFA integrations. [Duo](https://startwithidentity.com/vendors/mfa/duo/) documents RADIUS server sections in its Authentication Proxy, and [JumpCloud](https://startwithidentity.com/vendors/iam/jumpcloud/) sells a Cloud RADIUS service for Wi-Fi and VPN (both checked on the vendors' sites, 5 November 2026).

## Status (November 2026)

| Item | Status |
| --- | --- |
| RFC 2865, RADIUS | Draft Standard, June 2000; updated by RFC 2868, 3575, 5080, 6929, 8044 and 9765 ([RFC Editor](https://www.rfc-editor.org/info/rfc2865)) |
| RFC 2866, Accounting | Informational, June 2000 |
| RFC 3579, RADIUS support for EAP | Informational, September 2003; defines `Message-Authenticator` use for EAP |
| [RFC 6614](https://www.rfc-editor.org/rfc/rfc6614), RADIUS over TLS (RadSec) | Experimental, May 2012; TCP port 2083 |
| [RFC 7360](https://www.rfc-editor.org/rfc/rfc7360), RADIUS over DTLS | Experimental, September 2014 |
| [RFC 9765](https://www.rfc-editor.org/rfc/rfc9765), RADIUS/1.1 | Experimental, April 2025, by A. DeKok (FreeRADIUS); ALPN name `radius/1.1` |
| [draft-ietf-radext-radiusdtls-bis](https://datatracker.ietf.org/doc/draft-ietf-radext-radiusdtls-bis/) | Revision 18, 30 September 2026; intended Standards Track; would obsolete RFC 6614 and RFC 7360 if approved |
| [draft-ietf-radext-deprecating-radius](https://datatracker.ietf.org/doc/draft-ietf-radext-deprecating-radius/) | "Deprecating Insecure Practices in RADIUS", revision 10, active working group draft |
| Ports | 1812 `radius` and 1813 `radius-acct` (UDP and TCP), 2083 `radsec` ([IANA](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml)) |

The direction is clear even though the documents are not finished: RADIUS over plain UDP is being treated as legacy, and the working group's effort is on TLS transport and on removing MD5.

## How it works

Every packet has a 1-byte Code, a 1-byte Identifier, a 2-byte Length, a 16-byte Authenticator and a list of type-length-value attributes ([RFC 2865 §3](https://www.rfc-editor.org/rfc/rfc2865#section-3)). The NAS sends an **Access-Request** (Code 1) with attributes such as `User-Name`, `User-Password`, `NAS-IP-Address` and `Calling-Station-Id`. The server replies:

- **Access-Accept** (2), often with authorization attributes: a VLAN, a filter, a session timeout, or a `Class` value echoed into accounting.
- **Access-Reject** (3).
- **Access-Challenge** (11) with a `State` attribute and a prompt, used for one-time codes and for every round of EAP.

Security rests on a **shared secret** configured on both sides. It hides `User-Password` with an MD5-based keystream ([§5.2](https://www.rfc-editor.org/rfc/rfc2865#section-5.2)) and authenticates responses with the **Response Authenticator**, `MD5(Code + ID + Length + RequestAuth + Attributes + Secret)` (§3). The optional `Message-Authenticator` attribute adds an HMAC-MD5 over the whole packet ([RFC 3579 §3.2](https://www.rfc-editor.org/rfc/rfc3579#section-3.2)); RFC 3579 makes it mandatory only for packets carrying EAP. The full packet-by-packet view is in [how RADIUS works, message by message](https://startwithidentity.com/guides/protocols/radius-message-flow/).

## Blast-RADIUS and what changed

[CVE-2024-3596](https://startwithidentity.com/cves/cve-2024-3596/) (Blast-RADIUS, disclosed 9 July 2024) showed that an attacker in the network path can use an MD5 chosen-prefix collision to forge an Access-Accept from an Access-Reject when the exchange is PAP or CHAP without `Message-Authenticator`. The [researchers' guidance](https://www.blastradius.fail/) is, in the short term, for clients and servers to always send and require `Message-Authenticator` on all requests and responses, with servers placing it first in Access-Accept and Access-Reject; and, in the long term, to run RADIUS inside TLS. EAP exchanges were already protected because `Message-Authenticator` is mandatory there.

Two consequences for identity teams:

1. **MFA behind RADIUS inherits RADIUS's weakness.** If the NAS accepts a forged Access-Accept, the phishing-resistant factor behind the RADIUS server never mattered.
2. **The network access control plane is a target.** [CVE-2026-76460](https://startwithidentity.com/cves/cve-2026-76460/), an exploited authentication bypass in Cisco Identity Services Engine added to CISA KEV on 16 September 2026, sits in the RADIUS server product itself.

## When to use it

Use RADIUS where the device gives you no alternative: 802.1X with EAP-TLS for Wi-Fi and wired access, VPN gateways, and device administration. Prefer EAP methods that run inside TLS over PAP and CHAP, require `Message-Authenticator` on both sides, and use RadSec where the NAS supports it. For web and SaaS sign-in, use [SAML 2.0](https://startwithidentity.com/standards/saml-2-0/) or [OpenID Connect](https://startwithidentity.com/standards/openid-connect/) instead, and put the MFA at the identity provider where it can be phishing-resistant ([WebAuthn](https://startwithidentity.com/standards/webauthn-fido2/)). Many VPNs now also accept SAML, which removes the RADIUS hop from user sign-in.

## Pitfalls

- Shared secrets that are short, reused across every NAS, or older than the staff who set them. RFC 2865 §3 prefers secrets of at least 16 octets and forbids empty ones.
- RADIUS over UDP across networks you do not control, including to cloud RADIUS services, without TLS or IPsec.
- `Message-Authenticator` sent but not required, which leaves a downgrade.
- PAP across the network, where the password is protected only by the shared-secret keystream.
- MFA push approvals through RADIUS with no number matching, which invites [MFA fatigue](https://startwithidentity.com/techniques/mfa-fatigue-push-bombing/).

## How it works, message by message

The [RADIUS message-flow walkthrough](https://startwithidentity.com/guides/protocols/radius-message-flow/) decodes an Access-Request attribute by attribute, then the Access-Challenge used for one-time codes, the Access-Accept with its authorization attributes and the accounting records, with each attribute tied to RFC 2865, RFC 2866 or RFC 3579 and the checks a NAS and a server must run after Blast-RADIUS.

## Related

Walkthrough: [how RADIUS works, message by message](https://startwithidentity.com/guides/protocols/radius-message-flow/). Standards: [LDAP](https://startwithidentity.com/standards/ldap/), [Kerberos](https://startwithidentity.com/standards/kerberos/). Glossary: [RADIUS](https://startwithidentity.com/glossary/radius/). Guides: [MFA implementation best practices](https://startwithidentity.com/guides/authentication/mfa-implementation-best-practices/), [zero trust rollout](https://startwithidentity.com/guides/implementation/zero-trust-rollout/).

## SAML 2.0
Source: https://startwithidentity.com/standards/saml-2-0/
Last updated: 2026-11-05

## What it is

SAML 2.0 (Security Assertion Markup Language) is an XML-based standard for exchanging authentication and authorization assertions between an identity provider and a service provider. It has powered enterprise web single sign-on since 2005, and if you sell to enterprises you will be asked to support it because that is what their identity providers speak.

## How it works

The identity provider (IdP) authenticates the user and issues a signed XML **assertion** to the service provider (SP), which trusts it and grants access.

- **Assertion:** a signed XML document stating who the user is and when they authenticated.
- **SP-initiated vs IdP-initiated:** the flow can start at the application or at the identity provider's portal.
- **Metadata:** IdP and SP exchange metadata describing endpoints and signing keys.

## An SP-initiated login, step by step

The core documents are the OASIS [Assertions and Protocols](https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf), [Bindings](https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf) and [Profiles](https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf) specifications, plus the [approved errata](https://docs.oasis-open.org/security/saml/v2.0/sstc-saml-approved-errata-2.0.html). The flow most deployments use is the Web Browser SSO profile:

1. The user opens `https://app.example.com`. The SP builds an `<AuthnRequest>` with a unique `ID`, its entity ID as `<Issuer>`, and its Assertion Consumer Service (ACS) URL, then redirects the browser to the IdP using the HTTP-Redirect binding (deflated, base64, URL-encoded, optionally signed).
2. The IdP authenticates the user, applying its own MFA and conditional access policy.
3. The IdP returns an auto-submitting HTML form that POSTs a `<Response>` to the ACS URL (HTTP-POST binding). Inside is an `<Assertion>` with the `<Subject>` (a `<NameID>` such as an email or persistent identifier, the [SSO identifier](https://startwithidentity.com/glossary/sso-identifier/) the SP keys the account on), `<Conditions>` with `NotBefore`, `NotOnOrAfter` and an `<AudienceRestriction>` naming the SP, an `<AuthnStatement>`, and usually an `<AttributeStatement>` with groups or roles.
4. The SP validates the response and creates its own session.

## What the SP must validate

Most SAML vulnerabilities are validation bugs, not protocol flaws. A correct SP checks, in order:

- **The signature covers the assertion you will read.** Verify the XML signature with the IdP's certificate from metadata (never a key embedded in the message), and confirm the signed element is the same element your code then extracts attributes from. Signature wrapping attacks exploit exactly that gap.
- **`Issuer`** matches the expected IdP entity ID.
- **`AudienceRestriction`** contains your SP entity ID.
- **`Recipient` and `Destination`** match your ACS URL.
- **`InResponseTo`** matches an `AuthnRequest` ID you issued and have not seen used (blocks replay and unsolicited responses in SP-initiated flows).
- **Time window**: `NotBefore` and `NotOnOrAfter`, with small clock skew allowance.
- **One assertion only**, and reject responses with unexpected extra assertions.

## Where SAML breaks in practice

The SWI [identity CVE catalog](https://startwithidentity.com/cves/) shows the pattern repeatedly:

- **Signature wrapping through parser differentials.** In [CVE-2025-25291](https://startwithidentity.com/cves/cve-2025-25291/) and [CVE-2025-25292](https://startwithidentity.com/cves/cve-2025-25292/), two XML parsers inside ruby-saml disagreed about the same document, so an attacker with one valid signed assertion could wrap a forged one and log in as any user. Both are descendants of [CVE-2024-45409](https://startwithidentity.com/cves/cve-2024-45409/).
- **Optional encryption paths.** [CVE-2024-4985](https://startwithidentity.com/cves/cve-2024-4985/) let a forged response through GitHub Enterprise Server when encrypted assertions were enabled, allowing provisioning of a site administrator.
- **Appliance SSO bypass.** [CVE-2025-59718](https://startwithidentity.com/cves/cve-2025-59718/), a crafted SAML message bypassing FortiCloud SSO on FortiOS and related products, was added to CISA KEV in December 2025. The [breach database record](https://startwithidentity.com/breaches/incidents/2025-fortigate-forticloud-sso-saml-bypass/) covers its exploitation.
- **Forging at the source.** If an attacker steals the IdP's signing key, every SP will accept their assertions. That is the [federation trust abuse and SAML forgery](https://startwithidentity.com/techniques/federation-trust-abuse-saml-forgery/) technique, often called Golden SAML.

These are why the advice below is "use a maintained library and patch it", not "write careful XML code".

## Status

SAML 2.0 is a stable OASIS standard and remains deeply entrenched in enterprise IT. For new consumer, mobile, and API-centric apps, [OpenID Connect](https://startwithidentity.com/standards/openid-connect/) is the better choice, but most enterprises still require SAML for workforce SSO, so platforms support both.

## When to use it

When integrating with enterprise customers or established corporate identity providers. For greenfield modern apps, prefer OIDC. SWI's [Phishing-Resistant MFA Support Matrix](https://startwithidentity.com/reports/phishing-resistant-mfa-matrix-2026/) found SAML offered by 83 of 95 business SaaS apps and OpenID Connect by 30, so an OIDC-first identity provider still needs SAML for most of a SaaS estate.

## SAML and AI agents

SAML has no token an agent can carry to an API, which is why agent standards build on OAuth. It is not a dead end, though. The [ID-JAG draft](https://startwithidentity.com/standards/id-jag-cross-app-access/) (Cross App Access) defines SAML interoperability: a client that signed the user in with SAML exchanges the assertion at the IdP for a refresh token, using token exchange with the `urn:ietf:params:oauth:token-type:saml2` token type, and then uses that refresh token to request ID-JAGs for other apps. The IdP must map the assertion's audience to an OAuth client ID first. The MCP Enterprise-Managed Authorization extension uses the same path for SAML-based MCP clients.

## Pitfalls

- XML signature handling is historically error-prone; rely on a vetted library, never hand-roll validation.
- Validate signatures, audience, and conditions; misconfigured SAML has produced serious authentication bypasses.
- IdP-initiated SSO has no `InResponseTo` to check, so it is more exposed to replay and login CSRF. Disable it where the SP does not need it.
- Local login next to SAML: making SSO mandatory is a separate setting in most apps, and owner or admin accounts often keep a password. See [SSO enforcement](https://startwithidentity.com/glossary/sso-enforcement/) and [local login bypass](https://startwithidentity.com/glossary/local-login-bypass/).
- Certificate rollover: IdP signing certificates expire. Publish and consume metadata so rollovers do not become outages.

## How it works, message by message

The [SAML 2.0 message-flow walkthrough](https://startwithidentity.com/guides/protocols/saml-message-flow/) decodes a real-shaped `<AuthnRequest>` and signed `<Response>` field by field, maps each element to its section in SAML Core, Bindings and Profiles, and turns the validation list above into eight checks with the CVE each one prevents. Paste your own messages into the [SAML decoder](https://startwithidentity.com/tools/saml-decoder/) to compare.

## Related

Guide: [SAML vs OIDC](https://startwithidentity.com/guides/fundamentals/saml-vs-oidc/), [SSO implementation](https://startwithidentity.com/guides/authentication/complete-guide-implementing-sso/). Glossary: [SAML](https://startwithidentity.com/glossary/saml/), [federation](https://startwithidentity.com/glossary/federation/). CVEs: [identity CVE catalog](https://startwithidentity.com/cves/), including [ruby-saml 2024](https://startwithidentity.com/cves/cve-2024-45409/), [GHES encrypted assertions](https://startwithidentity.com/cves/cve-2024-4985/), [Keycloak 2024](https://startwithidentity.com/cves/cve-2024-8698/).

## Who wrote it

Most of the technical editing of SAML 2.0 was done by [Scott Cantor](https://startwithidentity.com/experts/scott-cantor/), who also architected Shibboleth. [Eve Maler](https://startwithidentity.com/experts/eve-maler/) was a co-author of the SAML specifications. More in the [experts directory](https://startwithidentity.com/experts/).

## SCIM 2.0
Source: https://startwithidentity.com/standards/scim-2-0/
Last updated: 2026-11-05

## What it is

SCIM (System for Cross-domain Identity Management) is an open standard, defined by IETF RFC 7643 (the schema) and RFC 7644 (the protocol), for automating the user and group lifecycle across applications. When HR hires someone or an admin grants an app, SCIM pushes that change so accounts are created, updated, and, most importantly, removed without manual work. Two later RFCs update both documents: [RFC 9865](https://datatracker.ietf.org/doc/rfc9865/) (October 2025) adds cursor-based pagination, and [RFC 9967](https://datatracker.ietf.org/doc/rfc9967/) (May 2026) adds a SCIM profile for security event tokens.

It answers a different question from [SAML](https://startwithidentity.com/standards/saml-2-0/) and [OIDC](https://startwithidentity.com/standards/openid-connect/). Those authenticate a person at login. SCIM makes sure the account exists, carries the right attributes, and disappears when they leave. Most enterprise deployments need both, which is why procurement checklists ask for them together.

## How it works

SCIM defines a standard JSON representation of users and groups and a REST API to manage them. An identity provider acts as the client and pushes changes to any application that exposes a SCIM endpoint.

- **Standard schema:** common attributes for users and groups, extensible per app.
- **REST operations:** create, read, update, delete, and search over `/Users` and `/Groups`.
- **Discovery endpoints:** `/ServiceProviderConfig`, `/ResourceTypes` and `/Schemas` declare what the server actually supports.
- **Filtering:** query by attribute, for example `userName eq "ada@example.com"`, so clients can look before they create.

The discovery endpoints are the most commonly skipped part of the specification, and skipping them is the most common cause of avoidable failures. A client that reads `/ServiceProviderConfig` before assuming `PATCH` is available fails less often than one that does not.

## Where implementations actually break

The specification is clearer than its reputation. Deployments break because implementations are partial, and in a consistent set of places.

**PATCH semantics for multi-valued attributes.** Group membership is the usual casualty. Some implementations do not support `PATCH` at all; others differ on whether a patch to a multi-valued attribute replaces or appends. The visible symptom is that additions work and removals silently do not, which is the worst possible failure mode for deprovisioning.

**Inconsistent filtering.** If filtering is unreliable, a client cannot confirm whether a user already exists before creating one, and duplicates follow.

**Soft delete versus hard delete.** RFC 7644 does not mandate which happens on `DELETE`. Applications vary. That distinction decides whether a licence is reclaimed and whether an auditor sees the account as removed, so confirm it per application rather than assuming.

**Custom schema extensions.** Vendors extend the schema differently. A working integration against one application predicts very little about the next.

## Status

The RFCs were finalised in 2015 and SCIM 2.0 remains current. There is no SCIM 3.0; IETF work continues on extensions and profiles rather than a new major version. That stability is an advantage: an integration written years ago still works.

## Why it matters

Deprovisioning is the part of the identity lifecycle most often handled badly by hand, and orphaned accounts are both a standing audit finding and a real attack path. Automating removal is usually the business case, ahead of the convenience of automated creation.

For anyone selling B2B software, SCIM has become a gate. Enterprise security reviews routinely require both SSO and automated provisioning before purchase, which is why a market exists specifically for adding them quickly. See our [SCIM provisioning tools](https://startwithidentity.com/articles/top-7-scim-provisioning-tools/) comparison for the options.

## How it works, message by message

The [SCIM message-flow walkthrough](https://startwithidentity.com/guides/protocols/scim-message-flow/) shows the full lifecycle as real requests: discovery, a filtered lookup, `POST /Users`, attribute `PATCH`, group membership add and remove, deactivation and `DELETE`, with every field tied to RFC 7643 or RFC 7644 and the checks each side should run. Build the same requests in the [SCIM request builder](https://startwithidentity.com/tools/scim-request-builder/).

## Related

[SAML 2.0](https://startwithidentity.com/standards/saml-2-0/), [OpenID Connect](https://startwithidentity.com/standards/openid-connect/), and the [SCIM glossary entry](https://startwithidentity.com/glossary/scim/). For identity governance built on top of provisioning, see [what is IGA](https://startwithidentity.com/guides/fundamentals/what-is-iga/).

## Who wrote it

The SCIM protocol, RFC 7644, was edited by [Phil Hunt](https://startwithidentity.com/experts/phil-hunt/) with co-authors from SailPoint, Cisco, Nexus, and Salesforce. More in the [experts directory](https://startwithidentity.com/experts/).

## Shared Signals Framework (SSF, CAEP and RISC)
Source: https://startwithidentity.com/standards/shared-signals-framework/
Last updated: 2026-11-05

## What it is

The Shared Signals Framework (SSF) is the OpenID Foundation standard for sending security events between cooperating systems as they happen. A **transmitter** (an identity provider, an EDR tool, a SaaS app) publishes events about a **subject** (a user, session, device or token), and **receivers** that subscribed to an event stream act on them: end a session, force reauthentication, disable an account. It replaces the polling and long token lifetimes that leave a fired employee or a stolen session active for an hour or a day after the IdP knows.

SSF is a profile of IETF Security Event work. Each event is a [Security Event Token (RFC 8417)](https://www.rfc-editor.org/rfc/rfc8417.html), subjects use [Subject Identifiers (RFC 9493)](https://www.rfc-editor.org/rfc/rfc9493.html), and delivery uses [push (RFC 8935)](https://www.rfc-editor.org/rfc/rfc8935.html) or [poll (RFC 8936)](https://www.rfc-editor.org/rfc/rfc8936.html). Two companion specifications define what the events mean: **CAEP**, the Continuous Access Evaluation Profile, and **RISC**, Risk Incident Sharing and Coordination. Glossary versions: [Shared Signals Framework](https://startwithidentity.com/glossary/shared-signals-framework/), [CAEP](https://startwithidentity.com/glossary/caep/), [RISC](https://startwithidentity.com/glossary/risc/), [Security Event Token](https://startwithidentity.com/glossary/security-event-token/).

## Status (November 2026)

All three are **OpenID Final Specifications**, published 29 August 2025:

- [OpenID Shared Signals Framework Specification 1.0](https://openid.net/specs/openid-sharedsignals-framework-1_0-final.html)
- [OpenID Continuous Access Evaluation Profile 1.0](https://openid.net/specs/openid-caep-1_0-final.html)
- [OpenID RISC Profile Specification 1.0](https://openid.net/specs/openid-risc-1_0-final.html)

The Foundation [announced the approval](https://openid.net/press-release-openid-foundation-finalizes-global-standards-for-real-time-identity-security/) on 16 September 2025. A Final Specification is not revised further, so this is among the most settled of the agent-relevant standards on this site. The working group's page, read 5 November 2026, lists a [CAEP Interoperability Profile](https://openid.net/specs/openid-caep-interoperability-profile-1_0-ID1.html) at Implementer's Draft stage, and the Foundation [said in September 2026](https://openid.net/oidf-welcomes-cisa-and-nists-new-guidance-on-token-security/) that a self-certification test suite would launch that autumn. We could not confirm it had launched.

## How it works

**Discovery.** A transmitter publishes metadata at `/.well-known/ssf-configuration`: its issuer, `jwks_uri` for signature keys, `delivery_methods_supported`, and the management endpoints (`configuration_endpoint`, `status_endpoint`, `add_subject_endpoint`, `remove_subject_endpoint`, `verification_endpoint`).

**Stream setup.** The receiver calls the configuration endpoint, authorized with OAuth or another method the transmitter names, to create a stream. It chooses the delivery method (`urn:ietf:rfc:8935` for push, with its own `endpoint_url`, or poll) and the `events_requested`. The transmitter assigns a `stream_id`. The receiver can then add or remove subjects and ask for a verification event to prove the pipe works end to end.

**An event.** When an admin revokes a user's sessions at the IdP, the IdP sends each receiver a signed SET like this (simplified from CAEP 1.0):

```json
{
  "iss": "https://idp.example.com/",
  "aud": "https://app.example.com/caep",
  "jti": "24c63fb56e5a2d77a6b512616ca9fa24",
  "iat": 1615305159,
  "sub_id": { "format": "email", "email": "ada@example.com" },
  "events": {
    "https://schemas.openid.net/secevent/caep/event-type/session-revoked": {
      "event_timestamp": 1615304991
    }
  }
}
```

The receiver verifies the signature against the transmitter's keys, finds the matching sessions, and ends them. With the same pattern a RISC `account-disabled` event (optional reason `hijacking` or `bulk-account`) tells every connected app to treat the account as disabled.

**The event vocabularies.** CAEP 1.0 has 8 event types: session revoked, token claims change, credential change, assurance level change, device compliance change, session established, session presented and risk level change. RISC 1.0 has 14, covering account credential change required, account purged, disabled and enabled, identifier changed and recycled, credential compromise, the opt-in and opt-out family, recovery activated, recovery information changed and sessions revoked.

## What it solves for AI agents and SaaS

For SaaS and workforce identity, SSF closes the gap between "the IdP knows" and "the app acts". Without it, revoking a user at the IdP ends new logins, but sessions and access tokens already issued to apps stay valid until they expire. [NIST IR 8587](https://doi.org/10.6028/NIST.IR.8587) (September 2026), *Protecting Tokens and Assertions from Forgery, Theft, and Misuse*, names SSF and CAEP and says cloud service providers and consuming agencies "SHOULD implement session revocation signals". It also notes "the SSF has seen significant adoption".

SSF is also the receiving end for [ITDR](https://startwithidentity.com/glossary/itdr/) and [conditional access](https://startwithidentity.com/glossary/conditional-access/): a detection in one tool becomes a session termination in many apps within seconds, which matters most for session-cookie and token theft, the paths where MFA has already been passed (see [session cookie theft](https://startwithidentity.com/techniques/session-cookie-theft/) and [refresh token abuse](https://startwithidentity.com/techniques/refresh-token-abuse/)).

For AI agents, SSF is the only Final standard that can revoke access mid-task across many resource servers. Model each agent as its own subject, subscribe every tool and MCP server it can reach as a receiver, and send `session-revoked` or `account-disabled` when the agent is disabled, its owner leaves, or its behavior trips a detection. The gap, recorded in SWI's [Agent Identity Standards Map 2026](https://startwithidentity.com/reports/agent-identity-standards-map-2026/): none of the 22 event types describes "this delegation grant was withdrawn" or "this agent was disabled", so agent semantics are a deployment convention, not a standard. The IETF [AIMS draft](https://datatracker.ietf.org/doc/draft-ietf-wimse-aims/) recommends SSF for agents on that basis.

## Adoption signals (verified)

- The OpenID Foundation's September 2025 release states that "Apple, [IBM](https://startwithidentity.com/vendors/iam/ibm-verify/), [Okta](https://startwithidentity.com/vendors/iam/okta/), and others, have already adopted these protocols."
- The specification authors work at SGNL, Okta, Coinbase, Amazon, Yubico, Cisco, Oracle and VeriClouds, per the published Final texts.
- [caep.dev](https://caep.dev/), a free online CAEP transmitter launched by [SGNL](https://startwithidentity.com/vendors/authorization/sgnl/) with the working group, is linked from the working group page for testing receivers.
- NIST IR 8587 recommends session revocation signals using SSF and CAEP.

We list only what a primary source confirms. Many IdPs and ITDR tools market "shared signals" support; check for the OpenID event type URIs and stream management API rather than the phrase.

## How to implement or evaluate

1. **Start as a receiver** in your most sensitive app: accept `session-revoked` and `credential-change` from your IdP and end matching sessions. This is where most value lands first.
2. **Ask vendors precise questions:** which SSF version, push or poll, which CAEP and RISC event types they transmit and receive, which subject identifier formats, and how long from event to enforced session end.
3. **Use short access tokens anyway.** Signals reduce exposure; they do not replace expiry. Pair them with [RFC 7009](https://www.rfc-editor.org/rfc/rfc7009.html) refresh-token revocation.
4. **Verify the stream.** Use the verification endpoint on a schedule and alert when a stream stops delivering. A silent broken stream looks exactly like a quiet day.
5. **For agents,** give each agent a stable subject identifier, register it with every receiver, and document your mapping (for example: agent disabled maps to RISC `account-disabled`).

## Pitfalls

- **Subject mismatch.** The transmitter's identifier (email, `iss`+`sub`, opaque) must resolve to the receiver's account. Agree on formats up front.
- **Receivers that log but do not act.** Test that a `session-revoked` event actually ends a live session.
- **Unauthenticated push endpoints.** Validate signatures and `aud` on every SET, or an attacker can send fake revocations or block real ones.

## Related

[MCP authorization](https://startwithidentity.com/standards/mcp-authorization/), [AuthZEN](https://startwithidentity.com/standards/authzen/), [OAuth Transaction Tokens](https://startwithidentity.com/standards/oauth-transaction-tokens/), [ID-JAG and Cross App Access](https://startwithidentity.com/standards/id-jag-cross-app-access/), the [securing AI agent identities](https://startwithidentity.com/guides/machine-identity/securing-ai-agent-identities/) guide, and the [Identity Breach Report 2026](https://startwithidentity.com/reports/identity-breach-report-2026/) for how often sessions and tokens outlived the response. Glossary: [token theft](https://startwithidentity.com/glossary/token-theft/), [MFA blind zone](https://startwithidentity.com/glossary/mfa-blind-zone/).

## Who wrote it

SSF is edited by [Atul Tulshibagwale](https://startwithidentity.com/experts/atul-tulshibagwale/), [Tim Cappalli](https://startwithidentity.com/experts/tim-cappalli/), Marius Scurtescu, [Annabelle Backman](https://startwithidentity.com/experts/annabelle-backman/), [John Bradley](https://startwithidentity.com/experts/john-bradley/) and Shayne Miel. RISC adds [Phil Hunt](https://startwithidentity.com/experts/phil-hunt/) and Stan Bounev among its authors. More in the [experts directory](https://startwithidentity.com/experts/).

## Verifiable Credentials & SD-JWT
Source: https://startwithidentity.com/standards/verifiable-credentials/
Last updated: 2026-11-05

## What it is

A Verifiable Credential (VC) is a cryptographically signed, tamper-evident digital credential a holder keeps in a [wallet](https://startwithidentity.com/glossary/digital-wallet/) and presents without the verifier calling the issuer. It is the data layer of [decentralized identity](https://startwithidentity.com/guides/fundamentals/what-is-decentralized-identity/): a machine-verifiable version of a diploma, a driver's license or proof of employment.

The term covers two standards families that share one model, the [issuer, holder, verifier](https://startwithidentity.com/glossary/issuer-holder-verifier/) triangle:

- **W3C [Verifiable Credentials Data Model 2.0](https://www.w3.org/TR/vc-data-model-2.0/)**, a JSON-LD data model secured with embedded Data Integrity proofs or enveloping JOSE and COSE signatures.
- **IETF [SD-JWT](https://startwithidentity.com/glossary/sd-jwt/) and SD-JWT VC**, a JWT-based format built for [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/), favored by the [EU wallet](https://startwithidentity.com/standards/eidas-2-eudi-wallet/).

A third family, ISO **mdoc**, covers [mobile driver's licenses](https://startwithidentity.com/standards/iso-18013-5-mdl/). [AnonCreds](https://startwithidentity.com/glossary/anoncreds/) persists in Hyperledger Indy based networks.

## Status (November 2026)

| Document | Body | Status | Date |
|---|---|---|---|
| VC Data Model 2.0 | W3C | Recommendation | 15 May 2025 |
| VC Data Integrity 1.0; ECDSA and EdDSA cryptosuites 1.0 | W3C | Recommendations (1.1 cryptosuite drafts in progress) | 15 May 2025 |
| Bitstring Status List v1.0 | W3C | Recommendation (v1.1 draft 21 October 2026) | 15 May 2025 |
| [Securing VCs using JOSE and COSE](https://www.w3.org/TR/vc-jose-cose/) | W3C | Recommendation (current edition dated 13 October 2026) | |
| Data Integrity BBS Cryptosuites v1.0 | W3C | Candidate Recommendation (draft 10 September 2026) | |
| [SD-JWT](https://www.rfc-editor.org/info/rfc9901) | IETF | RFC 9901, Proposed Standard (Fett, Yasuda, Campbell) | November 2025 |
| [SD-JWT VC](https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/) | IETF | draft-24, IESG Evaluation, "Revised I-D Needed", one DISCUSS open | 5 November 2026 |
| [Token Status List](https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/) | IETF | draft-21, RFC Editor queue | 21 June 2026 |

Dates are from the [W3C TR index](https://www.w3.org/TR/) and the IETF datatracker, checked 5 November 2026. SD-JWT VC was on the IESG telechat agenda for 5 November 2026; the DISCUSS must clear before it becomes an RFC. Note that [HAIP](https://startwithidentity.com/standards/openid4vc/) deliberately pins SD-JWT VC draft-13 and Token Status List draft-14, so production EU wallets lag the latest drafts.

## How it works

1. **Issuance.** An issuer signs claims about a subject and delivers the credential to the holder's wallet, typically over [OpenID4VCI](https://startwithidentity.com/standards/openid4vc/). The credential is bound to a key the wallet holds. The issuer's key is found through a [DID](https://startwithidentity.com/standards/decentralized-identifiers-did/), an X.509 chain, or (for SD-JWT VC) issuer metadata.
2. **Presentation.** A verifier requests specific claims over [OpenID4VP](https://startwithidentity.com/glossary/openid4vp/). The wallet builds a [verifiable presentation](https://startwithidentity.com/glossary/verifiable-presentation/) with only those claims, signed with the holder key over the verifier's nonce.
3. **Verification.** The verifier checks the issuer signature, the holder binding, validity dates and status, then decides whether it trusts the issuer, typically via a [trust registry](https://startwithidentity.com/glossary/trust-registry/) or trusted list.

**How SD-JWT selective disclosure works ([RFC 9901](https://www.rfc-editor.org/rfc/rfc9901.html)).** For each disclosable claim the issuer builds a disclosure, a base64url JSON array of salt, claim name and value, and puts its SHA-256 digest in an `_sd` array inside the JWT it signs. It may add decoy digests to hide how many claims exist. The holder sends the issuer-signed JWT followed by the disclosures it chooses, each terminated by `~`, and for holder-bound credentials a **key binding JWT** (`typ: kb+jwt`) carrying `iat`, `aud`, `nonce` and `sd_hash` over the presented SD-JWT. The verifier hashes each disclosure and matches it to a signed digest. If the issuer included a boolean age claim, a request for proof of age reveals that one claim and nothing else.

**What SD-JWT VC adds ([draft-24](https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-24.html)).** The `application/dc+sd-jwt` media type and `typ`, a required `vct` claim naming the credential type, type metadata retrievable from the `vct` URL, issuer key discovery through `/.well-known/jwt-vc-issuer` metadata or an inline `x5c` chain, and an optional `status` claim pointing at the IETF status list.

**Revocation.** The credential carries a status entry pointing to an index in a list the issuer publishes ([revocation registry](https://startwithidentity.com/glossary/revocation-registry/)). Bitstring Status List serves W3C credentials and Token Status List serves SD-JWT VC; HAIP requires the latter with a unique, unpredictable index per credential.

## Choosing a format

| Need | Format |
|---|---|
| EU wallet acceptance | SD-JWT VC or mdoc, per the ARF and HAIP |
| Driver's license, age at a counter | mdoc ([ISO/IEC 18013-5](https://startwithidentity.com/standards/iso-18013-5-mdl/)) |
| JSON-LD vocabularies, linked data | W3C VC 2.0 with Data Integrity |
| Unlinkable presentations without batch issuance | BBS ([BBS signatures](https://startwithidentity.com/glossary/bbs-signature/)) once out of CR, or AnonCreds |
| Plain workforce SSO | None. Use [OpenID Connect](https://startwithidentity.com/standards/openid-connect/) |

## Who implements it

- **[walt.id](https://startwithidentity.com/vendors/decentralized-identity/walt-id/):** [feature list](https://docs.walt.id/feature-list) covers `dc+sd-jwt`, `jwt_vc_json`, `mso_mdoc` and ISO/IEC 23220, plus Token Status List, Bitstring Status List v1.0 and older status lists. Its current stacks reject JSON-LD `ldp_vc`.
- **[Procivis](https://startwithidentity.com/vendors/decentralized-identity/procivis/):** [standards page](https://docs.procivis.ch/standards) lists SD-JWT VC (citing draft-05), mdoc, and W3C VCs with Data Integrity or JOSE and COSE, with Bitstring Status List and Token Status List revocation.
- **[Talao](https://startwithidentity.com/vendors/decentralized-identity/talao/):** [supports](https://www.talao.io/) SD-JWT VC, mdoc and W3C VCs.
- **[Microsoft Entra Verified ID](https://startwithidentity.com/vendors/decentralized-identity/microsoft-entra-verified-id/):** its [standards page](https://learn.microsoft.com/en-us/entra/verified-id/verifiable-credentials-standards) lists VC Data Model **v1.1** in JWT-VC form and a 2023 status list draft, so it predates both VC 2.0 and SD-JWT VC.
- **[MATTR](https://startwithidentity.com/vendors/decentralized-identity/mattr/)** and **[Hyperledger Indy, Aries and AnonCreds](https://startwithidentity.com/vendors/decentralized-identity/hyperledger-indy-aries/)** cover the mdoc and AnonCreds ends of the market.

Rankings: [best verifiable credential platforms](https://startwithidentity.com/rankings/best-verifiable-credential-platforms/), [best decentralized identity for KYC](https://startwithidentity.com/rankings/best-decentralized-identity-for-kyc/).

## Security and privacy pitfalls

- **Signature-only verification.** A valid issuer signature without a holder binding check accepts a stolen or copied credential. Always verify the key binding JWT or Data Integrity presentation proof against your nonce.
- **Correlation by signature.** Showing the same SD-JWT VC twice reveals the same issuer signature and digests, so colluding verifiers can link the user. Use batch issuance and one presentation per copy, or an unlinkable scheme.
- **Weak salts.** RFC 9901 relies on salts to stop verifiers guessing undisclosed values from their digests and recommends at least 128 bits of randomness. Use a vetted library, not a hand-rolled one.
- **Status list privacy and freshness.** Cache status lists sensibly; fetching per credential leaks timing, and stale lists accept revoked credentials.
- **Trusting the issuer field.** Anyone can mint a DID and sign a credential. Trust comes from your issuer allowlist or trust registry.
- **Version mismatch.** SD-JWT VC draft numbers, VC 1.1 versus 2.0, and status list versions all break interop silently. Pin versions per verifier.

## Related

Guides: [what is decentralized identity](https://startwithidentity.com/guides/fundamentals/what-is-decentralized-identity/), [verifiable credentials implementation guide](https://startwithidentity.com/guides/decentralized-identity/verifiable-credentials-implementation-guide/), [reusable identity and KYC with verifiable credentials](https://startwithidentity.com/guides/decentralized-identity/reusable-identity-and-kyc-with-verifiable-credentials/). Articles: [verifiable credentials use cases](https://startwithidentity.com/articles/verifiable-credentials-use-cases/). Standards: [DID](https://startwithidentity.com/standards/decentralized-identifiers-did/), [OpenID4VC](https://startwithidentity.com/standards/openid4vc/), [mDL](https://startwithidentity.com/standards/iso-18013-5-mdl/), [eIDAS 2 / EUDI Wallet](https://startwithidentity.com/standards/eidas-2-eudi-wallet/). Glossary: [verifiable credential](https://startwithidentity.com/glossary/verifiable-credential/), [SD-JWT](https://startwithidentity.com/glossary/sd-jwt/), [verifiable presentation](https://startwithidentity.com/glossary/verifiable-presentation/), [JWT](https://startwithidentity.com/glossary/jwt/), [zero-knowledge proof](https://startwithidentity.com/glossary/zero-knowledge-proof/). Vendors: [decentralized identity](https://startwithidentity.com/vendors/decentralized-identity/). Directory: [digital IDs by country](https://startwithidentity.com/digital-ids/).

## Who wrote it

[Manu Sporny](https://startwithidentity.com/experts/manu-sporny/) kickstarted the W3C work behind verifiable credentials and co-created JSON-LD underneath it. Selective disclosure rests on [Daniel Fett](https://startwithidentity.com/experts/daniel-fett/)'s SD-JWT and on BBS signatures, co-edited by [Tobias Looker](https://startwithidentity.com/experts/tobias-looker/) and built on the BLS scheme co-authored by [Dan Boneh](https://startwithidentity.com/experts/dan-boneh/). More in the [experts directory](https://startwithidentity.com/experts/).

## WebAuthn / FIDO2
Source: https://startwithidentity.com/standards/webauthn-fido2/
Last updated: 2026-11-05

## What it is

WebAuthn is the W3C browser API for public-key authentication, and FIDO2 is the broader FIDO Alliance specification set: WebAuthn plus CTAP, the protocol that talks to authenticators. Together they are the foundation of [passkeys](https://startwithidentity.com/guides/authentication/passkeys-101/) and hardware security keys, and they make [phishing-resistant authentication](https://startwithidentity.com/glossary/phishing-resistant-mfa/) practical at scale. The relying party (your site) stores only a public key, and the authenticator signs a fresh challenge that is bound to your origin, so there is no reusable secret to phish or leak.

## Status (November 2026)

| Spec | Body | Status |
| --- | --- | --- |
| [Web Authentication Level 3](https://www.w3.org/TR/webauthn-3/) | W3C Web Authentication WG | **W3C Recommendation, 25 August 2026** |
| Web Authentication Level 2 | W3C | Recommendation, 8 April 2021 (superseded) |
| [CTAP 2.3](https://fidoalliance.org/specifications/download/) | FIDO Alliance | Proposed Standard (26 February 2026) |
| CTAP 2.2 | FIDO Alliance | Proposed Standard (14 July 2025); adds hybrid transports |
| CTAP 2.3.1 | FIDO Alliance | Working Draft (29 May 2026) |

Level 3 went from a Candidate Recommendation Snapshot on 26 May 2026 to Recommendation with, in the W3C's words, "no substantive changes." Its editors are Tim Cappalli ([Okta](https://startwithidentity.com/vendors/iam/okta/)), Akshay Kumar (Microsoft), Emil Lundberg ([Yubico](https://startwithidentity.com/vendors/mfa/yubico/)), Matthew Miller (Cisco), Pascoe (Apple) and Nina Satragno (Google). CTAP dates above come from the document identifiers on the FIDO Alliance download page; the FIDO patent promise applies at Proposed Standard, not Working Draft.

## How it works

### Registration (create)

1. The relying party generates a random challenge and calls `navigator.credentials.create()` with its RP ID (a registrable domain such as `example.com`), a user handle, acceptable algorithms, and preferences such as `residentKey` and `userVerification`.
2. The browser builds `clientDataJSON` containing the challenge, the calling origin and the ceremony type, and passes a hash of it to the authenticator, over CTAP if the authenticator is external.
3. The authenticator asks for a user gesture (touch, biometric or PIN), generates a new key pair scoped to the RP ID, and returns the public key, a credential ID and `authenticatorData` with flags: user present (UP), user verified (UV), backup eligible (BE) and backup state (BS). It may include an attestation statement.
4. The relying party verifies the challenge, the origin, the RP ID hash and the flags, optionally validates attestation, and stores the credential ID, public key, signature counter and backup flags against the account.

### Authentication (get)

1. The relying party sends a new challenge via `navigator.credentials.get()`, either with a list of allowed credential IDs or empty, so the user can pick a discoverable credential (a passkey).
2. The authenticator finds the credential for this RP ID, gets the user gesture, and signs `authenticatorData` plus the hash of `clientDataJSON`.
3. The relying party verifies the signature with the stored public key, checks the challenge, origin, RP ID hash and UV flag, and starts a session.

**Origin binding is the security property.** The browser writes the real origin into `clientDataJSON` and the authenticator only releases a credential for the matching RP ID. A lookalike domain gets nothing usable, which is why [adversary-in-the-middle phishing proxies](https://startwithidentity.com/techniques/aitm-phishing-proxy/) fail against WebAuthn when the relying party checks the origin.

### Level 3 features practitioners meet

The Level 3 text defines several capabilities worth knowing about: `getClientCapabilities()` to ask the browser what it supports; `parseCreationOptionsFromJSON()` and `parseRequestOptionsFromJSON()` so servers can send options as JSON; signal methods (`signalUnknownCredential`, `signalAllAcceptedCredentials`, `signalCurrentUserDetails`) that let a site tell a passkey provider a credential was deleted or a user renamed; user-agent **hints**; **related origins**, so one passkey can work across a set of your domains; the BE and BS backup flags, which tell you whether a credential is a [synced passkey](https://startwithidentity.com/glossary/synced-passkey/); `topOrigin` for cross-origin iframes; and the `prf` and `largeBlob` extensions.

## Synced versus device-bound

| | Synced passkey | Device-bound passkey or security key |
| --- | --- | --- |
| Private key | Encrypted and synced by a provider (Apple, Google, a password manager) | Never leaves one authenticator |
| Attestation | Not supported for synced passkeys, per [Microsoft's Entra documentation](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-passkey-fido2) | Available, so you can verify make and model |
| Recovery | Survives device loss | Needs a second registered authenticator |
| Fit | Consumers, most workforce users | Admins, regulated roles, shared or controlled devices |

Microsoft's guidance is to treat synced passkeys as phishing-resistant but "with the same security posture as other unattested authenticators." That is a useful default for any relying party: allow synced passkeys broadly, and require attested, device-bound credentials (filtered by AAGUID) for privileged roles.

## Common implementation mistakes and attacks

| Mistake or attack | What goes wrong | In our catalog |
| --- | --- | --- |
| Server-side credential handling bugs | The server accepts an assertion for the wrong credential type, authenticating the attacker as the victim | [CVE-2025-26788](https://startwithidentity.com/cves/cve-2025-26788/) (StrongKey FIDO Server) |
| Assertion material leaked to logs | Recovered assertions replayed ("Pass-the-Passkey") | [CVE-2026-34348](https://startwithidentity.com/cves/cve-2026-34348/) (Windows event logging, replayed against Entra ID) |
| Not checking UV when policy needs it | A touch-only assertion satisfies a policy that assumed a PIN or biometric | Check the UV flag server-side |
| Not checking origin and RP ID | Removes the phishing resistance you deployed passkeys for | Use a maintained server library |
| Weak recovery and enrollment | Attackers skip the passkey and attack the reset path | [Help desk social engineering](https://startwithidentity.com/techniques/help-desk-social-engineering/), [account recovery](https://startwithidentity.com/glossary/account-recovery/) |
| Password or SMS left as fallback | Phishing simply targets the fallback | [Phishable MFA](https://startwithidentity.com/glossary/phishable-mfa/) |
| Session stolen after login | The passkey protected sign-in, not the cookie | [Session cookie theft](https://startwithidentity.com/techniques/session-cookie-theft/), [infostealers](https://startwithidentity.com/techniques/infostealer-credential-harvesting/) |
| Trusting AAGUID without attestation | AAGUID is self-reported unless attestation is verified | Microsoft: use AAGUID lists "as a policy guide rather than a strict security control" when attestation is off |

## Related standards

[OpenID Connect](https://startwithidentity.com/standards/openid-connect/) and [SAML](https://startwithidentity.com/standards/saml-2-0/) carry the result of a WebAuthn login from your IdP to applications, and OIDC's `amr` and `acr` claims are how an app learns a passkey was used. [NIST SP 800-63](https://startwithidentity.com/glossary/nist-800-63/) requires phishing-resistant authenticators at the highest authenticator assurance level ([AAL](https://startwithidentity.com/glossary/aal/)3). [Device Bound Session Credentials](https://startwithidentity.com/glossary/device-bound-session-credentials/) target the post-login session that WebAuthn does not cover. [FAPI 2.0](https://startwithidentity.com/standards/fapi/) and [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/) cover the API tokens issued afterwards.

## Who implements it

- **Authenticators:** platform authenticators in Apple, Google and Microsoft operating systems; hardware keys such as the Yubico YubiKey 5 Series, which lists FIDO2 alongside U2F, smart card, OTP and OpenPGP on [its product page](https://www.yubico.com/products/yubikey-5-overview/); and password managers acting as passkey providers, such as [1Password](https://startwithidentity.com/vendors/password-management/1password/) and [Bitwarden](https://startwithidentity.com/vendors/password-management/bitwarden/), which Microsoft's Entra documentation names as supported synced passkey providers.
- **Relying parties and IdPs:** [Microsoft Entra ID](https://startwithidentity.com/vendors/iam/microsoft-entra/) supports synced passkeys and device-bound passkeys on FIDO2 security keys and in Microsoft Authenticator, in all editions including Free, with passkey profiles that set attestation, passkey type and AAGUID allow or block lists per group.
- For the wider market, see [MFA and passwordless vendors](https://startwithidentity.com/vendors/mfa/), the [MFA matrix](https://startwithidentity.com/tools/mfa-matrix/), and SWI's [Phishing-Resistant MFA Matrix 2026](https://startwithidentity.com/reports/phishing-resistant-mfa-matrix-2026/).

## When to use it

For any account where phishing and account takeover matter, which is most of them. Synced passkeys suit consumers; device-bound passkeys and hardware keys suit high-value and workforce use. Plan enrollment, a second authenticator per user, and recovery before you remove passwords, because those are the steps attackers target next.

## How it works, message by message

The [WebAuthn message-flow walkthrough](https://startwithidentity.com/guides/protocols/webauthn-message-flow/) decodes both ceremonies: creation options, the attestation response, `clientDataJSON`, authenticator data byte by byte and flags, request options and the assertion, with each field tied to its Level 3 section and the relying party checks from §7.1 and §7.2. Try a ceremony in the [WebAuthn tester](https://startwithidentity.com/tools/webauthn-tester/).

## Related

Guides: [Passkeys 101](https://startwithidentity.com/guides/authentication/passkeys-101/), [implementing passkeys in the enterprise](https://startwithidentity.com/guides/authentication/implementing-passkeys-enterprise/), [what is passwordless](https://startwithidentity.com/guides/fundamentals/what-is-passwordless/), [MFA implementation best practices](https://startwithidentity.com/guides/authentication/mfa-implementation-best-practices/). Glossary: [FIDO2](https://startwithidentity.com/glossary/fido2/), [WebAuthn](https://startwithidentity.com/glossary/webauthn/), [passkey](https://startwithidentity.com/glossary/passkey/), [relying party](https://startwithidentity.com/glossary/relying-party/).

## Who wrote it

The WebAuthn specification is edited by a group including [Tim Cappalli](https://startwithidentity.com/experts/tim-cappalli/) and [Emil Lundberg](https://startwithidentity.com/experts/emil-lundberg/), with [John Bradley](https://startwithidentity.com/experts/john-bradley/) a long-standing co-author across WebAuthn and FIDO2. The hardware lineage runs back to [Stina Ehrensvard](https://startwithidentity.com/experts/stina-ehrensvard/), who co-invented the YubiKey, and adoption was driven by the FIDO Alliance under [Andrew Shikiar](https://startwithidentity.com/experts/andrew-shikiar/). More in the [experts directory](https://startwithidentity.com/experts/).

## WIMSE (Workload Identity in Multi-System Environments)
Source: https://startwithidentity.com/standards/wimse/
Last updated: 2026-11-05

## What it is

WIMSE is the [IETF working group](https://datatracker.ietf.org/wg/wimse/about/) standardizing how software workloads (services, jobs, functions, AI agents) identify and authenticate to each other at runtime, across clusters, clouds and organizations. Its drafts define four pieces: a **workload identifier** URI, two **credential** formats that bind a key to that identifier (a JWT and an X.509 certificate), **proof of possession** so a stolen credential cannot simply be replayed, and an **architecture** for carrying security context through call chains.

The charter scopes it to "the unique identity and access management aspects of workloads at runtime", building on OAuth, JWT and [SPIFFE](https://startwithidentity.com/glossary/spiffe/), and to "only specific REST-based technologies using HTTP." Static software identity and provenance (SBOMs), personal identities, deployment chains and supply chain management are out of scope. The working group sits in the Applications and Real-Time Area; the chairs are [Justin Richer](https://startwithidentity.com/experts/justin-richer/) and Pieter Kasselman.

The short version for practitioners: WIMSE is trying to replace static API keys and long-lived shared secrets between services with short-lived, key-bound credentials that any environment can verify. The [WIMSE glossary entry](https://startwithidentity.com/glossary/wimse/) has the one-paragraph definition.

## Status (5 November 2026)

None of the WIMSE documents is an RFC. From the [WIMSE documents page](https://datatracker.ietf.org/wg/wimse/documents/):

| Draft | Rev, date | What it defines | State |
| --- | --- | --- | --- |
| [draft-ietf-wimse-http-signature](https://datatracker.ietf.org/doc/draft-ietf-wimse-http-signature/) | -08, 20 Oct 2026 | Workload-to-workload authentication with HTTP Message Signatures | Publication Requested; submitted to IESG as Proposed Standard |
| [draft-ietf-wimse-workload-identity-practices](https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-identity-practices/) | -08, 30 Oct 2026 | Survey of current practice (Kubernetes, cloud, SPIFFE, CI/CD, meshes) | In Last Call, ends 13 Nov 2026; Informational |
| [draft-ietf-wimse-arch](https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/) | -08, 6 Jul 2026 | Architecture | WG Document; Informational |
| [draft-ietf-wimse-identifier](https://datatracker.ietf.org/doc/draft-ietf-wimse-identifier/) | -04, 23 Oct 2026 | Workload Identifier URI | WG Document; Standards Track |
| [draft-ietf-wimse-workload-creds](https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-creds/) | -03, 30 Oct 2026 | Workload Identity Token (WIT) and Certificate (WIC) | WG Document; Standards Track |
| [draft-ietf-wimse-wpt](https://datatracker.ietf.org/doc/draft-ietf-wimse-wpt/) | -02, 27 Aug 2026 | Workload Proof Token | WG Document; Standards Track |
| [draft-ietf-wimse-mutual-tls](https://datatracker.ietf.org/doc/draft-ietf-wimse-mutual-tls/) | -03, 24 Oct 2026 | Workload authentication over mutual TLS | WG Document |
| [draft-ietf-wimse-aims](https://datatracker.ietf.org/doc/draft-ietf-wimse-aims/) | -01, 2 Nov 2026 | AI Identity Management System | WG Document; Informational |

The original service-to-service protocol, [draft-ietf-wimse-s2s-protocol](https://datatracker.ietf.org/doc/draft-ietf-wimse-s2s-protocol/), stopped at -07 (16 October 2025) and is marked replaced by the workload-creds, http-signature, mutual-tls and wpt drafts. Older blog posts that cite "the WIMSE S2S draft" refer to that document.

The charter's milestones are behind schedule: the architecture was due to the IESG by 31 July 2026 and is still a working group draft. The datatracker also lists 20 related individual drafts, most about AI agent delegation; those have no working group standing.

## How it works

### The building blocks

- **Trust domain.** "A logical grouping of systems that share a common set of security controls and policies", named by a fully qualified domain name (architecture draft).
- **Workload identifier.** An absolute URI whose authority is the trust domain, with a non-empty path and no query, fragment, user info or port. The identifier draft defines `wimse://<trust-domain>/<path>`, for example `wimse://trust.example.com/service/payment`, and allows other schemes such as `spiffe://`. Consumers must compare the full normalized URI and must treat it as authenticated only when it came from a validated credential.
- **Workload Identity Token (WIT).** A JWS-signed JWT with `typ` `wit+jwt` (media type `application/wit+jwt`). Required claims: `sub` (one workload identifier), `exp` (refresh on the order of hours) and `cnf` with a `jwk` holding the workload's public key. `iss` is recommended, `jti` optional, `alg: none` forbidden, and ES256 must be supported. It travels in the `Workload-Identity-Token` HTTP header.
- **Workload Identity Certificate (WIC).** An X.509 certificate carrying exactly one workload identifier in a URI SubjectAltName, short-lived like a WIT, for mutual TLS.

The credentials draft is explicit that a WIT "MUST NOT be used as a bearer token." It always travels with a proof of possession.

### A workload-to-workload call with HTTP signatures

1. The workload obtains a WIT from its trust domain's issuer, typically after attestation (the architecture aligns with RATS, RFC 9334, and cites SPIRE as an example of attestation-based provisioning).
2. For each request it signs, per [RFC 9421](https://www.rfc-editor.org/rfc/rfc9421.html), `@method`, `@path` and `@query`, plus `Content-Type`, `Content-Digest`, `Authorization`, `Txn-Token` and `Workload-Identity-Token` when present. `@authority` is deliberately not covered so proxies can rewrite it.
3. The signature parameters include `created`, a short `expires`, a `nonce`, `tag` set to `wimse-workload-to-workload`, and `wimse-aud` naming the intended recipient. `keyid` and `alg` must not be used; the algorithm comes from the WIT's `cnf.jwk.alg`.
4. The receiver validates the WIT against the trust anchors for its trust domain, then verifies the signature with the public key in `cnf`, then authorizes on the full workload identifier.
5. Optionally, the client sets `wimse-sign-response` and the server signs its response, echoing the request nonce in `wimse-req-nonce`.

### The alternatives: Workload Proof Token and mTLS

The **Workload Proof Token** (WPT, `typ` `wpt+jwt`) is a per-request JWT signed with the WIT's key and sent as `Authorization: WPT <token>`. It carries `aud` (the target URI), a short `exp`, a 128-bit `jti`, and `wth`, the SHA-256 hash of the WIT. It can also bind other tokens on the request: `tth` for a [Transaction Token](https://startwithidentity.com/standards/oauth-transaction-tokens/) and `oth` for others. Receivers should reject a reused `jti` within the validity window, and implementations must not log raw WPTs by default. Use the WPT when you want a token-shaped proof; use HTTP signatures when you want the request body and headers covered.

The **mutual TLS** draft profiles the WIC: exactly one URI SAN with a workload identifier, chain validation to the anchor configured for that trust domain, and authorization on the whole identifier, never the path alone. It is the natural fit for service meshes that already terminate mTLS in sidecars.

## Where WIMSE fits with other standards

| Need | Standard |
| --- | --- |
| Workload proves who it is to another workload | WIMSE credentials plus HTTP signatures, WPT or mTLS |
| Carry the user and request context through internal hops | [OAuth Transaction Tokens](https://startwithidentity.com/standards/oauth-transaction-tokens/), bound into a WPT with `tth` |
| Workload calls an OAuth-protected API | [OAuth 2.0](https://startwithidentity.com/standards/oauth-2-0/) client credentials or [token exchange](https://startwithidentity.com/glossary/token-exchange/) (RFC 8693) |
| Agent acts for a user across apps | [ID-JAG and Cross App Access](https://startwithidentity.com/standards/id-jag-cross-app-access/), [MCP authorization](https://startwithidentity.com/standards/mcp-authorization/) |
| Revoke or react to compromise | [Shared Signals Framework](https://startwithidentity.com/standards/shared-signals-framework/) |

The architecture draft uses token exchange for delegation and impersonation, Transaction Tokens for context propagation, and OAuth identity chaining for cross-domain calls. WIMSE authenticates the caller; those documents carry what the caller is allowed to do and on whose behalf.

## Common mistakes the drafts warn about

- **Treating the WIT as a bearer token.** Without the proof of possession, a logged or intercepted WIT is a replayable credential, which is the [token replay at an unbound endpoint](https://startwithidentity.com/techniques/token-replay-unbound-endpoint/) pattern.
- **Authorizing on the path alone.** `/service/payment` means nothing outside its trust domain; compare the whole identifier.
- **Weak replay caches.** The WPT draft notes that if replay caches are not shared across validators and an attacker can choose which validator receives a message, replay protection may fail.
- **Secrets in environment variables.** The practices draft recommends delivering credentials via the filesystem or a local API, using a distinct audience per target, and preferring proof-of-possession over bearer tokens. See [secrets in repositories and CI](https://startwithidentity.com/techniques/secrets-in-repositories-and-ci/) and [static API key abuse](https://startwithidentity.com/techniques/static-api-key-abuse/) for what happens otherwise.

## Who is building it

Draft authors, as listed on the datatracker, include Joseph Salowey ([Palo Alto Networks](https://startwithidentity.com/vendors/zero-trust/palo-alto/)), Yaroslav Rosomakho ([Zscaler](https://startwithidentity.com/vendors/zero-trust/zscaler/)), [Brian Campbell](https://startwithidentity.com/experts/brian-campbell/) ([Ping Identity](https://startwithidentity.com/vendors/iam/ping-identity/)), Arndt Schwenkschuster and Pieter Kasselman ([Defakto (formerly SPIRL)](https://startwithidentity.com/vendors/machine-identity/spirl/)), Yaron Sheffer, and [Hannes Tschofenig](https://startwithidentity.com/experts/hannes-tschofenig/) on the architecture. The AIMS draft adds Jeff Lombardo (AWS), Nick Steele (OpenAI) and [Aaron Parecki](https://startwithidentity.com/experts/aaron-parecki/) ([Okta](https://startwithidentity.com/vendors/iam/okta/)). Authorship is not product support: no vendor has shipped a final WIMSE standard because none exists yet. The open source [SPIFFE / SPIRE](https://startwithidentity.com/vendors/machine-identity/spiffe-spire/) project is the closest deployed relative, and workload identity vendors such as [Aembit](https://startwithidentity.com/vendors/ai-identity/aembit/) solve the same problem today with their own mechanisms.

## How to prepare

1. Inventory service-to-service credentials and flag every static API key and long-lived shared secret.
2. Adopt URI workload identifiers now (SPIFFE IDs work), named by trust domain.
3. Move to short-lived, key-bound credentials (SPIFFE SVIDs or cloud workload identity federation) delivered by a local API.
4. Keep authorization on the full identifier, and carry user context separately in Transaction Tokens.
5. Track the http-signature draft through the IESG; it is the first WIMSE protocol likely to become an RFC.

## Related

Guides: [workload identity 101](https://startwithidentity.com/guides/machine-identity/workload-identity-101/), [securing AI agent identities](https://startwithidentity.com/guides/machine-identity/securing-ai-agent-identities/), [Kubernetes identity security](https://startwithidentity.com/guides/machine-identity/kubernetes-identity-security-guide/), [what is a non-human identity](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/). Report: [Agent Identity Standards Map 2026](https://startwithidentity.com/reports/agent-identity-standards-map-2026/). Glossary: [workload identity](https://startwithidentity.com/glossary/workload-identity/), [SPIFFE](https://startwithidentity.com/glossary/spiffe/), [workload identity federation](https://startwithidentity.com/glossary/workload-identity-federation/), [mTLS](https://startwithidentity.com/glossary/mtls/), [proof of possession](https://startwithidentity.com/glossary/proof-of-possession/), [NHI](https://startwithidentity.com/glossary/nhi/).

# Glossary

## aal
Source: https://startwithidentity.com/glossary/aal/
Last updated: 2026-08-29

NIST 800-63B levels describing authentication strength. AAL1: single factor. AAL2: multi-factor. AAL3: multi-factor with phishing-resistant cryptographic authenticator (FIDO2, smartcards). Higher AAL is mandatory for higher-impact systems.

Assurance levels matter because they let a policy say "this action requires AAL2" instead of naming a specific product, which survives vendor changes. The practical jump is AAL2 to AAL3: push notifications and one-time codes satisfy AAL2 but are relayed by attacker-in-the-middle kits every day, while AAL3 requires a cryptographic authenticator bound to the origin. US federal systems and a growing set of regulated industries map controls directly to these levels.

See also: [NIST 800-63](https://startwithidentity.com/glossary/nist-800-63/), [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/), [WebAuthn and FIDO2](https://startwithidentity.com/standards/webauthn-fido2/), [IAL](https://startwithidentity.com/glossary/ial/)

## abac
Source: https://startwithidentity.com/glossary/abac/
Last updated: 2026-08-29

Attribute-Based Access Control. Access decisions are made by evaluating attributes of the subject, resource, action, and environment against policy. Flexible but harder to audit than RBAC. Often expressed in XACML or modern policy languages like Rego.

ABAC earns its complexity when access depends on data the role cannot express: clearance level, project membership, time of day, device posture, or record ownership. The cost is auditability. A reviewer can read a role assignment; they cannot easily answer "who can read this record" from a policy file without evaluating it. Most mature deployments use roles for the coarse grant and attributes for the fine-grained condition rather than choosing one.

See also: [RBAC vs ABAC vs ReBAC](https://startwithidentity.com/guides/fundamentals/rbac-vs-abac-vs-rebac/), [ReBAC](https://startwithidentity.com/glossary/rebac/), [fine-grained authorization](https://startwithidentity.com/glossary/fga/), [authorization vendors](https://startwithidentity.com/vendors/authorization/)

## access-certification
Source: https://startwithidentity.com/glossary/access-certification/
Last updated: 2026-08-29

Periodic review of who has access to what, with managers or resource owners attesting that access is still appropriate. A regulatory requirement in many industries and a core IGA workflow.

Certification is where governance meets reality, and it fails in a predictable way: reviewers rubber-stamp because they are shown raw entitlement names with no context on what the access does or who else has it. Campaigns that show usage data ("this account has not used this entitlement in 180 days") get real revocations. Campaigns that show a list of group names get approvals. Auditors increasingly ask for the revocation rate, not the completion rate.

See also: [what is IGA](https://startwithidentity.com/guides/fundamentals/what-is-iga/), [entitlement](https://startwithidentity.com/glossary/entitlement/), [segregation of duties](https://startwithidentity.com/glossary/sod/), [IGA vendors](https://startwithidentity.com/vendors/iga/)

## access-token
Source: https://startwithidentity.com/glossary/access-token/
Last updated: 2026-08-29

A short-lived credential a client presents to a resource server to access protected data. Access tokens are typically opaque or JWT-formatted, with lifetimes measured in minutes. Treat them as bearer secrets: anyone holding the token can use it.

Because most access tokens are bearer tokens, possession is authorization: anyone holding one can use it until it expires. That is why token theft from browser sessions and infostealer logs has displaced password phishing as the dominant account-takeover path, and why a password reset does nothing to contain it. Short lifetimes limit the window; sender-constraining with DPoP or mTLS closes it by binding the token to a key the thief does not have.

See also: [OAuth 2.0](https://startwithidentity.com/standards/oauth-2-0/), [refresh token](https://startwithidentity.com/glossary/refresh-token/), [DPoP](https://startwithidentity.com/glossary/dpop/), [token theft](https://startwithidentity.com/glossary/token-theft/), [token introspection](https://startwithidentity.com/glossary/token-introspection/)

## account-recovery
Source: https://startwithidentity.com/glossary/account-recovery/
Last updated: 2026-11-05

The process by which a user regains access after losing their authenticator: a lost device, a forgotten password, or a revoked credential. It is a parallel authentication path, and its strength sets the real strength of the account.

Recovery is the most commonly under-designed part of an identity system. Deploying phishing-resistant authentication and then allowing a help desk to reset credentials after a few knowledge-based questions means the account's real assurance level is whatever the help desk enforces, and attackers know it. Passwordless deployments face this acutely: with no password to fall back on, recovery has to be designed deliberately, usually through multiple enrolled authenticators, a recovery code, or identity proofing at the same assurance level as enrolment.

See also: [help desk social engineering](https://startwithidentity.com/techniques/help-desk-social-engineering/), [what is passwordless](https://startwithidentity.com/guides/fundamentals/what-is-passwordless/), [passkey](https://startwithidentity.com/glossary/passkey/), [IDV](https://startwithidentity.com/glossary/idv/), [Temporary Access Pass](https://startwithidentity.com/glossary/temporary-access-pass/)

## account-takeover
Source: https://startwithidentity.com/glossary/account-takeover/
Last updated: 2026-08-29

When an attacker gains control of a legitimate account, often via stolen credentials, phishing, or session theft. A leading cause of breaches and fraud.

The distinguishing feature of ATO is that nothing looks broken: the login succeeds, the log line is normal, and detection has to come from behavior rather than from a failure. The three supply chains feeding it are infostealer logs, credential dumps replayed against unrelated sites, and real-time relay kits that capture a valid session. Each defeats a different control, which is why layered detection plus phishing-resistant credentials beats any single fix.

See also: [credential stuffing](https://startwithidentity.com/glossary/credential-stuffing/), [session hijacking](https://startwithidentity.com/glossary/session-hijacking/), [what is ITDR](https://startwithidentity.com/guides/fundamentals/what-is-itdr/), [infostealer session hijacking teardown](https://startwithidentity.com/breaches/infostealer-session-hijacking/)

## acme
Source: https://startwithidentity.com/glossary/acme/
Last updated: 2026-11-05

ACME (Automated Certificate Management Environment) is the IETF protocol, [RFC 8555](https://www.rfc-editor.org/rfc/rfc8555) (March 2019, Proposed Standard), that lets a server request, renew and revoke X.509 certificates from a certificate authority with no human in the loop, proving control of the domain through a challenge such as `http-01` or `dns-01`. It is what most people mean by automated certificate management.

A client (certbot, cert-manager in Kubernetes, or a web server's built-in client) creates an account key, places an order for a domain, answers the CA's challenge by publishing a token at a well-known HTTP path or in a DNS TXT record, then submits a certificate signing request and downloads the certificate. Renewal repeats the same steps on a schedule. [Let's Encrypt](https://startwithidentity.com/vendors/pki/lets-encrypt/), which helped standardize the protocol, issues certificates only through ACME; commercial CAs such as [DigiCert](https://startwithidentity.com/vendors/pki/digicert/) and [Sectigo](https://startwithidentity.com/vendors/pki/sectigo/) and private CAs such as [Smallstep](https://startwithidentity.com/vendors/pki/smallstep/) also support it.

| Challenge | How control is proven | Fits |
|---|---|---|
| `http-01` | File served on port 80 of the domain | Single public web servers |
| `dns-01` | TXT record in the domain's DNS | Wildcards, internal hosts, load balancers |

It matters more every year because certificate lifetimes are shrinking. Under CA/Browser Forum [Ballot SC-081v3](https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/), public TLS certificates have been capped at 200 days since March 15, 2026, falling to 100 days in 2027 and 47 days from March 15, 2029. At 47 days, renewing by ticket is not workable. ACME solves issuance and renewal, not inventory: you still need [certificate lifecycle management](https://startwithidentity.com/glossary/certificate-lifecycle/) to find certificates nobody automated, and protection for the `dns-01` API credentials, which can issue certificates for the whole domain.

See also: [certificate authority](https://startwithidentity.com/glossary/certificate-authority/), [PKI](https://startwithidentity.com/glossary/pki/), [X.509](https://startwithidentity.com/glossary/x509/), [certificate lifecycle management guide](https://startwithidentity.com/guides/machine-identity/certificate-lifecycle-management-guide/), [open-source PKI and certificate management tools](https://startwithidentity.com/articles/top-6-open-source-pki-certificate-management-tools/)

## active-directory
Source: https://startwithidentity.com/glossary/active-directory/
Last updated: 2026-11-05

Microsoft's on-premises directory service, providing authentication, authorization, group policy, and a hierarchical store of users, computers, and groups for a Windows domain. It authenticates with Kerberos, falls back to NTLM, and exposes its directory over LDAP.

Active Directory has been the centre of enterprise identity since 2000 and remains so at most organizations, including those that consider themselves cloud-first: the cloud tenant is usually synchronized from it, which makes the on-premises domain a path into the cloud one. That hybrid seam is where a large share of real intrusions travel. Entra ID is a separate product with a different model, not a hosted version of Active Directory, and conflating the two causes both architectural and security mistakes.

See also: [Kerberos](https://startwithidentity.com/glossary/kerberos/), [LDAP](https://startwithidentity.com/glossary/ldap/), [NTLM](https://startwithidentity.com/glossary/ntlm/), [primary refresh token theft](https://startwithidentity.com/techniques/primary-refresh-token-theft/), [best ITDR for Active Directory](https://startwithidentity.com/rankings/best-itdr-for-active-directory/), [directory service](https://startwithidentity.com/glossary/directory-service/)

## adaptive-auth
Source: https://startwithidentity.com/glossary/adaptive-auth/
Last updated: 2026-08-29

Authentication flows that change based on risk signals. Low-risk sign-ins may complete with one factor; high-risk sign-ins escalate to step-up MFA or are blocked. Synonym in most contexts: risk-based authentication.

The value of adaptive authentication is that it lets you raise assurance without raising friction for everyone, which is the only way strong controls survive contact with a consumer funnel. The risk is that the signals are mostly heuristics: IP reputation, geo-velocity, and device fingerprints all degrade as attackers use residential proxies and real browsers. Treat risk scoring as a way to decide when to demand a phishing-resistant factor, not as a replacement for one.

See also: [risk-based auth](https://startwithidentity.com/glossary/risk-based-auth/), [conditional access](https://startwithidentity.com/glossary/conditional-access/), [step-up auth](https://startwithidentity.com/glossary/step-up-auth/), [device posture](https://startwithidentity.com/glossary/device-posture/)

## adversary-in-the-middle
Source: https://startwithidentity.com/glossary/adversary-in-the-middle/
Last updated: 2026-10-16

Adversary-in-the-middle (AitM, written AiTM by MITRE) is an attack in which the attacker positions itself between two parties, such as a user and a sign-in service, so it can read, alter or replay what passes between them. MITRE ATT&CK catalogs it as [T1557](https://attack.mitre.org/techniques/T1557/).

ATT&CK's sub-techniques cover network positions such as ARP cache poisoning, DHCP spoofing and evil twin Wi-Fi, but in identity security the term now mostly means AitM phishing: a reverse proxy such as evilginx2, which MITRE lists under T1557, serves the real login page through the attacker's domain, relays the password and MFA challenge to the genuine service, and keeps the session cookie that comes back. Because the user completes a real sign-in, one-time codes, push approvals and number matching all pass straight through, and the captured session survives a password change until it is revoked. In October 2026 Cisco Talos described [UAT-11985 relaying Google passwords and MFA challenges](https://startwithidentity.com/blog/2026-10-08-uat-11985-fake-event-invites-target-taiwan-researchers-with-google-aitm-phishing/) from Taiwan research affiliates lured with fake event invitations. The control that breaks the relay is [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/), because a passkey or security key will not sign for the proxy's origin, backed by session revocation after any suspected exposure.

See also: [AitM phishing proxy](https://startwithidentity.com/techniques/aitm-phishing-proxy/), [session cookie theft](https://startwithidentity.com/techniques/session-cookie-theft/), [session hijacking](https://startwithidentity.com/glossary/session-hijacking/), [browser-in-the-browser](https://startwithidentity.com/glossary/browser-in-the-browser/), [Device Bound Session Credentials](https://startwithidentity.com/glossary/device-bound-session-credentials/)

## age-verification
Source: https://startwithidentity.com/glossary/age-verification/
Last updated: 2026-10-17

Age verification is a check that establishes a user's exact age, or that they are over a threshold such as 18, from an authoritative source like a government ID, a digital identity credential or a bank record. It is one form of age assurance; the other is age estimation, which infers an age or age range from signals such as a face image.

The UK [Online Safety Act 2023](https://www.legislation.gov.uk/ukpga/2023/50/section/230) draws that line in law: age verification is any measure "designed to verify the exact age" of users, age estimation estimates "the age or age-range", and self-declaration alone counts as neither, while sections 12 and 81 require checks that are "highly effective at correctly determining whether or not a particular user is a child", with Ofcom's guidance published in January 2025 ([GOV.UK](https://www.gov.uk/government/publications/online-safety-act-explainer/online-safety-act-explainer)). In the EU, the Commission's [age-verification blueprint](https://digital-strategy.ec.europa.eu/en/news/commission-releases-enhanced-second-version-age-verification-blueprint) (second version, October 2025) lets a user prove they are over 18 "without revealing any personal information, not even their exact age", is built on the [EUDI Wallet](https://startwithidentity.com/glossary/eudi-wallet/) specifications, and is being piloted by Denmark, France, Greece, Italy and Spain. In the US, the Supreme Court upheld Texas's H.B. 1181 age-verification law for adult sites under intermediate scrutiny in [Free Speech Coalition v. Paxton](https://www.supremecourt.gov/opinions/24pdf/23-1122_3e04.pdf) (June 27, 2025), noting that many states regulate in this area. The identity question is how much the check discloses: uploading an ID to every site creates a data trove, while an over-18 claim from a wallet or [mobile driver's license](https://startwithidentity.com/glossary/mobile-drivers-license/) using [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/) or a [zero-knowledge proof](https://startwithidentity.com/glossary/zero-knowledge-proof/) proves only the threshold.

See also: [identity verification](https://startwithidentity.com/glossary/idv/), [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/), [zero-knowledge proof](https://startwithidentity.com/glossary/zero-knowledge-proof/), [mobile driver's license](https://startwithidentity.com/glossary/mobile-drivers-license/), [identity verification vendors](https://startwithidentity.com/vendors/identity-verification/)

## agent-registry
Source: https://startwithidentity.com/glossary/agent-registry/
Last updated: 2026-11-05

An agent registry is an inventory of the AI agents an organization runs or allows, recording for each one its identity, accountable human owner, purpose, permissions, creation and expiry, so that agents can be reviewed, governed and deprovisioned like any other identity. No open standard defines one yet: SWI's [Agent Identity Standards Map 2026](https://startwithidentity.com/reports/agent-identity-standards-map-2026/) rates the agent lifecycle registry as the one agent identity problem with no working-group draft at all, after two individual SCIM agent extension drafts expired.

What exists today is product-specific. Microsoft's [agent registry in the Microsoft 365 admin center](https://learn.microsoft.com/en-us/microsoft-agent-365/admin/agent-registry-overview) "provides a centralized view of all agents available for your organization" to monitor and govern them, and [Okta](https://startwithidentity.com/vendors/iam/okta/) [describes](https://www.okta.com/newsroom/press-releases/okta-brings-first-class-identity-to-ai-agents-with-agent-sso/) Okta for AI Agents as discovering unregistered and shadow agents and assigning them named human owners. The [W3C Agent Identity Registry Protocol Community Group](https://www.w3.org/community/agent-identity/) has formed but published no drafts. Without a registry, agents become the orphaned, over-privileged identities that the OWASP Non-Human Identities Top 10 ranks first and fifth. Until a standard lands, put agents into your existing [non-human identity](https://startwithidentity.com/guides/machine-identity/non-human-identity-security/) inventory with an owner, a purpose and an expiry date.

See also: [agentic identity](https://startwithidentity.com/glossary/agentic-identity/), [non-human identity](https://startwithidentity.com/glossary/nhi/), [orphaned account](https://startwithidentity.com/glossary/orphaned-account/), [deprovisioning](https://startwithidentity.com/glossary/deprovisioning/), [Shared Signals Framework](https://startwithidentity.com/standards/shared-signals-framework/), [AI identity vendors](https://startwithidentity.com/vendors/ai-identity/)

## agentic-identity
Source: https://startwithidentity.com/glossary/agentic-identity/
Last updated: 2026-10-16

Identity for autonomous AI agents that act on a user's behalf, call APIs, and chain tools. Requires scoped, delegated, auditable, and revocable credentials rather than the standing privileges typical of service accounts.

Agents break the assumptions IAM was built on: there is no interactive login, the agent acts for a user across several systems, and it can be created faster than any review cycle. The 2026 standards answer is a delegation chain expressed in OAuth terms, with Cross App Access adopted as the Model Context Protocol authorization extension and short-lived tokens replacing static API keys. The governance answer is still missing at most organizations: an agent with no owner, no expiry, and no place in an access review.

See also: [what is non-human identity](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/), [service account](https://startwithidentity.com/glossary/service-account/), [token exchange](https://startwithidentity.com/glossary/token-exchange/), [AI identity vendors](https://startwithidentity.com/vendors/ai-identity/), [prompt injection](https://startwithidentity.com/glossary/prompt-injection/), [Cross App Access](https://startwithidentity.com/glossary/cross-app-access/), [MCP authorization](https://startwithidentity.com/glossary/mcp-authorization/)

## aml
Source: https://startwithidentity.com/glossary/aml/
Last updated: 2026-08-29

Anti-Money Laundering. The set of regulations and processes used to detect and report suspicious financial activity. AML programs sit on top of KYC and include sanctions and PEP screening, transaction monitoring, and SAR filing.

For identity teams the practical link is that AML obligations set the evidence bar for onboarding: how strong the proofing has to be, how long records are retained, and what has to be re-verified when risk changes. That makes AML a design constraint on the signup flow rather than a back-office concern, and it is why regulated CIAM builds cannot simply optimize for conversion.

See also: [KYC](https://startwithidentity.com/glossary/kyc/), [identity verification](https://startwithidentity.com/glossary/idv/), [PSD2](https://startwithidentity.com/glossary/psd2/), [identity verification vendors](https://startwithidentity.com/vendors/identity-verification/)

## anoncreds
Source: https://startwithidentity.com/glossary/anoncreds/
Last updated: 2026-08-29

A verifiable credential format, originating in Hyperledger Indy and now a standalone specification, built around zero-knowledge proofs for strong selective disclosure and predicate proofs (for example proving age over a threshold). Widely used in ledger-based SSI ecosystems.

AnonCreds is the most privacy-capable credential format in production use, supporting predicate proofs so a holder can prove "over 18" without revealing a birth date, and unlinkable presentations so two verifiers cannot correlate the same holder. The trade-off is ecosystem weight: it needs its own revocation registry machinery and has less tooling than SD-JWT, which is why most government programs including the EUDI Wallet went with SD-JWT and mdoc instead.

See also: [verifiable credentials](https://startwithidentity.com/standards/verifiable-credentials/), [zero-knowledge proof](https://startwithidentity.com/glossary/zero-knowledge-proof/), [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/), [SD-JWT](https://startwithidentity.com/glossary/sd-jwt/)

## api-key
Source: https://startwithidentity.com/glossary/api-key/
Last updated: 2026-08-29

A static secret string used to authenticate an application or caller to an API. Simple but weak: it does not expire on its own, is easy to leak, and should be vaulted and rotated.

API keys persist because they work on the first try and require no library, and they cause incidents for the same reason: they get committed to repositories, pasted into config files, and shared between services until nobody knows what would break if you rotated one. GitGuardian found thousands of live automation-platform tokens in public commits in 2026. Anything that can be replaced with a short-lived, scoped, workload-issued credential should be.

See also: [secrets management](https://startwithidentity.com/guides/fundamentals/what-is-secrets-management/), [non-human identity](https://startwithidentity.com/glossary/nhi/), [secrets rotation](https://startwithidentity.com/glossary/secrets-rotation/), [workload identity](https://startwithidentity.com/glossary/workload-identity/)

## attack-path
Source: https://startwithidentity.com/glossary/attack-path/
Last updated: 2026-09-21

A chain of individually legitimate permissions and relationships that together let a low-privileged identity reach a high-privileged one. Each link is a valid configuration; the risk is in the composition, which is why permission-by-permission auditing does not find it.

Attack path analysis treats the environment as a graph of principals, permissions, and relationships, then asks for the shortest route from any starting point to a target such as domain admin or a production role. Defenders historically reviewed group membership one object at a time while attackers read the whole graph, and closing a single well-chosen edge often removes thousands of paths at once. The approach originated in Active Directory tooling and now applies to cloud entitlements too.

See also: [privilege escalation](https://startwithidentity.com/glossary/privilege-escalation/), [lateral movement](https://startwithidentity.com/glossary/lateral-movement/), [Andy Robbins](https://startwithidentity.com/experts/andy-robbins/), [CIEM](https://startwithidentity.com/glossary/ciem/), [best ITDR tools](https://startwithidentity.com/rankings/best-itdr-tools/)

## authentication-policy
Source: https://startwithidentity.com/glossary/authentication-policy/
Last updated: 2026-11-05

An authentication policy is an identity provider rule that decides which authentication methods a user must satisfy to reach a given application, based on conditions such as group membership, network location, device state and risk. It is where "require MFA" becomes specific: which factors count, for whom, for which app, and how recently.

Vendors name and scope it differently. In Okta Identity Engine, [app sign-in policies](https://help.okta.com/oie/en-us/content/topics/identity-engine/policies/about-app-sign-on-policies.htm) "define how a user must authenticate to gain access to an app" using conditions like group, IP zone and risk level. In [Microsoft Entra](https://startwithidentity.com/vendors/iam/microsoft-entra/), Conditional Access combines conditions with an [authentication strength](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-strengths), which "specifies which combinations of authentication methods users can use to access a resource", for example only phishing-resistant methods for a sensitive app. The practical point from SWI's [Phishing-Resistant MFA Support Matrix 2026](https://startwithidentity.com/reports/phishing-resistant-mfa-matrix-2026/) is that 77 of 95 business SaaS apps (81.1%) offer SSO but cannot require phishing-resistant MFA themselves, so the IdP's authentication policy is the only place to enforce it. A policy that says "MFA required" without naming the method still lets an attacker pick the weakest factor the user has enrolled.

See also: [conditional access](https://startwithidentity.com/glossary/conditional-access/), [phishable MFA](https://startwithidentity.com/glossary/phishable-mfa/), [step-up authentication](https://startwithidentity.com/glossary/step-up-auth/), [SSO enforcement](https://startwithidentity.com/glossary/sso-enforcement/), [conditional access policies guide](https://startwithidentity.com/guides/implementation/conditional-access-policies-guide/), [MFA matrix](https://startwithidentity.com/tools/mfa-matrix/)

## authorization
Source: https://startwithidentity.com/glossary/authorization/
Last updated: 2026-11-05

Authorization (AuthZ) is the decision to permit or deny an authenticated subject access to a resource or action, and the rights that result; NIST's glossary, citing [CNSSI 4009-2022](https://csrc.nist.gov/glossary/term/authorization), defines it as "the decision to permit or deny a subject access to system objects (network, data, application, service, etc.)." Authentication (AuthN) comes first and answers who you are; authorization answers what you may do.

| | Authentication (AuthN) | Authorization (AuthZ) |
|---|---|---|
| Question | Who is this? | What may they do here, now? |
| NIST definition | "Verifying the identity of a user, process, or device" ([FIPS 200](https://csrc.nist.gov/glossary/term/authentication)) | The permit or deny decision above |
| Typical standards | Passwords, [passkeys](https://startwithidentity.com/glossary/passkey/), [OIDC](https://startwithidentity.com/glossary/oidc/), [SAML](https://startwithidentity.com/glossary/saml/) | [OAuth 2.0](https://startwithidentity.com/glossary/oauth/) scopes, [AuthZEN](https://startwithidentity.com/glossary/authzen/), policy engines |
| Models | Factors and assurance levels ([AAL](https://startwithidentity.com/glossary/aal/)) | [RBAC](https://startwithidentity.com/glossary/rbac/), [ABAC](https://startwithidentity.com/glossary/abac/), [ReBAC](https://startwithidentity.com/glossary/rebac/), [fine-grained authorization](https://startwithidentity.com/glossary/fga/) |
| HTTP failure | 401 Unauthorized (really "unauthenticated") | 403 Forbidden |

The common confusion is OAuth. OAuth 2.0 is an authorization framework: an access token says what a client may do, not who the user is. OpenID Connect adds an [ID token](https://startwithidentity.com/glossary/id-token/) on top of OAuth to carry authentication. Using an OAuth access token as proof of login is a classic integration bug.

It matters because most breaches after initial access are authorization failures: the attacker authenticated as someone real and the system let that identity do too much. Strong authentication with standing admin rights still fails; [least privilege](https://startwithidentity.com/glossary/least-privilege/), short-lived grants and decisions made per request, close to the resource, are the authorization side of the fix.

See also: [authentication vs authorization](https://startwithidentity.com/guides/fundamentals/authentication-vs-authorization/), [RBAC vs ABAC vs ReBAC](https://startwithidentity.com/guides/fundamentals/rbac-vs-abac-vs-rebac/), [OAuth vs OIDC](https://startwithidentity.com/guides/fundamentals/oauth-vs-oidc/), [best authorization tools](https://startwithidentity.com/rankings/best-authorization-tools/), [scope](https://startwithidentity.com/glossary/scope/), [privilege escalation](https://startwithidentity.com/glossary/privilege-escalation/)

## authorization-code-flow
Source: https://startwithidentity.com/glossary/authorization-code-flow/
Last updated: 2026-08-29

The recommended OAuth 2.0 flow for apps with a user: the app receives a short-lived code, then exchanges it for tokens from a back channel. Combined with PKCE for public clients.

This is the flow to use for anything with a human in it. The code is useless without the exchange, and the exchange happens over a channel the browser never sees, which is what keeps tokens out of URLs, browser history, and referrer headers. Implicit flow, which returned tokens directly in the redirect, is deprecated in OAuth 2.1 precisely because it lacked that separation. Public clients add PKCE so an intercepted code cannot be redeemed by anyone else.

See also: [OAuth 2.0](https://startwithidentity.com/standards/oauth-2-0/), [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/), [PKCE](https://startwithidentity.com/glossary/pkce/), [OIDC authorization code with PKCE recipe](https://startwithidentity.com/recipes/oidc-authorization-code-pkce/)

## authorization-server
Source: https://startwithidentity.com/glossary/authorization-server/
Last updated: 2026-09-21

In OAuth 2.0, the component that authenticates the resource owner, obtains their authorization, and issues access tokens to clients. It exposes the authorization and token endpoints and, in OpenID Connect deployments, also acts as the OpenID Provider issuing ID tokens.

The distinction between an authorization server and an identity provider is worth keeping straight even though one product usually does both. The authorization server's job is delegation: deciding what a client may do on a user's behalf and issuing a token scoped to it. Identity provision is authentication: asserting who the user is. Ory's architecture makes the split explicit by running an OAuth server that holds no user credentials at all.

See also: [OAuth](https://startwithidentity.com/glossary/oauth/), [access token](https://startwithidentity.com/glossary/access-token/), [scope](https://startwithidentity.com/glossary/scope/), [identity provider](https://startwithidentity.com/glossary/identity-provider/), [relying party](https://startwithidentity.com/glossary/relying-party/), [authorization server metadata](https://startwithidentity.com/glossary/authorization-server-metadata/), [protected resource metadata](https://startwithidentity.com/glossary/protected-resource-metadata/), [token introspection](https://startwithidentity.com/glossary/token-introspection/), [dynamic client registration](https://startwithidentity.com/glossary/dynamic-client-registration/), [Client ID Metadata Document](https://startwithidentity.com/glossary/client-id-metadata-document/)

## authorization-server-metadata
Source: https://startwithidentity.com/glossary/authorization-server-metadata/
Last updated: 2026-10-30

OAuth 2.0 Authorization Server Metadata ([RFC 8414](https://www.rfc-editor.org/rfc/rfc8414), Proposed Standard, June 2018) is a JSON document an authorization server publishes at `/.well-known/oauth-authorization-server` listing its issuer, endpoints, signing keys location, and supported grant types, scopes, and features, so clients can configure themselves automatically.

It generalizes OpenID Connect Discovery (`/.well-known/openid-configuration`) to plain OAuth, and the two documents share most field names. Metadata is how a client learns whether a server supports PKCE, PAR, DPoP, or Client ID Metadata Documents without guessing, and it is the second hop of discovery after a resource points to its authorization server through RFC 9728. The security rule that matters is the `issuer` check: the value in the document must exactly match the issuer the client expected, and with RFC 9207 the `iss` returned in authorization responses must match too, which is the defense against mix-up attacks when a client talks to more than one authorization server.

See also: [protected resource metadata](https://startwithidentity.com/glossary/protected-resource-metadata/), [authorization server](https://startwithidentity.com/glossary/authorization-server/), [JWKS](https://startwithidentity.com/glossary/jwks/), [OIDC](https://startwithidentity.com/glossary/oidc/), [MCP authorization](https://startwithidentity.com/glossary/mcp-authorization/), [OpenID Connect](https://startwithidentity.com/standards/openid-connect/)

## authzen
Source: https://startwithidentity.com/glossary/authzen/
Last updated: 2026-11-05

AuthZEN is the OpenID Foundation working group, and the [Authorization API 1.0](https://openid.net/specs/authorization-api-1_0-final.html) specification it produced, that standardizes how a policy enforcement point (PEP) asks a policy decision point (PDP) "can this subject perform this action on this resource in this context?" over a JSON HTTP API. Authorization API 1.0 was approved as an OpenID Final Specification in January 2026.

Externalized authorization has been held back by lock-in: every policy engine has its own request format, so swapping engines meant rewriting every enforcement point. AuthZEN fixes the wire format, with a subject, resource, action, and context model, an access evaluation endpoint (and a batch form), search endpoints that answer "which resources can this user see", and a metadata document for discovery. It does not define a policy language, so Cedar, Rego, OpenFGA-style relationship models, and XACML-heritage engines can all sit behind the same API. The working group's 2026 drafts extend the model to AI agent and API gateway use cases. The 1.0 editors are from [Aserto](https://startwithidentity.com/vendors/authorization/aserto/), Axiomatics, and [SGNL](https://startwithidentity.com/vendors/authorization/sgnl/).

See also: [fine-grained authorization](https://startwithidentity.com/glossary/fga/), [ABAC](https://startwithidentity.com/glossary/abac/), [ReBAC](https://startwithidentity.com/glossary/rebac/), [RBAC vs ABAC vs ReBAC](https://startwithidentity.com/guides/fundamentals/rbac-vs-abac-vs-rebac/), [authorization vendors](https://startwithidentity.com/vendors/authorization/), [Atul Tulshibagwale](https://startwithidentity.com/experts/atul-tulshibagwale/), [AuthZEN standard](https://startwithidentity.com/standards/authzen/), [MCP authorization](https://startwithidentity.com/standards/mcp-authorization/)

## bbs-signature
Source: https://startwithidentity.com/glossary/bbs-signature/
Last updated: 2026-08-29

A signature scheme that lets a holder reveal only a subset of the fields in a credential while keeping the issuer's single signature valid, without the issuer's involvement. It enables privacy-preserving selective disclosure and unlinkable presentations for verifiable credentials.

BBS matters because it moves selective disclosure from a workaround to a property of the signature itself. Alternatives either re-issue a credential per disclosure, which requires the issuer to be online and to learn where the credential is used, or hash-and-salt each field as SD-JWT does, which reveals which fields were withheld. BBS reveals only what is shown and produces unlinkable presentations, at the cost of newer cryptography and thinner library support.

See also: [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/), [zero-knowledge proof](https://startwithidentity.com/glossary/zero-knowledge-proof/), [verifiable credentials](https://startwithidentity.com/standards/verifiable-credentials/), [SD-JWT](https://startwithidentity.com/glossary/sd-jwt/)

## bearer-token
Source: https://startwithidentity.com/glossary/bearer-token/
Last updated: 2026-09-29

A bearer token is a credential that grants access to whoever presents it, with no proof that the presenter is the party it was issued to. OAuth 2.0 defines how bearer tokens are sent in [RFC 6750](https://www.rfc-editor.org/info/rfc6750/).

Most OAuth access tokens, browser session cookies and API keys behave as bearer credentials, which is why stealing one is as good as stealing the login: the thief replays it and the server cannot tell the difference. The defenses are to keep bearer tokens short-lived, narrowly scoped and revocable, and, where the risk justifies it, to use sender-constrained tokens that are bound to a key the client must prove it holds, through [DPoP](https://startwithidentity.com/glossary/dpop/) (RFC 9449) or [mutual TLS](https://startwithidentity.com/glossary/mtls/) (RFC 8705). Bearer credentials also hide in places that do not look like tokens: in September 2026, researchers showed that [GitLab's incoming email address works as a non-expiring token](https://startwithidentity.com/blog/2026-09-23-gitlab-incoming-email-token-lets-anyone-commit-and-run-ci-as-you/) that can commit code as its owner.

See also: [access token](https://startwithidentity.com/glossary/access-token/), [token theft](https://startwithidentity.com/glossary/token-theft/), [session hijacking](https://startwithidentity.com/glossary/session-hijacking/), [token replay on unbound endpoints](https://startwithidentity.com/techniques/token-replay-unbound-endpoint/)

## biometric-authentication
Source: https://startwithidentity.com/glossary/biometric-authentication/
Last updated: 2026-10-17

Biometric authentication confirms a person by comparing a live measurement of a physical characteristic, such as a fingerprint or face, against a template captured at enrollment. [NIST SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html) (section 3.2.3) says biometrics "SHALL only be used as part of multi-factor authentication with a physical authenticator", so a face or fingerprint is never a credential on its own.

The architecture matters more than the sensor. In a local match, the phone or laptop compares the biometric and uses it only to release a key held on the device; FIDO says that with passkeys "biometric information and processing continues to stay on the device and is never sent to any remote server" ([FIDO Alliance](https://fidoalliance.org/passkeys/)). Server-side matching stores templates centrally, which NIST ranks below local verification and which turns a breach into a permanent loss, because a fingerprint cannot be reissued. Where biometrics are used, NIST requires a false match rate of 1 in 10,000 or better across demographic groups, presentation attack detection for facial recognition (recommended for fingerprint and iris, tested per [ISO/IEC 30107-3](https://www.iso.org/standard/79520.html)), no voice matching, and a non-biometric alternative. A local biometric only gates the key: in August 2026 malware already running in a signed-in Windows session [used a Windows Hello for Business key with no biometric prompt](https://startwithidentity.com/blog/2026-08-07-windows-hello-for-business-keys-abused-for-entra-id-persistence/).

See also: [biometric authentication as a regulatory frontier](https://startwithidentity.com/blog/biometric-authentication-regulatory-frontier/), [top biometric authentication tools](https://startwithidentity.com/articles/top-5-biometric-authentication-tools/), [passkey](https://startwithidentity.com/glossary/passkey/), [FIDO2](https://startwithidentity.com/glossary/fido2/), [BIPA](https://startwithidentity.com/regulations/united-states/bipa/), [EU AI Act](https://startwithidentity.com/regulations/european-union/eu-ai-act/)

## break-glass
Source: https://startwithidentity.com/glossary/break-glass/
Last updated: 2026-11-05

A tightly controlled emergency account used only when normal access fails, with strong vaulting, monitoring, and alerting. Tested regularly so it works in a real incident.

Break-glass accounts fail in two directions. Untested, they do not work during the outage they exist for, usually because they depend on the SSO or MFA service that is down. Untested and unmonitored, they become a standing backdoor that nobody notices being used. The rule that survives audit is: excluded from conditional access, credentials split and vaulted, every use alerts immediately, and the whole path is exercised on a schedule.

See also: [what is PAM](https://startwithidentity.com/guides/fundamentals/what-is-pam/), [zero standing privileges](https://startwithidentity.com/glossary/zero-standing-privileges/), [just-in-time access](https://startwithidentity.com/glossary/jit-access/), [PAM vendors](https://startwithidentity.com/vendors/pam/), [local login bypass](https://startwithidentity.com/glossary/local-login-bypass/), [SSO enforcement](https://startwithidentity.com/glossary/sso-enforcement/)

## browser-in-the-browser
Source: https://startwithidentity.com/glossary/browser-in-the-browser/
Last updated: 2026-10-16

Browser-in-the-browser (BitB) is a phishing technique in which a web page draws a fake browser popup window, complete with title bar, address bar and padlock, out of HTML and CSS, so a spoofed sign-in form appears to come from a trusted domain such as accounts.google.com.

The researcher mr.d0x [published the technique and templates in March 2022](https://mrd0x.com/browser-in-the-browser-phishing-attack/), mimicking the popups used for "Sign in with Google", Microsoft or Apple, and pointed out that the URL is usually the thing security-aware users trust most. In a BitB window the address bar is part of the attacker's page, so "check the URL" training gives the wrong answer. Current kits pair the fake window with live relay of credentials and MFA codes: the [RecruitTrap campaign](https://startwithidentity.com/blog/2026-08-14-recruittrap-browser-in-the-browser-recruitment-phishing/) ran it across more than 3,000 recruitment phishing URLs, and in October 2026 Island described [fake ChatGPT, Gemini and Claude ad portals](https://startwithidentity.com/blog/2026-10-06-fake-chatgpt-gemini-and-claude-ad-portals-capture-credentials-and-mfa-codes/) whose "Connect" button opens a BitB window showing a Google or Okta address while an operator picks which MFA challenge to show next. The dependable defense is [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/): a passkey or security key checks the real origin of the page, not what the window draws, and will not produce a credential for the phishing domain.

See also: [adversary-in-the-middle](https://startwithidentity.com/glossary/adversary-in-the-middle/), [AitM phishing proxy](https://startwithidentity.com/techniques/aitm-phishing-proxy/), [OTP relay social engineering](https://startwithidentity.com/techniques/otp-relay-social-engineering/), [social login](https://startwithidentity.com/glossary/social-login/)

## caep
Source: https://startwithidentity.com/glossary/caep/
Last updated: 2026-11-05

Continuous Access Evaluation Protocol. A specification for communicating security-relevant session events, such as a credential change, a device falling out of compliance, or an assurance-level change, from one party to another so access decisions can be revised mid-session rather than only at login.

CAEP exists because federation has a structural gap: a token issued for an hour stays valid for an hour, whatever happens in minute two. Without out-of-band signalling, a relying party cannot know the user was disabled, the device was quarantined, or the session was hijacked. CAEP defines the event types; the Shared Signals Framework defines how they are delivered between a transmitter and a receiver. It was invented at Google and is now published by the OpenID Foundation.

See also: [Shared Signals Framework](https://startwithidentity.com/glossary/shared-signals-framework/), [session hijacking](https://startwithidentity.com/glossary/session-hijacking/), [token theft](https://startwithidentity.com/glossary/token-theft/), [Atul Tulshibagwale](https://startwithidentity.com/experts/atul-tulshibagwale/), [Zero Trust](https://startwithidentity.com/glossary/zero-trust/), [RISC](https://startwithidentity.com/glossary/risc/), [Shared Signals Framework standard](https://startwithidentity.com/standards/shared-signals-framework/)

## calling-name-presentation
Source: https://startwithidentity.com/glossary/calling-name-presentation/
Last updated: 2026-10-16

Calling Name Presentation (CNAP) is a telephone network service that shows the called user the caller's name, supplied by the network rather than by the caller, alongside the calling number. 3GPP specifies it as a name identification supplementary service in TS 22.096.

India's Department of Telecommunications [ordered all access providers](https://www.dot.gov.in/static/uploads/2026/10/d86da4092d50f052becd6113de83d37e.pdf) to switch it on in 4G and later networks from November 1, 2026: unless the recipient has saved the number, the handset shows the name in the originating operator's subscriber record, or "International Call", and business users may present a verified registered trade mark or GST trade name instead ([our coverage](https://startwithidentity.com/blog/2026-10-15-india-mandates-cnap-caller-name-display-from-november-1/)). That turns the caller's KYC record into a network-asserted identity signal against [vishing](https://startwithidentity.com/glossary/vishing/) from unknown numbers. It is a weak signal: it says who registered the SIM rather than who is speaking, the Indian mandate does not yet cover 2G, 3G or fixed lines, and calls placed through internet messaging apps do not carry it. Help desks and fraud teams should not treat a displayed name as identity verification and should keep call-back to a number on file.

See also: [vishing](https://startwithidentity.com/glossary/vishing/), [help-desk social engineering](https://startwithidentity.com/techniques/help-desk-social-engineering/), [SIM swap](https://startwithidentity.com/glossary/sim-swap/), [KYC](https://startwithidentity.com/glossary/kyc/)

## certificate-authority
Source: https://startwithidentity.com/glossary/certificate-authority/
Last updated: 2026-11-05

A certificate authority (CA) is the trusted party in a [PKI](https://startwithidentity.com/glossary/pki/) that verifies a requester's identity or control of a name and then signs an [X.509](https://startwithidentity.com/glossary/x509/) certificate binding that name to a public key, so anyone who trusts the CA can trust the certificate. The certificate profile is defined in [RFC 5280](https://www.rfc-editor.org/rfc/rfc5280); publicly trusted TLS CAs must also follow the CA/Browser Forum Baseline Requirements and the root programs of browser and OS vendors.

| | Public CA | Private (internal) CA |
|---|---|---|
| Trusted by | Every browser and OS by default | Only devices you configure to trust its root |
| Examples | [Let's Encrypt](https://startwithidentity.com/vendors/pki/lets-encrypt/), [DigiCert](https://startwithidentity.com/vendors/pki/digicert/), [Sectigo](https://startwithidentity.com/vendors/pki/sectigo/), [GlobalSign](https://startwithidentity.com/vendors/pki/globalsign/) | Microsoft AD CS, [EJBCA](https://startwithidentity.com/vendors/pki/ejbca/), [Smallstep](https://startwithidentity.com/vendors/pki/smallstep/), cloud private CAs |
| Rules | CA/Browser Forum; validity capped at 200 days since March 15, 2026 per [Ballot SC-081v3](https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/) | Your own policy |
| Used for | Public websites and APIs | [mTLS](https://startwithidentity.com/glossary/mtls/), devices, VPN, internal services, workload identity |

A CA hierarchy normally keeps the root offline and issues from intermediate CAs, so a compromised issuing CA can be revoked without replacing the root on every device. Issuance itself is increasingly automated through [ACME](https://startwithidentity.com/glossary/acme/) or, for workloads, through [SPIFFE](https://startwithidentity.com/glossary/spiffe/) implementations that run their own short-lived CA.

It matters for identity because a CA is a credential factory. Whoever can get a certificate issued for a privileged name can often authenticate as it: misconfigured Active Directory Certificate Services templates let an ordinary user request a certificate for a domain admin, which is the technique behind [AD CS certificate template abuse](https://startwithidentity.com/techniques/adcs-certificate-template-abuse/). Treat issuing CAs and their templates as tier-zero assets, and inventory them as part of [certificate lifecycle management](https://startwithidentity.com/glossary/certificate-lifecycle/).

See also: [PKI](https://startwithidentity.com/glossary/pki/), [X.509](https://startwithidentity.com/glossary/x509/), [PKI vendors](https://startwithidentity.com/vendors/pki/), [open-source PKI and certificate management tools](https://startwithidentity.com/articles/top-6-open-source-pki-certificate-management-tools/), [machine identity](https://startwithidentity.com/glossary/machine-identity/)

## certificate-lifecycle
Source: https://startwithidentity.com/glossary/certificate-lifecycle/
Last updated: 2026-11-05

Certificate lifecycle management (CLM), often called certificate management, is the practice of discovering, issuing, renewing, and revoking X.509 certificates, such as TLS certificates, across an organization. Automation matters because expired or unmanaged certificates cause outages and create machine-identity risk.

Certificate expiry is one of the few identity failures that causes a visible outage rather than a quiet compromise, which is why it gets budget. Under CA/Browser Forum [Ballot SC-081v3](https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/), approved in April 2025, the maximum validity of a publicly trusted TLS certificate is 200 days for certificates issued from March 15, 2026, then 100 days from March 15, 2027 and 47 days from March 15, 2029. At those lifetimes manual renewal stops being viable and automation becomes mandatory. The identity angle is that a certificate is a machine credential: the same questions about ownership, rotation, and revocation apply as for any other non-human identity.

See also: [certificate lifecycle management guide](https://startwithidentity.com/guides/machine-identity/certificate-lifecycle-management-guide/), [PKI](https://startwithidentity.com/glossary/pki/), [X.509](https://startwithidentity.com/glossary/x509/), [mTLS](https://startwithidentity.com/glossary/mtls/), [what is machine identity](https://startwithidentity.com/guides/fundamentals/what-is-machine-identity/), [ACME](https://startwithidentity.com/glossary/acme/), [certificate authority](https://startwithidentity.com/glossary/certificate-authority/)

## ciam
Source: https://startwithidentity.com/glossary/ciam/
Last updated: 2026-11-05

CIAM (customer identity and access management) is the sign-up, login, profile and consent layer for an application's customers, not the IAM system that manages employee access. It covers self-service registration, social and passkey login, MFA, account recovery, consent records and, for B2B SaaS, per-customer tenants with enterprise SSO and SCIM. CIAM optimizes for conversion, branding and consumer-scale user volumes; it is not identity governance, privileged access or identity verification (document and selfie checks), though many CIAM platforms integrate with verification vendors.

The difference from workforce IAM is not scale, it is who bears the cost of friction. A workforce user will complete whatever login you require because it is their job; a customer abandons. That inverts the design: progressive registration instead of full profiles, social and passkey options instead of mandated MFA, and consent and preference management as first-class features because the data is regulated. CIAM also owns the fraud surface that workforce identity mostly does not.

CIAM is usually priced per monthly active user, and most developer-focused platforms publish free tiers: our [pricing transparency index](https://startwithidentity.com/reports/identity-pricing-transparency-index-2026/) verified free tiers from 5,000 to 1,000,000 MAU on 30 October 2026.

See also: [what is CIAM](https://startwithidentity.com/guides/fundamentals/what-is-ciam/), [CIAM vs IAM](https://startwithidentity.com/articles/ciam-vs-iam/), [best CIAM platforms](https://startwithidentity.com/rankings/best-ciam-platforms/), [progressive profiling](https://startwithidentity.com/glossary/progressive-profiling/), [consent management](https://startwithidentity.com/glossary/consent-management/), [CIAM vendors](https://startwithidentity.com/vendors/ciam/)

## ciba
Source: https://startwithidentity.com/glossary/ciba/
Last updated: 2026-08-29

Client-Initiated Backchannel Authentication. An OpenID Connect flow where authentication is initiated on one device and approved on another, useful for call centers and decoupled approvals.

CIBA solves a real problem: the person who needs to approve is not at the device making the request. Call center verification, in-store payments, and machine-initiated transactions all fit. It is also the pattern that device-code phishing abuses, because decoupling the requesting device from the approving one is exactly what a phisher wants. Bind the approval prompt to transaction detail the user can check, and never let it read as a generic "approve sign-in".

See also: [OpenID Connect](https://startwithidentity.com/standards/openid-connect/), [device code flow](https://startwithidentity.com/glossary/device-code-flow/), [step-up auth](https://startwithidentity.com/glossary/step-up-auth/), [MFA](https://startwithidentity.com/glossary/mfa/)

## ciem
Source: https://startwithidentity.com/glossary/ciem/
Last updated: 2026-08-29

Cloud Infrastructure Entitlement Management. Tools that discover and right-size identities and permissions across AWS, Azure, and GCP, reducing excessive and unused entitlements. Focuses on effective permissions, the access an identity can actually use.

CIEM exists because cloud IAM policies are effectively unreadable at scale: permissions come from identity policies, resource policies, permission boundaries, service control policies, and role chains, and the effective answer is a computation rather than a lookup. The value is showing what an identity can actually do versus what it has used, which is what makes right-sizing possible. Most findings are unused permissions on service principals rather than over-privileged humans.

See also: [what is CIEM](https://startwithidentity.com/guides/fundamentals/what-is-ciem/), [least privilege](https://startwithidentity.com/glossary/least-privilege/), [entitlement](https://startwithidentity.com/glossary/entitlement/), [CIEM vendors](https://startwithidentity.com/vendors/ciem/)

## cjis
Source: https://startwithidentity.com/glossary/cjis/
Last updated: 2026-09-29

The CJIS Security Policy is the FBI's set of minimum security requirements for anyone who accesses, processes, stores or transmits criminal justice information (CJI) from FBI Criminal Justice Information Services systems, including state and local agencies and the private companies that support them.

Its modernized control set follows the NIST SP 800-53 families and borrows its authenticator rules from NIST SP 800-63B. For identity teams, the headline requirement is multi-factor authentication for every privileged and non-privileged account with access to CJI, plus a compromised-password list checked quarterly and a minimum user-chosen password length of 8 characters. Version 6.1, effective June 26, 2026, is a corrections release that clarifies authentication cross-references, requires incidents to be reported immediately rather than after confirmation, and raises symmetric encryption for CJI to 256-bit. The MFA requirements are Priority 1 and sanctionable now; lower-priority requirements stay auditable but not sanctionable until September 30, 2027.

See also: [CJIS Security Policy requirements](https://startwithidentity.com/regulations/united-states/cjis-security-policy/), [NIST SP 800-63](https://startwithidentity.com/glossary/nist-800-63/), [MFA](https://startwithidentity.com/glossary/mfa/), [FedRAMP](https://startwithidentity.com/glossary/fedramp/)

## claims
Source: https://startwithidentity.com/glossary/claims/
Last updated: 2026-11-05

Statements about a subject carried in a token, such as subject identifier, email, roles, or expiry. Relying parties make authorization decisions from claims, so their integrity and freshness matter.

Claims are where authentication quietly becomes authorization, and where most token bugs live. A relying party that trusts a `groups` or `roles` claim without verifying the issuer, audience, and signature has an authorization system anyone can forge. Claim freshness is the second trap: a token minted before a user was removed from a group stays valid until it expires, which is why revocation needs short lifetimes or a continuous-evaluation signal.

See also: [JWT](https://startwithidentity.com/glossary/jwt/), [ID token](https://startwithidentity.com/glossary/id-token/), [OpenID Connect](https://startwithidentity.com/standards/openid-connect/), [validate a JWT recipe](https://startwithidentity.com/recipes/validate-a-jwt/), [SSO identifier](https://startwithidentity.com/glossary/sso-identifier/)

## client-credentials
Source: https://startwithidentity.com/glossary/client-credentials/
Last updated: 2026-08-29

An OAuth 2.0 flow where an application authenticates as itself, with no user present, to obtain an access token. The standard pattern for machine-to-machine access.

This is the flow behind most service-to-service traffic, and the place where long-lived secrets accumulate. The credential authenticates the application itself, so there is no user to revoke and no session to expire, which makes ownership and rotation the whole ballgame. Prefer workload identity federation where the platform can attest the caller, so no secret exists to leak in the first place.

See also: [OAuth 2.0](https://startwithidentity.com/standards/oauth-2-0/), [service account](https://startwithidentity.com/glossary/service-account/), [workload identity](https://startwithidentity.com/glossary/workload-identity/), [what is non-human identity](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/)

## client-id-metadata-document
Source: https://startwithidentity.com/glossary/client-id-metadata-document/
Last updated: 2026-11-05

An OAuth Client ID Metadata Document (CIMD) is a JSON document of client metadata hosted at an HTTPS URL that the client uses as its `client_id`, so an authorization server can fetch and verify the client's details on first contact without any prior registration. It is specified in [draft-ietf-oauth-client-id-metadata-document](https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/), an active IETF OAuth Working Group draft that is not yet an RFC as of October 2026.

CIMD solves the open-ecosystem problem: thousands of AI clients connecting to thousands of servers that have never met. Dynamic Client Registration (RFC 7591) handles that by letting anyone create a client, which fills authorization servers with unverifiable, unbounded registrations. With CIMD the client's identity is a URL the server can check, cache, and allow or block by domain, and the redirect URIs come from a document the client's owner controls. The Model Context Protocol authorization spec tells clients to prefer CIMD over Dynamic Client Registration when the server advertises `client_id_metadata_document_supported`. Servers fetching the URL need SSRF protection (the draft has a section on it), and a valid document proves control of a domain, not that the client is trustworthy, so consent screens still need to show that domain clearly.

See also: [dynamic client registration](https://startwithidentity.com/glossary/dynamic-client-registration/), [MCP authorization](https://startwithidentity.com/glossary/mcp-authorization/), [authorization server metadata](https://startwithidentity.com/glossary/authorization-server-metadata/), [authorization server](https://startwithidentity.com/glossary/authorization-server/), [Aaron Parecki](https://startwithidentity.com/experts/aaron-parecki/), [agent identity standards map 2026](https://startwithidentity.com/reports/agent-identity-standards-map-2026/), [MCP authorization standard](https://startwithidentity.com/standards/mcp-authorization/)

## conditional-access
Source: https://startwithidentity.com/glossary/conditional-access/
Last updated: 2026-08-29

Policy-driven access decisions evaluated at sign-in time. Inputs include identity, device, location, risk signals, and application sensitivity. Microsoft Entra Conditional Access popularized the term; equivalent capability exists across IAM platforms.

Conditional access is where most organizations actually implement zero trust, because it is the one place policy can consider identity, device, location, and risk together at the moment of access. Two failure modes recur: exclusions that were added for a migration and never removed, and policies that require "MFA" generically rather than a phishing-resistant method, which relay kits satisfy. Audit the exclusion list more often than the policy list.

See also: [what is zero trust](https://startwithidentity.com/guides/fundamentals/what-is-zero-trust/), [adaptive auth](https://startwithidentity.com/glossary/adaptive-auth/), [device posture](https://startwithidentity.com/glossary/device-posture/), [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/)

## consent-management
Source: https://startwithidentity.com/glossary/consent-management/
Last updated: 2026-11-05

Consent management is the capture, storage and enforcement of a user's consent to specific data processing and communications, with a record of what they were shown and when, so that an organization can prove it under laws such as the GDPR. A consent management platform (CMP) is the software that does it. GDPR [Article 7](https://eur-lex.europa.eu/eli/reg/2016/679/oj) requires the controller to be able to demonstrate consent and to make withdrawal as easy as giving it, and Article 4(11) defines consent as a "freely given, specific, informed and unambiguous" indication of the data subject's wishes.

| Type | What it manages | Where it lives |
|---|---|---|
| Cookie consent CMP | Consent banner choices for cookies and trackers on a website | Front end, tag manager |
| Identity-level consent and preferences | Per-purpose consent tied to an account, across channels and devices | [CIAM](https://startwithidentity.com/glossary/ciam/) profile or a dedicated consent service |
| OAuth consent | A user letting a third-party app access their data with given [scopes](https://startwithidentity.com/glossary/scope/) | Authorization server; abused in [consent phishing](https://startwithidentity.com/glossary/consent-phishing/) |

Consent is a data problem disguised as a UI problem. The regulator's question is not whether a checkbox existed but whether you can produce, for a given user and a given moment, what they were shown and what they agreed to. That means versioned consent records tied to policy text, not a boolean column. Under eIDAS 2.0 the wallet model pushes consent further toward the holder, so verifiers request specific attributes rather than receiving a profile.

See also: [GDPR](https://startwithidentity.com/glossary/gdpr/), [what is CIAM](https://startwithidentity.com/guides/fundamentals/what-is-ciam/), [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/), [identity regulations by country](https://startwithidentity.com/regulations/)

## consent-phishing
Source: https://startwithidentity.com/glossary/consent-phishing/
Last updated: 2026-10-30

Consent phishing, which Microsoft calls an [illicit consent grant](https://learn.microsoft.com/en-us/defender-office-365/detect-and-remediate-illicit-consent-grants), is an attack in which a user is tricked into granting OAuth permissions to an attacker-controlled application, giving the attacker tokens to read mail, files, or other data without ever learning the user's password. MITRE ATT&CK tracks it under [T1528, Steal Application Access Token](https://attack.mitre.org/techniques/T1528/).

The consent screen is genuine, which is what makes this attack hard to train against: the URL belongs to Microsoft or Google, the sign-in is real, and MFA passes. What the user approves is an app with a plausible name requesting scopes such as offline access and mail read. The grant survives a password reset, because the attacker holds a refresh token tied to the app, not the user's credentials. The controls are administrative: restrict user consent to verified publishers and low-risk scopes, require admin approval for everything else, review existing grants, and revoke the app's service principal (not just the user's sessions) when you find one.

See also: [OAuth consent phishing technique](https://startwithidentity.com/techniques/oauth-consent-phishing/), [scope](https://startwithidentity.com/glossary/scope/), [refresh token abuse](https://startwithidentity.com/techniques/refresh-token-abuse/), [token theft](https://startwithidentity.com/glossary/token-theft/), [service principal](https://startwithidentity.com/glossary/service-principal/), [device code flow](https://startwithidentity.com/glossary/device-code-flow/)

## credential-brokering
Source: https://startwithidentity.com/glossary/credential-brokering/
Last updated: 2026-11-05

Credential brokering is the pattern in which an intermediary fetches a credential from a vault or credential store at the moment of access and hands it to an already-authorized user or workload, instead of that user or workload holding the credential permanently. [HashiCorp Boundary's documentation](https://developer.hashicorp.com/boundary/docs/concepts/credential-management) defines it this way and contrasts it with credential injection: brokering "returns credentials to the user", while injection "authenticates on the user's behalf without ever exposing the credential".

The distinction matters most for AI agents and other non-human identities. A brokered credential still reaches the client, so an agent that reads untrusted input can be steered into leaking or misusing it. Injection, or better, short-lived tokens issued for one audience (OAuth [token exchange](https://startwithidentity.com/glossary/token-exchange/) or [ID-JAG](https://startwithidentity.com/standards/id-jag-cross-app-access/)), keeps the secret out of the agent's reach entirely. Brokering is still a large improvement over static [API keys](https://startwithidentity.com/glossary/api-key/) in config files, which is the failure behind several [exposed-secret incidents](https://startwithidentity.com/breaches/incidents/) and the [static API key abuse](https://startwithidentity.com/techniques/static-api-key-abuse/) technique. When evaluating a broker, ask whether the credentials it hands out are dynamic and short-lived, scoped to one target, and logged per session.

See also: [secrets management](https://startwithidentity.com/glossary/secrets-management/), [just-in-time access](https://startwithidentity.com/glossary/jit-access/), [HashiCorp Boundary](https://startwithidentity.com/vendors/pam/hashicorp-boundary/), [HashiCorp Vault](https://startwithidentity.com/vendors/machine-identity/hashicorp-vault/), [MCP authorization](https://startwithidentity.com/standards/mcp-authorization/), [securing AI agent identities](https://startwithidentity.com/guides/machine-identity/securing-ai-agent-identities/)

## credential-stuffing
Source: https://startwithidentity.com/glossary/credential-stuffing/
Last updated: 2026-10-17

An attack that replays username and password pairs leaked from other breaches against a target, exploiting password reuse. Defended with MFA, passkeys, and bot detection.

Credential stuffing works because password reuse is near-universal and the attacker's cost per attempt is close to zero. Rate limiting alone loses: modern kits distribute across residential proxies at low volume per IP. What actually breaks the economics is removing the reusable secret, which is why passkey rollouts show sharp drops in stuffing success, and detecting the pattern at the population level rather than per account.

See also: [account takeover](https://startwithidentity.com/glossary/account-takeover/), [password spraying](https://startwithidentity.com/glossary/password-spraying/), [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/), [Snowflake 2024 credential attacks](https://startwithidentity.com/breaches/snowflake-2024-credential-attacks/), [password manager](https://startwithidentity.com/glossary/password-manager/)

## cross-app-access
Source: https://startwithidentity.com/glossary/cross-app-access/
Last updated: 2026-11-05

Cross App Access (XAA) is the informal name for the OAuth pattern, specified in the IETF draft Identity Assertion JWT Authorization Grant ([draft-ietf-oauth-identity-assertion-authz-grant](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/)), in which an enterprise identity provider brokers the connection between two applications so one can call the other's API on a user's behalf without a per-user consent screen. The draft's own abstract uses the name; it is an active IETF working group draft, not yet an RFC, as of October 2026.

The problem XAA targets is app-to-app and agent-to-app sprawl: every time an employee clicks "connect" between two SaaS tools or authorizes an AI agent, a long-lived grant appears that the identity team never sees and cannot revoke centrally. With XAA the requesting app asks the IdP for an [ID-JAG](https://startwithidentity.com/glossary/id-jag/), the IdP applies admin policy, and the resource app trusts the result because it already trusts the same IdP for SSO. The draft has co-authors from [Okta](https://startwithidentity.com/vendors/iam/okta/) and [Ping Identity](https://startwithidentity.com/vendors/iam/ping-identity/), and the Model Context Protocol adopted it as the Enterprise-Managed Authorization extension. Its reach is limited to cases where both apps federate with the same IdP; cross-organization delegation still needs other mechanisms.

See also: [ID-JAG](https://startwithidentity.com/glossary/id-jag/), [MCP authorization](https://startwithidentity.com/glossary/mcp-authorization/), [agentic identity](https://startwithidentity.com/glossary/agentic-identity/), [SSO](https://startwithidentity.com/glossary/sso/), [securing AI agent identities](https://startwithidentity.com/guides/machine-identity/securing-ai-agent-identities/), [agent identity standards map 2026](https://startwithidentity.com/reports/agent-identity-standards-map-2026/), [ID-JAG and Cross App Access standard](https://startwithidentity.com/standards/id-jag-cross-app-access/)

## cyber-resilience-act
Source: https://startwithidentity.com/glossary/cyber-resilience-act/
Last updated: 2026-10-17

The Cyber Resilience Act (CRA), [Regulation (EU) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj), sets mandatory cybersecurity requirements for hardware and software "products with digital elements" sold in the EU. It entered into force on 10 December 2024; manufacturers' vulnerability and incident reporting duties apply from 11 September 2026 and most other obligations from 11 December 2027 ([European Commission](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act)).

Two of its essential requirements (Annex I, Part I) are identity requirements: products must "ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems", report possible unauthorised access, and ship with "a secure by default configuration". The Act does not use the words "default password", but a shared factory credential is hard to square with secure by default. Identity vendors are also directly in scope: Annex III lists "identity management systems and privileged access management software and hardware", including biometric readers, and password managers as Class I important products, which need third-party assessment unless the manufacturer fully applies harmonised standards or a certification scheme. From 11 September 2026 a manufacturer must send an early warning of an actively exploited vulnerability within 24 hours, and fines for breaching the essential requirements reach 15 million euros or 2.5 percent of worldwide turnover.

See also: [Cyber Resilience Act in the regulations hub](https://startwithidentity.com/regulations/european-union/cyber-resilience-act/), [NIS2](https://startwithidentity.com/regulations/european-union/nis2/), [identity controls for NIS2](https://startwithidentity.com/guides/compliance/identity-controls-for-nis2/), [password manager](https://startwithidentity.com/glossary/password-manager/), [PAM](https://startwithidentity.com/glossary/pam/)

## decentralized-identifier
Source: https://startwithidentity.com/glossary/decentralized-identifier/
Last updated: 2026-08-29

A W3C standard identifier that a subject controls without a central registry, resolvable to a document with keys and endpoints. A building block of decentralized identity.

The point of a DID is that verification does not require calling the party that issued the identifier, which removes both a dependency and a surveillance channel. In practice the method matters more than the concept: did:web resolves through ordinary DNS and TLS and is easy to deploy but inherits domain control as its trust root, while ledger-anchored methods gain independence at the cost of operational weight. Most enterprise pilots start with did:web.

See also: [decentralized identifiers standard](https://startwithidentity.com/standards/decentralized-identifiers-did/), [DID method](https://startwithidentity.com/glossary/did-method/), [verifiable credential](https://startwithidentity.com/glossary/verifiable-credential/), [what is decentralized identity](https://startwithidentity.com/guides/fundamentals/what-is-decentralized-identity/)

## delegation-chain
Source: https://startwithidentity.com/glossary/delegation-chain/
Last updated: 2026-11-05

A delegation chain is the sequence of parties acting on a user's behalf as a request passes from one to the next: for example a user delegates to an AI agent, which calls a tool, which calls an API. Each hop should be recorded, and each hop should only be able to narrow the authority it received, never widen it.

OAuth can record a chain but not enforce one. [RFC 8693 token exchange](https://www.rfc-editor.org/rfc/rfc8693.html) lets a token carry nested `act` claims naming each prior actor, then states that those prior actors "are informational only and are not to be considered in access control decisions". SWI's [Agent Identity Standards Map 2026](https://startwithidentity.com/reports/agent-identity-standards-map-2026/) therefore scores chained delegation as only drafted: [identity chaining](https://startwithidentity.com/glossary/identity-chaining/) handles one cross-domain hop at a time, [Transaction Tokens](https://startwithidentity.com/standards/oauth-transaction-tokens/) carry context inside one trust domain, and the OAuth working group's Delegate SD-JWT draft targets agent delegation directly. The practical pattern today is a token exchange at every hop, down-scoped each time, with the full `act` chain logged and each hop enforcing its own policy. Forwarding the original token downstream, the opposite, is how [scope escalation through delegation](https://startwithidentity.com/techniques/scope-escalation-delegation/) happens.

See also: [token exchange](https://startwithidentity.com/glossary/token-exchange/), [identity chaining](https://startwithidentity.com/glossary/identity-chaining/), [Transaction Tokens](https://startwithidentity.com/glossary/transaction-tokens/), [ID-JAG and Cross App Access](https://startwithidentity.com/standards/id-jag-cross-app-access/), [agentic identity](https://startwithidentity.com/glossary/agentic-identity/), [securing AI agent identities](https://startwithidentity.com/guides/machine-identity/securing-ai-agent-identities/)

## deprovisioning
Source: https://startwithidentity.com/glossary/deprovisioning/
Last updated: 2026-11-05

Removing access when a user leaves or changes roles. Failed deprovisioning leaves orphaned accounts that auditors flag and attackers exploit. SCIM with HR-driven triggers is the modern best practice.

Deprovisioning is the control auditors test first because it is the easiest to fail: SSO removal looks like offboarding but leaves local accounts, API keys, personal access tokens, and OAuth grants working. The gap widens with SaaS bought outside IT. Drive it from the HR record, cover non-SSO applications explicitly, and treat tokens and keys owned by the departing user as items to revoke rather than to let expire.

See also: [joiner-mover-leaver](https://startwithidentity.com/glossary/joiner-mover-leaver/), [orphaned account](https://startwithidentity.com/glossary/orphaned-account/), [what is SCIM](https://startwithidentity.com/guides/fundamentals/what-is-scim/), [secure offboarding checklist](https://startwithidentity.com/templates/secure-offboarding-checklist/), [user lifecycle management](https://startwithidentity.com/glossary/user-lifecycle-management/)

## device-bound-session-credentials
Source: https://startwithidentity.com/glossary/device-bound-session-credentials/
Last updated: 2026-09-29

Device Bound Session Credentials (DBSC) is a web standard that binds a browser session to a private key held in the device's hardware, so a session cookie stolen from that device stops working anywhere else. It is being developed in the W3C Web Application Security Working Group, which published a first public working draft in August 2025.

With DBSC, the site sends a `Secure-Session-Registration` header at sign-in, the browser generates a key pair and registers the public key, and the site issues short-lived cookies. When they expire, the browser calls the site's refresh endpoint and proves it still holds the private key, which on Windows Chrome protects with the Trusted Platform Module. An infostealer can copy the cookie but not the key, so the stolen session dies at the next refresh, within whatever short cookie lifetime the site sets. Chrome shipped DBSC on Windows in early 2026, and Google says it is on by default for Google accounts; other browsers and platforms have not yet shipped it, and each site must implement the registration and refresh endpoints to benefit. It complements, rather than replaces, sender-constrained tokens such as [DPoP](https://startwithidentity.com/glossary/dpop/) for APIs.

See also: [session hijacking](https://startwithidentity.com/glossary/session-hijacking/), [session cookie theft](https://startwithidentity.com/techniques/session-cookie-theft/), [token theft](https://startwithidentity.com/glossary/token-theft/), [infostealer](https://startwithidentity.com/glossary/infostealer/)

## device-code-flow
Source: https://startwithidentity.com/glossary/device-code-flow/
Last updated: 2026-08-29

An OAuth 2.0 flow (RFC 8628) for input-constrained devices like TVs and CLIs. The user authorizes on a second device using a short code.

Device code flow is the most abused legitimate flow in identity right now. It deliberately separates the device requesting access from the device approving it, which is what makes it work for a TV and what makes it perfect for phishing: the victim approves a real Microsoft or Google prompt, and the attacker receives the tokens. Both state-linked crews and commodity kits adopted it in 2026. If your tenant has no input-constrained devices, disable it by policy.

See also: [OAuth 2.0](https://startwithidentity.com/standards/oauth-2-0/), [authorization code flow](https://startwithidentity.com/glossary/authorization-code-flow/), [token theft](https://startwithidentity.com/glossary/token-theft/), [conditional access](https://startwithidentity.com/glossary/conditional-access/)

## device-posture
Source: https://startwithidentity.com/glossary/device-posture/
Last updated: 2026-11-05

The state of a device at the time of access: OS patch level, disk encryption status, EDR presence, jailbreak detection, certificate enrollment. Posture is an input to Zero Trust access decisions.

Posture is the signal that turns "who are you" into "should this device be here", and it is the part of zero trust that most often stays unimplemented because it requires an agent or MDM enrollment on every endpoint. The honest limit is that posture is self-reported by software on a machine the attacker may already control, so it is a strong signal against commodity attacks and a weak one against a determined intruder holding the device.

See also: [what is zero trust](https://startwithidentity.com/guides/fundamentals/what-is-zero-trust/), [conditional access](https://startwithidentity.com/glossary/conditional-access/), [ZTNA](https://startwithidentity.com/glossary/ztna/), [zero trust vendors](https://startwithidentity.com/vendors/zero-trust/), [privileged access workstation](https://startwithidentity.com/glossary/privileged-access-workstation/)

## did-document
Source: https://startwithidentity.com/glossary/did-document/
Last updated: 2026-08-29

The JSON document a DID resolves to, containing the subject's public keys, authentication methods, and service endpoints. It lets a verifier find the keys needed to check credentials or signatures associated with the DID, per the W3C DID Core specification.

The DID document is the trust anchor for everything else in a decentralized exchange: it names the keys that can authenticate as the subject and the endpoints where the subject can be reached. Key rotation is handled by updating the document rather than reissuing the identifier, which is the practical advantage over a raw public key. Verifiers must resolve it freshly enough to catch rotation and revocation.

See also: [decentralized identifier](https://startwithidentity.com/glossary/decentralized-identifier/), [DID method](https://startwithidentity.com/glossary/did-method/), [decentralized identifiers standard](https://startwithidentity.com/standards/decentralized-identifiers-did/), [verifiable credential](https://startwithidentity.com/glossary/verifiable-credential/)

## did-method
Source: https://startwithidentity.com/glossary/did-method/
Last updated: 2026-08-29

The scheme that defines how a specific type of DID is created, resolved, updated, and deactivated, named in the identifier (for example did:web, did:key, did:ion, did:ethr). Ledger-anchored methods use a blockchain; ledgerless methods such as did:web and did:key do not.

Choosing a method is choosing a trust root and an operating cost, and it is the decision most decentralized identity pilots get wrong by defaulting to whatever the vendor ships. did:key is fine for ephemeral test credentials but cannot rotate. did:web is deployable today and understood by auditors but depends on DNS and TLS control. Ledger methods remove that dependency and add infrastructure you now operate or trust someone else to operate.

See also: [decentralized identifier](https://startwithidentity.com/glossary/decentralized-identifier/), [DID document](https://startwithidentity.com/glossary/did-document/), [DID methods compared](https://startwithidentity.com/guides/decentralized-identity/did-methods-compared/), [decentralized identity vendors](https://startwithidentity.com/vendors/decentralized-identity/)

## digital-wallet
Source: https://startwithidentity.com/glossary/digital-wallet/
Last updated: 2026-08-29

An app or service that stores a holder's decentralized identifiers and verifiable credentials and manages consent when presenting them. Government wallets such as the EU's EUDI Wallet and consumer wallets both implement this role in the issuer, holder, verifier model.

The wallet is where the holder sits in the trust triangle, and it is doing more work than the name suggests: key custody, consent, selective disclosure, and increasingly device binding and recovery. Recovery is the unsolved part. A lost phone that held a state-issued credential is not the same problem as a lost password, and every national program is still working out how re-issuance happens without recreating a central honeypot.

See also: [EUDI wallet](https://startwithidentity.com/glossary/eudi-wallet/), [verifiable credential](https://startwithidentity.com/glossary/verifiable-credential/), [issuer, holder, verifier](https://startwithidentity.com/glossary/issuer-holder-verifier/), [national digital ID schemes](https://startwithidentity.com/digital-ids/)

## directory-service
Source: https://startwithidentity.com/glossary/directory-service/
Last updated: 2026-11-05

A directory service is the system that stores an organization's identities and their attributes (users, groups, devices, service accounts) in one queryable database, and answers lookups and authentication requests from other systems. Most directory services follow the X.500 data model and are accessed with [LDAP](https://startwithidentity.com/glossary/ldap/), which [RFC 4511](https://www.rfc-editor.org/rfc/rfc4511) describes as providing "access to distributed directory services that act in accordance with X.500 data and service models."

The best-known example is [Active Directory](https://startwithidentity.com/glossary/active-directory/) Domain Services, which adds Kerberos authentication and Group Policy on top of the directory. Open-source options include OpenLDAP, 389 Directory Server and [FreeIPA](https://startwithidentity.com/vendors/open-source/freeipa/). Cloud directories, such as [Microsoft Entra ID](https://startwithidentity.com/vendors/iam/microsoft-entra/), [Okta](https://startwithidentity.com/vendors/iam/okta/) Universal Directory or [JumpCloud](https://startwithidentity.com/vendors/iam/jumpcloud/), keep the "one source of identity" role but expose it through SAML, OIDC and [SCIM](https://startwithidentity.com/glossary/scim/) instead of LDAP binds.

| A directory service | Not the same as |
|---|---|
| Stores identities and attributes, answers lookups | An [identity provider](https://startwithidentity.com/glossary/identity-provider/), which authenticates users and issues tokens (many products do both) |
| The authoritative store for accounts | An HR system, which is usually the authoritative source for who is employed |
| Often the target of provisioning | An IGA tool, which decides who should have what |

It matters because the directory is tier zero: whoever controls it controls group membership, and therefore access to everything that trusts it. Legacy directories also carry most of the attack paths, such as [Kerberoasting](https://startwithidentity.com/techniques/kerberoasting/) and delegation abuse, so moving apps from LDAP binds to federation is a security project as much as a modernization one. The terms "enterprise directory" and "master directory" usually mean the same thing: the one directory every other system synchronizes from.

See also: [LDAP](https://startwithidentity.com/glossary/ldap/), [Active Directory](https://startwithidentity.com/glossary/active-directory/), [top directory services solutions](https://startwithidentity.com/articles/top-5-directory-services-solutions/), [open-source directory services](https://startwithidentity.com/articles/top-6-open-source-directory-services/), [provisioning](https://startwithidentity.com/glossary/provisioning/)

## dpop
Source: https://startwithidentity.com/glossary/dpop/
Last updated: 2026-10-16

Demonstrating Proof of Possession (RFC 9449). Binds an access token to a specific key held by the client, so a stolen bearer token cannot be replayed. Important for high-assurance APIs that cannot rely on mTLS.

DPoP exists because bearer tokens are the last big replay hole in OAuth: steal one and you are the client. It binds the token to a key the client proves possession of on every request, so a token lifted from a browser or a log is useless elsewhere. mTLS-bound tokens do the same job with better performance where you control the transport; DPoP is the option for public clients and browser apps that cannot present a client certificate.

See also: [access token](https://startwithidentity.com/glossary/access-token/), [token theft](https://startwithidentity.com/glossary/token-theft/), [mTLS](https://startwithidentity.com/glossary/mtls/), [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/), [proof of possession](https://startwithidentity.com/glossary/proof-of-possession/)

## dynamic-client-registration
Source: https://startwithidentity.com/glossary/dynamic-client-registration/
Last updated: 2026-10-30

OAuth 2.0 Dynamic Client Registration (DCR, [RFC 7591](https://www.rfc-editor.org/rfc/rfc7591), Proposed Standard, July 2015) defines a registration endpoint where a client posts its metadata, such as redirect URIs, grant types, and a name, and receives a `client_id` (and optionally a secret) without a human creating it in an admin console.

DCR was designed for ecosystems where clients cannot be known in advance, and it underpins open banking registration, where the request carries a signed software statement from a trusted directory. Open registration without that statement is the weak spot: anyone can create clients, so the authorization server accumulates thousands of unverifiable entries and has no basis for showing users who they are really consenting to. That is why the Model Context Protocol demoted DCR to a fallback behind pre-registration and Client ID Metadata Documents. If you must allow open DCR, rate-limit it, expire unused clients, and never let a self-registered client skip consent.

See also: [Client ID Metadata Document](https://startwithidentity.com/glossary/client-id-metadata-document/), [authorization server](https://startwithidentity.com/glossary/authorization-server/), [authorization server metadata](https://startwithidentity.com/glossary/authorization-server-metadata/), [MCP authorization](https://startwithidentity.com/glossary/mcp-authorization/), [OAuth consent phishing](https://startwithidentity.com/techniques/oauth-consent-phishing/), [OAuth 2.0](https://startwithidentity.com/standards/oauth-2-0/)

## eidas
Source: https://startwithidentity.com/glossary/eidas/
Last updated: 2026-08-29

The EU regulation for electronic identification and trust services. eIDAS 2.0 introduces the European Digital Identity Wallet, driving adoption of verifiable credentials.

eIDAS 2.0 is the single largest force pushing verifiable credentials from pilot to production, because it puts a legal deadline on something the industry had been prototyping for a decade. Every member state must make a wallet available by 24 December 2026, and the obligations reach private relying parties: regulated services must accept the wallet, and any party requesting attributes has to register and declare what it will ask for.

See also: [eIDAS 2.0 and the EUDI Wallet](https://startwithidentity.com/standards/eidas-2-eudi-wallet/), [EUDI wallet](https://startwithidentity.com/glossary/eudi-wallet/), [verifiable credentials](https://startwithidentity.com/standards/verifiable-credentials/), [identity regulations](https://startwithidentity.com/regulations/)

## entitlement
Source: https://startwithidentity.com/glossary/entitlement/
Last updated: 2026-08-29

A specific permission or right an identity holds over a resource. Governance and CIEM exist to keep entitlements understood, justified, and minimal.

Entitlements are the unit governance actually operates on, and the reason IGA programs stall is that the raw names are meaningless to the humans reviewing them: `APP_FIN_GL_RW_PROD` tells a manager nothing. Programs that succeed invest in translating entitlements into business language and grouping them into roles, so certification asks "should this person approve payments" rather than "should this person hold this group".

See also: [access certification](https://startwithidentity.com/glossary/access-certification/), [what is IGA](https://startwithidentity.com/guides/fundamentals/what-is-iga/), [least privilege](https://startwithidentity.com/glossary/least-privilege/), [role mining](https://startwithidentity.com/glossary/role-mining/)

## entity-analytics
Source: https://startwithidentity.com/glossary/entity-analytics/
Last updated: 2026-11-05

Entity analytics is the behavioural analysis of every identity in an environment, human and non-human, to learn what normal activity looks like for each one and flag deviations that suggest compromise or misuse. An entity is any actor with an identity: an employee, a contractor, a service account, an API key, a workload, or an AI agent. [NIST's glossary](https://csrc.nist.gov/glossary/term/user_and_entity_behavior_analytics) treats the underlying category as user and entity behavior analytics (UEBA).

| Entity analytics | What it is not |
|---|---|
| Baselines per entity and per relationship between entities | A static rule such as "alert on login from a new country" |
| Covers service accounts, workloads and AI agents | UEBA limited to employee logins |
| A capability inside [ITDR](https://startwithidentity.com/glossary/itdr/) and [ISPM](https://startwithidentity.com/glossary/ispm/) tools | Usually a standalone product category |

Entity analytics is the broader successor to user and entity behaviour analytics ([UEBA](https://startwithidentity.com/glossary/ueba/)). The shift matters because in most environments non-human identities now outnumber human ones by a wide margin, and a model trained only on employee login patterns cannot reason about a service account that suddenly queries a new database or an AI agent invoking a tool it has never used. Where UEBA asked whether this user is behaving unusually, entity analytics asks the same of every principal and, critically, of the relationships between them.

In practice the capability appears inside [ITDR](https://startwithidentity.com/guides/fundamentals/what-is-itdr/) platforms and identity security posture tooling rather than as a standalone product category. Evaluate it on three things: which entity types are actually modelled, whether relationships between entities are represented or only individual behaviour, and how the baseline handles legitimate change such as a deployment or a seasonal workload.

See also: [ITDR](https://startwithidentity.com/guides/fundamentals/what-is-itdr/), [non-human identity](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/), [identity threat detection platforms](https://startwithidentity.com/articles/top-5-identity-threat-detection-platforms/)

## ethical-wall
Source: https://startwithidentity.com/glossary/ethical-wall/
Last updated: 2026-10-16

An ethical wall, also called an information barrier or screen, is a set of controls that stops confidential information held by one group inside a firm from reaching another group that must not have it. In US broker-dealers it is how firms meet Section 15(g) of the Securities Exchange Act, which requires written policies reasonably designed to prevent misuse of material nonpublic information (MNPI). In law firms it is the "screen" in ABA Model Rule 1.0(k), which under Rule 1.10 can keep a laterally hired lawyer's conflict from being imputed to the whole firm.

In identity terms an ethical wall is an access policy with a business reason attached. Bankers on the private side of a deal and traders on the public side get disjoint entitlements to deal rooms, document stores, chat channels and data feeds; a screened lawyer is denied access to the matter's files, which the ABA commentary says includes information in electronic form. Enforcement usually combines [RBAC](https://startwithidentity.com/glossary/rbac/) for the private and public side groups, [ABAC](https://startwithidentity.com/glossary/abac/) for deal-level or matter-level attributes, and [segregation of duties](https://startwithidentity.com/glossary/sod/) rules that block the conflicting combination at request time. The SEC's [2012 staff report on information barriers](https://www.sec.gov/about/offices/ocie/informationbarriers.pdf) flagged "above-the-wall" roles that receive MNPI with few controls, and listed reviewing access reports for electronic information services, and blocking public-side staff from them until authorized, among the effective practices it observed. Logged, reviewable access decisions are what turn the wall from a memo into evidence.

See also: [segregation of duties](https://startwithidentity.com/glossary/sod/), [ABAC](https://startwithidentity.com/glossary/abac/), [least privilege](https://startwithidentity.com/glossary/least-privilege/), [financial services identity](https://startwithidentity.com/verticals/financial-services/), [access certification](https://startwithidentity.com/glossary/access-certification/)

## eudi-wallet
Source: https://startwithidentity.com/glossary/eudi-wallet/
Last updated: 2026-08-29

The European Digital Identity Wallet mandated by the eIDAS 2.0 regulation, which requires every EU member state to offer citizens a state-recognized wallet for identity and attribute credentials. A flagship real-world driver of decentralized identity and the OpenID4VC protocols.

The EUDI Wallet is the reference implementation the rest of the world is watching, and its technical choices are becoming defaults elsewhere: OpenID4VCI and OpenID4VP for issuance and presentation, SD-JWT and mdoc for credential formats, selective disclosure by default. For companies outside the EU the relevant question is not compliance but interoperability, because national schemes are converging on the same protocol stack.

See also: [eIDAS 2.0 and the EUDI Wallet](https://startwithidentity.com/standards/eidas-2-eudi-wallet/), [OpenID4VC](https://startwithidentity.com/standards/openid4vc/), [mobile driver's license](https://startwithidentity.com/glossary/mobile-drivers-license/), [national digital ID schemes](https://startwithidentity.com/digital-ids/)

## fal
Source: https://startwithidentity.com/glossary/fal/
Last updated: 2026-10-16

NIST 800-63C levels describing how strongly a federated login protects the assertion an identity provider (IdP) sends to a relying party (RP). FAL1: the IdP signs the assertion with approved cryptography and restricts its audience. FAL2: adds strong protection against assertion injection, limits each assertion to a single RP, and requires a trust agreement set up before the transaction. FAL3: the RP also verifies that the subscriber controls an authenticator, through a holder-of-key assertion or a bound authenticator. Defined in [NIST SP 800-63C-4](https://pages.nist.gov/800-63-4/sp800-63c.html).

FAL is the level teams forget to write down. A program can demand AAL3 at the IdP and then hand the result to every application as a bearer SAML assertion or ID token, which an attacker who steals it can replay without ever touching the hardware key. The practical line in Revision 4 sits at FAL2, where injection protection means the RP must start the federation transaction, so unsolicited IdP-initiated responses no longer qualify. FAL3 closes the replay gap the same way [proof of possession](https://startwithidentity.com/glossary/proof-of-possession/) does for OAuth tokens: the assertion is only useful alongside a phishing-resistant authenticator the user holds.

See also: [NIST 800-63](https://startwithidentity.com/glossary/nist-800-63/), [AAL](https://startwithidentity.com/glossary/aal/), [IAL](https://startwithidentity.com/glossary/ial/), [identity federation](https://startwithidentity.com/glossary/federation/), [SAML 2.0](https://startwithidentity.com/standards/saml-2-0/)

## fan-out-breach
Source: https://startwithidentity.com/glossary/fan-out-breach/
Last updated: 2026-11-05

A fan-out breach is an incident in which one compromised identity or credential store at a provider (a support account, an integration's OAuth tokens, an app secret, a CI credential, a package publisher token) is used, or exposed for use, against many separate customer organizations. The term was coined by Start with Identity in the [Identity Breach Report 2026](https://startwithidentity.com/reports/identity-breach-report-2026/), which also defines the **fan-out** as the number of downstream organizations, tenants or repositories reached.

In the report's [Identity Breach Database](https://startwithidentity.com/breaches/incidents/), 19 of 123 incidents (15.4%) are fan-out breaches, rising to 10 of 50 (20%) of those disclosed in 2025-2026, and 14 of the 19 abused a non-human identity. Examples include [Okta via Sitel](https://startwithidentity.com/breaches/incidents/2022-okta-sitel-lapsus/), [CircleCI](https://startwithidentity.com/breaches/incidents/2023-circleci-engineer-session-token-theft/) and the [Salesloft Drift OAuth token theft](https://startwithidentity.com/breaches/incidents/2025-salesloft-drift-oauth-token-theft/). The report distinguishes these from shared-platform campaigns such as Snowflake 2024, where attackers broke into many customer accounts one by one with no compromise of the provider. The difference decides who has to act: a fan-out breach is the provider's identity problem (scope, rotate and revoke integration credentials), while each customer limits the blast radius with time-bound, least-privilege third-party access and IP restrictions on connected apps.

See also: [MFA blind zone](https://startwithidentity.com/glossary/mfa-blind-zone/), [non-human identity](https://startwithidentity.com/glossary/nhi/), [token theft](https://startwithidentity.com/glossary/token-theft/), [refresh token abuse](https://startwithidentity.com/techniques/refresh-token-abuse/), [secrets in repositories and CI](https://startwithidentity.com/techniques/secrets-in-repositories-and-ci/), [Shared Signals Framework](https://startwithidentity.com/standards/shared-signals-framework/)

## fapi
Source: https://startwithidentity.com/glossary/fapi/
Last updated: 2026-08-29

Financial-grade API. A hardened OAuth and OIDC security profile from the OpenID Foundation for high-risk APIs such as open banking, mandating stronger client authentication and request integrity.

FAPI is what OAuth looks like when the money is real: sender-constrained tokens, pushed authorization requests, strong client authentication, and signed request objects, all mandatory rather than optional. It became the de facto baseline for open banking worldwide, which means it is also the best available template for any high-value API even outside financial services. If you are securing payment initiation or account access, start from FAPI rather than from plain OAuth.

See also: [FAPI standard](https://startwithidentity.com/standards/fapi/), [PAR](https://startwithidentity.com/glossary/par/), [mTLS](https://startwithidentity.com/glossary/mtls/), [PSD2](https://startwithidentity.com/glossary/psd2/)

## federation
Source: https://startwithidentity.com/glossary/federation/
Last updated: 2026-11-05

Identity federation is a trust arrangement in which one party, the [identity provider](https://startwithidentity.com/glossary/identity-provider/), authenticates a user and another party, the [service provider](https://startwithidentity.com/glossary/service-provider/) or [relying party](https://startwithidentity.com/glossary/relying-party/), accepts a signed assertion of that identity instead of holding its own password for the user. The standards are [SAML 2.0](https://startwithidentity.com/standards/saml-2-0/) and [OpenID Connect](https://startwithidentity.com/standards/openid-connect/). Federation is the foundation of [SSO](https://startwithidentity.com/glossary/sso/), within one organization and between organizations.

| Federation | Not the same as |
|---|---|
| Trust between separate parties, expressed as signed assertions and exchanged metadata | Directory synchronization, which copies accounts and often password hashes |
| The mechanism | SSO, which is the user experience federation makes possible |
| Can span companies (partner or B2B access) | A shared account used by several organizations |

Federation is the reason an employee has one login instead of forty, and also the reason one compromised login opens forty systems. That trade is worth making, but it changes where the security work goes: into the identity provider, into session lifetime, and into what happens when the assertion itself can be forged. Most catastrophic SAML bugs are federation bugs, where a service provider accepted an assertion it should have rejected.

See also: [SSO](https://startwithidentity.com/glossary/sso/), [SAML 2.0](https://startwithidentity.com/standards/saml-2-0/), [OpenID Connect](https://startwithidentity.com/standards/openid-connect/), [SAML vs OIDC](https://startwithidentity.com/guides/fundamentals/saml-vs-oidc/)

## fedramp
Source: https://startwithidentity.com/glossary/fedramp/
Last updated: 2026-10-16

Federal Risk and Authorization Management Program. The US government cloud services authorization framework. Levels: Low, Moderate, High. Required for SaaS used by federal agencies. Authorization timelines run 12-24 months.

[FedRAMP](https://startwithidentity.com/regulations/united-states/fedramp/) is a market gate more than a security ceiling: it determines which identity vendors a federal agency can buy at all, which is why the authorized list is much shorter than the vendor landscape. Authorization timelines measured in months to years also shape the product, because vendors freeze the authorized boundary and ship new capability outside it. Check what is actually in the boundary, not just that the vendor holds an authorization.

See also: [compliance guides](https://startwithidentity.com/guides/compliance/), [SOC 2](https://startwithidentity.com/glossary/soc2/), [NIST 800-63](https://startwithidentity.com/glossary/nist-800-63/), [OSCAL](https://startwithidentity.com/glossary/oscal/), [identity for government article](https://startwithidentity.com/articles/identity-for-government/)

## fga
Source: https://startwithidentity.com/glossary/fga/
Last updated: 2026-08-29

Authorization at the level of individual resources or fields, rather than at the application or role level. Critical for multi-tenant SaaS, collaborative documents, and sharing patterns. ReBAC is the dominant implementation pattern.

Fine-grained authorization is the problem roles cannot solve: "can this user view this specific document" depends on relationships that change constantly and are owned by the application, not by the directory. Google's Zanzibar paper made relationship-based checks the dominant pattern, and the open implementations that followed made it buildable. The hard parts are consistency (a permission check that reads stale data grants stale access) and latency, since every request needs a decision.

See also: [ReBAC](https://startwithidentity.com/glossary/rebac/), [ABAC](https://startwithidentity.com/glossary/abac/), [RBAC vs ABAC vs ReBAC](https://startwithidentity.com/guides/fundamentals/rbac-vs-abac-vs-rebac/), [authorization vendors](https://startwithidentity.com/vendors/authorization/), [AuthZEN](https://startwithidentity.com/glossary/authzen/)

## fido2
Source: https://startwithidentity.com/glossary/fido2/
Last updated: 2026-08-29

FIDO2 is a set of specifications from the FIDO Alliance plus W3C. It combines WebAuthn (the browser API) with CTAP (the client-to-authenticator protocol) to enable phishing-resistant authentication using hardware or platform authenticators.

FIDO2 is the standards base under every passkey. The security property that matters is origin binding: the authenticator will only produce a signature for the site that registered the credential, so a proxy phishing page cannot obtain a usable assertion no matter how convincing it looks. That single property defeats the attacker-in-the-middle kits that relay one-time codes and push approvals at scale.

See also: [WebAuthn and FIDO2](https://startwithidentity.com/standards/webauthn-fido2/), [passkey](https://startwithidentity.com/glossary/passkey/), [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/), [add passkeys with WebAuthn recipe](https://startwithidentity.com/recipes/add-passkeys-webauthn/)

## gdpr
Source: https://startwithidentity.com/glossary/gdpr/
Last updated: 2026-08-29

General Data Protection Regulation. EU privacy law in force since 2018. Establishes user rights (access, rectification, erasure, portability) and obligations on controllers and processors. Identity systems must support data subject requests and granular consent.

GDPR shapes identity architecture more than any other privacy law because its rights map onto identity operations: access and portability require knowing every system holding a user's data, and erasure requires being able to delete it there. Purpose limitation is the one teams underestimate, since an identity graph assembled for authentication cannot be quietly reused for analytics. Consent records, retention windows, and lawful basis belong in the identity design, not bolted on.

See also: [consent management](https://startwithidentity.com/glossary/consent-management/), [what is CIAM](https://startwithidentity.com/guides/fundamentals/what-is-ciam/), [compliance guides](https://startwithidentity.com/guides/compliance/), [identity regulations](https://startwithidentity.com/regulations/)

## gnap
Source: https://startwithidentity.com/glossary/gnap/
Last updated: 2026-10-30

GNAP, the Grant Negotiation and Authorization Protocol ([RFC 9635](https://www.rfc-editor.org/rfc/rfc9635), Proposed Standard, October 2024), is an IETF delegated authorization protocol designed as a clean-slate successor to OAuth 2.0, in which a client negotiates a grant with an authorization server through a single JSON request that can describe rich access, several interaction modes, and key-bound tokens.

GNAP folds into one protocol several things OAuth needed extensions for: structured access requests similar to RAR, key-bound tokens by default, and interaction that can start on one device and finish on another. It is not compatible with OAuth, which is its main obstacle: client libraries, authorization servers, and API gateways all speak OAuth 2.0 and are moving to OAuth 2.1, while production GNAP deployments are uncommon. Read it for the design ideas, several of which (rich authorization, sender-constrained tokens) are now standard OAuth practice through RFC 9396 and DPoP, and choose OAuth for production unless you control both ends.

See also: [OAuth](https://startwithidentity.com/glossary/oauth/), [rich authorization requests](https://startwithidentity.com/glossary/rich-authorization-requests/), [proof of possession](https://startwithidentity.com/glossary/proof-of-possession/), [DPoP](https://startwithidentity.com/glossary/dpop/), [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/), [Justin Richer](https://startwithidentity.com/experts/justin-richer/)

## hipaa
Source: https://startwithidentity.com/glossary/hipaa/
Last updated: 2026-08-29

Health Insurance Portability and Accountability Act. US law governing the privacy and security of protected health information. Identity vendors serving healthcare must sign Business Associate Agreements and meet the Security Rule's access controls.

For identity teams [HIPAA](https://startwithidentity.com/regulations/united-states/hipaa/) translates into concrete controls: unique user identification, automatic logoff, audit controls over PHI access, and emergency access procedures. The access-log requirement is the one that drives architecture, because "who viewed this record and why" has to be answerable years later. Vendors handling PHI need a Business Associate Agreement, which is a procurement gate before it is a technical one.

See also: [compliance guides](https://startwithidentity.com/guides/compliance/), [access certification](https://startwithidentity.com/glossary/access-certification/), [break-glass](https://startwithidentity.com/glossary/break-glass/), [healthcare identity vertical](https://startwithidentity.com/verticals/healthcare/)

## hotp
Source: https://startwithidentity.com/glossary/hotp/
Last updated: 2026-08-29

HMAC-based One-Time Password (RFC 4226). A counter-based one-time code and the basis for TOTP. Largely superseded by time-based codes and phishing-resistant methods.

HOTP is mostly of historical interest now, but the counter model still shows up in hardware tokens and legacy banking devices. Its practical weakness beyond phishability is desynchronization: if the token advances without the server seeing it, the two drift apart and need a resync window, which is itself an attack surface. Time-based codes replaced it, and origin-bound credentials are replacing those.

See also: [TOTP](https://startwithidentity.com/glossary/totp/), [MFA](https://startwithidentity.com/glossary/mfa/), [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/), [MFA vendors](https://startwithidentity.com/vendors/mfa/)

## ial
Source: https://startwithidentity.com/glossary/ial/
Last updated: 2026-11-05

NIST 800-63A levels describing identity proofing strength. IAL1: self-asserted. IAL2: remote or in-person verification with evidence. IAL3: in-person verification by a trained agent.

IAL is about proofing, not login: it answers "how sure are we this account belongs to a real, specific person" rather than "how strongly did they authenticate". Conflating it with AAL is the common mistake, and it produces systems with hardware keys protecting accounts that were opened with an unverified email. Regulated onboarding, benefits programs, and anything with fraud exposure need both levels stated separately.

See also: [AAL](https://startwithidentity.com/glossary/aal/), [NIST 800-63](https://startwithidentity.com/glossary/nist-800-63/), [identity verification](https://startwithidentity.com/glossary/idv/), [trusted referee](https://startwithidentity.com/glossary/trusted-referee/), [identity verification vendors](https://startwithidentity.com/vendors/identity-verification/), [identity proofing](https://startwithidentity.com/glossary/identity-proofing/)

## iam
Source: https://startwithidentity.com/glossary/iam/
Last updated: 2026-11-05

IAM stands for identity and access management: the policies, processes and technology an organization uses to make sure the right identities (people and machines) get the right access to the right resources, and nothing more. In practice it covers four jobs: identifying users, [authenticating](https://startwithidentity.com/glossary/mfa/) them, [authorizing](https://startwithidentity.com/glossary/authorization/) what they can do, and managing that access across its lifecycle with an audit trail.

| IAM full form and scope | What it is not |
|---|---|
| Identity and Access Management, usually for the workforce: employees, contractors, partners, service accounts | [CIAM](https://startwithidentity.com/glossary/ciam/), which manages customers signing up to your product |
| The umbrella that includes [SSO](https://startwithidentity.com/glossary/sso/), [MFA](https://startwithidentity.com/glossary/mfa/), [IGA](https://startwithidentity.com/glossary/iga/) and [PAM](https://startwithidentity.com/glossary/pam/) | A single product, although [IDaaS](https://startwithidentity.com/glossary/idaas/) suites cover much of it |
| Access decisions for applications, data and infrastructure | Cloud provider IAM only (AWS IAM, Azure RBAC), which is one slice of it |

Workforce IAM is a lifecycle problem more than an authentication problem: the login is solved, and the failures are in what happens when someone joins, moves, or leaves, and in the accounts that belong to no one. It also increasingly covers identities that are not people at all, since service accounts and workloads now outnumber employees in most environments by a wide margin.

See also: [what is IAM](https://startwithidentity.com/guides/fundamentals/what-is-iam/), [what is IGA](https://startwithidentity.com/guides/fundamentals/what-is-iga/), [what is CIAM](https://startwithidentity.com/guides/fundamentals/what-is-ciam/), [IAM vendors](https://startwithidentity.com/vendors/iam/), [open source IAM](https://startwithidentity.com/articles/top-10-open-source-iam-solutions/)

## id-jag
Source: https://startwithidentity.com/glossary/id-jag/
Last updated: 2026-11-05

The Identity Assertion JWT Authorization Grant (ID-JAG) is a signed JWT, issued by an enterprise identity provider through OAuth 2.0 Token Exchange (RFC 8693), that a client presents as a JWT authorization grant (RFC 7523) to a third-party authorization server to get an access token for that server's API without a user consent prompt. It is defined in [draft-ietf-oauth-identity-assertion-authz-grant](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/), an active IETF OAuth Working Group draft that is not yet an RFC as of October 2026.

The flow has three steps: the user signs in to the requesting app through the IdP with OpenID Connect or SAML, the app exchanges that ID token (or a refresh token) at the IdP for an ID-JAG naming the target resource, and the app redeems the ID-JAG at the resource's authorization server. The token carries the `typ` header `oauth-id-jag+jwt` and its own token type URN, so it cannot be confused with an ID token. What changes for security teams is where the decision sits: the IdP, not each end user, decides which app may reach which API, and the IdP can refuse or log every connection. ID-JAG is the mechanism behind Cross App Access and the Model Context Protocol's Enterprise-Managed Authorization extension.

See also: [Cross App Access](https://startwithidentity.com/glossary/cross-app-access/), [identity chaining](https://startwithidentity.com/glossary/identity-chaining/), [token exchange](https://startwithidentity.com/glossary/token-exchange/), [MCP authorization](https://startwithidentity.com/glossary/mcp-authorization/), [agentic identity](https://startwithidentity.com/glossary/agentic-identity/), [Aaron Parecki](https://startwithidentity.com/experts/aaron-parecki/), [agent identity standards map 2026](https://startwithidentity.com/reports/agent-identity-standards-map-2026/), [ID-JAG and Cross App Access standard](https://startwithidentity.com/standards/id-jag-cross-app-access/), [delegation chain](https://startwithidentity.com/glossary/delegation-chain/)

## id-token
Source: https://startwithidentity.com/glossary/id-token/
Last updated: 2026-11-05

A JWT issued by an OpenID Connect provider that conveys authentication claims about the user. Unlike access tokens, ID tokens are intended for the client, not for resource servers. The client validates the signature, issuer, audience, and expiration before trusting the claims.

The single most common OIDC implementation bug is sending an ID token to an API and treating it as authorization. ID tokens are for the client: audience-restricted, meant to be read once at sign-in, and not designed to be presented to resource servers. Validate signature, issuer, audience, expiry, and nonce, then derive your own session. Use an access token for API calls.

See also: [OpenID Connect](https://startwithidentity.com/standards/openid-connect/), [access token](https://startwithidentity.com/glossary/access-token/), [claims](https://startwithidentity.com/glossary/claims/), [validate a JWT recipe](https://startwithidentity.com/recipes/validate-a-jwt/), [SSO identifier](https://startwithidentity.com/glossary/sso-identifier/)

## idaas
Source: https://startwithidentity.com/glossary/idaas/
Last updated: 2026-10-17

Identity as a Service (IDaaS) is identity and access management delivered from the cloud as a subscription: the provider runs the directory, single sign-on, MFA, and user provisioning, and you consume them over standard protocols such as [SAML](https://startwithidentity.com/glossary/saml/), [OpenID Connect](https://startwithidentity.com/glossary/oidc/), and [SCIM](https://startwithidentity.com/glossary/scim/) instead of operating identity servers yourself.

IDaaS is a delivery model, not a separate discipline. The capabilities match on-premises IAM; what moves to the provider is patching, scaling, and availability, while configuration, access policy, and integration stay your responsibility. Most workforce identity platforms, such as [Okta](https://startwithidentity.com/vendors/iam/okta/) and [Microsoft Entra ID](https://startwithidentity.com/vendors/iam/microsoft-entra/), are IDaaS, and most [CIAM](https://startwithidentity.com/glossary/ciam/) platforms are delivered the same way for customer-facing apps. The trade-off is concentration: a single IDaaS tenant fronts every application, so its admin accounts and session tokens become the highest-value targets in the estate.

See also: [what is IDaaS](https://startwithidentity.com/guides/fundamentals/what-is-idaas/), [what is workforce identity](https://startwithidentity.com/guides/fundamentals/what-is-workforce-identity/), [workforce identity](https://startwithidentity.com/glossary/workforce-identity/), [SSO](https://startwithidentity.com/glossary/sso/), [IAM platforms compared](https://startwithidentity.com/rankings/best-iam-platforms/)

## identity-chaining
Source: https://startwithidentity.com/glossary/identity-chaining/
Last updated: 2026-10-30

Identity chaining is an OAuth 2.0 mechanism, defined in the IETF draft OAuth Identity and Authorization Chaining Across Domains ([draft-ietf-oauth-identity-chaining](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/)), that preserves who the user is and what was authorized when a request crosses from one trust domain to another, by combining Token Exchange (RFC 8693) inside the first domain with a JWT authorization grant (RFC 7523) in the second. As of October 2026 the draft has been approved by the IESG and sits in the RFC Editor queue: it is not yet published as an RFC and has no RFC number.

The pattern repeats at every boundary: the client asks its own authorization server for a JWT grant aimed at the other domain, then redeems that grant at the other domain's authorization server for a local access token. Each hop can narrow scope and audience, and the subject survives the trip instead of being replaced by a shared service credential. It is the base layer for [ID-JAG](https://startwithidentity.com/glossary/id-jag/) and Cross App Access, which profile it for the enterprise IdP case, and it is the most likely standard answer for AI agents that call APIs in another company's domain.

See also: [token exchange](https://startwithidentity.com/glossary/token-exchange/), [ID-JAG](https://startwithidentity.com/glossary/id-jag/), [Cross App Access](https://startwithidentity.com/glossary/cross-app-access/), [transaction tokens](https://startwithidentity.com/glossary/transaction-tokens/), [federation](https://startwithidentity.com/glossary/federation/), [OAuth 2.0](https://startwithidentity.com/standards/oauth-2-0/), [agent identity standards map 2026](https://startwithidentity.com/reports/agent-identity-standards-map-2026/)

## identity-fabric
Source: https://startwithidentity.com/glossary/identity-fabric/
Last updated: 2026-11-05

An identity fabric is an architecture, not a product: a set of identity services from one or more vendors (identity provider, governance, privileged access, orchestration, analytics) connected so that policy, lifecycle and visibility stay consistent across cloud, on-premises and legacy systems. The term comes from Gartner, which [describes](https://www.gartner.com/en/conferences/na/identity-access-management-us/sessions/detail/4046039-The-10-Identity-Fabric-Principles-That-Prepare-IAM-for-the-Future) the identity fabric approach as evolving IAM infrastructure into a connected, risk-aware "system of systems."

A typical fabric has five layers: a primary [identity provider](https://startwithidentity.com/glossary/identity-provider/) for authentication and SSO, an [identity orchestration](https://startwithidentity.com/glossary/identity-orchestration/) layer that routes flows between systems, a governance layer ([IGA](https://startwithidentity.com/glossary/iga/)) for lifecycle and access reviews, a privileged access layer ([PAM](https://startwithidentity.com/glossary/pam/)), and an analytics or detection layer ([ITDR](https://startwithidentity.com/glossary/itdr/), [ISPM](https://startwithidentity.com/glossary/ispm/)) that correlates events across all of them. Shared signals, for example through the [Shared Signals Framework](https://startwithidentity.com/glossary/shared-signals-framework/), let one layer react to what another sees.

| Identity fabric | What it is not |
|---|---|
| An architecture that composes several identity services | A single suite, even if one vendor markets an "identity fabric" product |
| Consistent policy across many systems | A requirement to replace existing systems |
| Includes orchestration as one layer | The same as [identity orchestration](https://startwithidentity.com/glossary/identity-orchestration/), which is only the routing layer |

It matters because almost no enterprise runs one identity system: Active Directory sits next to Entra or Okta, a CIAM platform serves customers, and governance and PAM come from other vendors. The fabric view asks the right question, which is where policy is decided and how it reaches every system, instead of which single product to buy. The trade-off is integration cost and more tier-zero dependencies; Rubrik, for example, bought Strata in June 2026 to [fail authentication over to a secondary IdP](https://s203.q4cdn.com/667520861/files/doc_news/Rubrik-Advances-Identity-Resilience-Through-Strata-Acquisition-and-Identity-Roll-Forward-Innovation-2026.pdf) when the primary is down, a resilience layer most fabrics lack.

See also: [what is an identity fabric](https://startwithidentity.com/guides/fundamentals/what-is-identity-fabric/), [top identity fabric solutions](https://startwithidentity.com/articles/top-7-identity-fabric-solutions/), [identity orchestration platforms](https://startwithidentity.com/articles/top-7-identity-orchestration-platforms/), [identity resilience](https://startwithidentity.com/glossary/identity-resilience/), [workforce identity](https://startwithidentity.com/glossary/workforce-identity/)

## identity-orchestration
Source: https://startwithidentity.com/glossary/identity-orchestration/
Last updated: 2026-11-05

Identity orchestration is the practice of running login, registration, verification and access journeys as configurable flows that call several identity services (identity providers, MFA, fraud signals, identity proofing) from one layer outside the application, so the journey can change without a code release. An identity orchestration platform is the product that runs those flows.

The mechanics are simple: a flow is a sequence of steps, each step calls a connector to a service, and decision logic between steps picks the next path. Ping's documentation describes [PingOne DaVinci](https://docs.pingidentity.com/davinci/davinci_introduction.html) as "an orchestration platform that lets you create flows to guide users through IAM activities," and lets one application split traffic between flows for A/B testing. The same pattern drives IdP migrations: the orchestration layer routes each user to the old or new provider until cutover, and Rubrik now uses [Strata's orchestration](https://s203.q4cdn.com/667520861/files/doc_news/Rubrik-Advances-Identity-Resilience-Through-Strata-Acquisition-and-Identity-Roll-Forward-Innovation-2026.pdf), acquired in June 2026, to fail authentication over to a secondary IdP during an outage.

It matters because most organizations run more than one identity system. The trade-off is a new tier-zero dependency in the login path: if the orchestration layer is down or misconfigured, every flow behind it is too.

See also: [identity orchestration tools compared](https://startwithidentity.com/articles/top-7-identity-orchestration-platforms/), [CIAM journey orchestration](https://startwithidentity.com/articles/ciam-orchestration-guide/), [what is identity fabric](https://startwithidentity.com/guides/fundamentals/what-is-identity-fabric/), [identity provider](https://startwithidentity.com/glossary/identity-provider/), [identity fabric](https://startwithidentity.com/glossary/identity-fabric/)

## identity-proofing
Source: https://startwithidentity.com/glossary/identity-proofing/
Last updated: 2026-11-05

Identity proofing is the process of confirming that an applicant is a specific, real person before issuing them an account or credential; [NIST SP 800-63A-4](https://pages.nist.gov/800-63-4/sp800-63a.html) defines it as "establishing a relationship between a subject accessing online services" and "a real-life person to some degree of assurance." The strength of the process is graded by [Identity Assurance Level (IAL)](https://startwithidentity.com/glossary/ial/).

SP 800-63A-4, which supersedes SP 800-63A, splits proofing into three steps:

| Step | What it confirms |
|---|---|
| Resolution | The evidence and attributes collected point to one unique person |
| Validation | The evidence (for example a passport or driver's license) is genuine, accurate and current |
| Verification | The applicant is the same person the evidence was issued to, often by comparing a live selfie to the document photo |

It also names four ways to run them: remote unattended (fully automated), remote attended (a proofing agent over a secure video session), on-site unattended (a kiosk) and on-site attended. At IAL3 a trained representative attends the session and collects at least one biometric. A [trusted referee](https://startwithidentity.com/glossary/trusted-referee/) can make a risk-based decision for an applicant who cannot meet the normal evidence requirements.

Identity proofing is not authentication. Proofing happens once, at enrollment or recovery, and answers "who is this person"; authentication happens at every sign-in and answers "is this the same person we proofed". The two meet at account recovery: if a help desk resets MFA without re-proofing, the attacker skips straight past both. That is why proofing now appears in workforce programs, not only in banking [KYC](https://startwithidentity.com/glossary/kyc/): it is the step before issuing a [Temporary Access Pass](https://startwithidentity.com/glossary/temporary-access-pass/) or a first passkey.

See also: [identity verification (IDV)](https://startwithidentity.com/glossary/idv/), [IAL](https://startwithidentity.com/glossary/ial/), [NIST SP 800-63](https://startwithidentity.com/glossary/nist-800-63/), [top identity proofing solutions](https://startwithidentity.com/articles/top-5-identity-proofing-solutions/), [customer identity verification guide](https://startwithidentity.com/guides/compliance/customer-identity-verification-guide/), [help desk social engineering](https://startwithidentity.com/techniques/help-desk-social-engineering/)

## identity-provider
Source: https://startwithidentity.com/glossary/identity-provider/
Last updated: 2026-08-29

A system that authenticates users and issues assertions or tokens vouching for their identity to other applications. In federated single sign-on, the identity provider (for example Okta, Microsoft Entra ID, or Ping) authenticates the user once and the relying service provider trusts its assertion, using [SAML](https://startwithidentity.com/standards/saml-2-0/) or [OpenID Connect](https://startwithidentity.com/standards/openid-connect/). Decentralized identity removes the runtime dependency on a central IdP by letting the holder present signed credentials directly.

Concentrating authentication in one provider is the right architecture and creates the obvious dependency: the IdP is now both the highest-value target and a single point of failure. That is why break-glass paths, IdP-side threat detection, and a tested answer to "what do we do when the IdP is down or compromised" belong in the design rather than in the incident retrospective.

See also: [SSO](https://startwithidentity.com/glossary/sso/), [identity orchestration](https://startwithidentity.com/glossary/identity-orchestration/), [best SSO providers](https://startwithidentity.com/articles/top-8-sso-solutions-smbs/), [federation](https://startwithidentity.com/glossary/federation/), [service provider](https://startwithidentity.com/glossary/service-provider/), [Okta 2023 support system breach](https://startwithidentity.com/breaches/okta-2023-support-system-breach/)

## identity-resilience
Source: https://startwithidentity.com/glossary/identity-resilience/
Last updated: 2026-09-20

The ability to keep authenticating and authorising legitimate users, and to recover the identity system itself, when the identity provider or directory is degraded, compromised, or unavailable.

Identity resilience is a distinct discipline from identity security. Security asks how an attacker gets in; resilience asks what happens once the identity system is the casualty. If Active Directory is encrypted in a ransomware event, or a cloud identity provider has a multi-hour outage, every downstream application that depends on it fails at once. Identity has become the single point of failure that most disaster recovery plans still treat as infrastructure someone else looks after.

Three capabilities carry most of the weight. **Forest and tenant recovery** means being able to rebuild a directory to a known-good state, tested rather than assumed, which is the specialism of vendors such as Semperis. **Break-glass access** means credentials that work when the identity provider does not, stored and governed outside it, and exercised in drills rather than discovered during an incident. **Authentication fallback** means a documented path for critical applications when primary authentication is down, agreed in advance rather than improvised.

The practical test is simple and uncomfortable: if your directory were unavailable right now, how long until a named person could restore it, and has anyone actually done it?

See also: [ITDR](https://startwithidentity.com/guides/fundamentals/what-is-itdr/), [zero standing privileges](https://startwithidentity.com/articles/zero-standing-privileges-best-practices/), [ITDR tools compared](https://startwithidentity.com/rankings/best-itdr-tools/)

## idv
Source: https://startwithidentity.com/glossary/idv/
Last updated: 2026-11-05

The process of confirming that a person is who they claim to be, typically at account opening. Common signals: government ID document scan, selfie with liveness, address verification, device and behavior signals.

Identity verification is a fraud problem with an accuracy budget: every control that stops a fraudster also rejects some genuine customers, and the right operating point differs between a bank and a marketplace. Document plus liveness is the current baseline, deepfake-resistant liveness is the active arms race, and reusable credentials are the direction of travel, because verifying once and presenting many times is cheaper and less invasive than re-proofing at every relationship.

See also: [KYC](https://startwithidentity.com/glossary/kyc/), [IAL](https://startwithidentity.com/glossary/ial/), [identity verification vendors](https://startwithidentity.com/vendors/identity-verification/), [reusable identity and KYC with verifiable credentials](https://startwithidentity.com/guides/decentralized-identity/reusable-identity-and-kyc-with-verifiable-credentials/), [age verification](https://startwithidentity.com/glossary/age-verification/), [identity proofing](https://startwithidentity.com/glossary/identity-proofing/)

## iga
Source: https://startwithidentity.com/glossary/iga/
Last updated: 2026-08-29

Identity Governance and Administration. The discipline of managing who has access to what, why, and for how long. Covers access certification, segregation of duties, joiner-mover-leaver lifecycle, and audit reporting.

IGA is the least glamorous and most audited part of identity, and the discipline where tooling helps least without process. The recurring failure is buying a platform to answer "who has access to what" in an environment where the authoritative data is spread across an HR system, a directory, and dozens of applications with no consistent notion of a user. Connector coverage and data quality decide the outcome, not the product.

See also: [what is IGA](https://startwithidentity.com/guides/fundamentals/what-is-iga/), [access certification](https://startwithidentity.com/glossary/access-certification/), [joiner-mover-leaver](https://startwithidentity.com/glossary/joiner-mover-leaver/), [IGA vendors](https://startwithidentity.com/vendors/iga/)

## infostealer
Source: https://startwithidentity.com/glossary/infostealer/
Last updated: 2026-08-29

Malware that harvests credentials, cookies, and session tokens from infected devices, then sells them. A major driver of recent account-takeover and session-theft growth.

Infostealers changed the economics of account takeover: the credential is stolen once from an endpoint and resold repeatedly, often working years later because nobody rotated it. They also take session cookies, which is why the theft survives a password reset and defeats MFA that was only enforced at login. The Snowflake campaign is the canonical case, built entirely on infostealer logs against accounts without MFA.

See also: [token theft](https://startwithidentity.com/glossary/token-theft/), [session hijacking](https://startwithidentity.com/glossary/session-hijacking/), [account takeover](https://startwithidentity.com/glossary/account-takeover/), [Snowflake 2024 credential attacks](https://startwithidentity.com/breaches/snowflake-2024-credential-attacks/)

## instance-metadata-service
Source: https://startwithidentity.com/glossary/instance-metadata-service/
Last updated: 2026-10-16

The instance metadata service (IMDS) is an HTTP endpoint reachable only from inside a cloud virtual machine, at 169.254.169.254 on AWS EC2, that returns data about the instance, including temporary credentials for the IAM role attached to it.

On AWS, [IMDSv1](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) answers a plain GET request, so a server-side request forgery (SSRF) flaw that makes an application fetch an attacker-chosen URL can hand over the role's credentials. IMDSv2 is session-oriented: the caller must first obtain a token with a PUT request (valid for up to six hours) and send it as a header on every request, PUT requests carrying an X-Forwarded-For header are rejected, and each instance can be set to refuse IMDSv1 entirely. AI agents are a new source of SSRF: in October 2026 Zenity Labs showed a prompt making an Amazon Bedrock AgentCore agent's HTTP tool [fetch its execution role credentials from IMDS](https://startwithidentity.com/blog/2026-10-08-one-prompt-pulled-aws-agentcore-role-credentials-from-imds/), and the default role could reach other agents' conversations, memory and secrets. Require IMDSv2, and scope every instance or agent role on the assumption that anyone who can make the workload issue a request holds its credentials.

See also: [workload identity](https://startwithidentity.com/glossary/workload-identity/), [least privilege](https://startwithidentity.com/glossary/least-privilege/), [prompt injection](https://startwithidentity.com/glossary/prompt-injection/), [MLflow SSRF reaches cloud metadata](https://startwithidentity.com/blog/2026-08-18-mlflow-ssrf-reaches-cloud-metadata-for-credentials/)

## iso-27001
Source: https://startwithidentity.com/glossary/iso-27001/
Last updated: 2026-10-17

ISO/IEC 27001 is the international standard that specifies requirements for an information security management system (ISMS). The current edition is [ISO/IEC 27001:2022](https://www.iso.org/standard/27001), amended in February 2024 by [Amendment 1](https://www.iso.org/standard/88435.html), and organizations are certified against it by accredited third-party certification bodies, not by ISO itself.

The 2024 amendment is narrow: it adds climate change as an issue the organization must consider when setting the context of its ISMS (clauses 4.1 and 4.2), and changes no controls. The identity work sits in Annex A: 5.15 Access control, 5.16 Identity management, 5.17 Authentication information, 5.18 Access rights, 8.2 Privileged access rights and 8.5 Secure authentication, which auditors test through evidence of provisioning, [access reviews](https://startwithidentity.com/glossary/access-certification/), prompt [deprovisioning](https://startwithidentity.com/glossary/deprovisioning/), MFA coverage and privileged access control. Unlike a [SOC 2](https://startwithidentity.com/glossary/soc2/) report, which is an auditor's attestation read by customers, ISO 27001 produces a certificate with a declared scope and a Statement of Applicability, so check the scope covers the systems you care about.

See also: [identity controls for ISO 27001](https://startwithidentity.com/guides/compliance/identity-controls-for-iso-27001/), [SOC 2](https://startwithidentity.com/glossary/soc2/), [IAM audit preparation](https://startwithidentity.com/guides/compliance/iam-audit-preparation-guide/), [access certification](https://startwithidentity.com/glossary/access-certification/), [joiner-mover-leaver](https://startwithidentity.com/glossary/joiner-mover-leaver/)

## ispm
Source: https://startwithidentity.com/glossary/ispm/
Last updated: 2026-08-29

Identity Security Posture Management. Continuous assessment of identity-related misconfigurations and risk, such as dormant accounts, weak MFA coverage, and risky entitlements. Posture is preventive; ITDR is the runtime detection counterpart.

Posture management answers "what could go wrong" while detection answers "what is going wrong", and the two need different data. ISPM findings are usually unglamorous and high value: accounts excluded from MFA policy, admins without privileged workstations, dormant service accounts with live keys, and nested group membership nobody intended. The work is prioritization, since a raw findings list from a large tenant is unusable.

See also: [what is ITDR](https://startwithidentity.com/guides/fundamentals/what-is-itdr/), [CIEM](https://startwithidentity.com/glossary/ciem/), [least privilege](https://startwithidentity.com/glossary/least-privilege/), [ITDR vendors](https://startwithidentity.com/vendors/itdr/)

## issuer-holder-verifier
Source: https://startwithidentity.com/glossary/issuer-holder-verifier/
Last updated: 2026-08-29

The three roles in every decentralized identity exchange, often called the trust triangle. The issuer signs and grants a credential, the holder stores it in a wallet and controls presentation, and the verifier checks the signature and status without contacting the issuer in real time.

The triangle is what makes decentralized identity different from federation: the verifier checks a signature rather than calling the issuer, so the issuer does not learn where the credential is used. That removes a surveillance channel and a runtime dependency, and it moves two hard problems onto the verifier: deciding which issuers to trust, and checking revocation without reintroducing the phone-home the model was meant to remove.

See also: [verifiable credential](https://startwithidentity.com/glossary/verifiable-credential/), [trust registry](https://startwithidentity.com/glossary/trust-registry/), [revocation registry](https://startwithidentity.com/glossary/revocation-registry/), [what is decentralized identity](https://startwithidentity.com/guides/fundamentals/what-is-decentralized-identity/)

## itdr
Source: https://startwithidentity.com/glossary/itdr/
Last updated: 2026-08-29

Identity Threat Detection and Response. Security tooling that detects and responds to identity-based attacks such as account takeover, privilege escalation, and lateral movement, often across Active Directory, Entra ID, and cloud IdPs. Complements prevention and posture by catching attacks at runtime.

ITDR exists because endpoint and network tools do not see identity attacks: there is no malware in a valid login with a stolen token. It watches the identity control plane itself, which in most enterprises means Active Directory and the cloud IdP together, since attackers routinely pivot between them. The detections that matter are behavioral, because every individual action in the chain is technically authorized.

See also: [what is ITDR](https://startwithidentity.com/guides/fundamentals/what-is-itdr/), [lateral movement](https://startwithidentity.com/glossary/lateral-movement/), [ISPM](https://startwithidentity.com/glossary/ispm/), [ITDR vendors](https://startwithidentity.com/vendors/itdr/)

## jit-access
Source: https://startwithidentity.com/glossary/jit-access/
Last updated: 2026-11-05

Granting elevated permissions only when needed, for a limited duration, and revoking them automatically. JIT eliminates [standing privilege](https://startwithidentity.com/glossary/standing-privilege/), the largest contributor to blast radius after compromise.

Just-in-time access is the most effective single change available to a privileged access program, because it converts a permanent target into a time-boxed one. It only works if the request path is fast enough that engineers use it rather than routing around it, which usually means approval automation and chat-based requests rather than a ticket queue. Measure standing privilege count as the outcome, not the number of requests processed.

See also: [best just-in-time access tools](https://startwithidentity.com/articles/top-5-just-in-time-access-tools/), [best PAM tools for DevOps](https://startwithidentity.com/rankings/best-pam-for-devops/), [zero standing privileges](https://startwithidentity.com/glossary/zero-standing-privileges/), [what is PAM](https://startwithidentity.com/guides/fundamentals/what-is-pam/), [least privilege](https://startwithidentity.com/glossary/least-privilege/), [PAM vendors](https://startwithidentity.com/vendors/pam/)

## joiner-mover-leaver
Source: https://startwithidentity.com/glossary/joiner-mover-leaver/
Last updated: 2026-11-05

The joiner-mover-leaver (JML) process is the set of identity changes triggered when someone joins an organization (joiner: create accounts and grant birthright access), changes role (mover: add new access and remove old access) or leaves (leaver: disable accounts and revoke access). Automating JML from the HR system is the core of [user lifecycle management](https://startwithidentity.com/glossary/user-lifecycle-management/) and a core [IGA](https://startwithidentity.com/glossary/iga/) capability.

| Event | Trigger | Must happen |
|---|---|---|
| Joiner | Hire record in HR | Accounts and birthright roles ready on day one, first credential issued safely |
| Mover | Department, title or manager change | New-role access added and old-role access removed in the same change |
| Leaver | Termination or end date | Accounts disabled, sessions and tokens revoked, owned assets reassigned |

Mover is the event everyone under-invests in and auditors always find. Joiners get access because someone is waiting to work, leavers get removed because HR triggers it, but transfers accumulate: the new role's access is added and the old role's is never taken away, producing employees whose entitlements are an archaeology of their career. Automated mover handling is what keeps least privilege true over time.

See also: [deprovisioning](https://startwithidentity.com/glossary/deprovisioning/), [provisioning](https://startwithidentity.com/glossary/provisioning/), [what is IGA](https://startwithidentity.com/guides/fundamentals/what-is-iga/), [access certification](https://startwithidentity.com/glossary/access-certification/)

## jwks
Source: https://startwithidentity.com/glossary/jwks/
Last updated: 2026-08-29

JSON Web Key Set. A published set of public keys an issuer uses to sign tokens, letting relying parties verify JWT signatures and handle key rotation.

The JWKS endpoint is what makes key rotation possible without coordinating with every relying party, and caching it correctly is what makes rotation not cause an outage. Cache with a sane TTL, refetch on an unknown key id rather than on every request, and never disable signature verification to work around a rotation problem. Pinning a single key defeats the purpose and eventually breaks.

See also: [JWT](https://startwithidentity.com/glossary/jwt/), [ID token](https://startwithidentity.com/glossary/id-token/), [OpenID Connect](https://startwithidentity.com/standards/openid-connect/), [validate a JWT recipe](https://startwithidentity.com/recipes/validate-a-jwt/)

## jwt
Source: https://startwithidentity.com/glossary/jwt/
Last updated: 2026-08-29

A compact, URL-safe token format with three base64-encoded segments: header, payload, and signature. Defined by RFC 7519. JWTs are the dominant format for ID tokens and bearer access tokens. Verify the signature; never trust unsigned JWTs.

JWTs are easy to produce and easy to verify wrongly, which is why they generate a steady stream of authentication bypasses: accepting `alg: none`, confusing HMAC and RSA verification, skipping the audience check, or trusting a `kid` that points at attacker-controlled key material. Use a maintained library, pin the expected algorithms, and validate issuer, audience, and expiry every time. A JWT is signed, not encrypted, so nothing secret belongs in the payload.

See also: [claims](https://startwithidentity.com/glossary/claims/), [JWKS](https://startwithidentity.com/glossary/jwks/), [access token](https://startwithidentity.com/glossary/access-token/), [identity CVE catalog](https://startwithidentity.com/cves/)

## kerberos
Source: https://startwithidentity.com/glossary/kerberos/
Last updated: 2026-09-21

A ticket-based network authentication protocol using symmetric cryptography and a trusted third party, the Key Distribution Center. A client authenticates once, receives a ticket-granting ticket, and exchanges it for short-lived service tickets without resending credentials. Version 5 is specified in RFC 4120.

Kerberos descends from the Needham-Schroeder protocol of 1978 and was built at MIT's Project Athena. It is the primary authentication protocol in Active Directory, which makes it one of the most widely used pieces of security software in existence. Its design, authenticate once then present short-lived tickets, is the same shape as every token-based system that followed, including OAuth. It also means the ticket handling is the attack surface: tickets that can be requested offline and cracked, service accounts with weak passwords, and delegation settings that let one compromise reach further than intended.

See also: [Active Directory](https://startwithidentity.com/glossary/active-directory/), [Kerberoasting](https://startwithidentity.com/techniques/kerberoasting/), [Kerberos delegation abuse](https://startwithidentity.com/techniques/kerberos-delegation-abuse/), [Clifford Neuman](https://startwithidentity.com/experts/clifford-neuman/), [SSO](https://startwithidentity.com/glossary/sso/)

## kyc
Source: https://startwithidentity.com/glossary/kyc/
Last updated: 2026-08-29

Know Your Customer. Regulatory obligations to identify and verify the identity of customers, primarily in financial services. KYC is a workflow built on top of identity verification technology.

KYC is the regulated wrapper around identity verification: the same document and liveness checks, plus record-keeping, risk scoring, ongoing monitoring, and sanctions screening. The cost and friction it imposes at onboarding are what make reusable credentials attractive, since a verified attribute presented from a wallet can satisfy the check without repeating the proofing at every institution.

See also: [AML](https://startwithidentity.com/glossary/aml/), [identity verification](https://startwithidentity.com/glossary/idv/), [reusable identity and KYC](https://startwithidentity.com/guides/decentralized-identity/reusable-identity-and-kyc-with-verifiable-credentials/), [identity verification vendors](https://startwithidentity.com/vendors/identity-verification/)

## lateral-movement
Source: https://startwithidentity.com/glossary/lateral-movement/
Last updated: 2026-08-29

How an attacker moves from an initial foothold to other systems and accounts, often abusing identity and trust relationships. A primary target of identity threat detection.

Modern lateral movement is mostly identity work rather than exploitation: harvest a token, abuse a trust relationship between an on-premises directory and a cloud tenant, assume a role, or use a management platform that already has agents everywhere. That is why network segmentation alone does not stop it, and why the useful telemetry is authentication and authorization events rather than packets.

See also: [privilege escalation](https://startwithidentity.com/glossary/privilege-escalation/), [what is ITDR](https://startwithidentity.com/guides/fundamentals/what-is-itdr/), [token theft](https://startwithidentity.com/glossary/token-theft/), [Scattered Spider help desk social engineering](https://startwithidentity.com/breaches/scattered-spider-helpdesk-social-engineering/)

## ldap
Source: https://startwithidentity.com/glossary/ldap/
Last updated: 2026-11-05

Lightweight Directory Access Protocol. A protocol for querying and modifying a hierarchical directory of entries, each identified by a distinguished name. Used to read users, groups, and attributes, and to authenticate by binding as a user with their password.

LDAP predates the modern identity stack and still underpins it. Active Directory, OpenLDAP, and most directory products speak it, and a large amount of legacy application authentication is still an LDAP bind. That is worth understanding precisely, because an LDAP bind means the application receives the user's actual password, which is exactly what SAML, OIDC, and Kerberos were designed to avoid. Migrating those applications to a federation protocol is usually the highest-value step in an identity modernization.

See also: [Active Directory](https://startwithidentity.com/glossary/active-directory/), [SAML](https://startwithidentity.com/glossary/saml/), [OIDC](https://startwithidentity.com/glossary/oidc/), [identity provider](https://startwithidentity.com/glossary/identity-provider/), [directory service](https://startwithidentity.com/glossary/directory-service/)

## least-privilege
Source: https://startwithidentity.com/glossary/least-privilege/
Last updated: 2026-08-29

The principle of granting an identity only the access it needs, for only as long as it needs it. Reduces blast radius when an account is compromised.

Least privilege is universally endorsed and rarely measured, which is the whole problem. It becomes real when you can compare granted permissions against used permissions and act on the difference, and when access is time-bound by default rather than permanent. Without those two mechanisms it degrades into an aspiration that entitlement growth quietly overwhelms.

See also: [zero standing privileges](https://startwithidentity.com/glossary/zero-standing-privileges/), [CIEM](https://startwithidentity.com/glossary/ciem/), [entitlement](https://startwithidentity.com/glossary/entitlement/), [just-in-time access](https://startwithidentity.com/glossary/jit-access/)

## llmjacking
Source: https://startwithidentity.com/glossary/llmjacking/
Last updated: 2026-09-29

LLMjacking is the use of stolen credentials to consume, resell, or abuse someone else's access to a large language model, usually through a cloud account or an AI provider API key, leaving the victim with the bill. The term was coined by the Sysdig Threat Research Team in 2024.

In the cases Sysdig documented, attackers obtained cloud access keys, found hosted model services such as Amazon Bedrock, invoked models directly, and in some cases sold access onward through reverse proxies; Sysdig estimated costs to a victim of more than 46,000 dollars a day for some models, and two to three times that for the most expensive. The same pattern now extends to AI provider keys and sessions harvested by infostealers, such as the [live API keys for four AI providers](https://startwithidentity.com/blog/2026-09-09-okta-finds-replayable-ai-session-tokens-in-infostealer-logs/) Okta found in one dump. Defenses are ordinary credential hygiene applied to a new, expensive target: no long-lived AI keys in code or on laptops, least-privilege policies that deny model invocation to identities that do not need it, budget alerts, and model invocation logging, including alerts on attempts to switch that logging off.

See also: [API key](https://startwithidentity.com/glossary/api-key/), [infostealer](https://startwithidentity.com/glossary/infostealer/), [static API key abuse](https://startwithidentity.com/techniques/static-api-key-abuse/), [secrets management](https://startwithidentity.com/glossary/secrets-management/)

## local-login-bypass
Source: https://startwithidentity.com/glossary/local-login-bypass/
Last updated: 2026-11-05

A local login bypass is any way into an SSO-protected application that does not go through the identity provider: an owner or admin account that keeps a password, a social login that skips SSO, an API token or a break-glass account. Because the IdP never sees these sign-ins, none of its controls (phishing-resistant MFA, conditional access, session revocation, deprovisioning) apply to them.

SWI uses the term in the [Phishing-Resistant MFA Support Matrix 2026](https://startwithidentity.com/reports/phishing-resistant-mfa-matrix-2026/), which documents bypass paths next to SSO in widely used apps: HCP Terraform owners can bypass SSO, Linear's top role can still log in by any method, 1Password Owners still sign in with their account password and Secret Key, Grafana Cloud exempts social-login users from enforced MFA, and Coda's 2FA covers only email and password logins. Attackers look for exactly these doors, since one owner account with a phishable password undoes an SSO rollout. The fix is to enable [SSO enforcement](https://startwithidentity.com/glossary/sso-enforcement/) where the app offers it, keep the unavoidable exceptions to named [break-glass accounts](https://startwithidentity.com/glossary/break-glass/) with security keys stored offline, alert on every local sign-in, and review the list quarterly. The [MFA matrix](https://startwithidentity.com/tools/mfa-matrix/) notes column records each app's known exceptions.

See also: [SSO enforcement](https://startwithidentity.com/glossary/sso-enforcement/), [break-glass account](https://startwithidentity.com/glossary/break-glass/), [phishable MFA](https://startwithidentity.com/glossary/phishable-mfa/), [social login](https://startwithidentity.com/glossary/social-login/), [orphaned account abuse](https://startwithidentity.com/techniques/orphaned-account-abuse/), [SAML 2.0](https://startwithidentity.com/standards/saml-2-0/)

## machine-identity
Source: https://startwithidentity.com/glossary/machine-identity/
Last updated: 2026-11-05

A machine identity is the credential that lets a device, server, application or workload prove who it is to another system without a person signing in: most often an [X.509](https://startwithidentity.com/glossary/x509/) certificate, and also SSH keys, API keys, cloud workload credentials and [SPIFFE](https://startwithidentity.com/glossary/spiffe/) SVIDs. Machine identities are the cryptographic subset of [non-human identities](https://startwithidentity.com/glossary/nhi/).

| Credential | Issued by | Typical lifetime | Managed with |
|---|---|---|---|
| Public TLS certificate | Public [certificate authority](https://startwithidentity.com/glossary/certificate-authority/) | At most 200 days since March 15, 2026, 47 days from 2029 | [ACME](https://startwithidentity.com/glossary/acme/), [CLM](https://startwithidentity.com/glossary/certificate-lifecycle/) |
| Internal mTLS or device certificate | Private CA | Policy-defined, often hours to a year | CLM, service mesh |
| SPIFFE SVID | SPIRE or a mesh CA | Short-lived by design | [Workload identity](https://startwithidentity.com/glossary/workload-identity/) platform |
| Cloud workload credential | AWS, Azure or Google Cloud | Minutes to hours | [Workload identity federation](https://startwithidentity.com/glossary/workload-identity-federation/) |
| SSH key, API key | Whoever generated it | Often never expires | [Secrets management](https://startwithidentity.com/glossary/secrets-management/) |

"Machine identity" and "non-human identity" are often used interchangeably, but the useful distinction is this: NHI is the whole population of non-person identities, including [service accounts](https://startwithidentity.com/glossary/service-account/) and AI agents, while machine identity management focuses on issuing, rotating and revoking the credentials those identities present. The public TLS lifetime cuts under CA/Browser Forum [Ballot SC-081v3](https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/) are the main reason the market has grown: a certificate that renews every 47 days cannot be managed by spreadsheet.

It matters because a stolen machine credential is a stolen identity with no MFA in front of it. The goal is credentials that are short-lived, attested by the platform and owned by a named team, rather than long-lived keys that someone pasted into a config file.

See also: [what is machine identity](https://startwithidentity.com/guides/fundamentals/what-is-machine-identity/), [machine identity management guide](https://startwithidentity.com/guides/machine-identity/machine-identity-management-guide/), [top machine identity management platforms](https://startwithidentity.com/articles/top-5-machine-identity-management-platforms/), [best machine identity for enterprises](https://startwithidentity.com/rankings/best-machine-identity-for-enterprises/), [machine identity vendors](https://startwithidentity.com/vendors/machine-identity/)

## magic-link
Source: https://startwithidentity.com/glossary/magic-link/
Last updated: 2026-08-29

A passwordless login where the user clicks a one-time link sent to their email. Simple to ship but inherits email security and deliverability limits, and is not phishing-resistant.

Magic links trade one credential for another: the account is now exactly as secure as the mailbox, and the mailbox is the single most attacked account a person has. They also break in ordinary ways, through link scanners that consume the token, corporate mail rewriting, and cross-device flows where the link opens in the wrong browser. Fine as a low-friction option, wrong as the only path for anything valuable.

See also: [what is passwordless](https://startwithidentity.com/guides/fundamentals/what-is-passwordless/), [passkey](https://startwithidentity.com/glossary/passkey/), [social login](https://startwithidentity.com/glossary/social-login/), [CIAM vendors](https://startwithidentity.com/vendors/ciam/)

## mcp-authorization
Source: https://startwithidentity.com/glossary/mcp-authorization/
Last updated: 2026-11-05

MCP authorization is the part of the [Model Context Protocol specification](https://modelcontextprotocol.io/specification/latest/basic/authorization) that defines how an AI client obtains and presents OAuth access tokens to a remote MCP server over HTTP, built on a subset of the OAuth 2.1 draft plus RFC 9728 (Protected Resource Metadata), RFC 8414 (Authorization Server Metadata), RFC 8707 (Resource Indicators), and Client ID Metadata Documents. It is a specification published by the MCP project, not an IETF standard; the current revision at the time of writing is dated 2026-07-28, and servers using the local STDIO transport are told not to use it and to read credentials from the environment instead.

In practice the MCP server acts as an OAuth resource server, returns a 401 that points to its protected resource metadata, and the client discovers the authorization server, registers (pre-registration first, then a Client ID Metadata Document, then Dynamic Client Registration as a fallback), and runs the authorization code flow with PKCE and a `resource` parameter. Two rules carry most of the security weight: tokens must be audience-bound to the specific MCP server, and an MCP server must not pass a client's token through to upstream APIs, which prevents the confused deputy problem. Optional extensions, kept in a [separate repository](https://github.com/modelcontextprotocol/ext-auth), add Enterprise-Managed Authorization (Cross App Access via ID-JAG) and OAuth client credentials for machine-to-machine use. For security teams, the open issue is less the protocol than inventory: knowing which MCP servers employees have connected and what each token can reach.

Implementations fail in ordinary ways. LiteLLM's MCP Streamable HTTP endpoint fell back to an empty auth object when key validation failed, so a fabricated Authorization header reached the gateway's tools ([CVE-2026-59822](https://startwithidentity.com/cves/cve-2026-59822/)); honeypots saw it used in the wild before CISA added it to KEV. Treat a failed token check as a hard 401, never as anonymous access.

See also: [protected resource metadata](https://startwithidentity.com/glossary/protected-resource-metadata/), [resource indicators](https://startwithidentity.com/glossary/resource-indicators/), [Client ID Metadata Document](https://startwithidentity.com/glossary/client-id-metadata-document/), [Cross App Access](https://startwithidentity.com/glossary/cross-app-access/), [agentic identity](https://startwithidentity.com/glossary/agentic-identity/), [PKCE](https://startwithidentity.com/glossary/pkce/), [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/), [agent instruction injection](https://startwithidentity.com/techniques/agent-instruction-injection/), [agent identity standards map 2026](https://startwithidentity.com/reports/agent-identity-standards-map-2026/), [MCP authorization standard](https://startwithidentity.com/standards/mcp-authorization/), [agent registry](https://startwithidentity.com/glossary/agent-registry/)

## mega-seed
Source: https://startwithidentity.com/glossary/mega-seed/
Last updated: 2026-11-05

A mega-seed is a seed-stage funding round of $20 million or more. Start with Identity defined the term, and the related **mega-seed share** (the share of all priced seed capital that sits in seed rounds of $20 million or more), in the [Identity Funding Report 2026](https://startwithidentity.com/reports/identity-funding-report-2026/), which covers identity security rounds announced between 1 January 2025 and 31 October 2026.

In that dataset the mega-seed share is 55%: six of 31 priced seed rounds hold $237.0 million of $433.7 million in seed capital, against a median seed round of $9.5 million. Three of the six are pitched at AI agent identity, including the two largest (NewCore at $66 million and Oak at $60 million, both Israeli). For buyers, the report's advice is that a round label is not a maturity signal: a $60 million seed from a company that left stealth this year shows investor confidence, not years of production deployments, so ask for references at your scale and negotiate change-of-control terms, since well-funded agent startups are frequent acquisition targets. For founders, it recommends benchmarking against the stage median rather than the headlines.

See also: [agentic identity](https://startwithidentity.com/glossary/agentic-identity/), [AI identity vendors](https://startwithidentity.com/vendors/ai-identity/), [AI agent identity tools ranking](https://startwithidentity.com/rankings/best-ai-agent-identity-tools/), [identity consolidation report](https://startwithidentity.com/reports/identity-consolidation-report-2026/), [acquisitions](https://startwithidentity.com/acquisitions/)

## mfa
Source: https://startwithidentity.com/glossary/mfa/
Last updated: 2026-11-05

MFA (multi-factor authentication) is sign-in that requires two or more factors from different categories: something you know (a password or PIN), something you have (an [MFA device](https://startwithidentity.com/glossary/mfa-device/) such as a phone or security key) or something you are (a biometric). [NIST SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html) grades MFA by Authenticator Assurance Level ([AAL](https://startwithidentity.com/glossary/aal/)) and requires verifiers to offer at least one phishing-resistant option at AAL2.

| MFA method | Phishing-resistant? |
|---|---|
| SMS or voice code (a NIST "restricted" authenticator) | No |
| Authenticator app code ([TOTP](https://startwithidentity.com/glossary/totp/)) | No |
| Push approval, even with [number matching](https://startwithidentity.com/glossary/number-matching/) | No |
| [Passkey](https://startwithidentity.com/glossary/passkey/) or [FIDO2](https://startwithidentity.com/glossary/fido2/) security key | Yes |
| PIV or CAC smart card | Yes |

The word MFA now covers methods with a security gap of several orders of magnitude, which is why policies that just say "require MFA" keep failing. SMS codes, app-generated codes, and push approvals are all relayed by commodity phishing kits in real time. Origin-bound credentials are not. When you write a policy or a compliance control, name the method class, not the acronym.

See also: [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/), [passkey](https://startwithidentity.com/glossary/passkey/), [AAL](https://startwithidentity.com/glossary/aal/), [MFA vendors](https://startwithidentity.com/vendors/mfa/), [two-factor authentication (2FA)](https://startwithidentity.com/glossary/two-factor-authentication/)

## mfa-blind-zone
Source: https://startwithidentity.com/glossary/mfa-blind-zone/
Last updated: 2026-11-05

The MFA blind zone is the set of breaches in which the abused path had no interactive login where MFA could have applied: a service account, API key, token or OAuth app, or a flaw that skips the login step entirely. Start with Identity defined the term in the [Identity Breach Report 2026](https://startwithidentity.com/reports/identity-breach-report-2026/); in the underlying [Identity Breach Database](https://startwithidentity.com/breaches/incidents/) these are the incidents with MFA status "not applicable".

The blind zone grew from 7 of 33 incidents (21.2%) in 2021-2022 to 11 of 40 (27.5%) in 2023-2024 and 22 of 50 (44%) in 2025-2026, and across the whole period it holds 40 of 123 incidents (32.5%), more than either bypassed or missing MFA. The 2025-2026 growth came from machine identities (npm worms, the tj-actions GitHub Action, OAuth tokens stolen from SaaS integrations, cloud service principals) and from appliance flaws that hand out an authenticated session without a login. The point for defenders: an MFA rollout, however good, cannot reach more than four in ten of the newest breaches. Those need short-lived machine credentials, token binding such as [DPoP](https://startwithidentity.com/glossary/dpop/), fast patching of identity edge devices, and revocation signals that reach every app.

See also: [fan-out breach](https://startwithidentity.com/glossary/fan-out-breach/), [talk-past attack](https://startwithidentity.com/glossary/talk-past-attack/), [non-human identity](https://startwithidentity.com/glossary/nhi/), [token theft](https://startwithidentity.com/glossary/token-theft/), [static API key abuse](https://startwithidentity.com/techniques/static-api-key-abuse/), [token replay at unbound endpoints](https://startwithidentity.com/techniques/token-replay-unbound-endpoint/), [OAuth Transaction Tokens](https://startwithidentity.com/standards/oauth-transaction-tokens/)

## mfa-device
Source: https://startwithidentity.com/glossary/mfa-device/
Last updated: 2026-11-05

An MFA device is the physical thing a user has (a phone running an authenticator app, a hardware security key, a smart card, or an OTP token) that supplies the "something you have" factor in [multi-factor authentication](https://startwithidentity.com/glossary/mfa/). [NIST SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html) calls these authenticators and classifies them by how they prove possession, not by brand.

| MFA device | NIST 800-63B-4 type | Phishing-resistant? |
|---|---|---|
| Phone receiving an SMS or voice code | Out-of-band device over the PSTN, a "restricted" authenticator | No |
| Phone with a push app, such as [Microsoft Authenticator](https://startwithidentity.com/vendors/mfa/microsoft-authenticator/) or [Duo](https://startwithidentity.com/vendors/mfa/duo/) | Out-of-band device | No, even with [number matching](https://startwithidentity.com/glossary/number-matching/) |
| Phone or token showing a 6-digit [TOTP](https://startwithidentity.com/glossary/totp/) code | Single-factor OTP | No |
| Hardware security key, such as a [YubiKey](https://startwithidentity.com/vendors/mfa/yubico/) | Single- or multi-factor cryptographic authenticator ([FIDO2](https://startwithidentity.com/glossary/fido2/)) | Yes |
| Phone or laptop holding a [passkey](https://startwithidentity.com/glossary/passkey/) | Multi-factor cryptographic authenticator | Yes |
| PIV or CAC smart card | Multi-factor cryptographic authenticator | Yes |

The distinction that matters is the last column. A device that displays or receives a code the user types can be relayed by a phishing proxy; a device that signs a challenge bound to the website's origin cannot. NIST SP 800-63B-4 requires that verifiers "SHALL offer at least one phishing-resistant authentication option at AAL2", and it bars syncable authenticators, such as synced passkeys, at AAL3 because their keys can be exported.

When choosing MFA devices, plan for loss as carefully as for issuance: register at least two devices per user, decide how a lost device is replaced (a [Temporary Access Pass](https://startwithidentity.com/glossary/temporary-access-pass/) after re-verification, not an SMS code), and remove the old device from the account.

See also: [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/), [phishable MFA](https://startwithidentity.com/glossary/phishable-mfa/), [AAL](https://startwithidentity.com/glossary/aal/), [MFA matrix](https://startwithidentity.com/tools/mfa-matrix/), [best MFA solutions](https://startwithidentity.com/rankings/best-mfa-solutions/), [MFA implementation best practices](https://startwithidentity.com/guides/authentication/mfa-implementation-best-practices/)

## mfa-fatigue
Source: https://startwithidentity.com/glossary/mfa-fatigue/
Last updated: 2026-11-05

MFA fatigue, also called push bombing, is an attack in which someone who already has a user's password triggers push approval prompts over and over until the user accepts one, by accident or to make them stop. MITRE ATT&CK tracks it as [T1621, Multi-Factor Authentication Request Generation](https://attack.mitre.org/techniques/T1621/).

CISA's [October 2022 fact sheet](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implement-number-matching-in-mfa-applications-508c.pdf) recommends phishing-resistant MFA first and, where push has to stay, number matching as "one of the best interim" mitigations: the user must type a number shown on the sign-in screen into the app, so a prompt cannot be approved by someone who is not looking at that screen. Microsoft now [applies number matching to all Authenticator push notifications](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-mfa-number-match) with no user opt-out, and [NIST SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html) no longer accepts out-of-band methods where the user compares two codes and taps approve, citing "authentication fatigue" attacks, and tells verifiers to limit the rate or number of push notifications. Number matching stops blind approval, not a phishing proxy that shows the victim the real number, which is why the end state is a [passkey](https://startwithidentity.com/glossary/passkey/) or security key with no prompt to approve. The 2022 Uber breach is the [best-known case](https://startwithidentity.com/breaches/mfa-fatigue-push-bombing/).

See also: [MFA fatigue and push bombing technique](https://startwithidentity.com/techniques/mfa-fatigue-push-bombing/), [MFA fatigue breaches](https://startwithidentity.com/breaches/mfa-fatigue-push-bombing/), [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/), [MFA](https://startwithidentity.com/glossary/mfa/), [vishing](https://startwithidentity.com/glossary/vishing/), [number matching](https://startwithidentity.com/glossary/number-matching/), [phishable MFA](https://startwithidentity.com/glossary/phishable-mfa/), [talk-past attack](https://startwithidentity.com/glossary/talk-past-attack/)

## microsegmentation
Source: https://startwithidentity.com/glossary/microsegmentation/
Last updated: 2026-10-16

Microsegmentation is a network control that divides an environment into small zones and allows only the connections policy explicitly permits between them, so a compromised host can reach little beyond its own segment. Identity-based microsegmentation writes those rules against who or what is connecting (a user, device, workload or AI agent) instead of IP ranges and VLANs. CISA's [Microsegmentation in Zero Trust, Part One](https://www.cisa.gov/resources-tools/resources/microsegmentation-zero-trust-part-one-introduction-and-planning) (July 2025) describes the shift: under zero trust, access rules move beyond IP addresses to contextual attributes, with a policy decision point drawing on identity, device and connection data.

The identity version exists because address-based rules break as soon as workloads move, scale or share addresses, and because the question an attacker exploits is "what can this identity reach", not "what can this subnet reach". It is the network-layer form of [least privilege](https://startwithidentity.com/glossary/least-privilege/) and the main control against [lateral movement](https://startwithidentity.com/glossary/lateral-movement/), especially for OT and unmanaged devices that cannot run an agent. The hard part is the same as in [zero trust](https://startwithidentity.com/glossary/zero-trust/) generally: an accurate inventory of identities and the flows they actually need. In October 2026 IonQ agreed to [acquire Elisity, an identity-based microsegmentation vendor, for up to $1.3 billion](https://startwithidentity.com/blog/2026-10-12-ionq-to-acquire-elisity-for-up-to-1-3-billion/); [Illumio](https://startwithidentity.com/vendors/zero-trust/illumio/) and [Zero Networks](https://startwithidentity.com/vendors/zero-trust/zero-networks/) compete in the same space.

See also: [zero trust](https://startwithidentity.com/glossary/zero-trust/), [ZTNA](https://startwithidentity.com/glossary/ztna/), [zero trust architecture implementation guide](https://startwithidentity.com/guides/architecture/zero-trust-architecture-implementation-guide/), [zero trust vendors](https://startwithidentity.com/vendors/zero-trust/)

## mobile-drivers-license
Source: https://startwithidentity.com/glossary/mobile-drivers-license/
Last updated: 2026-08-29

A driver's license issued to a phone wallet under the ISO/IEC 18013-5 standard, presentable in person and increasingly online. It supports selective disclosure, letting a holder share only age or a photo rather than the full document. Rolling out across US states and other jurisdictions.

mDL is the first widely deployed verifiable credential most people will actually hold, and its in-person mode is what makes it different: the verifier reads it over NFC or QR without network access, so a bar can check age offline. The online presentation path is newer and converging with the OpenID4VP stack the EU wallet uses, which is why mDL and EUDI are increasingly the same technical conversation.

See also: [digital wallet](https://startwithidentity.com/glossary/digital-wallet/), [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/), [verifiable credentials](https://startwithidentity.com/standards/verifiable-credentials/), [national digital ID schemes](https://startwithidentity.com/digital-ids/)

## mtls
Source: https://startwithidentity.com/glossary/mtls/
Last updated: 2026-08-29

Mutual TLS. Both the client and server present and validate X.509 certificates during the TLS handshake. The cryptographic identity binding makes mTLS a strong fit for service-to-service authentication and high-assurance API access.

mTLS gives the strongest identity binding available for service-to-service traffic because the credential is proven during the handshake and cannot be replayed elsewhere. The reason it is not universal is operational: every workload needs a certificate, and certificates expire. Service meshes and SPIFFE exist largely to make that lifecycle automatic, which is what turns mTLS from a good idea into something a platform team can actually run.

See also: [X.509](https://startwithidentity.com/glossary/x509/), [certificate lifecycle](https://startwithidentity.com/glossary/certificate-lifecycle/), [workload identity](https://startwithidentity.com/glossary/workload-identity/), [SPIFFE](https://startwithidentity.com/glossary/spiffe/)

## nhi
Source: https://startwithidentity.com/glossary/nhi/
Last updated: 2026-11-05

Any identity that is not a person: service accounts, API keys, OAuth tokens, certificates, workloads, and AI agents. NHIs now outnumber human identities in most organizations and are frequently over-permissioned and under-governed.

The count is the headline (NHIs outnumber humans by a large multiple almost everywhere) but the governance gap is the actual problem: these identities are created by engineers during delivery, inherit whatever credential was nearest, have no owner, and appear in no access review. AI agents are making them faster. Start with ownership and expiry, not with a discovery tool that produces an unactionable inventory.

See also: [what is non-human identity](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/), [service account](https://startwithidentity.com/glossary/service-account/), [workload identity](https://startwithidentity.com/glossary/workload-identity/), [machine identity vendors](https://startwithidentity.com/vendors/machine-identity/), [MFA blind zone](https://startwithidentity.com/glossary/mfa-blind-zone/), [fan-out breach](https://startwithidentity.com/glossary/fan-out-breach/), [agent registry](https://startwithidentity.com/glossary/agent-registry/), [machine identity](https://startwithidentity.com/glossary/machine-identity/)

## nist-800-63
Source: https://startwithidentity.com/glossary/nist-800-63/
Last updated: 2026-10-16

The US National Institute of Standards and Technology Digital Identity Guidelines. Defines Identity Assurance Levels (IAL), Authenticator Assurance Levels (AAL), and Federation Assurance Levels (FAL). The reference framework for federal and many enterprise identity programs.

The value of SP 800-63 is that it separates three questions people constantly conflate: how well we proved who you are (IAL), how strongly you authenticated (AAL), and how much we trust an assertion from another party (FAL). Writing requirements against those levels rather than against products is what makes a control survive a vendor migration, and it is why US federal and many regulated programs reference it directly.

See also: [IAL](https://startwithidentity.com/glossary/ial/), [AAL](https://startwithidentity.com/glossary/aal/), [FAL](https://startwithidentity.com/glossary/fal/), [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/), [identity verification](https://startwithidentity.com/glossary/idv/)

## ntlm
Source: https://startwithidentity.com/glossary/ntlm/
Last updated: 2026-09-21

A challenge-response authentication protocol used by Windows before Kerberos and still present as a fallback. The client proves knowledge of a password hash without sending the password, but the hash itself is sufficient to authenticate, which is the root of pass-the-hash and relay attacks.

NTLM has no mutual authentication in its common configurations and no binding between the authentication and the channel it travels over, so an attacker who can coerce a machine to authenticate to them can often relay that authentication elsewhere. Microsoft has been working to remove it from Windows for years. Most environments still cannot disable it, because some application, appliance, or hard-coded script depends on it, and finding those dependencies is the actual project.

See also: [Kerberos](https://startwithidentity.com/glossary/kerberos/), [Active Directory](https://startwithidentity.com/glossary/active-directory/), [lateral movement](https://startwithidentity.com/glossary/lateral-movement/), [credential manager key extraction](https://startwithidentity.com/techniques/credential-manager-key-extraction/)

## number-matching
Source: https://startwithidentity.com/glossary/number-matching/
Last updated: 2026-11-05

Number matching is a push MFA design in which the sign-in screen shows a short number and the user must type that number into the authenticator app to approve, instead of tapping a plain Approve button. It stops blind approval of prompts the user did not start, which is the mechanism behind [MFA fatigue](https://startwithidentity.com/glossary/mfa-fatigue/) and push bombing ([MITRE ATT&CK T1621](https://attack.mitre.org/techniques/T1621/)).

Microsoft documents that number matching is now [enabled for all Microsoft Authenticator push notifications](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-mfa-number-match), including MFA, self-service password reset and the AD FS and NPS integrations, and it is not supported on wearable devices. The limit is important: number matching is still phishable. A real-time phishing proxy shows the victim the genuine number from the real sign-in page, and the victim types it in. [NIST SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html) says authenticators that involve manual entry of an output "SHALL NOT be considered phishing-resistant", so number matching is an interim control on the way to [passkeys](https://startwithidentity.com/glossary/passkey/) or security keys. The 2022 Uber incident in the [Identity Breach Database](https://startwithidentity.com/breaches/incidents/2022-uber-mfa-fatigue/) is the case usually cited for why plain push approval was not enough.

See also: [MFA fatigue and push bombing](https://startwithidentity.com/techniques/mfa-fatigue-push-bombing/), [phishable MFA](https://startwithidentity.com/glossary/phishable-mfa/), [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/), [Microsoft Authenticator](https://startwithidentity.com/vendors/mfa/microsoft-authenticator/), [MFA matrix](https://startwithidentity.com/tools/mfa-matrix/)

## oauth
Source: https://startwithidentity.com/glossary/oauth/
Last updated: 2026-08-29

OAuth 2.0 is the standard authorization framework for delegated access. It lets a client obtain limited access to a resource owner's data without handling their credentials. OAuth 2.0 is defined by RFC 6749; modern usage should follow OAuth 2.1 guidance, which removes deprecated flows and bakes in PKCE.

The most common OAuth mistake is using it for authentication. OAuth answers "may this client access that resource", not "who is this person", and building a login on the presence of an access token produces well-known impersonation bugs. Use OIDC when you need identity. OAuth 2.1 consolidates the current best practice: authorization code with PKCE everywhere, no implicit flow, no password grant.

See also: [OAuth 2.0](https://startwithidentity.com/standards/oauth-2-0/), [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/), [OAuth vs OIDC](https://startwithidentity.com/guides/fundamentals/oauth-vs-oidc/), [protect an API with OAuth scopes recipe](https://startwithidentity.com/recipes/protect-an-api-with-oauth-scopes/), [GNAP](https://startwithidentity.com/glossary/gnap/)

## oidc
Source: https://startwithidentity.com/glossary/oidc/
Last updated: 2026-08-29

OpenID Connect is an authentication layer built on top of OAuth 2.0. Where OAuth tells you what a token is authorized for, OIDC tells you who the user is via a signed ID token. OIDC is the modern default for federated sign-in.

OIDC is the default for new applications because it fits how software is actually built now: JSON, JWTs, mobile apps, and APIs, rather than XML posted through a browser form. SAML persists where the enterprise on the other side requires it, which is most large B2B deals, so real-world stacks support both. The discovery document is the practical superpower, letting a client self-configure from one URL.

See also: [OpenID Connect](https://startwithidentity.com/standards/openid-connect/), [ID token](https://startwithidentity.com/glossary/id-token/), [SAML vs OIDC](https://startwithidentity.com/guides/fundamentals/saml-vs-oidc/), [add login to Next.js recipe](https://startwithidentity.com/recipes/add-login-to-nextjs/)

## one-time-password
Source: https://startwithidentity.com/glossary/one-time-password/
Last updated: 2026-10-17

A one-time password (OTP) is a code that is valid for a single sign-in or transaction, either generated by an authenticator from a shared secret, as in HOTP ([RFC 4226](https://www.rfc-editor.org/info/rfc4226/), counter-based) and TOTP ([RFC 6238](https://www.rfc-editor.org/info/rfc6238/), time-based with a 30-second default step), or sent by the service over SMS, voice or email.

[NIST SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html) states plainly that "OTP authentication is not phishing-resistant", because a code a person reads can be typed into a fake page and relayed before it expires. SMS and voice delivery add their own weaknesses, [SIM swap](https://startwithidentity.com/glossary/sim-swap/) and number porting among them, and NIST treats the phone network as a "restricted" authenticator that verifiers should only use after checking signals such as a recent SIM change. Both problems are live: the InsureOTP kit in July 2026 [asked insurance customers for their OTP "as routine identity verification" and relayed it to the real portal](https://startwithidentity.com/blog/2026-07-25-insurance-phishing-evolves-into-real-time-otp-relay-account-hijacking/), and Microsoft Entra ID [stops delivering its own SMS and voice codes on February 1, 2027](https://startwithidentity.com/blog/2026-09-21-entra-id-stops-delivering-sms-and-voice-codes-february-1-and-global-admins-go-last/).

See also: [HOTP](https://startwithidentity.com/glossary/hotp/), [TOTP](https://startwithidentity.com/glossary/totp/), [OTP relay social engineering](https://startwithidentity.com/techniques/otp-relay-social-engineering/), [two-factor authentication](https://startwithidentity.com/glossary/two-factor-authentication/), [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/)

## openid4vci
Source: https://startwithidentity.com/glossary/openid4vci/
Last updated: 2026-08-29

An OpenID Foundation protocol that defines how an issuer delivers verifiable credentials to a holder's wallet, building on OAuth 2.0. Together with OpenID4VP it is emerging as the dominant transport for decentralized credentials, and underpins the EU's EUDI Wallet.

OpenID4VCI matters because it lets wallets and issuers interoperate without bilateral integration: the wallet discovers what a credential offer contains and how to obtain it using OAuth machinery developers already have. It is the issuance half of the stack the EU wallet standardized on, which effectively settled a decade-long argument about credential transport in favor of OAuth-based flows over bespoke DIDComm messaging.

See also: [OpenID4VC](https://startwithidentity.com/standards/openid4vc/), [OpenID4VP](https://startwithidentity.com/glossary/openid4vp/), [verifiable credential](https://startwithidentity.com/glossary/verifiable-credential/), [digital wallet](https://startwithidentity.com/glossary/digital-wallet/)

## openid4vp
Source: https://startwithidentity.com/glossary/openid4vp/
Last updated: 2026-08-29

An OpenID Foundation protocol defining how a verifier requests, and a wallet presents, verifiable credentials, built on OAuth 2.0. It is the presentation counterpart to OpenID4VCI and supports selective disclosure formats such as SD-JWT and mDL.

For anyone building a verifier, OpenID4VP is the integration surface: you describe the claims you need, the wallet returns a presentation containing only those, and you validate the proof. That is a smaller job than a federation integration, since there is no relationship to negotiate with the issuer. The work moves to trust decisions, which issuers you accept and how you check revocation.

See also: [OpenID4VC](https://startwithidentity.com/standards/openid4vc/), [verifiable presentation](https://startwithidentity.com/glossary/verifiable-presentation/), [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/), [issuer, holder, verifier](https://startwithidentity.com/glossary/issuer-holder-verifier/)

## orphaned-account
Source: https://startwithidentity.com/glossary/orphaned-account/
Last updated: 2026-08-29

An active account with no valid owner, typically left behind after someone leaves or changes roles. A common audit finding and a soft target for attackers.

Orphaned accounts are dangerous precisely because they are boring: no owner means no one notices the login, no password change, and no MFA enrollment. They cluster in the systems outside SSO, in local admin accounts on appliances, and in service accounts created for a project that ended. Reconciling every account against an authoritative owner is the only reliable way to find them.

See also: [deprovisioning](https://startwithidentity.com/glossary/deprovisioning/), [what is IGA](https://startwithidentity.com/guides/fundamentals/what-is-iga/), [joiner-mover-leaver](https://startwithidentity.com/glossary/joiner-mover-leaver/), [access certification](https://startwithidentity.com/glossary/access-certification/)

## oscal
Source: https://startwithidentity.com/glossary/oscal/
Last updated: 2026-10-16

OSCAL (Open Security Controls Assessment Language) is a NIST-led set of machine-readable formats, in XML, JSON and YAML, for writing down security controls and the evidence that a system meets them. Its models cover control catalogs, profiles (baselines selected from a catalog), component definitions, system security plans, assessment plans, assessment results, and plans of action and milestones. The specification and NIST's own SP 800-53 Rev. 5 catalog are published on [GitHub](https://github.com/usnistgov/OSCAL) and documented at [pages.nist.gov/OSCAL](https://pages.nist.gov/OSCAL/).

OSCAL matters to identity teams because compliance mapping is still mostly done by hand from prose standards into spreadsheets. When a control set exists as structured data, a GRC tool can import it, track each requirement against the systems that implement it, and diff the result when the standard changes. In October 2026 NIST [published version 0.1 conformance criteria for SP 800-63-4 in OSCAL](https://startwithidentity.com/blog/2026-10-06-nist-opens-implementation-hub-for-sp-800-63-4/), which turns IAL, AAL and FAL requirements into controls you can assess rather than paragraphs you interpret. OSCAL is a format, not a certification: a clean OSCAL package says the evidence is well organized, not that it is true.

See also: [NIST 800-63](https://startwithidentity.com/glossary/nist-800-63/), [FedRAMP](https://startwithidentity.com/glossary/fedramp/), [compliance guides](https://startwithidentity.com/guides/compliance/), [SOC 2](https://startwithidentity.com/glossary/soc2/)

## pam
Source: https://startwithidentity.com/glossary/pam/
Last updated: 2026-11-05

PAM (privileged access management) is the set of controls that secure accounts and credentials with elevated rights, such as domain admins, root, cloud owners and database administrators, by vaulting their credentials, brokering and [recording their sessions](https://startwithidentity.com/glossary/session-recording/), and granting elevation [just in time](https://startwithidentity.com/glossary/jit-access/) instead of permanently. A PAM solution is the product that does this.

| A PAM solution typically includes | It is not |
|---|---|
| Credential vault with automatic rotation | A general [password manager](https://startwithidentity.com/glossary/password-manager/) for every employee |
| Session brokering and [session recording](https://startwithidentity.com/glossary/session-recording/) | [IGA](https://startwithidentity.com/glossary/iga/), which decides who should be entitled to access |
| Just-in-time elevation that removes [standing privilege](https://startwithidentity.com/glossary/standing-privilege/) | [Secrets management](https://startwithidentity.com/glossary/secrets-management/) for application credentials, though suites now bundle both |
| [Privileged remote access](https://startwithidentity.com/glossary/privileged-remote-access/) for vendors and remote admins | A VPN |

PAM programs succeed or fail on adoption rather than features. Vaulting and session brokering work only if the privileged path through the tool is faster than the path around it, and engineers will route around a slow one. The modern direction is to reduce what needs vaulting at all by moving to just-in-time elevation and short-lived credentials, so there is less standing privilege to protect.

See also: [what is PAM](https://startwithidentity.com/guides/fundamentals/what-is-pam/), [best PAM tools](https://startwithidentity.com/rankings/best-pam-tools/), [top 10 PAM solutions in 2026](https://startwithidentity.com/articles/top-10-pam-solutions-2026/), [how to choose a PAM solution](https://startwithidentity.com/guides/buyer-guides/how-to-choose-a-pam-solution/), [just-in-time access](https://startwithidentity.com/glossary/jit-access/), [zero standing privileges](https://startwithidentity.com/glossary/zero-standing-privileges/), [PAM vendors](https://startwithidentity.com/vendors/pam/), [Cyber Resilience Act](https://startwithidentity.com/glossary/cyber-resilience-act/)

## par
Source: https://startwithidentity.com/glossary/par/
Last updated: 2026-08-29

Pushed Authorization Requests (RFC 9126). The client sends authorization parameters directly to the server over a back channel first, hardening the flow against tampering. Required by stricter profiles like FAPI.

PAR removes the front channel as a tampering surface: instead of packing scope, redirect URI, and request parameters into a browser URL where they can be modified or logged, the client registers them server to server and passes an opaque reference. It also gets around URL length limits for rich authorization requests. Mandatory in FAPI, and a sensible default for anything high value.

See also: [OAuth 2.0](https://startwithidentity.com/standards/oauth-2-0/), [FAPI](https://startwithidentity.com/standards/fapi/), [authorization code flow](https://startwithidentity.com/glossary/authorization-code-flow/), [PKCE](https://startwithidentity.com/glossary/pkce/)

## pass-the-cookie
Source: https://startwithidentity.com/glossary/pass-the-cookie/
Last updated: 2026-10-30

Pass-the-cookie is an attack in which a stolen, already-authenticated web session cookie is imported into the attacker's browser to take over the session, bypassing the password and MFA entirely; MITRE ATT&CK tracks the replay as [T1550.004, Web Session Cookie](https://attack.mitre.org/techniques/T1550/004/) and the theft as [T1539, Steal Web Session Cookie](https://attack.mitre.org/techniques/T1539/).

Cookies are bearer credentials: whoever presents one is the user, for as long as the session lives. Infostealer malware harvests them in bulk from browser profiles, and adversary-in-the-middle phishing kits capture them in real time during a genuine MFA login, which is why phishing-resistant MFA alone does not stop the infostealer path. Defenses work on the session rather than the login: shorter sessions for sensitive apps, re-evaluation through signals such as CAEP, binding the session to a device key so a copied cookie fails elsewhere, which is what Chrome's [Device Bound Session Credentials](https://developer.chrome.com/docs/web-platform/device-bound-session-credentials) does, and revoking sessions, not just resetting passwords, after an infection.

See also: [session cookie theft](https://startwithidentity.com/techniques/session-cookie-theft/), [session hijacking](https://startwithidentity.com/glossary/session-hijacking/), [Device Bound Session Credentials](https://startwithidentity.com/glossary/device-bound-session-credentials/), [infostealer](https://startwithidentity.com/glossary/infostealer/), [token theft](https://startwithidentity.com/glossary/token-theft/), [AiTM phishing proxy](https://startwithidentity.com/techniques/aitm-phishing-proxy/), [CAEP](https://startwithidentity.com/glossary/caep/)

## passkey
Source: https://startwithidentity.com/glossary/passkey/
Last updated: 2026-11-05

A passkey is a WebAuthn public-key credential that replaces a password. Possession of the authenticator plus a user verification step proves identity, with no shared secret transmitted to the server.

Passkeys removed remote phishing as an attack path, which is a genuine change in the threat model, and the 2026 research wave clarified what they did not remove. Every published break started with malware already on the endpoint and attacked the plumbing (event logs, sync key custody, in-session key reuse) rather than the cryptography. The practical rule: [synced passkeys](https://startwithidentity.com/glossary/synced-passkey/) for consumers, device-bound hardware authenticators for administrators.

See also: [WebAuthn and FIDO2](https://startwithidentity.com/standards/webauthn-fido2/), [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/), [passkey rollout checklist](https://startwithidentity.com/templates/passkey-rollout-checklist/), [passkeys had a hard month](https://startwithidentity.com/blog/passkeys-first-hard-month/), [biometric authentication](https://startwithidentity.com/glossary/biometric-authentication/), [Temporary Access Pass](https://startwithidentity.com/glossary/temporary-access-pass/)

## password-manager
Source: https://startwithidentity.com/glossary/password-manager/
Last updated: 2026-10-17

A password manager is software that generates, stores and fills in a distinct, strong password for every account, keeping them in an encrypted vault opened with one primary secret or a device authenticator. [NIST SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html) (section 3.1.1.2) says verifiers "SHALL allow the use of password managers and autofill functionality" and should permit pasting into password fields.

NIST's reason is that password managers make users more likely to choose stronger passwords, and a unique password per site is what breaks [credential stuffing](https://startwithidentity.com/glossary/credential-stuffing/), which depends on reuse. The trade-off is concentration: one vault now holds every credential, and many managers now also store [passkeys](https://startwithidentity.com/glossary/passkey/) and TOTP seeds, so the vault's primary secret and the endpoint it runs on become the real security boundary. In August 2026 Unit 42 showed malware on a Windows machine could [pull synced passkey keys out of Google Password Manager in Chrome's memory](https://startwithidentity.com/blog/2026-08-03-unit-42-pass-ta-key-attacks-extract-google-synced-passkey-keys/), and the EU [Cyber Resilience Act](https://startwithidentity.com/glossary/cyber-resilience-act/) lists password managers among its "important products", which face stricter conformity assessment. NIST's [SP 800-63-4 implementation hub](https://startwithidentity.com/blog/2026-10-06-nist-opens-implementation-hub-for-sp-800-63-4/) includes an FAQ on password managers for agencies deciding what to recommend.

See also: [top open-source password managers](https://startwithidentity.com/articles/top-7-open-source-password-managers/), [best password managers for business](https://startwithidentity.com/rankings/best-password-managers-for-business/), [best password managers for personal use](https://startwithidentity.com/rankings/best-password-managers-for-personal/), [password management vendors](https://startwithidentity.com/vendors/password-management/), [credential stuffing](https://startwithidentity.com/glossary/credential-stuffing/)

## password-spraying
Source: https://startwithidentity.com/glossary/password-spraying/
Last updated: 2026-08-29

Trying a few common passwords across many accounts to avoid lockouts. Effective against weak password policies and accounts without MFA.

Spraying is designed to stay under lockout thresholds, so per-account controls do not see it and only population-level detection does: a small number of failures across a large number of accounts from a narrow set of sources. It remains effective because a predictable seasonal password still works somewhere in any organization above a few thousand people. Banning common and breached passwords does more than complexity rules.

See also: [credential stuffing](https://startwithidentity.com/glossary/credential-stuffing/), [account takeover](https://startwithidentity.com/glossary/account-takeover/), [MFA](https://startwithidentity.com/glossary/mfa/), [what is ITDR](https://startwithidentity.com/guides/fundamentals/what-is-itdr/)

## passwordless
Source: https://startwithidentity.com/glossary/passwordless/
Last updated: 2026-08-29

Authentication without a password as a primary factor. Implementations include magic links, OTP codes, and passkeys. Passkeys are the only passwordless method that is also phishing-resistant.

Passwordless is a user-experience claim, not a security claim, and the two get conflated constantly. Emailed links and one-time codes remove the password and keep the phishability; passkeys remove both. The other half of any passwordless project is recovery, because deleting the password also deletes the fallback everyone quietly relied on, and an insecure recovery path becomes the new weakest link.

See also: [what is passwordless](https://startwithidentity.com/guides/fundamentals/what-is-passwordless/), [passkey](https://startwithidentity.com/glossary/passkey/), [magic link](https://startwithidentity.com/glossary/magic-link/), [CIAM vendors](https://startwithidentity.com/vendors/ciam/)

## pci-dss
Source: https://startwithidentity.com/glossary/pci-dss/
Last updated: 2026-08-29

Payment Card Industry Data Security Standard. Required of any organization that stores, processes, or transmits cardholder data. The current major version (4.0) tightens authentication requirements and adds MFA for non-console administrative access.

[PCI DSS 4.0](https://startwithidentity.com/regulations/united-states/pci-dss/) pushed authentication requirements up sharply: MFA for all access into the cardholder data environment rather than just remote administrative access, and stronger password rules where passwords remain. For identity teams the practical impact is scoping, since every account that can reach the environment is in scope, including service accounts and vendor support access.

See also: [compliance guides](https://startwithidentity.com/guides/compliance/), [MFA](https://startwithidentity.com/glossary/mfa/), [what is PAM](https://startwithidentity.com/guides/fundamentals/what-is-pam/), [retail and e-commerce identity](https://startwithidentity.com/verticals/retail-ecommerce/)

## phishable-mfa
Source: https://startwithidentity.com/glossary/phishable-mfa/
Last updated: 2026-11-05

Phishable MFA is any multi-factor method whose output a user can be tricked into handing to an attacker's site, which then replays it to the real one: SMS and voice codes, authenticator app codes (TOTP), email codes and push approvals, with or without number matching. NIST [SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html) draws the line precisely: authenticators "that involve the manual entry of an authenticator output (e.g., out-of-band and OTP authenticators) SHALL NOT be considered phishing-resistant because the manual entry does not bind the authenticator output to the specific session being authenticated".

The distinction matters because phishable MFA still stops password-only attacks but not [adversary-in-the-middle](https://startwithidentity.com/glossary/adversary-in-the-middle/) proxies or a convincing phone call. SWI's [Identity Breach Report 2026](https://startwithidentity.com/reports/identity-breach-report-2026/) found MFA bypassed in 25 of the 41 breaches where MFA status was known, and the [Phishing-Resistant MFA Support Matrix 2026](https://startwithidentity.com/reports/phishing-resistant-mfa-matrix-2026/) found that 21 of 95 business SaaS apps (22.1%) document only phishable local MFA. US federal policy ([OMB M-22-09](https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf)) requires phishing-resistant methods for agency staff. The way out is [passkeys](https://startwithidentity.com/glossary/passkey/) or FIDO2 security keys enforced at the identity provider, plus [SSO enforcement](https://startwithidentity.com/glossary/sso-enforcement/) so the phishable fallback cannot be chosen.

See also: [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/), [number matching](https://startwithidentity.com/glossary/number-matching/), [AitM phishing proxy](https://startwithidentity.com/techniques/aitm-phishing-proxy/), [OTP relay social engineering](https://startwithidentity.com/techniques/otp-relay-social-engineering/), [MFA matrix](https://startwithidentity.com/tools/mfa-matrix/), [WebAuthn / FIDO2](https://startwithidentity.com/standards/webauthn-fido2/)

## phishing-resistant-mfa
Source: https://startwithidentity.com/glossary/phishing-resistant-mfa/
Last updated: 2026-11-05

Multi-factor methods that cannot be relayed or replayed by a phishing site, principally FIDO2 security keys and passkeys. Recommended by NIST and CISA over OTP and push.

The property that makes a method phishing-resistant is origin binding: the authenticator refuses to produce a signature for a domain other than the one that registered the credential, so an [adversary-in-the-middle](https://startwithidentity.com/glossary/adversary-in-the-middle/) proxy gets nothing usable. Everything a human can read, type, or approve can be relayed, which is why one-time codes and push approvals are not in this category regardless of how they are marketed.

See also: [WebAuthn and FIDO2](https://startwithidentity.com/standards/webauthn-fido2/), [passkey](https://startwithidentity.com/glossary/passkey/), [AAL](https://startwithidentity.com/glossary/aal/), [MFA vendors](https://startwithidentity.com/vendors/mfa/), [browser-in-the-browser](https://startwithidentity.com/glossary/browser-in-the-browser/), [MFA fatigue](https://startwithidentity.com/glossary/mfa-fatigue/), [phishable MFA](https://startwithidentity.com/glossary/phishable-mfa/), [authentication policy](https://startwithidentity.com/glossary/authentication-policy/), [SSO enforcement](https://startwithidentity.com/glossary/sso-enforcement/), [MFA device](https://startwithidentity.com/glossary/mfa-device/)

## pkce
Source: https://startwithidentity.com/glossary/pkce/
Last updated: 2026-08-29

Proof Key for Code Exchange (RFC 7636). A binding between an authorization request and the code exchange that prevents intercepted authorization codes from being redeemed. Originally for mobile and SPA clients; OAuth 2.1 requires PKCE for all clients.

PKCE started as a mobile fix for codes intercepted through custom URL schemes and is now recommended for every client including confidential ones, which is why OAuth 2.1 makes it mandatory. The mechanism is simple: the client commits to a secret verifier at request time and must produce it at exchange time, so a stolen code alone is worthless. There is no reason to omit it in new code.

See also: [authorization code flow](https://startwithidentity.com/glossary/authorization-code-flow/), [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/), [OIDC authorization code with PKCE recipe](https://startwithidentity.com/recipes/oidc-authorization-code-pkce/), [OAuth 2.0](https://startwithidentity.com/standards/oauth-2-0/)

## pki
Source: https://startwithidentity.com/glossary/pki/
Last updated: 2026-11-05

PKI (public key infrastructure) is the system of [certificate authorities](https://startwithidentity.com/glossary/certificate-authority/), [X.509](https://startwithidentity.com/glossary/x509/) certificates, keys and revocation services that binds public keys to named identities, so that a server, device, person or workload can prove who it is with a private key. The certificate and revocation list profile used on the internet is [RFC 5280](https://www.rfc-editor.org/rfc/rfc5280). PKI underpins TLS, [mTLS](https://startwithidentity.com/glossary/mtls/), code signing, smart cards and most [machine identity](https://startwithidentity.com/glossary/machine-identity/).

| PKI component | Role |
|---|---|
| Root CA | Trust anchor, normally kept offline |
| Issuing (intermediate) CA | Signs end-entity certificates |
| Registration and issuance, often via [ACME](https://startwithidentity.com/glossary/acme/) | Checks the request and automates issuance and renewal |
| Revocation (CRL, OCSP) | Tells relying parties a certificate is no longer valid |
| [Certificate lifecycle management](https://startwithidentity.com/glossary/certificate-lifecycle/) | Inventory, ownership and renewal across all of the above |

Enterprise PKI is where machine identity actually lives, and it is usually the least inventoried part of the estate: certificates issued by a forgotten internal CA, private keys copied between hosts, and no owner for the one that expires on a Sunday. Shrinking certificate lifetimes turn that from an annual annoyance into a continuous automation requirement.

See also: [X.509](https://startwithidentity.com/glossary/x509/), [certificate lifecycle](https://startwithidentity.com/glossary/certificate-lifecycle/), [what is machine identity](https://startwithidentity.com/guides/fundamentals/what-is-machine-identity/), [PKI vendors](https://startwithidentity.com/vendors/pki/)

## privilege-escalation
Source: https://startwithidentity.com/glossary/privilege-escalation/
Last updated: 2026-08-29

Gaining higher access than originally granted, by exploiting misconfigurations, vulnerabilities, or over-permissioned identities. Tightly linked to privileged access risk.

Most real escalations are not exploits, they are configuration: a group that grants more than anyone realized, a role that can modify its own policy, a certificate template with dangerous permissions, or a service account with domain rights. That is why attack-path analysis across the identity graph finds more than vulnerability scanning does, and why the fix is usually a permission change rather than a patch.

See also: [lateral movement](https://startwithidentity.com/glossary/lateral-movement/), [least privilege](https://startwithidentity.com/glossary/least-privilege/), [what is PAM](https://startwithidentity.com/guides/fundamentals/what-is-pam/), [identity CVE catalog](https://startwithidentity.com/cves/)

## privileged-access-workstation
Source: https://startwithidentity.com/glossary/privileged-access-workstation/
Last updated: 2026-11-05

A privileged access workstation (PAW) is a dedicated, hardened computer used only for administrative work, with no email, no general web browsing and only approved applications, so that a phishing email or malicious website cannot reach the device that holds admin credentials. [Microsoft's privileged access guidance](https://learn.microsoft.com/en-us/security/privileged-access-workstations/privileged-access-devices) calls it "the highest security configuration designed for extremely sensitive roles."

Microsoft defines three device levels, and the PAW is the top one:

| Control | Enterprise | Specialized | Privileged (PAW) |
|---|---|---|---|
| Web browsing | Allow most | Allow most | Deny by default, admin portals only |
| Email and productivity apps | Yes | Yes | No, on a separate device |
| User is local admin | Allowed | No | No |
| Application control (AppLocker) | None | Audit, then enforced | Enforced |
| BYOD enrollment | Allowed | Denied | Denied |

A PAW also relies on a hardware root of trust (TPM 2.0, Secure Boot, BitLocker) and Windows protections such as Credential Guard. The reason is the clean source principle: an admin session is only as trustworthy as the device it starts from, because an attacker who controls that device can steal the admin's tokens or act as them.

A PAW is not a jump server or bastion. A jump server is an intermediary that admins connect through; a PAW is the device they connect from, and a compromised laptop connecting to a perfect bastion still hands the attacker the session. The cost is real: admins need two devices or a separate hardened virtual environment, which is why many organizations limit PAWs to tier-zero roles (domain, identity provider and cloud tenant admins) and pair them with [device posture](https://startwithidentity.com/glossary/device-posture/) checks in [conditional access](https://startwithidentity.com/glossary/conditional-access/) so admin portals refuse sign-ins from anything else.

See also: [top privileged access workstations](https://startwithidentity.com/articles/top-5-privileged-access-workstations/), [PAM](https://startwithidentity.com/glossary/pam/), [session recording](https://startwithidentity.com/glossary/session-recording/), [privileged remote access](https://startwithidentity.com/glossary/privileged-remote-access/), [primary refresh token theft](https://startwithidentity.com/techniques/primary-refresh-token-theft/)

## privileged-remote-access
Source: https://startwithidentity.com/glossary/privileged-remote-access/
Last updated: 2026-11-05

Privileged remote access (PRA) is the brokering of administrative sessions to servers, network devices, databases and OT systems for remote employees, vendors and contractors through a gateway that authenticates the user, injects or hides the credential, limits the session to named systems and records it, without giving the user a VPN connection to the network. It is a component of [PAM](https://startwithidentity.com/glossary/pam/), sold separately by some vendors.

| | VPN | [ZTNA](https://startwithidentity.com/glossary/ztna/) | Privileged remote access |
|---|---|---|---|
| What the user reaches | A network segment | Specific applications | Specific privileged sessions (SSH, RDP, database, web console) |
| Credential handling | User holds their own | User holds their own | Vaulted credential injected; the user never sees it |
| [Session recording](https://startwithidentity.com/glossary/session-recording/) | No | Usually logs, not recordings | Yes, a core feature |
| Approval and time limits | Rare | Policy-based | Per-session approval, [just-in-time](https://startwithidentity.com/glossary/jit-access/) windows |

The pattern grew out of vendor and remote-support access, which is still the strongest use case: a third-party engineer needs two hours on one controller, not standing VPN access. [BeyondTrust](https://startwithidentity.com/vendors/pam/beyondtrust/), whose roots are in remote support, is the PAM vendor most associated with the category, and it covers employee and third-party sessions alongside password and session management; infrastructure access tools such as [Teleport](https://startwithidentity.com/vendors/pam/teleport/) and [StrongDM](https://startwithidentity.com/vendors/pam/strongdm/) (acquired by Delinea in March 2026) apply the same model to engineers. [Teleport's documentation](https://goteleport.com/docs/reference/architecture/session-recording/), for instance, records full terminal output for SSH and screen activity for remote desktop.

It matters because remote access tools are a favored entry point: a vendor account with a VPN and a shared password is standing privilege held by someone outside your directory. PRA replaces that with an identity-bound, time-boxed, recorded session. The tools themselves are targets too: pre-authentication command injection in BeyondTrust Remote Support ([CVE-2026-1731](https://startwithidentity.com/cves/cve-2026-1731/)), technician-to-admin escalation in SimpleHelp ([CVE-2024-57726](https://startwithidentity.com/cves/cve-2024-57726/)), an authentication bypass in N-able N-central ([CVE-2026-18556](https://startwithidentity.com/cves/cve-2026-18556/)), unconfirmed file execution through ScreenConnect sessions ([CVE-2026-84869](https://startwithidentity.com/cves/cve-2026-84869/)) and a password-free login to macOS Screen Sharing ([CVE-2026-65400](https://startwithidentity.com/cves/cve-2026-65400/)) are all in CISA's Known Exploited Vulnerabilities catalog, as is an Ivanti Endpoint Manager bypass that exposed stored credential data ([CVE-2026-1603](https://startwithidentity.com/cves/cve-2026-1603/)). Keep the remote access server itself patched and off the open internet where you can. Check that vendor users authenticate with phishing-resistant MFA, ideally federated from their own employer, and that sessions end when the approval window closes.

See also: [third-party access management practices](https://startwithidentity.com/articles/third-party-access-management-practices/), [privileged access workstation](https://startwithidentity.com/glossary/privileged-access-workstation/), [standing privilege](https://startwithidentity.com/glossary/standing-privilege/), [best PAM tools](https://startwithidentity.com/rankings/best-pam-tools/), [what is PAM](https://startwithidentity.com/guides/fundamentals/what-is-pam/)

## progressive-profiling
Source: https://startwithidentity.com/glossary/progressive-profiling/
Last updated: 2026-08-29

Collecting user profile data gradually over multiple interactions rather than in one long signup form, to reduce friction and improve conversion in customer identity.

Progressive profiling is the practical answer to a real tension: product wants profile data, growth wants a two-field signup. Collecting attributes at the moment they are needed, and only then, improves both conversion and data quality, since a user asked for a shipping address at checkout gives a real one. It also aligns with data-minimization obligations, because you never hold what you never needed.

See also: [what is CIAM](https://startwithidentity.com/guides/fundamentals/what-is-ciam/), [consent management](https://startwithidentity.com/glossary/consent-management/), [social login](https://startwithidentity.com/glossary/social-login/), [CIAM vendors](https://startwithidentity.com/vendors/ciam/)

## prompt-injection
Source: https://startwithidentity.com/glossary/prompt-injection/
Last updated: 2026-10-16

Prompt injection is a vulnerability in which input to a large language model alters its behavior or output in ways its developer did not intend, for example making it ignore its instructions, disclose data or take actions it should not. OWASP ranks it first in its Top 10 for LLM applications as [LLM01:2025](https://genai.owasp.org/llmrisk/llm01-prompt-injection/).

OWASP separates direct injection, where the user's own prompt carries the instructions, from indirect injection, where they arrive in content the model reads, such as a web page, file, email or tool result. Indirect injection is the identity problem, because an agent acts with its user's or its own credentials, so instructions hidden in fetched content can make it read secrets and send them out. In October 2026 Adversa AI showed an encrypted web page [steering GitHub Copilot CLI into leaking a .env file](https://startwithidentity.com/blog/2026-10-06-encrypted-web-page-tricks-github-copilot-cli-into-leaking-env-secrets/), and Zenity Labs showed one prompt making an [Amazon Bedrock AgentCore agent return its execution role credentials](https://startwithidentity.com/blog/2026-10-08-one-prompt-pulled-aws-agentcore-role-credentials-from-imds/). No input filter catches it reliably, so the containment is on the identity side: short-lived, least-privilege credentials for each agent, no standing secrets within its reach, and human confirmation before sensitive actions.

See also: [agent instruction injection](https://startwithidentity.com/techniques/agent-instruction-injection/), [agentic identity](https://startwithidentity.com/glossary/agentic-identity/), [securing AI agent identities](https://startwithidentity.com/guides/machine-identity/securing-ai-agent-identities/), [instance metadata service](https://startwithidentity.com/glossary/instance-metadata-service/)

## proof-of-possession
Source: https://startwithidentity.com/glossary/proof-of-possession/
Last updated: 2026-10-16

Proof of possession (PoP) is a property of a token or credential that requires the presenter to show it controls a specific cryptographic key, so holding the token alone is not enough to use it. [RFC 7800](https://www.rfc-editor.org/info/rfc7800/) defines how a JWT names its PoP key in the `cnf` (confirmation) claim.

PoP is the answer to the [bearer token](https://startwithidentity.com/glossary/bearer-token/) problem, where anyone who copies a token can replay it. In OAuth, [RFC 8705](https://www.rfc-editor.org/info/rfc8705/) binds access tokens to the client's TLS certificate through [mutual TLS](https://startwithidentity.com/glossary/mtls/), and [RFC 9449](https://www.rfc-editor.org/info/rfc9449/) ([DPoP](https://startwithidentity.com/glossary/dpop/)) has the client sign a short proof with its key on each request, which suits browser and mobile apps that cannot present client certificates; FAPI 2.0 requires one or the other. The same principle applies to client authentication: in October 2026 a CVSS 10 flaw in the SAP Cloud SDK for Python [sent OAuth client IDs and secrets to an attacker-controlled host](https://startwithidentity.com/blog/2026-10-13-sap-cloud-sdk-python-flaw-sends-oauth-client-secrets-to-attackers/), whereas a client authenticating with a private key over mTLS never transmits anything an attacker could reuse.

See also: [DPoP](https://startwithidentity.com/glossary/dpop/), [mTLS](https://startwithidentity.com/glossary/mtls/), [bearer token](https://startwithidentity.com/glossary/bearer-token/), [token replay on unbound endpoints](https://startwithidentity.com/techniques/token-replay-unbound-endpoint/), [FAPI](https://startwithidentity.com/glossary/fapi/)

## protected-resource-metadata
Source: https://startwithidentity.com/glossary/protected-resource-metadata/
Last updated: 2026-10-30

OAuth 2.0 Protected Resource Metadata ([RFC 9728](https://www.rfc-editor.org/rfc/rfc9728), Proposed Standard, April 2025) is a JSON document an API publishes at `/.well-known/oauth-protected-resource` to tell clients which authorization servers issue tokens for it, which scopes it understands, and how tokens must be presented.

Before RFC 9728, a client had to be configured in advance with the authorization server for each API, which works for a fixed integration and fails for an agent that discovers tools at runtime. The RFC also adds a `resource_metadata` parameter to the `WWW-Authenticate` header, so a 401 response can point the client straight at the metadata. The Model Context Protocol made it mandatory for protected MCP servers, which turned a little-used RFC into one of the most implemented OAuth extensions of 2025 and 2026. Clients should still validate the metadata: the document's `resource` value has to match the URL they fetched it for, or an attacker can steer them to a hostile authorization server.

See also: [authorization server metadata](https://startwithidentity.com/glossary/authorization-server-metadata/), [MCP authorization](https://startwithidentity.com/glossary/mcp-authorization/), [resource indicators](https://startwithidentity.com/glossary/resource-indicators/), [authorization server](https://startwithidentity.com/glossary/authorization-server/), [OAuth 2.0](https://startwithidentity.com/standards/oauth-2-0/), [agent identity standards map 2026](https://startwithidentity.com/reports/agent-identity-standards-map-2026/)

## provisioning
Source: https://startwithidentity.com/glossary/provisioning/
Last updated: 2026-11-05

Creating user accounts and entitlements in target systems. Modern provisioning is automated via SCIM or vendor APIs, triggered by HR system events. Manual provisioning is the leading cause of orphaned accounts.

Automated provisioning is worth building for correctness more than for speed: a manual process creates accounts inconsistently, misses systems, and leaves no record of why an entitlement exists. SCIM covers the applications that support it well, and the residual work is always the ones that do not, which is where scripts and orphaned accounts accumulate.

See also: [what is SCIM](https://startwithidentity.com/guides/fundamentals/what-is-scim/), [SCIM 2.0](https://startwithidentity.com/standards/scim-2-0/), [deprovisioning](https://startwithidentity.com/glossary/deprovisioning/), [set up SCIM provisioning recipe](https://startwithidentity.com/recipes/set-up-scim-provisioning/), [user lifecycle management](https://startwithidentity.com/glossary/user-lifecycle-management/)

## psd2
Source: https://startwithidentity.com/glossary/psd2/
Last updated: 2026-08-29

Revised Payment Services Directive. EU regulation requiring Strong Customer Authentication for electronic payments and enabling open banking. SCA mandates two-factor authentication with specific dynamic linking requirements.

PSD2 is the reason European checkout flows look the way they do, and dynamic linking is the requirement most often implemented poorly: the authentication has to be bound to the specific amount and payee, shown to the user, so an approval cannot be replayed against a different transaction. That constraint is why generic push approvals do not satisfy it.

See also: [SCA](https://startwithidentity.com/glossary/sca/), [FAPI](https://startwithidentity.com/standards/fapi/), [step-up auth](https://startwithidentity.com/glossary/step-up-auth/), [identity regulations](https://startwithidentity.com/regulations/)

## radius
Source: https://startwithidentity.com/glossary/radius/
Last updated: 2026-09-29

RADIUS (Remote Authentication Dial-In User Service) is a protocol, defined in [RFC 2865](https://www.rfc-editor.org/info/rfc2865/), that network devices such as switches, wireless controllers and VPN gateways use to ask a central server whether a user or device may connect, and with what access.

RADIUS sits underneath most enterprise Wi-Fi and wired 802.1X, VPN sign-in and network device administration, with servers such as Cisco ISE, Microsoft NPS and FreeRADIUS making the decisions and often consulting Active Directory. Each network device shares a secret with the server, and classic RADIUS over UDP protects responses with MD5-based checks; the 2024 Blast-RADIUS attack (CVE-2024-3596) showed those responses could be forged by an attacker in the network path, and the recommended mitigations are requiring the Message-Authenticator attribute and moving to RADIUS over TLS (RadSec). The server itself is tier-zero infrastructure: it decides who gets on the network and holds the secrets every device trusts, which is why the [exploited Cisco ISE flaw](https://startwithidentity.com/blog/2026-09-17-cisco-ise-cvss-10-auth-bypass-exploited-as-a-zero-day/) in September 2026 was an identity incident, not just a patch.

See also: [LDAP](https://startwithidentity.com/glossary/ldap/), [Active Directory](https://startwithidentity.com/glossary/active-directory/), [ZTNA](https://startwithidentity.com/glossary/ztna/), [federation](https://startwithidentity.com/glossary/federation/)

## rbac
Source: https://startwithidentity.com/glossary/rbac/
Last updated: 2026-11-05

Role-Based Access Control. Permissions are bundled into roles, users are assigned roles. Simple to understand and audit, but role explosion is a common failure mode at scale. Almost every modern access model starts with RBAC and adds finer-grained controls on top.

RBAC's strength is that a human can read an assignment and understand it, which is why auditors like it and why it will not go away. Role explosion is the standard failure: every exception becomes a new role until there are more roles than users. The workable pattern is a small set of coarse roles for the bulk grant, with attributes or relationships handling the conditions that would otherwise multiply roles.

See also: [RBAC vs ABAC vs ReBAC](https://startwithidentity.com/guides/fundamentals/rbac-vs-abac-vs-rebac/), [ABAC](https://startwithidentity.com/glossary/abac/), [role mining](https://startwithidentity.com/glossary/role-mining/), [entitlement](https://startwithidentity.com/glossary/entitlement/), [authorization](https://startwithidentity.com/glossary/authorization/)

## rebac
Source: https://startwithidentity.com/glossary/rebac/
Last updated: 2026-08-29

Relationship-Based Access Control. Authorization is computed by traversing a graph of relationships between subjects and resources. Popularized by Google's Zanzibar paper. Modern implementations include Authzed SpiceDB, OpenFGA, and Permify.

ReBAC fits the sharing and collaboration model most products actually have: access follows from being an owner, a member, or a parent of something, and those relationships change constantly. Zanzibar-style systems make the check fast and the graph traversable, at the cost of running a new stateful service on the request path and reasoning carefully about consistency when a permission was just revoked.

See also: [fine-grained authorization](https://startwithidentity.com/glossary/fga/), [RBAC vs ABAC vs ReBAC](https://startwithidentity.com/guides/fundamentals/rbac-vs-abac-vs-rebac/), [ABAC](https://startwithidentity.com/glossary/abac/), [authorization vendors](https://startwithidentity.com/vendors/authorization/)

## refresh-token
Source: https://startwithidentity.com/glossary/refresh-token/
Last updated: 2026-08-29

A longer-lived credential used to obtain new access tokens without re-authenticating the user. Refresh tokens should be one-time-use (rotated on each exchange) and bound to the client. Storing them carelessly is one of the most common identity security failures.

Refresh tokens are the highest-value credential in most OAuth deployments because they mint new access tokens without any user interaction, and stolen ones are what turn a browser compromise into months of access. Rotate on every use and detect reuse of an already-spent token, which is the signal that a copy is circulating. Bind them to the client, and keep them out of local storage in browsers.

See also: [access token](https://startwithidentity.com/glossary/access-token/), [token theft](https://startwithidentity.com/glossary/token-theft/), [DPoP](https://startwithidentity.com/glossary/dpop/), [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/)

## relying-party
Source: https://startwithidentity.com/glossary/relying-party/
Last updated: 2026-08-29

The application that relies on an external identity provider to authenticate users. The term is used in OIDC and WebAuthn. The RP validates tokens or assertions but does not store user credentials itself.

Being a relying party means outsourcing authentication and keeping responsibility for validation, which is where the bugs live: accepting an assertion without checking the audience, trusting a signature algorithm the attacker chose, or treating an ID token as an API credential. In WebAuthn the RP identifier is also the security boundary, since it determines which origin a credential will sign for.

See also: [identity provider](https://startwithidentity.com/glossary/identity-provider/), [OpenID Connect](https://startwithidentity.com/standards/openid-connect/), [WebAuthn and FIDO2](https://startwithidentity.com/standards/webauthn-fido2/), [validate a JWT recipe](https://startwithidentity.com/recipes/validate-a-jwt/)

## resource-indicators
Source: https://startwithidentity.com/glossary/resource-indicators/
Last updated: 2026-10-30

Resource Indicators for OAuth 2.0 ([RFC 8707](https://www.rfc-editor.org/rfc/rfc8707), Proposed Standard, February 2020) define a `resource` request parameter a client sends to the authorization server to name the API it intends to call, so the server can audience-restrict the access token to that API.

Without a resource indicator, one access token often works at every API that trusts the same authorization server, so a token leaked from, or deliberately replayed by, a low-value service opens high-value ones. RFC 8707 closes that by letting the token's audience say exactly which resource server may accept it, and the resource server must reject tokens minted for someone else. The Model Context Protocol requires MCP clients to send the `resource` parameter in both authorization and token requests for this reason: a malicious MCP server must not be able to replay a user's token at another server. Audience checks only help if resource servers actually enforce them, which is the step most often skipped.

See also: [access token](https://startwithidentity.com/glossary/access-token/), [scope](https://startwithidentity.com/glossary/scope/), [MCP authorization](https://startwithidentity.com/glossary/mcp-authorization/), [protected resource metadata](https://startwithidentity.com/glossary/protected-resource-metadata/), [bearer token](https://startwithidentity.com/glossary/bearer-token/), [token replay against unbound endpoints](https://startwithidentity.com/techniques/token-replay-unbound-endpoint/), [cross-tenant token confusion](https://startwithidentity.com/techniques/cross-tenant-token-confusion/)

## revocation-registry
Source: https://startwithidentity.com/glossary/revocation-registry/
Last updated: 2026-08-29

The mechanism an issuer uses to mark a verifiable credential as revoked so verifiers can detect it, using approaches such as status lists or cryptographic accumulators. It answers "is this credential still valid" without the verifier having to contact the issuer directly.

Revocation is the hardest unsolved part of decentralized identity, because the naive fix (ask the issuer) reintroduces exactly the phone-home the model removed. Status lists are the pragmatic compromise, publishing a compressed bitmap the verifier can cache, at some cost to privacy since position in the list is an identifier. Cryptographic accumulators preserve privacy better and are heavier to operate.

See also: [verifiable credential](https://startwithidentity.com/glossary/verifiable-credential/), [issuer, holder, verifier](https://startwithidentity.com/glossary/issuer-holder-verifier/), [AnonCreds](https://startwithidentity.com/glossary/anoncreds/), [verifiable credentials standard](https://startwithidentity.com/standards/verifiable-credentials/)

## rich-authorization-requests
Source: https://startwithidentity.com/glossary/rich-authorization-requests/
Last updated: 2026-10-30

OAuth 2.0 Rich Authorization Requests (RAR, [RFC 9396](https://www.rfc-editor.org/rfc/rfc9396), Proposed Standard, May 2023) add an `authorization_details` parameter that lets a client request structured, fine-grained permissions as JSON objects, for example "pay 123.50 EUR to this account", instead of flat scope strings.

Scopes describe a category of access and cannot express amounts, specific records, or one-time actions, which is why payment and health APIs kept inventing their own extensions. RAR gives each request a `type` plus whatever fields that type needs (actions, locations, datatypes, identifiers), the authorization server shows them on the consent screen, and the granted details come back in the token response and the access token or introspection response. The RFC's own examples are payment initiation and account access, it is used alongside FAPI 2.0 in open banking, and it is a natural fit for AI agents that should be authorized for one purchase or one document rather than a standing scope. The cost is complexity: every resource server has to parse and enforce the detail types it accepts.

See also: [scope](https://startwithidentity.com/glossary/scope/), [FAPI](https://startwithidentity.com/glossary/fapi/), [fine-grained authorization](https://startwithidentity.com/glossary/fga/), [PAR](https://startwithidentity.com/glossary/par/), [PSD2](https://startwithidentity.com/glossary/psd2/), [FAPI standard](https://startwithidentity.com/standards/fapi/), [agentic identity](https://startwithidentity.com/glossary/agentic-identity/)

## risc
Source: https://startwithidentity.com/glossary/risc/
Last updated: 2026-11-05

RISC (Risk Incident Sharing and Coordination) is an OpenID Foundation specification, the [OpenID RISC Profile Specification 1.0](https://openid.net/specs/openid-risc-1_0-final.html), that defines account-level security event types, such as credential compromise, account disabled, identifier recycled, and sessions revoked, delivered as Security Event Tokens over the Shared Signals Framework. It was approved as an OpenID Final Specification together with SSF and CAEP in September 2025.

Where CAEP is about sessions changing state, RISC is about accounts at risk. The classic use case is cross-provider: when the email provider that holds a user's recovery address detects a takeover, it can tell every relying party that uses that address to log the user in, so they stop trusting password resets sent there. The "identifier recycled" event addresses a quieter problem, an email address or phone number reassigned to a new person who then inherits the old owner's accounts. Google sends RISC events to apps that use Sign in with Google through its [Cross-Account Protection](https://developers.google.com/identity/protocols/risc) program; the receiving side is where adoption lags, and an event nobody acts on changes nothing.

See also: [Shared Signals Framework](https://startwithidentity.com/glossary/shared-signals-framework/), [CAEP](https://startwithidentity.com/glossary/caep/), [Security Event Token](https://startwithidentity.com/glossary/security-event-token/), [account takeover](https://startwithidentity.com/glossary/account-takeover/), [account recovery](https://startwithidentity.com/glossary/account-recovery/), [ITDR](https://startwithidentity.com/glossary/itdr/), [Shared Signals Framework standard](https://startwithidentity.com/standards/shared-signals-framework/)

## risk-based-auth
Source: https://startwithidentity.com/glossary/risk-based-auth/
Last updated: 2026-08-29

Risk-based authentication (RBA) adjusts authentication requirements based on signals such as device, location, network, and behavior. Low-risk sessions pass smoothly while risky ones face a step-up challenge such as MFA.

The point is to reduce friction without weakening security: a login from a known device and usual location proceeds, while an unfamiliar device, an impossible-travel pattern, or an anomalous action triggers an additional factor. RBA is the engine behind [adaptive authentication](https://startwithidentity.com/glossary/adaptive-auth/) and a core building block of [conditional access](https://startwithidentity.com/glossary/conditional-access/) and [zero trust](https://startwithidentity.com/guides/fundamentals/what-is-zero-trust/). For platforms that implement it, see the [top risk-based authentication platforms](https://startwithidentity.com/articles/top-5-risk-based-authentication-platforms/).

RBA is the mechanism behind most consumer MFA that users tolerate, since the challenge only appears when something looks unusual. The honest limitation is signal quality: residential proxies, real browsers, and stolen sessions all look normal, so a low risk score can mean either a legitimate user or a good attacker. Use it to decide when to demand a strong factor, not whether to have one.

See also: [adaptive auth](https://startwithidentity.com/glossary/adaptive-auth/), [step-up auth](https://startwithidentity.com/glossary/step-up-auth/), [conditional access](https://startwithidentity.com/glossary/conditional-access/), [UEBA](https://startwithidentity.com/glossary/ueba/)

## role-mining
Source: https://startwithidentity.com/glossary/role-mining/
Last updated: 2026-08-29

Analyzing existing access to discover sensible roles, reducing role explosion and cleaning up entitlements. A common step in rolling out or fixing RBAC.

Role mining is most useful as a cleanup exercise rather than a design method: the clusters it finds describe access as it happened to accumulate, including the mistakes. Treat the output as a starting proposal that business owners edit, and pair it with usage data so roles are built from entitlements people actually exercise rather than from everything they were ever granted.

See also: [RBAC](https://startwithidentity.com/glossary/rbac/), [what is IGA](https://startwithidentity.com/guides/fundamentals/what-is-iga/), [entitlement](https://startwithidentity.com/glossary/entitlement/), [access certification](https://startwithidentity.com/glossary/access-certification/)

## row-level-security
Source: https://startwithidentity.com/glossary/row-level-security/
Last updated: 2026-09-29

Row-level security (RLS) is a database feature that decides which rows a query may read or change based on who is running it, enforced by the database itself rather than by application code.

In PostgreSQL, RLS is switched on per table with `ALTER TABLE ... ENABLE ROW LEVEL SECURITY` and defined with `CREATE POLICY` rules, typically comparing a column such as `user_id` to the identity of the signed-in user. It matters most on platforms that let the browser talk to the database directly with a public key, such as Supabase: there, RLS is the entire authorization layer, and a table without it is readable by anyone holding the key that ships in every page. Note that table owners bypass RLS unless it is forced, and superusers and roles with `BYPASSRLS` always do, so a policy is only as strong as the role the application connects with. In September 2026, researchers found more than [16,000 Supabase databases readable because RLS was missing](https://startwithidentity.com/blog/2026-09-28-16000-supabase-databases-readable-because-row-level-security-was-off/).

See also: [authentication vs authorization](https://startwithidentity.com/guides/fundamentals/authentication-vs-authorization/), [ABAC](https://startwithidentity.com/glossary/abac/), [least privilege](https://startwithidentity.com/glossary/least-privilege/), [Supabase Auth](https://startwithidentity.com/vendors/open-source/supabase-auth/)

## saml
Source: https://startwithidentity.com/glossary/saml/
Last updated: 2026-08-29

Security Assertion Markup Language. An XML-based protocol for federated authentication, dominant in enterprise SSO. Largely superseded by OIDC for new deployments but still required for legacy SaaS app catalogs.

SAML is not going away because the enterprise buyer on the other side of a B2B deal requires it, which is why every serious CIAM platform still ships it. Its security record is worse than OIDC's for a structural reason: XML signature validation is genuinely hard, and canonicalization and parser-differential bugs have produced a long run of authentication bypasses where a service provider accepted a forged assertion.

See also: [SAML 2.0](https://startwithidentity.com/standards/saml-2-0/), [SAML vs OIDC](https://startwithidentity.com/guides/fundamentals/saml-vs-oidc/), [federation](https://startwithidentity.com/glossary/federation/), [identity CVE catalog](https://startwithidentity.com/cves/)

## sca
Source: https://startwithidentity.com/glossary/sca/
Last updated: 2026-08-29

The PSD2 requirement that electronic payment authentication use at least two of: knowledge, possession, inherence. Plus dynamic linking, the auth factor must be tied to the specific transaction amount and payee.

Dynamic linking is what separates SCA from ordinary MFA: the authentication has to be cryptographically tied to the amount and the payee, and the user has to see them. That rules out an approval prompt that just says "confirm sign-in". Exemptions for low-value and recurring payments exist and are where most of the implementation complexity actually sits.

See also: [PSD2](https://startwithidentity.com/glossary/psd2/), [MFA](https://startwithidentity.com/glossary/mfa/), [step-up auth](https://startwithidentity.com/glossary/step-up-auth/), [FAPI](https://startwithidentity.com/standards/fapi/)

## scim
Source: https://startwithidentity.com/glossary/scim/
Last updated: 2026-11-05

SCIM (System for Cross-domain Identity Management) is the IETF standard, RFC 7643 (schema) and RFC 7644 (protocol), that lets an identity provider create, update and remove user and group accounts in applications through a REST API. Two later RFCs extend it: [RFC 9865](https://datatracker.ietf.org/doc/rfc9865/) (2025) adds cursor-based pagination and [RFC 9967](https://datatracker.ietf.org/doc/rfc9967/) (2026) adds a profile for security event tokens.

SCIM is the reason enterprise buyers can turn on a SaaS tool without building a custom sync, and it is a hard requirement in most B2B procurement above a certain size. Implementations vary widely in practice: group handling, soft delete versus hard delete, and filtering support are where integrations break. Support PATCH, honor `active: false` as a deactivation, and paginate correctly.

## What SCIM does and does not do

| SCIM does | SCIM does not |
|---|---|
| Define a standard JSON schema for User, Group and Enterprise User resources ([RFC 7643](https://www.rfc-editor.org/rfc/rfc7643.html)) | Sign users in. Authentication and SSO are [SAML](https://startwithidentity.com/glossary/saml/) or [OIDC](https://startwithidentity.com/glossary/oidc/) |
| Define REST create, read, replace, PATCH, delete, filter and bulk operations ([RFC 7644](https://www.rfc-editor.org/rfc/rfc7644.html)); PATCH and bulk are optional for servers | Define its own client authentication. RFC 7644 relies on TLS plus standard HTTP schemes such as OAuth 2.0 bearer tokens, and says basic authentication should be avoided |
| Let clients discover server capabilities through `/ServiceProviderConfig`, `/ResourceTypes` and `/Schemas` | Decide what a user may do inside the app. Roles and entitlements beyond group membership are app-specific |
| Automate [deprovisioning](https://startwithidentity.com/glossary/deprovisioning/) when someone leaves | Guarantee a hard delete. RFC 7644 lets a server keep a deleted resource as long as it returns 404 and omits it from queries |
| Work for any app that exposes a SCIM endpoint, so one connector serves many apps | Make two implementations interoperable by itself. Custom extensions and partial PATCH support differ per vendor |

See also: [SCIM 2.0 standard](https://startwithidentity.com/standards/scim-2-0/), [what is SCIM](https://startwithidentity.com/guides/fundamentals/what-is-scim/), [provisioning](https://startwithidentity.com/glossary/provisioning/), [set up SCIM provisioning recipe](https://startwithidentity.com/recipes/set-up-scim-provisioning/), [SCIM provisioning tools](https://startwithidentity.com/articles/top-7-scim-provisioning-tools/)

## scope
Source: https://startwithidentity.com/glossary/scope/
Last updated: 2026-09-21

In OAuth 2.0, a space-delimited list of strings in an authorization request naming the access a client is asking for. The authorization server decides what to grant, and the resulting token carries the granted scopes, which the resource server enforces.

Scopes are coarse by design and frequently misused as an authorization model. A scope says what kind of access was delegated, not which specific records the user may touch, so a token with `files.read` still needs the resource server to check which files belong to that user. Over-broad scopes are also what makes consent phishing effective: the user approves an application that requested far more than it needs, and the grant persists after the phishing page is gone.

See also: [OAuth](https://startwithidentity.com/glossary/oauth/), [access token](https://startwithidentity.com/glossary/access-token/), [OAuth consent phishing](https://startwithidentity.com/techniques/oauth-consent-phishing/), [scope escalation](https://startwithidentity.com/techniques/scope-escalation-delegation/), [least privilege](https://startwithidentity.com/glossary/least-privilege/), [consent phishing](https://startwithidentity.com/glossary/consent-phishing/), [rich authorization requests](https://startwithidentity.com/glossary/rich-authorization-requests/), [resource indicators](https://startwithidentity.com/glossary/resource-indicators/)

## sd-jwt
Source: https://startwithidentity.com/glossary/sd-jwt/
Last updated: 2026-08-29

Selective Disclosure JWT. A token format that lets a holder reveal only chosen claims from a credential, used for privacy-preserving verifiable credentials and EU digital identity.

SD-JWT won the format argument for European digital identity because it is a JWT: existing libraries, existing tooling, and a mental model developers already have, with salted per-claim hashes providing selective disclosure. The trade-off against BBS is that a verifier can see how many claims were withheld, and presentations are linkable unless the wallet takes extra steps.

See also: [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/), [verifiable credentials](https://startwithidentity.com/standards/verifiable-credentials/), [EUDI wallet](https://startwithidentity.com/glossary/eudi-wallet/), [BBS signature](https://startwithidentity.com/glossary/bbs-signature/)

## secrets-management
Source: https://startwithidentity.com/glossary/secrets-management/
Last updated: 2026-11-05

Secrets management is the centralized storage, delivery, rotation and audit of the credentials that applications and infrastructure use, such as API keys, database passwords, tokens and private keys, so that they are not hard-coded in source, config files or CI pipelines. Secrets management tools such as [HashiCorp Vault](https://startwithidentity.com/vendors/machine-identity/hashicorp-vault/) also issue short-lived dynamic credentials on demand instead of storing long-lived static ones.

| Secrets management | What it is not |
|---|---|
| Credentials used by software and pipelines | A [password manager](https://startwithidentity.com/glossary/password-manager/) for people |
| Delivery at runtime, rotation and dynamic credentials | Secrets scanning, which finds secrets that already leaked |
| One part of [machine identity](https://startwithidentity.com/glossary/machine-identity/) | A replacement for [workload identity](https://startwithidentity.com/glossary/workload-identity/), which removes the secret entirely |

The measure of a secrets program is not how many secrets are in the vault but how many exist outside it, and the winning move is issuing short-lived dynamic credentials so there is nothing durable to steal. Vaulting a static database password improves auditability; generating a 15-minute one on demand removes the asset. Most incidents still start with a credential in a repository, not in a vault.

See also: [what is secrets management](https://startwithidentity.com/guides/fundamentals/what-is-secrets-management/), [secrets rotation](https://startwithidentity.com/glossary/secrets-rotation/), [workload identity](https://startwithidentity.com/glossary/workload-identity/), [secrets vendors](https://startwithidentity.com/vendors/secrets/), [open source secrets management](https://startwithidentity.com/articles/top-6-open-source-secrets-management/), [HashiCorp Vault alternatives](https://startwithidentity.com/articles/hashicorp-vault-alternatives/)

## secrets-rotation
Source: https://startwithidentity.com/glossary/secrets-rotation/
Last updated: 2026-08-29

The practice of regularly changing credentials such as API keys, database passwords, and tokens to limit the window an exposed secret is useful. Dynamic secrets, issued short-lived and on demand, are the strongest form.

Rotation on a calendar is a weak control compared to rotation on an event, and both are weaker than not having a long-lived secret at all. The reason teams avoid rotating is unknown blast radius: nobody is certain what breaks. That uncertainty is itself the finding, and fixing it (ownership, references rather than copies, tested rotation) matters more than the interval you choose.

See also: [secrets management](https://startwithidentity.com/glossary/secrets-management/), [API key](https://startwithidentity.com/glossary/api-key/), [service account](https://startwithidentity.com/glossary/service-account/), [secrets vendors](https://startwithidentity.com/vendors/secrets/)

## security-event-token
Source: https://startwithidentity.com/glossary/security-event-token/
Last updated: 2026-10-30

A Security Event Token (SET) is a JWT that states that a security event occurred to a subject, defined in [RFC 8417](https://www.rfc-editor.org/rfc/rfc8417) (Proposed Standard, July 2018) and used as the envelope for every CAEP and RISC event in the OpenID Shared Signals Framework.

A SET is not an access token and grants nothing: it carries an `events` claim describing what happened, such as a session revoked or a credential changed, and the receiver decides what to do. Delivery is specified separately, by push over HTTP in RFC 8935 or by polling in RFC 8936, and subjects are described using the formats in RFC 9493. Because a SET is a signed JWT, receivers must verify issuer, audience, and signature exactly as they would for any other token; a forged "account enabled" event is an attack, not a notification.

See also: [Shared Signals Framework](https://startwithidentity.com/glossary/shared-signals-framework/), [CAEP](https://startwithidentity.com/glossary/caep/), [RISC](https://startwithidentity.com/glossary/risc/), [JWT](https://startwithidentity.com/glossary/jwt/), [SCIM](https://startwithidentity.com/glossary/scim/)

## selective-disclosure
Source: https://startwithidentity.com/glossary/selective-disclosure/
Last updated: 2026-08-29

Revealing only the minimum claims needed for a transaction, for example proving you are over 18 without sharing your birth date. A core privacy goal of verifiable credentials.

Selective disclosure is what makes digital credentials better for privacy than the plastic they replace: handing over a driver's license to prove age reveals name, address, and document number, while a digital presentation can return a single boolean. It only delivers that benefit if verifiers actually request the minimum, which is why the EU model requires relying parties to register the attributes they intend to ask for.

See also: [SD-JWT](https://startwithidentity.com/glossary/sd-jwt/), [zero-knowledge proof](https://startwithidentity.com/glossary/zero-knowledge-proof/), [verifiable credentials](https://startwithidentity.com/standards/verifiable-credentials/), [EUDI wallet](https://startwithidentity.com/glossary/eudi-wallet/)

## self-sovereign-identity
Source: https://startwithidentity.com/glossary/self-sovereign-identity/
Last updated: 2026-08-29

A model in which individuals own and control their own digital credentials directly, holding them in a wallet and presenting them without a central provider's permission. Popularized by Christopher Allen's 2016 principles; the guiding philosophy behind decentralized identity.

SSI is the philosophical position underneath the technology, and the deployments that are actually shipping have quietly relaxed it: government wallets are state-issued, recovery mechanisms need a custodian, and revocation needs an authority. That is not a failure so much as a correction. The durable ideas are holder-mediated presentation and the removal of the issuer from every transaction.

See also: [what is self-sovereign identity](https://startwithidentity.com/guides/fundamentals/what-is-self-sovereign-identity/), [decentralized identifier](https://startwithidentity.com/glossary/decentralized-identifier/), [issuer, holder, verifier](https://startwithidentity.com/glossary/issuer-holder-verifier/), [decentralized identity vendors](https://startwithidentity.com/vendors/decentralized-identity/)

## service-account
Source: https://startwithidentity.com/glossary/service-account/
Last updated: 2026-08-29

A non-human account used by an application or service to authenticate. Often over-permissioned and rarely rotated, making service accounts a frequent breach vector.

Service accounts are the most reliable finding in any identity audit: over-permissioned because scoping was hard on day one, never rotated because nobody knows what depends on them, and excluded from MFA policy because they cannot do MFA. Ownership is the fix that unlocks the others. An account with a named owner can be reviewed, scoped, rotated, and eventually replaced by a workload identity.

See also: [non-human identity](https://startwithidentity.com/glossary/nhi/), [client credentials](https://startwithidentity.com/glossary/client-credentials/), [workload identity](https://startwithidentity.com/glossary/workload-identity/), [what is non-human identity](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/)

## service-principal
Source: https://startwithidentity.com/glossary/service-principal/
Last updated: 2026-09-29

A service principal is the identity an application or automated workload uses to sign in to Microsoft Entra ID and access Azure or Microsoft Graph resources: the instance of an app registration inside a specific tenant.

Service principals authenticate with a client secret, a certificate, or a federated credential, and receive permissions through Azure role assignments and Microsoft Graph application permissions. Managed identities are a special kind of service principal whose credentials Azure creates and rotates, so there is no secret to leak. The recurring problems are the ones common to every [non-human identity](https://startwithidentity.com/glossary/nhi/): client secrets copied into code, tickets and chat, broad roles such as Contributor granted at subscription scope for convenience, and no named owner to review them. In September 2026, Microsoft described an attacker using [a service principal whose secret appeared in a public GitHub issue](https://startwithidentity.com/blog/2026-09-28-jadepuffer-used-leaked-service-principal-credentials-to-wipe-azure-tenants/) to delete recovery locks and destroy Azure resources in seven minutes.

See also: [workload identity](https://startwithidentity.com/glossary/workload-identity/), [workload identity federation](https://startwithidentity.com/glossary/workload-identity-federation/), [client credentials](https://startwithidentity.com/glossary/client-credentials/), [Microsoft Entra](https://startwithidentity.com/vendors/iam/microsoft-entra/)

## service-provider
Source: https://startwithidentity.com/glossary/service-provider/
Last updated: 2026-08-29

The application that consumes identity assertions from an IdP to grant the user access. In SAML it's the SP; in OIDC the equivalent is the Relying Party.

The service provider does the validation, and therefore owns most of the risk in a federation. Checking the signature is necessary and not sufficient: the assertion must be for this SP, recent, unreplayed, and from the expected issuer with an algorithm you chose rather than one the message declared. A long run of SAML bypasses come from skipping one of those.

See also: [identity provider](https://startwithidentity.com/glossary/identity-provider/), [relying party](https://startwithidentity.com/glossary/relying-party/), [SAML 2.0](https://startwithidentity.com/standards/saml-2-0/), [federation](https://startwithidentity.com/glossary/federation/)

## session-hijacking
Source: https://startwithidentity.com/glossary/session-hijacking/
Last updated: 2026-08-29

Stealing a valid session, commonly via a captured session cookie or token, to impersonate a user and bypass MFA. Mitigated by token binding, short lifetimes, and DPoP.

Session theft is the dominant way MFA gets bypassed today, because the attacker never authenticates: they arrive holding a session that already did. That is also why the incident response is different, since resetting the password leaves the stolen session alive. Revoke sessions and refresh tokens explicitly, and consider device-bound or sender-constrained sessions so a lifted cookie is useless elsewhere.

See also: [token theft](https://startwithidentity.com/glossary/token-theft/), [account takeover](https://startwithidentity.com/glossary/account-takeover/), [DPoP](https://startwithidentity.com/glossary/dpop/), [infostealer session hijacking teardown](https://startwithidentity.com/breaches/infostealer-session-hijacking/), [pass-the-cookie](https://startwithidentity.com/glossary/pass-the-cookie/)

## session-recording
Source: https://startwithidentity.com/glossary/session-recording/
Last updated: 2026-11-05

Session recording is the capture of what happens inside a privileged session (terminal output, commands, screen and mouse activity, database queries) so that it can be watched live, replayed later and searched during an investigation; in [NIST SP 800-53 Rev. 5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) it is control AU-14, Session Audit. It is a core feature of [PAM](https://startwithidentity.com/glossary/pam/) and [privileged remote access](https://startwithidentity.com/glossary/privileged-remote-access/) tools.

How it works depends on where the recorder sits. A proxy or bastion in the connection path records every session that passes through it, which is why PAM products broker sessions instead of handing out passwords. An agent on the target host records locally. [Teleport's architecture documentation](https://goteleport.com/docs/reference/architecture/session-recording/) is a useful concrete reference: it captures the full pseudo-terminal output of SSH and `kubectl exec` sessions, records screen and mouse input but not keystrokes for remote desktop sessions, and offers synchronous modes where a failed recording event ends the session and asynchronous modes that buffer locally and upload later.

| Session recording is | Session recording is not |
|---|---|
| Evidence of what a privileged user did | A control that stops the action as it happens |
| A deterrent and an audit artifact | A replacement for removing [standing privilege](https://startwithidentity.com/glossary/standing-privilege/) |
| Searchable replay, often with command indexing | Complete: encoded commands and scripts can hide intent in terminal output |

It matters because auditors and incident responders ask the same question after a breach: what did the admin account actually do. The limits are real. Recordings are large, so retention and storage cost need a decision up front; recordings contain secrets and personal data, so access to them is itself privileged; and a recording reviewed by nobody is only a log. Pair it with [just-in-time access](https://startwithidentity.com/glossary/jit-access/) so there are fewer privileged sessions to record in the first place.

See also: [PAM](https://startwithidentity.com/glossary/pam/), [what is PAM](https://startwithidentity.com/guides/fundamentals/what-is-pam/), [implementing privileged access management](https://startwithidentity.com/guides/architecture/implementing-privileged-access-management/), [best PAM tools](https://startwithidentity.com/rankings/best-pam-tools/), [Teleport](https://startwithidentity.com/vendors/pam/teleport/), [privileged access workstation](https://startwithidentity.com/glossary/privileged-access-workstation/)

## shared-account
Source: https://startwithidentity.com/glossary/shared-account/
Last updated: 2026-09-29

A shared account is a single set of credentials used by more than one person, or by a function rather than a person, such as a team mailbox, a kiosk or front-desk login, a vendor support account, or a generic administrator.

Shared accounts break accountability, because actions cannot be tied to an individual, and they tend to escape the controls applied to everyone else: they are exempted from MFA because nobody is there to answer the prompt, their passwords are rarely rotated because several people would need the new one, and they have no named owner to review them. That combination makes them a favorite target for [password spraying](https://startwithidentity.com/techniques/password-spraying/); in September 2026, a campaign against more than 5,700 Microsoft 365 accounts succeeded [only against functional accounts on default passwords with no MFA](https://startwithidentity.com/blog/2026-09-24-teamfiltration-spraying-found-seven-service-accounts-on-default-passwords/). Replace them with delegated access from individual accounts wherever the platform allows, block interactive sign-in for functional accounts that do not need it, and put any unavoidable shared credential behind a [PAM](https://startwithidentity.com/glossary/pam/) vault with check-out and session recording.

See also: [service account](https://startwithidentity.com/glossary/service-account/), [orphaned account](https://startwithidentity.com/glossary/orphaned-account/), [break-glass accounts](https://startwithidentity.com/glossary/break-glass/), [non-human identity](https://startwithidentity.com/glossary/nhi/)

## shared-signals-framework
Source: https://startwithidentity.com/glossary/shared-signals-framework/
Last updated: 2026-11-05

An OpenID Foundation specification defining how security events are shared between cooperating parties: how a transmitter and receiver establish a stream, how events are delivered by push or poll, and how delivery is acknowledged. CAEP and RISC are profiles that define the event types carried over it.

The framework matters because signalling only works if both sides implement the same mechanics. Delivery is specified in RFC 8935 (push) and RFC 8936 (poll), using Security Event Tokens, a JWT profile for representing an event. Adoption is the hard part: a signal is only useful if the receiving application acts on it, which means revoking a session rather than logging the event.

See also: [CAEP](https://startwithidentity.com/glossary/caep/), [ITDR](https://startwithidentity.com/glossary/itdr/), [JWT](https://startwithidentity.com/glossary/jwt/), [Annabelle Backman](https://startwithidentity.com/experts/annabelle-backman/), [RISC](https://startwithidentity.com/glossary/risc/), [Security Event Token](https://startwithidentity.com/glossary/security-event-token/), [Shared Signals Framework standard](https://startwithidentity.com/standards/shared-signals-framework/)

## sim-swap
Source: https://startwithidentity.com/glossary/sim-swap/
Last updated: 2026-11-05

A SIM swap is an attack in which a criminal gets a victim's mobile number moved to a SIM or eSIM they control, usually by deceiving or bribing mobile carrier staff, so that calls and text messages for that number, including one-time codes, go to the attacker.

SIM swapping defeats SMS and voice MFA and, more damagingly, SMS-based account recovery, which often resets both the password and the second factor at once. It is one reason NIST's digital identity guidelines have treated codes sent over the public telephone network as a restricted authenticator since 2017, and in the United States the FCC adopted rules in 2023 requiring carriers to authenticate customers before SIM changes and number transfers. The durable fix is to stop relying on the phone number: move sign-in to [passkeys](https://startwithidentity.com/glossary/passkey/) or other [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/), and remove SMS from recovery for high-value accounts. Microsoft Entra ID is [ending the SMS and voice codes it delivers itself in 2027](https://startwithidentity.com/blog/2026-09-21-entra-id-stops-delivering-sms-and-voice-codes-february-1-and-global-admins-go-last/).

See also: [MFA](https://startwithidentity.com/glossary/mfa/), [account recovery](https://startwithidentity.com/glossary/account-recovery/), [account takeover](https://startwithidentity.com/glossary/account-takeover/), [OTP relay social engineering](https://startwithidentity.com/techniques/otp-relay-social-engineering/), [smishing](https://startwithidentity.com/glossary/smishing/)

## smishing
Source: https://startwithidentity.com/glossary/smishing/
Last updated: 2026-11-05

Smishing, short for SMS phishing, is phishing delivered by text message: the attacker sends an SMS (or a chat message on a messaging app) that pushes the target to open a link to a fake sign-in page, call a number, or install an app. MITRE ATT&CK lists it under [Phishing (T1660)](https://attack.mitre.org/techniques/T1660/) for Android and iOS, noting that attackers use "social engineering techniques in text messages to trick the victims into acting quickly."

In identity attacks the text is a delivery step, and the payload is a credential and MFA relay. The [0ktapus campaign](https://startwithidentity.com/breaches/incidents/2022-0ktapus-phishing-campaign/) in 2022 sent texts linking to fake Okta pages and, per Group-IB, captured 9,931 credential sets and 5,441 MFA codes from more than 130 organizations; [Twilio](https://startwithidentity.com/breaches/incidents/2022-twilio-sms-phishing/) was one victim. In the [2023 Retool incident](https://startwithidentity.com/breaches/incidents/2023-retool-sms-phishing-authenticator-sync/) a payroll-themed text was followed by a deepfaked IT call that collected the MFA code.

| Smishing | Related but different |
|---|---|
| Lure arrives by SMS or messaging app | [Vishing](https://startwithidentity.com/glossary/vishing/): the lure is a phone call |
| Usually links to a credential-harvesting page | [SIM swap](https://startwithidentity.com/glossary/sim-swap/): attacker takes over the phone number itself |
| Defeated by origin-bound authenticators | Not stopped by SMS or TOTP codes, which the page relays |

It matters because mobile screens hide the full URL and texts feel personal, and because the same channel often carries the OTP the attacker wants. The fix that worked in the record is technical: Cloudflare was targeted by the same 0ktapus wave and stopped it with FIDO2 security keys, because a [passkey](https://startwithidentity.com/glossary/passkey/) or security key will not sign for a lookalike domain. Training helps at the margin; [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/) closes the gap. Note that [NIST SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html) already treats SMS as a restricted authenticator.

See also: [OTP relay social engineering](https://startwithidentity.com/techniques/otp-relay-social-engineering/), [AiTM phishing proxy](https://startwithidentity.com/techniques/aitm-phishing-proxy/), [phishable MFA](https://startwithidentity.com/glossary/phishable-mfa/), [adversary-in-the-middle](https://startwithidentity.com/glossary/adversary-in-the-middle/), [best phishing-resistant MFA](https://startwithidentity.com/rankings/best-phishing-resistant-mfa/)

## soc2
Source: https://startwithidentity.com/glossary/soc2/
Last updated: 2026-10-17

A report issued by an auditor against the AICPA Trust Services Criteria (security, availability, processing integrity, confidentiality, privacy). Type 1 is a point-in-time design; Type 2 covers an operating period, typically 6-12 months.

SOC 2 is the report every B2B buyer asks for, and its identity content is predictable: access provisioning and removal, periodic access review, MFA, and logging. A Type 2 covering a real observation window is the one that means something, since a Type 1 only says the design existed on a given day. Read the exceptions section, not the opinion letter.

See also: [compliance guides](https://startwithidentity.com/guides/compliance/), [access certification](https://startwithidentity.com/glossary/access-certification/), [deprovisioning](https://startwithidentity.com/glossary/deprovisioning/), [B2B SaaS identity](https://startwithidentity.com/verticals/b2b-saas/), [ISO/IEC 27001](https://startwithidentity.com/glossary/iso-27001/)

## social-login
Source: https://startwithidentity.com/glossary/social-login/
Last updated: 2026-08-29

Letting users sign in with an existing account from a provider like Google or Apple, usually over OIDC. Reduces signup friction but ties accounts to third-party providers.

Social login raises conversion measurably and creates a dependency worth understanding: account recovery, email changes, and provider policy shifts now happen outside your control, and a user who loses the upstream account may lose yours. Support at least one path that does not depend on a third party, and never key your user records solely on an email address the provider can change.

See also: [OpenID Connect](https://startwithidentity.com/standards/openid-connect/), [what is CIAM](https://startwithidentity.com/guides/fundamentals/what-is-ciam/), [progressive profiling](https://startwithidentity.com/glossary/progressive-profiling/), [CIAM vendors](https://startwithidentity.com/vendors/ciam/)

## sod
Source: https://startwithidentity.com/glossary/sod/
Last updated: 2026-10-16

Ensuring no single user can complete a sensitive process unilaterally, for example, both creating and approving a vendor payment. SoD policies are encoded into IGA tools and tested during access certification.

Segregation of duties is where governance gets specific enough to be useful: the policy names two entitlements that must not coexist on one person, and the system enforces it at request time rather than discovering the violation at audit. The hard part is authoring the ruleset, since it requires business process knowledge that lives with finance and operations rather than with IT.

See also: [access certification](https://startwithidentity.com/glossary/access-certification/), [what is IGA](https://startwithidentity.com/guides/fundamentals/what-is-iga/), [entitlement](https://startwithidentity.com/glossary/entitlement/), [ethical wall](https://startwithidentity.com/glossary/ethical-wall/), [IGA vendors](https://startwithidentity.com/vendors/iga/)

## spiffe
Source: https://startwithidentity.com/glossary/spiffe/
Last updated: 2026-08-29

Secure Production Identity Framework for Everyone. A CNCF-graduated specification for workload identity. SPIFFE IDs are URI-like identifiers; SVIDs are the cryptographic credentials (x509 or JWT) that prove a workload owns its ID.

SPIFFE matters because it gives workloads an identity the platform attests, rather than a secret someone provisioned, which removes the credential from the threat model entirely. The identity is derived from where and what the workload is, and the SVID is short-lived by design. It is the cleanest available answer to service-to-service authentication in Kubernetes and multi-cloud estates.

See also: [workload identity](https://startwithidentity.com/glossary/workload-identity/), [mTLS](https://startwithidentity.com/glossary/mtls/), [what is machine identity](https://startwithidentity.com/guides/fundamentals/what-is-machine-identity/), [machine identity vendors](https://startwithidentity.com/vendors/machine-identity/), [WIMSE](https://startwithidentity.com/glossary/wimse/)

## sso
Source: https://startwithidentity.com/glossary/sso/
Last updated: 2026-11-05

SSO (single sign-on) is an authentication setup in which a user signs in once at an [identity provider](https://startwithidentity.com/glossary/identity-provider/) and then reaches many applications without signing in again, because each application trusts a signed [SAML](https://startwithidentity.com/glossary/saml/) assertion or [OIDC](https://startwithidentity.com/glossary/oidc/) ID token from that provider instead of checking its own password. The application finds the user by the [SSO identifier](https://startwithidentity.com/glossary/sso-identifier/) in that assertion or token.

| SSO is | SSO is not |
|---|---|
| One sign-in session at the IdP reused across apps | A [password manager](https://startwithidentity.com/glossary/password-manager/) that fills a different password into each app |
| Built on [federation](https://startwithidentity.com/glossary/federation/) standards (SAML 2.0, OpenID Connect) | MFA by itself, although it is where MFA is enforced |
| Paired with [SCIM](https://startwithidentity.com/glossary/scim/) for account creation and removal | Account provisioning: SSO authenticates, it does not deprovision |

SSO is the highest-impact control in workforce identity and the one that concentrates risk: one credential now opens everything behind it, so the session lifetime, the strength of the factor, and the detection around the identity provider all matter more than they did before. Nearly every large breach of the past three years reached SSO credentials first and used them normally.

See also: [federation](https://startwithidentity.com/glossary/federation/), [identity provider](https://startwithidentity.com/glossary/identity-provider/), [SAML vs OIDC](https://startwithidentity.com/guides/fundamentals/saml-vs-oidc/), [IAM vendors](https://startwithidentity.com/vendors/iam/), [SSO tax](https://startwithidentity.com/glossary/sso-tax/), [SSO enforcement](https://startwithidentity.com/glossary/sso-enforcement/), [local login bypass](https://startwithidentity.com/glossary/local-login-bypass/), [best SSO providers for SMBs](https://startwithidentity.com/articles/top-8-sso-solutions-smbs/)

## sso-enforcement
Source: https://startwithidentity.com/glossary/sso-enforcement/
Last updated: 2026-11-05

SSO enforcement is an application setting that makes single sign-on through the organization's identity provider the only way to sign in, disabling or removing local passwords, social login and other sign-in methods for members of the organization. Offering SSO and enforcing it are separate things: an app can support SAML while still letting every user log in with a local password that the identity provider never sees.

GitHub's documentation is a clear example of the difference. Its organizations can configure SAML SSO, and separately [enforce it](https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-saml-single-sign-on-for-your-organization/enforcing-saml-single-sign-on-for-your-organization): "all members of the organization must authenticate through your IdP", and members who have not are removed. Enforcement is what makes IdP controls such as [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/), [conditional access](https://startwithidentity.com/glossary/conditional-access/) and deprovisioning apply to the app. In SWI's [Phishing-Resistant MFA Support Matrix 2026](https://startwithidentity.com/reports/phishing-resistant-mfa-matrix-2026/), the notes for 12 of 95 apps document a setting that makes SSO the only way in, and in 9 apps turning it on also switches off the app's own passkeys, so the account becomes exactly as strong as the IdP policy for that app. Check each app's row in the [MFA matrix](https://startwithidentity.com/tools/mfa-matrix/) and inventory the exceptions that remain.

See also: [local login bypass](https://startwithidentity.com/glossary/local-login-bypass/), [SSO tax](https://startwithidentity.com/glossary/sso-tax/), [break-glass account](https://startwithidentity.com/glossary/break-glass/), [authentication policy](https://startwithidentity.com/glossary/authentication-policy/), [SSO](https://startwithidentity.com/glossary/sso/), [SAML 2.0](https://startwithidentity.com/standards/saml-2-0/)

## sso-identifier
Source: https://startwithidentity.com/glossary/sso-identifier/
Last updated: 2026-11-05

An SSO identifier, or SSO ID, is the value an identity provider sends to an application to say which user just signed in: the `NameID` in a [SAML](https://startwithidentity.com/glossary/saml/) assertion or the `sub` (subject) claim in an [OIDC](https://startwithidentity.com/glossary/oidc/) [ID token](https://startwithidentity.com/glossary/id-token/). The application uses it to find or create the matching local account. (Some vendors also use "SSO ID" for an organization's SSO connection or tenant ID; this entry covers the user identifier.)

The two standards define it differently:

| | SAML 2.0 `NameID` | OIDC `sub` |
|---|---|---|
| Defined in | [SAML Core](https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf), section 8.3 | [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html), section 2 |
| Stable format | `persistent`: an opaque, pair-wise pseudonym per IdP and SP, up to 256 characters | "locally unique and never reassigned identifier within the Issuer", up to 255 ASCII characters, case-sensitive |
| Unique together with | `NameQualifier` (the IdP) | `iss` (the issuer) |
| Common shortcut | `emailAddress` or `unspecified` format | Using the `email` claim instead of `sub` |

The shortcut is where integrations break. OIDC Core section 5.7 says `sub` and `iss` together "are the only Claims that an RP can rely upon as a stable identifier", and that claims such as `email`, `phone_number` and `preferred_username` "MUST NOT be used as unique identifiers", because an issuer can reassign an email to a different person and a user's email can change. Keying accounts on email causes duplicate accounts after a name change, and in multi-tenant apps it can let one tenant's user sign in as another's.

The practical rule: store the issuer and subject pair as the account key, treat email as a mutable attribute, and use [SCIM](https://startwithidentity.com/glossary/scim/) or a just-in-time update to keep attributes current.

See also: [SSO](https://startwithidentity.com/glossary/sso/), [claims](https://startwithidentity.com/glossary/claims/), [SAML 2.0](https://startwithidentity.com/standards/saml-2-0/), [OpenID Connect](https://startwithidentity.com/standards/openid-connect/), [cross-tenant token confusion](https://startwithidentity.com/techniques/cross-tenant-token-confusion/), [implementing SSO](https://startwithidentity.com/guides/authentication/complete-guide-implementing-sso/)

## sso-tax
Source: https://startwithidentity.com/glossary/sso-tax/
Last updated: 2026-11-05

The SSO tax is the practice of offering single sign-on (SAML or OIDC) only on a higher-priced plan, an enterprise plan or a paid add-on, so that a customer must pay more to connect an app to its identity provider. The term was popularized by the [SSO Wall of Shame](https://sso.tax/), a community list of vendors that treat SSO "as a luxury feature, not a core security requirement".

It matters because SSO is where most security controls for a SaaS app actually live: MFA strength, conditional access, and removal of access when someone leaves. In SWI's [Phishing-Resistant MFA Support Matrix 2026](https://startwithidentity.com/reports/phishing-resistant-mfa-matrix-2026/), 49 of the 82 business SaaS apps that offer SSO and document which plan includes it (59.8%) charge more for it: 23 on a higher paid tier, 20 on an enterprise plan only and 6 as an add-on. For two in three apps that cannot require phishing-resistant MFA on their own login, the SSO tax is therefore the price of phishing-resistant sign-in. The per-app data is in the [MFA matrix tool](https://startwithidentity.com/tools/mfa-matrix/), and the [TCO calculator](https://startwithidentity.com/tools/tco-calculator/) puts the cost next to the rest of the identity budget.

See also: [The SSO tax explained](https://startwithidentity.com/articles/sso-tax-explained/), [SSO](https://startwithidentity.com/glossary/sso/), [SSO enforcement](https://startwithidentity.com/glossary/sso-enforcement/), [local login bypass](https://startwithidentity.com/glossary/local-login-bypass/), [phishable MFA](https://startwithidentity.com/glossary/phishable-mfa/), [SAML 2.0](https://startwithidentity.com/standards/saml-2-0/), [implementing SSO](https://startwithidentity.com/guides/authentication/complete-guide-implementing-sso/)

## standing-privilege
Source: https://startwithidentity.com/glossary/standing-privilege/
Last updated: 2026-11-05

Standing privilege is elevated access (an admin role, a privileged group membership, a cloud owner permission) that an account holds permanently, whether or not the person or workload is using it at the moment. It is the opposite of [just-in-time access](https://startwithidentity.com/glossary/jit-access/), and removing it is the goal of [zero standing privileges](https://startwithidentity.com/glossary/zero-standing-privileges/).

Microsoft's [Privileged Identity Management documentation](https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure) makes the distinction precise. A "permanent active" assignment is one "where a user can always use the role without performing any actions": that is standing privilege. An "eligible" assignment requires the user to activate the role, with MFA, a justification or an approval, for a limited period. Microsoft also notes there is no difference in the access granted, only in when it exists. The control does not reduce what an admin can do; it reduces how long a stolen session or credential is worth anything.

| | Standing privilege | Just-in-time (eligible) privilege |
|---|---|---|
| When the access exists | Always | Only during an approved activation window |
| Value of a stolen admin session | Full, indefinitely | Limited to the window, or nothing outside it |
| Audit trail | Membership only | Who activated, why, when and for how long |
| Typical exceptions | None by design | [Break-glass](https://startwithidentity.com/glossary/break-glass/) accounts |

It matters because attackers who phish or buy a credential inherit whatever that account holds right now. Standing privilege is also what accumulates silently: a mover keeps the admin group from the last team, a service account keeps owner rights granted for a one-time migration. Start by inventorying permanent assignments to the highest-impact roles and converting them to eligible ones; leave two monitored break-glass accounts as the only standing exceptions.

See also: [zero standing privileges](https://startwithidentity.com/glossary/zero-standing-privileges/), [least privilege](https://startwithidentity.com/glossary/least-privilege/), [privilege escalation](https://startwithidentity.com/glossary/privilege-escalation/), [zero standing privileges rollout](https://startwithidentity.com/guides/implementation/zero-standing-privileges-rollout/), [zero standing privileges best practices](https://startwithidentity.com/articles/zero-standing-privileges-best-practices/), [mover entitlement accumulation](https://startwithidentity.com/techniques/mover-entitlement-accumulation/)

## step-up-auth
Source: https://startwithidentity.com/glossary/step-up-auth/
Last updated: 2026-08-29

Requiring additional authentication when a user attempts a higher-risk action, such as changing email or initiating a large payment. Implemented via OIDC `acr_values` and `amr` claims in modern stacks.

Step-up is how you keep everyday access frictionless without leaving sensitive operations protected only by a session from three days ago. Implement it as a property of the action rather than of the login: changing a recovery email, adding a payee, or exporting data should each declare the assurance they require, and the application should ask for it at that moment.

See also: [adaptive auth](https://startwithidentity.com/glossary/adaptive-auth/), [risk-based auth](https://startwithidentity.com/glossary/risk-based-auth/), [MFA](https://startwithidentity.com/glossary/mfa/), [SCA](https://startwithidentity.com/glossary/sca/)

## synced-passkey
Source: https://startwithidentity.com/glossary/synced-passkey/
Last updated: 2026-10-16

A synced passkey is a passkey that a passkey provider, such as a platform keychain or password manager, copies across the user's devices through a cloud service; a device-bound passkey never leaves the single device or security key that created it. These are the [FIDO Alliance's](https://fidoalliance.org/passkeys/) terms for the two when the distinction matters.

Both kinds are phishing-resistant, because both are bound to the site's origin. The difference is custody: a synced passkey survives a lost phone and follows the user to a new device, which is what drives consumer adoption (the [FIDO Passkey Index 2026](https://startwithidentity.com/blog/2026-10-15-fido-passkey-index-2026-passkeys-reach-36-percent-of-sign-ins/) found passkeys in 36% of sign-ins at participating services), but its security also depends on the sync account and every endpoint the key lands on, as [Unit 42's research extracting Google synced passkey keys](https://startwithidentity.com/blog/2026-08-03-unit-42-pass-ta-key-attacks-extract-google-synced-passkey-keys/) showed. FIDO says device-bound passkeys on hardware security keys offer the highest assurance and meet the most stringent compliance requirements, so the usual split is synced passkeys for customers and most staff, and device-bound passkeys for administrators and regulated access, in line with NIST SP 800-63B-4, which accepts syncable authenticators at AAL2 but requires non-exportable keys at AAL3.

See also: [passkey](https://startwithidentity.com/glossary/passkey/), [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/), [AAL](https://startwithidentity.com/glossary/aal/), [implementing passkeys in the enterprise](https://startwithidentity.com/guides/authentication/implementing-passkeys-enterprise/)

## talk-past-attack
Source: https://startwithidentity.com/glossary/talk-past-attack/
Last updated: 2026-11-05

A talk-past attack is initial access gained by persuading a person to hand over, reset or approve access, so that authentication is satisfied rather than broken: credential phishing by email, text or phone, a help desk reset, an OAuth consent grant, a push approval or a SIM swap. Start with Identity coined the term in the [Identity Breach Report 2026](https://startwithidentity.com/reports/identity-breach-report-2026/), along with the **talk-past share**, the share of human-account incidents whose initial access falls in that family.

In the [Identity Breach Database](https://startwithidentity.com/breaches/incidents/), the talk-past share was 32.1% in 2021-2022, 23.3% in 2023-2024 and 38.2% (13 of 34) in 2025-2026, while stolen, stuffed or sprayed passwords fell from 53.3% to 20.6% of human-account incidents between the last two periods. The targets moved too: 7 of the 14 social engineering incidents in 2025-2026 involved CRM or SaaS data, often a phone call persuading staff to approve a malicious connected app. Talk-past attacks are why MFA alone is not the fix: [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/) stops relayed codes and push approvals, but help desk resets and consent grants need caller verification, admin approval for OAuth apps and limits on who can authorize integrations.

See also: [help desk social engineering](https://startwithidentity.com/techniques/help-desk-social-engineering/), [OAuth consent phishing](https://startwithidentity.com/techniques/oauth-consent-phishing/), [MFA fatigue and push bombing](https://startwithidentity.com/techniques/mfa-fatigue-push-bombing/), [vishing](https://startwithidentity.com/glossary/vishing/), [phishable MFA](https://startwithidentity.com/glossary/phishable-mfa/), [MFA blind zone](https://startwithidentity.com/glossary/mfa-blind-zone/)

## temporary-access-pass
Source: https://startwithidentity.com/glossary/temporary-access-pass/
Last updated: 2026-11-05

A Temporary Access Pass (TAP) is a time-limited passcode in Microsoft Entra ID, issued by an administrator, that a user signs in with to register a passwordless method such as a passkey or Windows Hello for Business, or to recover after losing their usual method. [Microsoft Learn](https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-temporary-access-pass) defines it as "a time-limited passcode that can be configured for single use or multiple sign-ins."

The documented settings (checked 2026-11-05):

| Setting | Default | Allowed |
|---|---|---|
| Lifetime | 1 hour default, 8 hours maximum | 10 minutes to 30 days |
| One-time use | Off | On or off, tenant-wide |
| Length | 8 characters | 8 to 48 characters |

Authentication Administrators can issue a TAP for members and Privileged Authentication Administrators for admins, never for themselves, and each user can hold only one. Only users in scope of the TAP authentication methods policy can sign in with one. A one-time TAP must be used to finish registering a passwordless method within 10 minutes of sign-in. A TAP cannot be used with the NPS extension or the AD FS adapter, and for federated domains Entra handles the TAP sign-in itself rather than redirecting to the federated IdP.

It matters because onboarding and recovery are where phishing-resistant programs leak: if a new hire bootstraps a [passkey](https://startwithidentity.com/glossary/passkey/) with an SMS code, the passkey is only as strong as that code. A TAP handed over after an [identity proofing](https://startwithidentity.com/glossary/identity-proofing/) check closes that gap. Two cautions. Tokens issued during a TAP sign-in can outlive the TAP, so set a sign-in frequency policy; and a TAP issued over the phone is exactly what [help desk social engineering](https://startwithidentity.com/techniques/help-desk-social-engineering/) is after, so verify the caller before issuing one.

See also: [account recovery](https://startwithidentity.com/glossary/account-recovery/), [passwordless](https://startwithidentity.com/glossary/passwordless/), [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/), [implementing passkeys in the enterprise](https://startwithidentity.com/guides/authentication/implementing-passkeys-enterprise/), [Microsoft Entra](https://startwithidentity.com/vendors/iam/microsoft-entra/)

## token-exchange
Source: https://startwithidentity.com/glossary/token-exchange/
Last updated: 2026-11-05

An OAuth 2.0 extension (RFC 8693) that exchanges one token for another, enabling delegation and impersonation across services. Increasingly used to scope tokens for downstream APIs and AI agents.

Token exchange is the mechanism that keeps delegation honest across service hops: instead of forwarding a broad token downstream, a service swaps it for a narrower one scoped to the next call, preserving who the original subject was. That property is exactly what agent architectures need, which is why it underpins the 2026 work on standardizing AI agent authorization.

See also: [OAuth 2.0](https://startwithidentity.com/standards/oauth-2-0/), [agentic identity](https://startwithidentity.com/glossary/agentic-identity/), [client credentials](https://startwithidentity.com/glossary/client-credentials/), [what is non-human identity](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/), [ID-JAG](https://startwithidentity.com/glossary/id-jag/), [identity chaining](https://startwithidentity.com/glossary/identity-chaining/), [transaction tokens](https://startwithidentity.com/glossary/transaction-tokens/), [delegation chain](https://startwithidentity.com/glossary/delegation-chain/), [ID-JAG and Cross App Access](https://startwithidentity.com/standards/id-jag-cross-app-access/)

## token-introspection
Source: https://startwithidentity.com/glossary/token-introspection/
Last updated: 2026-10-30

OAuth 2.0 Token Introspection ([RFC 7662](https://www.rfc-editor.org/rfc/rfc7662), Proposed Standard, October 2015) defines an endpoint where a resource server sends a token to the authorization server and gets back whether it is `active` plus its scopes, client, subject, audience, and expiry.

Introspection is the alternative to self-contained JWT access tokens (RFC 9068). A resource server that introspects learns about revocation immediately, because the authorization server answers from live state, while one that only validates a JWT signature keeps accepting a revoked token until it expires. The trade-off is a network call per request (usually cached for seconds) and an availability dependency on the authorization server. Many deployments use opaque tokens for external clients and introspect at the gateway, then pass a short-lived internal token downstream. The endpoint itself must require resource server authentication, or it becomes an oracle for anyone holding a stolen token.

See also: [access token](https://startwithidentity.com/glossary/access-token/), [bearer token](https://startwithidentity.com/glossary/bearer-token/), [JWT](https://startwithidentity.com/glossary/jwt/), [authorization server](https://startwithidentity.com/glossary/authorization-server/), [transaction tokens](https://startwithidentity.com/glossary/transaction-tokens/), [token theft](https://startwithidentity.com/glossary/token-theft/)

## token-theft
Source: https://startwithidentity.com/glossary/token-theft/
Last updated: 2026-08-29

Stealing access or refresh tokens, increasingly via infostealer malware, to access resources without credentials. Sender-constrained tokens and short lifetimes reduce the impact.

Token theft is the reason "we have MFA" is no longer a sufficient answer. Infostealers lift tokens and cookies from the endpoint, phishing kits capture them in real time, and both leave the attacker with a credential that already satisfied every policy at issuance. Short lifetimes reduce the window, sender-constraining removes the replay, and revocation has to cover refresh tokens rather than just passwords.

See also: [session hijacking](https://startwithidentity.com/glossary/session-hijacking/), [infostealer](https://startwithidentity.com/glossary/infostealer/), [DPoP](https://startwithidentity.com/glossary/dpop/), [refresh token](https://startwithidentity.com/glossary/refresh-token/), [pass-the-cookie](https://startwithidentity.com/glossary/pass-the-cookie/)

## totp
Source: https://startwithidentity.com/glossary/totp/
Last updated: 2026-10-17

Time-based One-Time Password (RFC 6238). A six to eight digit code derived from a shared secret and the current time, used by authenticator apps. Phishable, so weaker than passkeys.

TOTP was a real improvement over SMS and is now the most common weak link in an otherwise modern stack, because a code a human reads and types can be relayed by a proxy in seconds. It also carries an enrollment problem: the shared secret is displayed as a QR code that can be screenshotted, backed up, and copied. Keep it as a fallback, not as the target state.

See also: [MFA](https://startwithidentity.com/glossary/mfa/), [HOTP](https://startwithidentity.com/glossary/hotp/), [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/), [passkey](https://startwithidentity.com/glossary/passkey/), [one-time password (OTP)](https://startwithidentity.com/glossary/one-time-password/)

## transaction-tokens
Source: https://startwithidentity.com/glossary/transaction-tokens/
Last updated: 2026-11-05

Transaction Tokens (Txn-Tokens) are short-lived, signed JWTs, defined in the IETF draft [draft-ietf-oauth-transaction-tokens](https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/), that carry the user identity, workload identity, and authorization context of one external request through every internal service that processes it inside a single trust domain. As of October 2026 the draft is an IETF OAuth Working Group document in the "WG Consensus: Waiting for Write-Up" state, which means the working group has agreed on it but it has not gone to the IESG and is not an RFC.

The problem is the internal call chain. A request hits an API gateway with a user's access token, then fans out across ten microservices, and by the third hop most architectures either forward the original broad token (a replay risk) or drop it and rely on network trust (no user context at all). A Transaction Token Service mints a Txn-Token at the edge, typically lasting minutes and bound to that one transaction, and downstream services verify it instead of the external token. A stolen Txn-Token is worth far less than a stolen access token, and every service can see who started the request and why. Expect it to show up alongside WIMSE and SPIFFE in service mesh and agent runtime designs.

See also: [token exchange](https://startwithidentity.com/glossary/token-exchange/), [WIMSE](https://startwithidentity.com/glossary/wimse/), [workload identity](https://startwithidentity.com/glossary/workload-identity/), [access token](https://startwithidentity.com/glossary/access-token/), [token theft](https://startwithidentity.com/glossary/token-theft/), [workload identity 101](https://startwithidentity.com/guides/machine-identity/workload-identity-101/), [agent identity standards map 2026](https://startwithidentity.com/reports/agent-identity-standards-map-2026/), [OAuth Transaction Tokens standard](https://startwithidentity.com/standards/oauth-transaction-tokens/), [delegation chain](https://startwithidentity.com/glossary/delegation-chain/)

## trust-over-ip
Source: https://startwithidentity.com/glossary/trust-over-ip/
Last updated: 2026-08-29

A Linux Foundation framework that organizes decentralized trust into a dual stack: technology layers (identifiers, credentials, protocols) and governance layers (rules, trust registries, ecosystems). It gives SSI deployments a shared model for how technical and human trust combine.

The useful contribution of Trust over IP is insisting that governance is a layer, not an afterthought. A verifier needs to know which issuers count and under what rules, and that question is human and jurisdictional rather than cryptographic. Every national wallet program ends up building the governance layer whether or not it uses this vocabulary.

See also: [trust registry](https://startwithidentity.com/glossary/trust-registry/), [issuer, holder, verifier](https://startwithidentity.com/glossary/issuer-holder-verifier/), [what is self-sovereign identity](https://startwithidentity.com/guides/fundamentals/what-is-self-sovereign-identity/), [decentralized identity guides](https://startwithidentity.com/guides/decentralized-identity/)

## trust-registry
Source: https://startwithidentity.com/glossary/trust-registry/
Last updated: 2026-08-29

An authoritative list a verifier consults to decide which issuers and credential types to trust, and under what governance rules. It answers "is this issuer allowed to issue this credential" so trust scales beyond one-off issuer whitelists.

A trust registry is where decentralized identity quietly reintroduces an authority, and that is fine as long as it is explicit. Someone has to decide that this university may issue diplomas and that this member state may issue identity credentials. The design questions are who governs the list, how a verifier discovers it, and what happens across jurisdictions when two registries disagree.

See also: [issuer, holder, verifier](https://startwithidentity.com/glossary/issuer-holder-verifier/), [trust over IP](https://startwithidentity.com/glossary/trust-over-ip/), [verifiable credentials](https://startwithidentity.com/standards/verifiable-credentials/), [EUDI wallet](https://startwithidentity.com/glossary/eudi-wallet/)

## trusted-publishing
Source: https://startwithidentity.com/glossary/trusted-publishing/
Last updated: 2026-10-16

Trusted publishing is a way to publish packages to a registry such as npm or PyPI from a CI/CD workflow without a stored API token: the workflow presents a short-lived OpenID Connect (OIDC) identity token from its CI provider, and the registry exchanges it for a short-lived publish credential if it matches a publisher configuration the maintainer registered.

On [PyPI](https://docs.pypi.org/trusted-publishers/) the resulting API token is valid for 15 minutes; [npm](https://docs.npmjs.com/trusted-publishers/) supports GitHub Actions, GitLab CI/CD and CircleCI (npm CLI 11.5.1 or later) and adds provenance attestations automatically for public packages published from GitHub or GitLab. It removes the long-lived publish token that worms such as Shai-Hulud harvest from laptops and CI, but the trust is only as good as the identifier the configuration binds to. In October 2026 Bloom Security's [SlugFest research](https://startwithidentity.com/blog/2026-10-13-npm-trusted-publishing-slugfest-let-reclaimed-repo-names-publish-packages/) showed npm matched repositories by owner and name until the first publish, so anyone who reclaimed a renamed or deleted repository name could mint publish credentials for more than 1,500 packages. Maintainers should publish once right after creating a binding, review bindings after any rename or transfer, and remove them before deleting a repository.

See also: [workload identity federation](https://startwithidentity.com/glossary/workload-identity-federation/), [OIDC](https://startwithidentity.com/glossary/oidc/), [secrets in repositories and CI](https://startwithidentity.com/techniques/secrets-in-repositories-and-ci/), [Shai-Hulud reaches the Tensorlake npm SDK](https://startwithidentity.com/blog/2026-10-08-shai-hulud-reaches-tensorlake-npm-sdk-with-a-token-revocation-wiper/)

## trusted-referee
Source: https://startwithidentity.com/glossary/trusted-referee/
Last updated: 2026-10-16

A trusted referee is a person vetted and trained to make risk-based decisions about an applicant's identity proofing case when that applicant cannot meet the normal requirements of an Identity Assurance Level (IAL). [NIST SP 800-63A-4](https://pages.nist.gov/800-63-4/sp800-63a.html) defines the role as an agent of the credential service provider (CSP), a third-party service, or a relying party, and lets CSPs offer referees in on-site or remote attended sessions.

Referees are the exception path for people the automated flow rejects: no accepted ID document, a recent name change that breaks attribute matching, a failed face comparison, or a failed fraud check in an unattended remote session. NIST says CSPs SHOULD offer them for IAL1 and IAL2, and when they do, the CSP must tell the public the service exists, document which failures qualify, train referees in document inspection, facial comparison and social engineering, reassess them annually, and record every decision. A referee is not an applicant reference, who vouches for the applicant rather than deciding for the CSP. The design tension is plain: the path that keeps proofing accessible is also the one a fraudster will aim for, so the training and logging requirements are the control.

See also: [IAL](https://startwithidentity.com/glossary/ial/), [identity verification](https://startwithidentity.com/glossary/idv/), [NIST 800-63](https://startwithidentity.com/glossary/nist-800-63/), [identity verification vendors](https://startwithidentity.com/vendors/identity-verification/)

## two-factor-authentication
Source: https://startwithidentity.com/glossary/two-factor-authentication/
Last updated: 2026-11-05

Two-factor authentication (2FA) is sign-in that requires two distinct types of authentication factor, typically a password (something you know) plus a phone, code generator or security key (something you have), which makes it the most common form of [multi-factor authentication](https://startwithidentity.com/glossary/mfa/). [NIST SP 800-63-4](https://pages.nist.gov/800-63-4/sp800-63.html) defines MFA as "an authentication system that requires more than one distinct type of authentication factor" and notes that a password plus a PIN is not two factors, because both are something you know.

The label says nothing about which second factor is in use, and that is where 2FA succeeds or fails. An SMS code, an authenticator-app code and a push approval all count as 2FA, and all can be handed to an attacker by a person who believes the request is genuine: in August 2026 the AnonyMousKIT kit used [a rented AI voice agent to phone theft victims and ask for their 2FA code](https://startwithidentity.com/blog/2026-08-26-anonymouskit-ai-voice-agent-phishes-apple-passcodes-and-2fa/). A passkey or FIDO2 security key is also a second factor but cannot be read aloud or typed into a fake page, which is why policies should name the method class ([phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/)) rather than just require "2FA".

See also: [MFA](https://startwithidentity.com/glossary/mfa/), [one-time password](https://startwithidentity.com/glossary/one-time-password/), [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/), [AAL](https://startwithidentity.com/glossary/aal/), [MFA implementation best practices](https://startwithidentity.com/guides/authentication/mfa-implementation-best-practices/), [MFA device](https://startwithidentity.com/glossary/mfa-device/)

## ueba
Source: https://startwithidentity.com/glossary/ueba/
Last updated: 2026-08-29

User and Entity Behavior Analytics. Machine-learning analysis of normal behavior to flag anomalies that signal compromise or insider risk. A common building block of identity threat detection.

UEBA is the analytic layer under most identity detection, and its value depends entirely on the baseline: a model trained during a period that already contained the intrusion learns the intrusion as normal. It works best on high-signal identity events (impossible travel, first-time privileged action, unusual consent grant) and worst as a general anomaly firehose that buries the analyst.

See also: [what is ITDR](https://startwithidentity.com/guides/fundamentals/what-is-itdr/), [account takeover](https://startwithidentity.com/glossary/account-takeover/), [lateral movement](https://startwithidentity.com/glossary/lateral-movement/), [ITDR vendors](https://startwithidentity.com/vendors/itdr/)

## user-lifecycle-management
Source: https://startwithidentity.com/glossary/user-lifecycle-management/
Last updated: 2026-11-05

User lifecycle management is the automated creation, change and removal of a person's accounts and access as their relationship with an organization changes, driven by the [joiner-mover-leaver](https://startwithidentity.com/glossary/joiner-mover-leaver/) events in an authoritative source such as the HR system. It is a core function of [IGA](https://startwithidentity.com/glossary/iga/) and of most identity providers, and its standard transport to applications is [SCIM](https://startwithidentity.com/glossary/scim/).

[Microsoft Entra lifecycle workflows](https://learn.microsoft.com/en-us/entra/id-governance/what-are-lifecycle-workflows) are a concrete example of the three phases: a joiner "enters the scope of needing access", a mover "moves between boundaries within an organization", and a leaver "leaves the scope of needing access." Each phase triggers tasks, such as generating a first-day credential, changing group memberships or disabling the account, based on attributes like hire date or department.

| Event | Typical actions | Common failure |
|---|---|---|
| Joiner | Create accounts, assign birthright roles, issue first credential | Day-one access granted by copying a colleague's permissions |
| Mover | Add new-role access, remove old-role access | Old access never removed, see [mover entitlement accumulation](https://startwithidentity.com/techniques/mover-entitlement-accumulation/) |
| Leaver | Disable accounts, revoke sessions and tokens, reassign owned resources | Accounts in apps outside SSO and SCIM survive, becoming [orphaned accounts](https://startwithidentity.com/glossary/orphaned-account/) |

User lifecycle management is not the same as access certification: lifecycle automation acts on events as they happen, while [access certification](https://startwithidentity.com/glossary/access-certification/) periodically checks that the result is still correct. You need both, because automation only covers the apps it is connected to. In UX and product design the same phrase means the customer journey from sign-up to churn; in identity it always means accounts and entitlements.

See also: [user lifecycle management guide](https://startwithidentity.com/guides/implementation/user-lifecycle-management-guide/), [provisioning](https://startwithidentity.com/glossary/provisioning/), [deprovisioning](https://startwithidentity.com/glossary/deprovisioning/), [SCIM provisioning implementation](https://startwithidentity.com/guides/implementation/scim-provisioning-implementation-guide/), [top SCIM provisioning tools](https://startwithidentity.com/articles/top-7-scim-provisioning-tools/), [orphaned account abuse](https://startwithidentity.com/techniques/orphaned-account-abuse/)

## verifiable-credential
Source: https://startwithidentity.com/glossary/verifiable-credential/
Last updated: 2026-08-29

A tamper-evident, cryptographically signed digital credential following the W3C VC Data Model. Issued by an issuer, held in a wallet, and presented to a verifier without contacting the issuer.

A verifiable credential is the data model that makes the whole decentralized identity stack work: signed by an issuer, held by a subject, checkable by anyone without contacting the issuer. Two things decide whether a deployment succeeds: the format (SD-JWT and mdoc in practice, whatever the abstract model allows) and revocation, which is where most designs get uncomfortable.

See also: [verifiable credentials standard](https://startwithidentity.com/standards/verifiable-credentials/), [decentralized identifier](https://startwithidentity.com/glossary/decentralized-identifier/), [revocation registry](https://startwithidentity.com/glossary/revocation-registry/), [verifiable credentials implementation guide](https://startwithidentity.com/guides/decentralized-identity/verifiable-credentials-implementation-guide/)

## verifiable-presentation
Source: https://startwithidentity.com/glossary/verifiable-presentation/
Last updated: 2026-08-29

A signed package a holder sends to a verifier that bundles one or more verifiable credentials, or claims derived from them, along with proof that the presenter controls them. Supports selective disclosure so only the required claims are shared.

The presentation is the thing a verifier actually receives, and it is doing more work than the credential: proving holder binding (this is the party the credential was issued to, not someone who copied it), scoping disclosure to the requested claims, and preventing replay against a different verifier through a challenge. Skipping holder binding is the classic implementation error.

See also: [verifiable credential](https://startwithidentity.com/glossary/verifiable-credential/), [OpenID4VP](https://startwithidentity.com/glossary/openid4vp/), [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/), [verifiable credentials standard](https://startwithidentity.com/standards/verifiable-credentials/)

## vishing
Source: https://startwithidentity.com/glossary/vishing/
Last updated: 2026-11-05

Vishing, short for voice phishing, is social engineering carried out over a phone call, in which an attacker impersonates a trusted party to get the target to reveal credentials, approve a sign-in, or reset an account.

In identity attacks the call usually has one of two goals: persuade a help desk to reset a password or MFA method for an account the attacker names, or persuade an employee to enter credentials or a one-time code into a lookalike sign-in page while the caller relays them. Groups such as Scattered Spider and ShinyHunters have used it to reach SSO accounts and then the SaaS data behind them, and attackers have used [passkey rollouts themselves as the pretext](https://startwithidentity.com/blog/2026-07-09-entra-passkey-enrollment-vishing-targets-microsoft-365-users/). The controls are procedural as much as technical: verified callback and identity checks before any help-desk reset, a published rule that IT never asks for codes or credentials by phone, and [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/) that a relayed session cannot satisfy.

See also: [help-desk social engineering](https://startwithidentity.com/techniques/help-desk-social-engineering/), [OTP relay social engineering](https://startwithidentity.com/techniques/otp-relay-social-engineering/), [account takeover](https://startwithidentity.com/glossary/account-takeover/), [Scattered Spider](https://startwithidentity.com/breaches/scattered-spider-helpdesk-social-engineering/), [Calling Name Presentation (CNAP)](https://startwithidentity.com/glossary/calling-name-presentation/), [smishing](https://startwithidentity.com/glossary/smishing/)

## webauthn
Source: https://startwithidentity.com/glossary/webauthn/
Last updated: 2026-08-29

A W3C standard browser API for public-key authentication. WebAuthn is the protocol used by passkeys and FIDO2 security keys. The relying party server stores the public key, the authenticator holds the private key.

WebAuthn is the API every passkey and security key goes through, and the parameters a relying party sets decide the security you actually get: `userVerification` determines whether a PIN or biometric is required, attestation determines whether you can tell what kind of authenticator enrolled, and the RP ID fixes the origin the credential will sign for. Validate the user-verification flag server side rather than trusting the client.

See also: [WebAuthn and FIDO2](https://startwithidentity.com/standards/webauthn-fido2/), [passkey](https://startwithidentity.com/glossary/passkey/), [relying party](https://startwithidentity.com/glossary/relying-party/), [add passkeys with WebAuthn recipe](https://startwithidentity.com/recipes/add-passkeys-webauthn/)

## wimse
Source: https://startwithidentity.com/glossary/wimse/
Last updated: 2026-11-05

WIMSE (Workload Identity in Multi-System Environments) is an [IETF working group](https://datatracker.ietf.org/wg/wimse/about/) and the family of specifications it produces for how software workloads identify and authenticate to each other across clouds, clusters, and organizations, starting from the architecture in [draft-ietf-wimse-arch](https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/). As of early November 2026 none of the WIMSE documents is an RFC: the architecture, workload identifier, workload credentials, and mutual TLS documents are active working group drafts, the HTTP message signatures document has been submitted to the IESG, and the workload identity practices document is in IETF Last Call (ending 13 November 2026). See the [WIMSE standards page](https://startwithidentity.com/standards/wimse/) for draft versions.

WIMSE exists because workload identity grew up in silos: SPIFFE inside clusters, cloud IAM federation between a runtime and its own provider, and bespoke service tokens everywhere else. The working group is standardizing the common pieces, including a workload identifier format, a workload credential, and proof-of-possession at the application layer through HTTP message signatures or mutual TLS, so a workload in one environment can present a credential another environment understands without a shared secret. For practitioners the near-term value is vocabulary and design patterns; the long-term value is replacing static API keys between services with credentials that are short-lived, attested, and bound to the caller.

See also: [workload identity](https://startwithidentity.com/glossary/workload-identity/), [SPIFFE](https://startwithidentity.com/glossary/spiffe/), [workload identity federation](https://startwithidentity.com/glossary/workload-identity-federation/), [transaction tokens](https://startwithidentity.com/glossary/transaction-tokens/), [mTLS](https://startwithidentity.com/glossary/mtls/), [workload identity 101](https://startwithidentity.com/guides/machine-identity/workload-identity-101/), [agent identity standards map 2026](https://startwithidentity.com/reports/agent-identity-standards-map-2026/)

## workforce-identity
Source: https://startwithidentity.com/glossary/workforce-identity/
Last updated: 2026-10-17

Workforce identity is the set of digital identities belonging to the people who work for or with an organization: employees, contractors, and partners. Workforce identity management (workforce IAM) governs how those identities are created, authenticated with SSO and MFA, granted access to company systems, reviewed, and removed.

It is the population an HR system knows about, which is what separates it from [CIAM](https://startwithidentity.com/glossary/ciam/) (customers, optimized for conversion) and [non-human identity](https://startwithidentity.com/glossary/nhi/) (service accounts, workloads, and agents, which have no HR record). Because access is granted for a job, the lifecycle is driven by [joiner-mover-leaver](https://startwithidentity.com/glossary/joiner-mover-leaver/) events and pushed to applications through [SCIM](https://startwithidentity.com/glossary/scim/), and authentication is held to a higher bar: [NIST SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b.html) requires phishing resistance at AAL3, which is where workforce passkey and security-key rollouts aim. Google Cloud uses "Workforce Identity Federation" as the name of a feature for signing employees in from an external identity provider; it is a product, not a separate concept.

See also: [what is workforce identity](https://startwithidentity.com/guides/fundamentals/what-is-workforce-identity/), [what is IAM](https://startwithidentity.com/guides/fundamentals/what-is-iam/), [IDaaS](https://startwithidentity.com/glossary/idaas/), [identity provider](https://startwithidentity.com/glossary/identity-provider/), [workforce IAM vendors](https://startwithidentity.com/vendors/iam/)

## workload-identity
Source: https://startwithidentity.com/glossary/workload-identity/
Last updated: 2026-10-16

Cryptographic identity for software workloads (containers, services, functions) rather than humans. Workload identity replaces long-lived API keys with short-lived, attested credentials. SPIFFE is the standard; cloud providers offer proprietary equivalents.

Workload identity is the shift from "here is a secret that proves you are the service" to "the platform attests what you are", which removes the credential an attacker would otherwise steal. Cloud providers implement it through federation with the workload's runtime, Kubernetes through projected service account tokens, and SPIFFE as a vendor-neutral abstraction across both.

See also: [SPIFFE](https://startwithidentity.com/glossary/spiffe/), [what is machine identity](https://startwithidentity.com/guides/fundamentals/what-is-machine-identity/), [service account](https://startwithidentity.com/glossary/service-account/), [machine identity vendors](https://startwithidentity.com/vendors/machine-identity/), [instance metadata service](https://startwithidentity.com/glossary/instance-metadata-service/), [WIMSE](https://startwithidentity.com/glossary/wimse/)

## workload-identity-federation
Source: https://startwithidentity.com/glossary/workload-identity-federation/
Last updated: 2026-10-16

Workload identity federation lets a workload authenticate to a cloud provider by presenting a short-lived token from an identity provider it already has, such as a CI/CD system or a Kubernetes cluster, instead of storing a long-lived secret or access key.

The workload obtains a signed [OIDC](https://startwithidentity.com/glossary/oidc/) token from its own platform (for example, the token GitHub Actions issues to each job), and the cloud validates the token's issuer, subject and audience against a trust configuration before exchanging it for temporary credentials. AWS supports this through IAM OIDC identity providers, Google Cloud through Workload Identity Federation, and Microsoft Entra through federated identity credentials on app registrations and managed identities. It removes the stored secret that leaks into repositories and tickets, which is the most common way cloud workloads are compromised. The main mistake is a trust condition that is too broad, such as accepting any branch or any repository in an organization, which lets an attacker who can run a job anywhere in scope assume the role.

See also: [workload identity](https://startwithidentity.com/glossary/workload-identity/), [token exchange](https://startwithidentity.com/glossary/token-exchange/), [SPIFFE](https://startwithidentity.com/glossary/spiffe/), [secrets in repositories and CI](https://startwithidentity.com/techniques/secrets-in-repositories-and-ci/), [trusted publishing](https://startwithidentity.com/glossary/trusted-publishing/)

## x509
Source: https://startwithidentity.com/glossary/x509/
Last updated: 2026-11-05

The standard format for public-key certificates used in TLS and PKI. An X.509 certificate binds a public key to a subject and is signed by a certificate authority.

X.509 is everywhere and rarely thought about as identity, which is how estates end up with certificates nobody owns. The fields that carry identity are the subject and subject alternative names, and the trust decision depends entirely on the chain to a root the verifier accepts. Misissuance and template misconfiguration in enterprise CAs have produced some of the most severe privilege escalation paths in Active Directory.

See also: [PKI](https://startwithidentity.com/glossary/pki/), [certificate lifecycle](https://startwithidentity.com/glossary/certificate-lifecycle/), [mTLS](https://startwithidentity.com/glossary/mtls/), [identity CVE catalog](https://startwithidentity.com/cves/), [certificate authority](https://startwithidentity.com/glossary/certificate-authority/)

## zero-knowledge-proof
Source: https://startwithidentity.com/glossary/zero-knowledge-proof/
Last updated: 2026-08-29

A cryptographic technique that proves a statement is true without revealing the underlying data, for example proving you are over 18 without disclosing your birth date. In decentralized identity it enables privacy-preserving credential presentation beyond simple selective disclosure.

ZKPs are the strongest available privacy tool in credentials, letting a holder prove a predicate (over 18, resident of this country, income above a threshold) without revealing the underlying value or being correlatable across presentations. Adoption is limited less by the cryptography than by tooling and verifier support, which is why simpler hash-based selective disclosure shipped first in national programs.

See also: [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/), [BBS signature](https://startwithidentity.com/glossary/bbs-signature/), [AnonCreds](https://startwithidentity.com/glossary/anoncreds/), [verifiable credentials](https://startwithidentity.com/standards/verifiable-credentials/)

## zero-standing-privileges
Source: https://startwithidentity.com/glossary/zero-standing-privileges/
Last updated: 2026-11-05

Zero standing privileges (ZSP) is an access model in which no human or machine identity holds permanent elevated rights: every privilege is granted [just in time](https://startwithidentity.com/glossary/jit-access/) for a task, with approval or policy, and expires automatically. It is the end state of removing [standing privilege](https://startwithidentity.com/glossary/standing-privilege/), and the strongest form of [least privilege](https://startwithidentity.com/glossary/least-privilege/) for admin access.

| ZSP means | ZSP does not mean |
|---|---|
| Admin roles are eligible, activated per task and time-boxed | No one can ever be an admin |
| Permanent assignments limited to monitored [break-glass](https://startwithidentity.com/glossary/break-glass/) accounts | Removing emergency access |
| Machine identities get scoped, short-lived credentials | Only humans are in scope |

Zero standing privilege is the outcome that makes a privileged access program measurable: count the identities holding permanent elevated rights and drive it toward zero. It also changes what a compromised admin workstation means, since there is nothing to inherit at rest. The prerequisite is an elevation path fast enough that engineers use it during an incident rather than keeping a standing account "just in case".

See also: [just-in-time access](https://startwithidentity.com/glossary/jit-access/), [least privilege](https://startwithidentity.com/glossary/least-privilege/), [what is PAM](https://startwithidentity.com/guides/fundamentals/what-is-pam/), [break-glass](https://startwithidentity.com/glossary/break-glass/)

## zero-trust
Source: https://startwithidentity.com/glossary/zero-trust/
Last updated: 2026-10-16

A security model where trust is never assumed based on network location and is continuously re-evaluated. Each access decision considers identity, device posture, and context. Codified in NIST SP 800-207. Distinct from ZTNA, which is the access control product category.

Zero trust is a set of design principles, not a product, and the identity parts are the ones that actually get implemented: strong authentication, device posture, per-application authorization, and continuous re-evaluation instead of a one-time gate at the perimeter. NIST SP 800-207 is the reference worth reading, mostly because it is vendor-neutral enough to argue with.

See also: [what is zero trust](https://startwithidentity.com/guides/fundamentals/what-is-zero-trust/), [conditional access](https://startwithidentity.com/glossary/conditional-access/), [ZTNA](https://startwithidentity.com/glossary/ztna/), [microsegmentation](https://startwithidentity.com/glossary/microsegmentation/), [zero trust vendors](https://startwithidentity.com/vendors/zero-trust/)

## ztna
Source: https://startwithidentity.com/glossary/ztna/
Last updated: 2026-08-29

Zero Trust Network Access. The product category that replaces VPNs with identity-aware proxies. ZTNA grants access to specific applications based on identity and policy, never exposing the underlying network.

ZTNA replaces the VPN's "you are on the network" model with per-application authorization, which shrinks lateral movement dramatically because a compromised endpoint reaches only what its user is entitled to. The migration difficulty is rarely the technology and usually the inventory: knowing every application, who should reach it, and what depends on flat network access today.

See also: [what is zero trust](https://startwithidentity.com/guides/fundamentals/what-is-zero-trust/), [zero trust](https://startwithidentity.com/glossary/zero-trust/), [device posture](https://startwithidentity.com/glossary/device-posture/), [zero trust vendors](https://startwithidentity.com/vendors/zero-trust/)