# 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-03-07

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, AWS Secrets Manager, Azure Key Vault, or Google 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 (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) |
| 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.

## FAQs

**Q: How frequently should I rotate API keys?**
A: As frequently as operationally feasible. 30 days is a good starting target for most keys. For high-sensitivity keys (production database credentials, payment processor keys), consider 7 days. For internal service-to-service keys, daily or even hourly rotation is achievable with dynamic secrets.

**Q: What if the API provider does not support multiple active keys?**
A: Some providers allow only one key at a time. For these, you must accept a brief interruption or use an API gateway as a proxy that can be updated atomically. Alternatively, negotiate with the provider for multi-key support, it is a common and reasonable request.

**Q: Should I rotate keys on a schedule or on-demand?**
A: Both. Scheduled rotation provides regular hygiene. On-demand rotation provides emergency response capability. Implement scheduled rotation first, then build the on-demand trigger.

**Q: What about database credentials?**
A: Use dynamic database credentials (Vault database secrets engine, AWS RDS IAM authentication) instead of static passwords. Each application instance gets a unique, short-lived credential that is automatically revoked when it expires.

**Q: How do I handle API keys in CI/CD pipelines?**
A: CI/CD pipelines should read keys from the vault at runtime, not from pipeline configuration. Use Vault's AppRole or Kubernetes auth method to authenticate the pipeline to the vault, then read the key for the duration of the pipeline run.

## Authentication vs Authorization: The Difference That Trips Everyone Up
Source: https://startwithidentity.com/guides/fundamentals/authentication-vs-authorization/
Last updated: 2026-08-29

Authentication and authorization sound alike and are often shortened to the same "authZ/authN," but they answer different questions. Getting them straight is foundational to identity.

## 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/vendors/mfa/). A successful authentication establishes a trusted session.

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

Authorization happens **after** authentication and decides what the verified identity is allowed to access. This is where [RBAC, ABAC, and ReBAC](https://startwithidentity.com/guides/fundamentals/rbac-vs-abac-vs-rebac/) models live.

## Why mixing them up is dangerous

A common flaw is treating "logged in" as "allowed." A user can be perfectly authenticated and still must be checked for permission on every sensitive action. Broken authorization is consistently among the most common and severe application vulnerabilities.

## Where it fits

Both are pillars of [IAM](https://startwithidentity.com/guides/fundamentals/what-is-iam/) and [Zero Trust](https://startwithidentity.com/guides/fundamentals/what-is-zero-trust/), where every request is verified (authN) and least-privilege checked (authZ).

## The failure looks like this

Broken authorization is consistently near the top of the OWASP list, and the shape is almost always the same. A request arrives with a valid session, the application confirms the user is logged in, and then reads an identifier from the request to decide what to return. Change the identifier and you get someone else's data. The user was perfectly authenticated the whole time.

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.

## Authorization models, briefly

Once you are checking properly, the question becomes how the rules are expressed:

- **[RBAC](https://startwithidentity.com/glossary/rbac/)** bundles permissions into roles. Readable and auditable, and prone to role explosion as every exception becomes a new role.
- **[ABAC](https://startwithidentity.com/glossary/abac/)** evaluates attributes of the subject, resource, action, and environment. Flexible, harder to audit, because "who can read this record" becomes a computation rather than a lookup.
- **[ReBAC](https://startwithidentity.com/glossary/rebac/)** derives access from relationships (owner, member, parent), which is what sharing and collaboration products actually need.

Most mature systems use roles for the coarse grant and attributes or relationships for the fine-grained condition. See [RBAC vs ABAC vs ReBAC](https://startwithidentity.com/guides/fundamentals/rbac-vs-abac-vs-rebac/).

## 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.

## Where to start

## Where to start

Browse [authentication and 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-01-15

## The default answer is buy

For 95% of teams, building identity in-house is wrong. Not because building it is hard (it isn't, for the basics) but because maintaining it at production quality across the long tail of edge cases takes more engineering than the founders predicted.

## The honest cost of "build"

Assume one senior engineer for 3 months to ship v1 ($75K loaded). Assume 0.25 of one engineer ongoing for security patches, compliance evidence, SDK updates, and new feature requests ($65K per year ongoing). Year 1 total: $140K. Year 3 total: $270K.

That's before the first SOC 2 audit makes you implement the IGA controls a vendor would have shipped by default.

## The cost of "buy" at scale

CIAM vendor pricing at common scales (rough mid-2026 estimates):

- 10K MAU: $15-25K annual
- 100K MAU: $50-100K annual
- 1M MAU: $200-400K annual

Crossover with "build" happens around 1M MAU for most teams, later for teams whose product UX requirements are minimal.

## When to actually build

- You are a hyperscale consumer platform (10M+ MAU) where the per-MAU economics break vendor pricing
- Your product is itself an identity platform (vendors selling to other devs)
- 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 full custom build, consider self-hosted open-source CIAM (SuperTokens, FusionAuth, Keycloak). The economics improve at scale, the operational cost is real but bounded, and the code is portable.

## 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
- Building without designing for migration to a vendor later

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

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 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, DigiCert, Sectigo) or a private CA (AWS Private CA, HashiCorp Vault PKI, Microsoft AD CS, step-ca).
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.

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

OCSP provides real-time revocation checking. 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 for public-facing TLS, 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 (typically 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. Monitor NIST PQC standardization and your CA vendor's PQC roadmap.

## 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.

## FAQs

**Q: How short should certificate lifetimes be?**
A: As short as your automation can support. For public-facing TLS, 90 days (Let's Encrypt default) is standard. For internal services with strong automation, 30 days or less. For service mesh (SPIFFE/SPIRE), 1-24 hours.

**Q: Do I need a private CA?**
A: If you have internal services that communicate over mTLS, client certificate authentication, or code signing, yes. Public CAs issue certificates for public DNS names only. Internal services need a private CA.

**Q: What about wildcard certificates?**
A: Wildcard certificates (*.example.com) are convenient but risky. A single compromised key exposes all subdomains. Use them at the edge (CDN, load balancer) where they reduce certificate count, but use specific certificates for individual services behind the load balancer.

**Q: How do I handle certificate rotation with zero downtime?**
A: Most web servers and load balancers support certificate reload without restart (NGINX: `nginx -s reload`, HAProxy: `set ssl cert`). For applications, implement hot-reloading of TLS certificates from the filesystem or vault.

**Q: What is ACME and should I use it?**
A: ACME (Automated Certificate Management Environment) is the protocol that Let's Encrypt uses for automated certificate issuance and renewal. You should use ACME for all public certificates and consider using it for private certificates too (step-ca supports ACME).

**Q: How do I prepare for post-quantum cryptography?**
A: Start by inventorying all certificates and their algorithms. Monitor NIST PQC standards. Test hybrid certificates (classical + PQC) when your CA supports them. Plan for a migration window of 3-5 years once PQC standards are finalized.

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

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 hybrid Azure AD joined device, require approved client app, require app protection policy
- Session controls: sign-in frequency, persistent browser, conditional access app control (MCAS), 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.

## Frequently Asked Questions

**Q: Can I use conditional access with non-Microsoft applications?**
A: Yes. Any application registered in Microsoft Entra ID (including SAML and OIDC apps) can be targeted by conditional access policies. This includes thousands of pre-integrated SaaS applications in the Entra gallery.

**Q: What happens if a user matches multiple policies with conflicting controls?**
A: All matching policies are evaluated together. Grant controls are combined with AND logic, the user must satisfy all required controls from all matching policies. If any policy blocks access, the block takes precedence.

**Q: Do conditional access policies apply to mobile apps?**
A: Yes, conditional access applies to modern authentication flows on mobile devices. You can target specific device platforms (iOS, Android) and require app protection policies or compliant devices for mobile access.

**Q: How do I handle the transition period when deploying MFA for all users?**
A: Use a phased rollout. Start with report-only mode, then enable enforcement for IT staff first, followed by department-by-department rollout over 4-8 weeks. Provide clear communication and support resources at each phase.

**Q: Can conditional access detect if a device is compromised?**
A: Through integration with Microsoft Intune and Microsoft Defender for Endpoint, conditional access can evaluate device risk level and compliance status. A device flagged as compromised by Defender would fail compliance checks, triggering additional controls or access denial.

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

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) and Anti-Money Laundering (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, Ping Identity, ForgeRock, AWS Cognito) that supports step-up verification workflows.
- **Verification service provider**, Jumio, Onfido, Socure, 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

**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: 0.85,
      },
    ],
    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 threshold (typically 0.80-0.90 depending on risk tolerance).

### Step 4: Implement Progressive Profiling

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
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:**

| Risk Score | Action |
|---|---|
| 0-20 | Auto-approve |
| 21-50 | Approve with enhanced monitoring |
| 51-75 | Route to manual review |
| 76-100 | 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. Typically 5-15% of verifications require some manual intervention.

### 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.

## Frequently Asked Questions

**Q: How long does customer identity verification typically take?**
A: Automated verification (document + liveness) typically completes in 30-90 seconds. Complex cases routed to manual review may take 1-24 hours depending on your team's capacity and SLAs.

**Q: What is the typical pass rate for automated identity verification?**
A: Industry averages are 75-90% auto-approval for legitimate customers. The rate varies by document type, country, customer demographics, and your risk thresholds. Lower thresholds approve more automatically but increase fraud risk.

**Q: Can we verify identity without government documents?**
A: For lower assurance levels, yes. Email verification, phone verification, knowledge-based authentication (KBA), and credit bureau data checks can provide identity assurance without documents. However, for KYC/AML compliance, government-issued documents are typically required.

**Q: How do we handle customers whose documents are in a language we do not support?**
A: Use a verification provider with global document coverage. Leading providers support documents from 190+ countries in native scripts. OCR and document template matching work across languages. For manual review, ensure your team has access to translation services.

**Q: What is the cost per verification?**
A: Pricing varies by provider and volume. Document verification with liveness typically costs $1-5 per verification at scale. Sanctions screening adds $0.10-0.50 per check. Credit bureau checks add $1-3 per check. At high volumes, negotiate volume discounts and consider the cost of fraud prevention versus the cost of fraud.

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

Decentralized identity is one of the most talked-about shifts in the identity field, and one of the most misunderstood. This guide gives practitioners a grounded overview: what it actually is, the standards underneath it, where it is real in 2026, and how to think about whether it belongs on your roadmap. For the conceptual primer first, 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/).

## The core idea

In today's systems, 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. Instead, you hold cryptographically signed [verifiable credentials](https://startwithidentity.com/standards/verifiable-credentials/) in a [wallet](https://startwithidentity.com/glossary/digital-wallet/) and present them directly. The verifier trusts the issuer's signature and the math, 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 the property that makes the whole model scale and preserves privacy.

## The building blocks

Three standards do most of the work:

- **[Decentralized Identifiers (DIDs)](https://startwithidentity.com/standards/decentralized-identifiers-did/):** identifiers a subject controls, resolving to a [DID document](https://startwithidentity.com/glossary/did-document/) of public keys. `did:web` is the pragmatic enterprise default.
- **[Verifiable Credentials](https://startwithidentity.com/standards/verifiable-credentials/):** the signed, tamper-evident data format, commonly carried as SD-JWT VC.
- **[OpenID4VC](https://startwithidentity.com/standards/openid4vc/):** the OAuth-based protocols that issue and present credentials to and from wallets.

Privacy comes from [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/) and, where stronger unlinkability is needed, [zero-knowledge proofs](https://startwithidentity.com/glossary/zero-knowledge-proof/) and [BBS signatures](https://startwithidentity.com/glossary/bbs-signature/).

## Where it is real in 2026

- **Government wallets:** the EU's [eIDAS 2.0 and EUDI Wallet](https://startwithidentity.com/standards/eidas-2-eudi-wallet/) put a state wallet in every citizen's hands, the largest single driver.
- **Mobile driver's licenses:** [ISO/IEC 18013-5 mDL](https://startwithidentity.com/standards/iso-18013-5-mdl/) is shipping into phone wallets and accepted at US airport checkpoints. Track schemes in [digital IDs by country](https://startwithidentity.com/digital-ids/).
- **Reusable identity and KYC:** verify once, reuse the credential, instead of repeating document checks. 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 near-term picture is hybrid: federated for existing sign-in, decentralized credentials for reusable proofs and portability, stitched by an [identity fabric](https://startwithidentity.com/guides/fundamentals/what-is-identity-fabric/).

## 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. Our [choosing a decentralized identity platform](https://startwithidentity.com/guides/decentralized-identity/choosing-a-decentralized-identity-platform/) guide covers vendor 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 choice: [DID methods compared](https://startwithidentity.com/guides/decentralized-identity/did-methods-compared/). 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-07-06

Federated identity and decentralized identity both answer "how does a service know who you are," but they do it in opposite ways. Understanding the difference helps you place each correctly rather than treating decentralized identity as a replacement for what you already run. 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 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.

**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 directly to a verifier, which checks the signature and issuer without calling anyone. See the full picture in [decentralized identity explained](https://startwithidentity.com/guides/decentralized-identity/decentralized-identity-explained/).

## How they compare

- **Trust model:** federated trusts a live provider; decentralized trusts a signature and the issuer's key.
- **Availability:** federated depends on the IdP being up at login; decentralized credentials can be verified offline.
- **Privacy:** in federation the IdP can see every login; decentralized presentation reveals nothing to the issuer at verification time, and [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/) shares only what is needed.
- **Portability:** federated identities live in a provider's namespace; decentralized credentials are portable and holder-controlled.
- **Maturity:** federated is battle-tested and universal; decentralized is younger, with wallet adoption still spreading.
- **Single point of failure:** the IdP is one in federation; decentralized removes it but shifts responsibility to holders for key and wallet management.

## 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. It is not going away.

**Decentralized identity wins** for reusable [identity verification and KYC](https://startwithidentity.com/guides/decentralized-identity/reusable-identity-and-kyc-with-verifiable-credentials/), portable credentials like certifications that should outlast any provider, privacy-sensitive proofs (age, eligibility), 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 future is hybrid

These models are not a war with a winner. The realistic architecture for most organizations is both: keep [federated SSO](https://startwithidentity.com/standards/openid-connect/) for sign-in, add decentralized credentials for reusable and portable proofs, and bridge them with an [identity fabric](https://startwithidentity.com/guides/fundamentals/what-is-identity-fabric/). Standards are converging to make this practical, notably [OpenID4VC](https://startwithidentity.com/standards/openid4vc/), which builds decentralized credential exchange on the same OAuth foundation federated identity already uses.

## Where to go next

Overview: [decentralized identity explained](https://startwithidentity.com/guides/decentralized-identity/decentralized-identity-explained/). Build: [verifiable credentials implementation guide](https://startwithidentity.com/guides/decentralized-identity/verifiable-credentials-implementation-guide/). 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-05-30

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, AWS Secrets Manager, 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 (15-minute expiration, scoped to specific 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 \
  --thumbprint-list 6938fd4d98bab03faadb97b34396831e3780aea1
```

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
```

**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).
- **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, GCR 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.

## Frequently Asked Questions

**Q: Does OIDC federation work with self-hosted CI/CD platforms like Jenkins?**
A: Jenkins does not natively issue OIDC tokens like GitHub Actions or GitLab CI. You can integrate Jenkins with Vault using AppRole authentication or configure the Jenkins OIDC plugin. For self-hosted platforms, Vault-based authentication is often the better path.

**Q: How do we handle secrets for local development?**
A: Developers should never have production secrets locally. Use Vault-backed development secrets or mock services for local testing. For cloud access, use short-lived credentials obtained through your IdP (e.g., `aws sso login` or `az login`), never long-lived access keys.

**Q: What if our CI/CD platform has an outage, how do we deploy?**
A: Maintain a documented manual deployment procedure using human credentials with appropriate MFA and approval workflows. This break-glass procedure should be tested quarterly.

**Q: How do we prevent a compromised dependency from stealing pipeline credentials?**
A: Use dependency pinning (pin to specific versions and SHA hashes, not tags). Limit network egress from pipeline steps. Use separate pipeline stages with isolated credentials (the build stage does not have deployment credentials). Scan dependencies for known vulnerabilities before building.

**Q: Should pipeline service accounts be included in our IGA access review campaigns?**
A: Absolutely. Pipeline identities should be reviewed quarterly with their owning team as the reviewer. The review should verify that permissions are still appropriate, the pipeline is still active, and credentials (if any) have been rotated.

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

The `method` in a [decentralized identifier](https://startwithidentity.com/standards/decentralized-identifiers-did/) determines how it is created and resolved, and the choice has real operational consequences. This guide compares the methods that matter in production so you can pick one without over-engineering. For the standard itself, 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.

## Two families

DID methods split into two camps:

- **Ledgerless:** resolution uses ordinary infrastructure (DNS, HTTPS, or the identifier itself). Simple to operate, no blockchain.
- **Ledger-anchored:** resolution uses a distributed ledger, adding decentralization independent of any single domain or provider, at the cost of ledger dependency, governance, and sometimes fees.

## The methods that matter

**did:web** anchors a DID to a domain by hosting the [DID document](https://startwithidentity.com/glossary/did-document/) at a well-known HTTPS path. It reuses the TLS and DNS trust you already run, needs no ledger, and is the most common enterprise choice. The tradeoff: it inherits DNS and domain-control assumptions, so it is only as decentralized as your domain.

**did:key** encodes a public key directly in the identifier, so it is fully self-contained with no network lookup. Ideal for ephemeral or holder-side identifiers and testing. The tradeoff: no rotation or service endpoints, because there is nothing to update.

**did:jwk** is similar to did:key but wraps a JWK, convenient in JWT-heavy stacks.

**did:ion** anchors to Bitcoin via the Sidetree protocol, giving strong decentralization without per-operation on-chain cost. The tradeoff: more moving parts and reliance on the ION network.

**did:ethr** anchors to Ethereum, common in Web3-adjacent ecosystems. The tradeoff: chain dependency and gas considerations.

**did:indy** is used in Hyperledger Indy ecosystems, often paired with [AnonCreds](https://startwithidentity.com/glossary/anoncreds/) credentials. The tradeoff: it ties you to that ecosystem's governance and ledger.

## How to choose

Work from constraints, not novelty:

1. **Do you need decentralization independent of DNS?** If no, `did:web` is almost always right.
2. **Is the identifier ephemeral or holder-side?** `did:key` fits.
3. **Are you joining an existing ecosystem** (an EU pilot, a Hyperledger network, a Web3 project)? Use the method that ecosystem standardizes on.
4. **As a verifier,** support every method your issuers use, gated by what your resolver and libraries handle.

For most organizations issuing or accepting credentials, the answer is `did:web` for issuers and whatever the wallets use for holders, with ledger methods added only when a concrete requirement demands them.

## 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/). Vendors: [decentralized identity directory](https://startwithidentity.com/vendors/decentralized-identity/).

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

## Why teams migrate

RBAC is great until your customers need to share individual resources, not entire roles. The moment you find yourself adding a 50th role named like `editor_for_project_xyz`, you've outgrown RBAC. Document-level, record-level, and resource-level access call for ReBAC.

## Recognize the signs

- Role explosion: more roles than active users
- Sharing patterns: "share this with Bob but not Alice" can't be modeled
- Inheritance gone wrong: nested folders, organization hierarchies, team trees
- Multi-tenant SaaS where tenants have their own access patterns

## What to migrate to

The dominant pattern is Google Zanzibar-style ReBAC. Implementations:

- **OpenFGA / Auth0 FGA:** Cloud and self-hosted. Open-source spec.
- **Authzed SpiceDB:** Commercial-grade Zanzibar implementation.
- **Permify:** Open-source, simpler to operate.
- **Oso:** A different model (Polar policy language); evaluate as a peer option.

## The migration

1. **Model first.** Write the schema in your chosen tool. Don't migrate code yet, get the model right.
2. **Dual-write.** Existing RBAC checks continue. Mirror writes to ReBAC.
3. **Shadow reads.** Compare ReBAC decisions to RBAC decisions in production logs. Alert on divergence.
4. **Cutover by call site.** One endpoint at a time. Roll back is trivial.
5. **Decommission RBAC.** Only after weeks of shadow agreement.

## Common pitfalls

- Treating ReBAC as a code library instead of a system of record
- Not designing for "negative permissions" (deny rules) early, they're hard to add later
- Failing to budget for latency, every request now hits the authz service
- Cache invalidation: relationship changes must propagate or stale auth decisions leak

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

## What identity teams must support

GDPR confers user rights (access, rectification, erasure, portability, object). Identity systems are usually where those requests are routed because they hold the canonical user record.

## The eight obligations to implement

1. **Lawful basis tracking.** For every data field, why are you processing it? Consent, contract, legitimate interest. Store this with the data, not in a wiki.
2. **Granular consent capture.** Marketing consent is not the same as cookie consent is not the same as data sharing consent. Capture separately, time-stamped, with audit trail.
3. **Right of access.** A user-initiated export of their data within 30 days. Build the export pipeline before someone asks.
4. **Right to rectification.** Users can correct inaccurate data. Profile editing screens count, but only if all derived systems get updated.
5. **Right to erasure.** "Delete my account" must actually delete (or anonymize beyond reidentification). Backups complicate this, have an answer.
6. **Right to portability.** Machine-readable export in a common format (JSON usually suffices).
7. **Right to object.** Users can opt out of specific processing (notably profiling). Honor it in the identity layer.
8. **Data residency.** Where is the data physically stored? Some customers will require EU-only.

## Vendor requirements

User data export API. Account deletion with downstream propagation. Consent capture with audit trail. Data residency controls (EU, US, regional). Audit log of all access to personal data.

## Common pitfalls

- Confusing "delete" with "mark inactive", GDPR is explicit that erasure is erasure
- Not propagating deletions to data warehouses and BI systems
- Treating GDPR as an EU-only concern when CCPA and similar laws now apply globally
- Marketing consent that defaults to opt-in (illegal in EU)
- Failing to log who accessed personal data (Article 30 record keeping)

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

A greenfield product is the best time to get customer identity right, because there are no users to migrate and no legacy decisions to unwind. It is also the moment teams most often get it wrong, usually by treating login as a weekend feature. This guide is an 8-week plan to ship a real first version, plus a clear line on what to defer.

## Build or buy: decide first

For a new product, buy. [Customer identity](https://startwithidentity.com/guides/fundamentals/what-is-ciam/) looks like a login form, but the work that matters is the part you cannot see on the screen: password hashing that survives a database leak, breach and credential-stuffing defense, MFA, account recovery that is not itself phishable, session management, audit logging, and privacy-compliant deletion. A managed platform delivers all of it on day one, and the free tiers cover early volume. Build your own only when identity is the product you sell.

For picking a platform, use the [how to evaluate CIAM](https://startwithidentity.com/guides/buyer-guides/how-to-evaluate-ciam/) buyer guide and the [best CIAM for startups](https://startwithidentity.com/rankings/best-ciam-for-startups/) ranking. For a wider capability view across platforms, [Deepak Gupta's CIAM Compass](https://guptadeepak.com/ciam-compass/) maps 40-plus platforms against a capability matrix.

## What "first version" means

A working CIAM for a new product covers: signup, sign-in, password reset, email verification, social login, basic profile, session management, and an account deletion flow. Anything beyond that is phase 2. Scope discipline here is what makes the eight weeks realistic.

## Week-by-week

**Weeks 1-2: foundation.** Pick the vendor. Spin up a free tier. Wire signup and sign-in with the SDK. Decide the session strategy early, because it is hard to change later: prefer a short-lived token in an HttpOnly, Secure, SameSite cookie over a token in localStorage. Configure separate tenants or environments 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 (Google and Apple at minimum, since Apple is mandatory if you also offer other social logins on iOS). Branded transactional emails from a domain you control with SPF, DKIM, and DMARC set, or deliverability will suffer.

**Weeks 5-6: profile and step-up.** Profile screens and password change. MFA enrollment: TOTP authenticator apps as the baseline, with passkeys planned for phase 2. Make MFA available to all users and required for any account that touches money or sensitive data.

**Weeks 7-8: production hardening.** Structured audit logging for every identity event. Account deletion and data export flows for GDPR and CCPA. Rate limiting and lockout on login, reset, and verification endpoints. A load test against your expected launch traffic. A runbook for the two incidents you will eventually have: account takeover reports and a locked-out founder.

## What to defer

- Federation with enterprise identity providers (only when the first enterprise prospect asks), using [OpenID Connect](https://startwithidentity.com/standards/openid-connect/) 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)
- Custom auth flows and journey orchestration (default flows handle the large majority of cases)
- Migration tooling (you have no users yet)
- 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 bcrypt, scrypt, or Argon2
- 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 actual users and first enterprise buyers need, not by features you imagined at the start.

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

Identity engineering is one of the best-paid, most durable specialties in security, and you do not need a specific degree to get in. You need to understand a handful of protocols deeply, get hands-on with real platforms, and be able to reason about trade-offs. Here is a concrete path.

## Learn the foundations

Start with the concepts, not a product: [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 exactly this.

## Get hands-on

Reading is not enough; identity rewards building.

- Stand up a free tier of a developer identity platform ([Auth0](https://startwithidentity.com/vendors/ciam/auth0/), [Clerk](https://startwithidentity.com/vendors/ciam/clerk/), or open-source [Keycloak](https://startwithidentity.com/vendors/open-source/keycloak/)) and implement login end to end.
- Wire up the [authorization code flow with PKCE](https://startwithidentity.com/standards/oauth-2-1/), validate a [JWT](https://startwithidentity.com/glossary/jwt/) (try the [JWT decoder](https://startwithidentity.com/tools/jwt-decoder/)), and add [passkeys](https://startwithidentity.com/guides/authentication/passkeys-101/).
- Configure SAML and [SCIM](https://startwithidentity.com/standards/scim-2-0/) against a test app so you understand enterprise federation and provisioning.

## Build the security mindset

Study how identity actually fails. The [breach teardowns](https://startwithidentity.com/breaches/) show the real patterns: stolen credentials, [MFA fatigue](https://startwithidentity.com/breaches/mfa-fatigue-push-bombing/), [session theft](https://startwithidentity.com/breaches/infostealer-session-hijacking/), weak recovery. Being able to explain how a breach happened and how identity controls 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/) to validate fundamentals, contribute to open-source identity projects, and write up what you build. Then prepare for the conversation with our [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.

## 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 portfolio, 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
Source: https://startwithidentity.com/guides/buyer-guides/how-to-choose-a-ciam-platform/
Last updated: 2026-08-06

Picking a [CIAM](https://startwithidentity.com/guides/fundamentals/what-is-ciam/) platform is harder to reverse than a workforce IAM choice, since your customers are the ones who feel a migration. Here is a practical framework to narrow the field before you start booking demos.

## 1. Decide build vs. buy, and overlay vs. replace

The first fork isn't a feature comparison, it's architectural. If your product already has working authentication and the only gap is enterprise SSO and SCIM for procurement, you want an overlay ([WorkOS](https://startwithidentity.com/vendors/ciam/workos/), [SSOJet](https://startwithidentity.com/vendors/ciam/ssojet/)) that adds those features without touching what you have. If you're building or replacing authentication itself, evaluate full platforms ([Auth0](https://startwithidentity.com/vendors/ciam/auth0/), [Frontegg](https://startwithidentity.com/vendors/ciam/frontegg/)) that cover both. Getting this fork wrong is the single most common reason teams end up re-platforming within a year.

## 2. Map your requirements before demos

Write down: B2C, B2B, or both; expected user and enterprise-connection volume over 24 months, not today; which identity providers your enterprise customers actually use; your compliance obligations (SOC 2, HIPAA, data residency); and whether you need self-hosted or SaaS-only deployment. A platform that's a strong general fit can still be wrong for your specific compliance or residency constraints.

## 3. Score the capabilities that matter to you

Use the published [10-dimension methodology](https://startwithidentity.com/methodology/) as a checklist: authentication and [MFA](https://startwithidentity.com/vendors/mfa/), SSO and federation, [SCIM](https://startwithidentity.com/standards/scim-2-0/) 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 (a B2B SaaS team weighs SCIM and multi-tenancy far higher than a consumer app does), then compare candidates in the [capability checker](https://startwithidentity.com/tools/capability-checker/).

## 4. Model pricing at your real volume, not the entry tier

CIAM pricing comes in incompatible shapes, per-MAU, per-connection, and flat platform tiers, so list prices from different vendors aren't comparable without your own numbers plugged in. Model the full 24-month cost with the [TCO calculator](https://startwithidentity.com/tools/tco-calculator/), and see [enterprise authentication pricing in 2026](https://startwithidentity.com/articles/enterprise-authentication-pricing-2026/) for what each billing shape actually costs at scale. The vendor that looks cheapest at your current volume is frequently not the cheapest at the volume you'll reach.

## 5. Watch the usual traps

- **Migration cost:** customer identity migrations are riskier than workforce ones; check export formats and standards support before you need them, not after.
- **Retail plan caps:** several platforms bundle a handful of enterprise connections into a retail tier, then jump to custom Enterprise pricing above a cap. Know where that cap is before you're near it.
- **Reference base vs. speed:** newer, cheaper vendors ship faster; established vendors carry a longer track record. Neither is universally right, match it to how much risk your stage can absorb.

## 6. Shortlist and pilot

Narrow with the [vendor selector](https://startwithidentity.com/tools/vendor-selector/), then pilot the top two against a real enterprise customer's actual identity provider, not a demo environment.

## Where to start

Browse [CIAM platforms](https://startwithidentity.com/vendors/ciam/), the [best CIAM platforms](https://startwithidentity.com/rankings/best-ciam-platforms/) and [best SSO & SCIM platforms for B2B SaaS](https://startwithidentity.com/rankings/best-sso-scim-platforms-b2b-saas/) rankings, and head-to-head comparisons like [WorkOS vs SSOJet vs Auth0](https://startwithidentity.com/articles/workos-vs-ssojet-vs-auth0-b2b-saas/).

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

Decentralized identity platforms vary widely, from developer toolkits to managed issuance-and-verification clouds to government-grade wallet infrastructure. This buyer guide helps you evaluate them without getting lost in marketing. If you are still deciding whether you need one, start with [decentralized identity explained](https://startwithidentity.com/guides/decentralized-identity/decentralized-identity-explained/).

## Start from your use case

The single biggest filter is what you are trying to do:

- **Verifier only:** you want to accept credentials others issue. Prioritize verification SDKs, wallet compatibility, and [OpenID4VP](https://startwithidentity.com/glossary/openid4vp/) support.
- **Issuer:** you want to issue portable credentials. Prioritize signing, schema management, [revocation](https://startwithidentity.com/glossary/revocation-registry/), and [OpenID4VCI](https://startwithidentity.com/glossary/openid4vci/).
- **Government or regulated interop:** you must work with the [EUDI Wallet](https://startwithidentity.com/standards/eidas-2-eudi-wallet/) or [mDL](https://startwithidentity.com/standards/iso-18013-5-mdl/). Prioritize ARF and HAIP conformance above all.

## The capabilities that matter

Evaluate every shortlisted vendor against these:

- **Standards support:** genuine [W3C Verifiable Credentials](https://startwithidentity.com/standards/verifiable-credentials/), [DIDs](https://startwithidentity.com/standards/decentralized-identifiers-did/), and [OpenID4VC](https://startwithidentity.com/standards/openid4vc/), not a proprietary credential format wrapped in the vocabulary.
- **Credential formats:** does it support the format your ecosystem uses (SD-JWT VC, W3C Data Integrity, [AnonCreds](https://startwithidentity.com/glossary/anoncreds/))?
- **Wallet strategy:** does it provide a wallet, integrate third-party wallets, or both? Who owns the holder relationship?
- **Revocation and status:** how are credentials revoked and checked?
- **Trust framework:** does it support [trust registries](https://startwithidentity.com/glossary/trust-registry/) and governance, or leave that to you?
- **Privacy:** [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/) at minimum; [BBS signatures](https://startwithidentity.com/glossary/bbs-signature/) or [ZKPs](https://startwithidentity.com/glossary/zero-knowledge-proof/) if unlinkability matters.
- **Interoperability evidence:** conformance test results, HAIP alignment, participation in EU large-scale pilots.

## Questions that separate substance from marketing

- "Which credential formats and DID methods do you support in production, not on a roadmap?"
- "Show me an interop test result against another vendor's wallet or verifier."
- "How does revocation work, and what does a verifier do offline?"
- "If we leave, what happens to issued credentials and the holder wallets?"
- "Are you aligned to the eIDAS ARF and OpenID4VC HAIP?"

## 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 (many vendors, such as walt.id and SpruceID, offer them) when your scope is narrow and you have the cryptographic engineering depth to own key management and upgrades.

## The vendor landscape

The [decentralized identity vendor directory](https://startwithidentity.com/vendors/decentralized-identity/) profiles the active platforms, and [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 use case, 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
Source: https://startwithidentity.com/guides/buyer-guides/how-to-choose-a-pam-solution/
Last updated: 2026-08-29

[Privileged Access Management](https://startwithidentity.com/guides/fundamentals/what-is-pam/) protects your highest-risk accounts, so the selection bar is high. Use this framework.

## 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.

## 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. 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.

## 5. 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.

## 6. 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.

## 7. 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/).

## 8. 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

## Where to start

Browse [PAM vendors](https://startwithidentity.com/vendors/pam/) and [CyberArk vs Delinea](https://startwithidentity.com/compare/cyberark-vs-delinea/) or [CyberArk vs BeyondTrust](https://startwithidentity.com/compare/cyberark-vs-beyondtrust/).

## How to Choose a Workforce IAM Platform
Source: https://startwithidentity.com/guides/buyer-guides/how-to-choose-an-iam-platform/
Last updated: 2026-08-29

Picking a workforce [IAM](https://startwithidentity.com/guides/fundamentals/what-is-iam/) platform is a multi-year commitment. Here is a practical framework to get it right.

## 1. Map your requirements first

Before demos, write down: number of employees and contractors, your apps (and whether they speak SAML or [OIDC](https://startwithidentity.com/guides/fundamentals/saml-vs-oidc/)), your HR system of record, on-prem vs cloud needs, and your compliance obligations.

## 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/).

## 3. Watch the usual traps

- **Hidden cost:** model the full 3-year total with our [TCO calculator](https://startwithidentity.com/tools/tco-calculator/), including platform fees and the staff time to run it.
- **Lock-in:** check export, standards support, and migration paths.
- **Lifecycle depth:** SSO is easy; clean joiner-mover-leaver automation is where platforms differ.

## 4. Shortlist and pilot

Narrow with the [vendor selector](https://startwithidentity.com/tools/vendor-selector/), then pilot the top two against your real apps.

## 5. Price the comparison honestly

Most workforce IAM evaluations are decided on cost, and most cost comparisons are unfair. Microsoft Entra's base tier comes bundled with Microsoft 365, but the capabilities identity programmes actually need, conditional access, identity protection, and access reviews, sit in the P1 and P2 add-ons. 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, and add a separate MDM where the platform does not include one. See [Okta vs Microsoft Entra](https://startwithidentity.com/compare/okta-vs-microsoft-entra/).

## 6. 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](https://startwithidentity.com/standards/scim-2-0/) 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 are the most common audit finding in workforce identity, and they are the case most demos skip.

## 7. 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. The standards moved quickly in 2026, so this is a fair question to ask now rather than a future-looking one.

## 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.

## Where to start

## Where to start

Browse [IAM platforms](https://startwithidentity.com/vendors/iam/) and comparisons like [Okta vs Microsoft Entra](https://startwithidentity.com/compare/okta-vs-microsoft-entra/).

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

[Identity Governance](https://startwithidentity.com/guides/fundamentals/what-is-iga/) projects succeed or fail on fit and connectors. Here is how to choose well.

## 1. Define the outcomes you need

Access reviews and certifications, automated provisioning, separation of duties, role management, or all of the above? 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

IGA lives or dies on integrations. List your target systems (HR, cloud, SaaS, on-prem, mainframe) and confirm each has a supported, maintained connector. Thin connector coverage means costly custom work.

## 3. Modern vs traditional

Newer cloud-native tools deploy fast and excel at SaaS; established suites go deeper on complex legacy estates. Match the tool to your environment, not the hype.

## 4. 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 pilot a real certification campaign.

## 5. Test against your worst applications, not their reference architecture

Every governance platform demos beautifully against Active Directory and a well-behaved SaaS application. Ask both vendors to connect 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. That proof of concept tells you more than the feature matrix.

## 6. Budget for identity data quality

The reason IGA implementations run long is almost never the product. It is that the HR system, the directory, and the applications disagree about who exists, which accounts belong to whom, and what an entitlement means. Reconciling that is a project of its own, and it happens whether or not you plan for it.

Ask specifically: 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.

## 7. Design certification so it produces revocations

A certification campaign that shows reviewers a list of raw entitlement names produces approvals. `APP_FIN_GL_RW_PROD` means nothing to a manager, so they approve everything and the campaign generates evidence without reducing risk.

Campaigns that produce real revocations do three things: translate entitlements into business language, show usage data alongside the grant ("not used in 180 days"), and make revocation the low-effort default rather than an exception requiring justification. Ask each vendor to demonstrate all three. Auditors increasingly ask for the revocation rate, not the completion rate. See [access certification](https://startwithidentity.com/glossary/access-certification/).

## 8. Ask about non-human identities

[Service accounts](https://startwithidentity.com/glossary/service-account/) and workloads outnumber employees in most environments and appear in almost no certification campaign, because they have no manager to attest for them. Ask how each platform handles ownership assignment, review, and the growing population of AI agents. This is where the category is heading and where SailPoint's Entro Security acquisition in June 2026 was aimed.

## Where to start

## Where to start

Browse [IGA platforms](https://startwithidentity.com/vendors/iga/) and [SailPoint vs Saviynt](https://startwithidentity.com/compare/sailpoint-vs-saviynt/).

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

Identity Threat Detection and Response (ITDR) catches identity-based attacks that prevention misses. The category is broad, so scope your need first.

## 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. Check integration with your stack

ITDR feeds and consumes signals from your IdP, EDR, and SIEM. Confirm clean integration so detections are actionable, not noise.

## 3. Posture vs detection vs response

Some tools find misconfigurations (posture), some detect attacks at runtime, some help you recover. Decide how much of that lifecycle you need in one product.

## 4. Score and pilot

Compare with the [capability checker](https://startwithidentity.com/tools/capability-checker/) and validate detections against real scenarios.

## 5. Test detections against your own scenarios

Vendor demos show the detections that work. Bring your own, drawn from what actually happens:

- 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.
- A new OAuth consent grant to an unfamiliar application.
- A service account performing its first-ever privileged action.
- A directory change that creates an escalation path, such as a certificate template permission or new delegation right.

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

## 6. Hybrid coverage is not optional

Attackers pivot between on-premises Active Directory and the cloud identity provider because the trust between them is the point of the architecture. A tool that watches one and not the other misses the path entirely. Confirm coverage of both, and confirm it correlates rather than presenting two consoles.

## 7. Ask about response, not just detection

Detection without a playbook produces alerts. Identity containment is different from endpoint containment: revoking [refresh tokens](https://startwithidentity.com/glossary/refresh-token/) and sessions matters more than resetting a password, because a reset leaves a stolen session alive. Ask what the product can do directly, what it hands to your identity provider, and what remains manual.

## 8. Prevention and resilience are separate purchases

Runtime protection that extends MFA to protocols agents cannot reach, and directory resilience that lets you recover a forest cleanly, are different products solving different halves. If budget allows only one, choose the one matching the incident you would struggle most to survive. See [Silverfort vs Semperis](https://startwithidentity.com/compare/silverfort-vs-semperis/) and [ISPM](https://startwithidentity.com/glossary/ispm/) for the preventive posture side.

## Where to start

## Where to start

Browse [ITDR vendors](https://startwithidentity.com/vendors/itdr/) 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
Source: https://startwithidentity.com/guides/buyer-guides/how-to-choose-an-mfa-solution/
Last updated: 2026-08-29

Not all multi-factor authentication is equal. The goal in 2026 is **phishing-resistant** [MFA](https://startwithidentity.com/vendors/mfa/), not just any second factor.

## 1. Prioritize phishing resistance

SMS and basic OTP are better than nothing but are phishable and vulnerable to SIM swaps. Favor FIDO2 security keys and [passkeys](https://startwithidentity.com/guides/authentication/passkeys-101/), which resist phishing by design. Our [research](https://startwithidentity.com/research/) shows phishing-resistant MFA blocks the overwhelming majority of identity attacks.

## 2. Cover your whole estate

Modern web apps are easy. The hard parts are VPNs, legacy apps, desktop login, and [service accounts](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/). Confirm coverage where you actually need it.

## 3. Mind enrollment and recovery

Most real-world MFA bypasses target weak enrollment and account recovery, not the factor itself. Evaluate how a vendor handles onboarding and reset.

## 4. Fit your stack

If you already run a major [IAM](https://startwithidentity.com/vendors/iam/) platform, its built-in MFA may suffice. Standalone specialists shine for workforce passwordless and broad coverage.

## 5. Name the method class in your policy

A policy that says "require MFA" is satisfied by methods that commodity phishing kits defeat every day. The Mirage2FA campaign reached 4,532 organization domains between 2024 and 2026 without breaking a single factor: it captured the password and the resulting session cookie through legitimate Microsoft 365 login flows and rode the authenticated session.

Write policy against the property, not the acronym. [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.

## 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. Ask specifically about token binding or device-bound sessions, session revocation APIs, and continuous evaluation, because [token theft](https://startwithidentity.com/glossary/token-theft/) is now the dominant bypass rather than factor compromise.

## 7. Interrogate enrolment and recovery

Most real bypasses target enrolment and reset rather than the factor. The questions that matter:

- 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, and if so, what is the point of the strong factor?
- Can help desk staff reset a factor, and what verifies the caller? This is exactly the path [Scattered Spider](https://startwithidentity.com/breaches/scattered-spider-helpdesk-social-engineering/) uses.

## 8. Tier your authenticators

Synced [passkeys](https://startwithidentity.com/glossary/passkey/) are what 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. Choose a vendor that supports both classes and lets policy distinguish them. See [best phishing-resistant MFA](https://startwithidentity.com/rankings/best-phishing-resistant-mfa/).

## Where to start

## Where to start

Browse [MFA and passwordless vendors](https://startwithidentity.com/vendors/mfa/) and the [MFA implementation guide](https://startwithidentity.com/guides/authentication/mfa-implementation-best-practices/).

## 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-01-15

## What the demo will not tell you

CIAM demos show the polished happy path. They will not surface what matters at scale: pricing curves above 1M MAU, the data export experience, the operational cost of running custom auth flows, and how the vendor responds when something breaks in production 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.
2. **What is the data export format and how do I get my users out?** Test it on the trial account.
3. **What is the SLA, and what's the historical uptime?** Ask for the last 12 months of status page data.
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.
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.

## What to test in trial

- Performance under burst load (sign-in spikes at 9 AM)
- The recovery flow when an authenticator is lost
- The flow for a user whose email changed
- The behavior when MFA is misconfigured
- The audit log for a sequence of normal user actions

## Pricing reality

Per-MAU list pricing is rarely what enterprises pay. Negotiation matters. Get multiple bids. Push for caps on growth-stage pricing. Ask about "active" MAU definitions, they vary widely.

## 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/).

## 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-06-24

IAM hiring rewards people who can show, not just tell. The fastest way in is to build something real,
learn the protocols deeply, and present outcomes clearly. Here is a practical path, whether you are
switching from help desk, sysadmin, software, or general security.

## 1. Learn the core, deeply

You do not need every protocol, but you need the main ones cold:
[OAuth 2.0 and OIDC](https://startwithidentity.com/guides/fundamentals/oauth-vs-oidc/),
[SAML](https://startwithidentity.com/standards/saml-2-0/), and [SCIM](https://startwithidentity.com/standards/scim-2-0/) for provisioning. Understand the
difference between [authentication and authorization](https://startwithidentity.com/guides/fundamentals/authentication-vs-authorization/),
how [MFA and passwordless](https://startwithidentity.com/guides/fundamentals/what-is-passwordless/) work, and the basics of
[least privilege](https://startwithidentity.com/articles/least-privilege-access-best-practices/). Depth in a few topics reads as
competence; a shallow list of acronyms does not.

## 2. Build a portfolio you can demo

Hiring managers remember candidates who built things. With free tiers you can:

- Stand up an app with SSO via OIDC, then add MFA and passkeys. Our
  [recipes](https://startwithidentity.com/recipes/) walk through add-login, JWT validation, and SCIM step by step.
- Configure provisioning so creating a user in one system propagates to others via SCIM.
- Write a short note explaining the design decisions and trade-offs. The explanation is the part that
  signals real understanding.

Put it on GitHub with a clear README. A working demo plus a clear write-up is worth more than any
single line on a resume. Contributing to an open-source identity project counts too: our
[IAM interview questions repository](https://github.com/Start-With-Identity/iam-interview-questions)
welcomes contributions and credits every contributor by name, which doubles as a public track record.

## 3. Get one relevant certification

Certifications help most early on and for consulting or vendor-aligned roles. Choose by goal, a
vendor certification (Okta, Microsoft Entra, SailPoint, CyberArk) for platform fluency, or a broader
security credential for fundamentals. See
[identity security certifications](https://startwithidentity.com/guides/career/identity-security-certifications/) for which to
prioritize.

## 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." Name the protocols and platforms you
have used, quantify scale, and link your portfolio. Cut generic security filler.

## 5. 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 our
[IAM interview questions](https://startwithidentity.com/guides/career/iam-interview-questions/) guide and the full open-source
[interview questions bank](https://github.com/Start-With-Identity/iam-interview-questions).

## 6. Apply where identity roles actually are

Target IAM, IGA, PAM, CIAM, and identity security titles, and apply directly through employer
postings. Browse current openings on the [IAM jobs board](https://startwithidentity.com/jobs/), and if you want fully remote work,
read [remote IAM jobs](https://startwithidentity.com/guides/career/remote-iam-jobs/). For the wider arc of the field, see
[IAM career paths](https://startwithidentity.com/guides/career/iam-career-paths/).

## IAM Audit Preparation Guide: SOX, SOC 2, and HIPAA Readiness
Source: https://startwithidentity.com/guides/compliance/iam-audit-preparation-guide/
Last updated: 2026-06-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 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 authorization (164.312(a)(1)), implement technical policies to grant access only to authorized persons.
- 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. If your average termination-to-deprovisioning time is 3 days, auditors will flag it.

### 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 |
|---|---|---|---|
| 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 (10-25 samples)
│   └── 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 25 random terminated employees and verify all access was revoked timely.
- Pull 25 random access grants and verify approval documentation exists.
- Pull 10 random 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.

## Frequently Asked Questions

**Q: How many samples will auditors typically test?**
A: For SOX, the standard is 25 samples per control for daily/transaction-level controls, and 2-5 samples for quarterly controls. SOC 2 auditors typically test 25-30 samples. The exact number depends on the audit firm's methodology and the population size.

**Q: What if we cannot produce approval records for access granted years ago?**
A: Be transparent with auditors. Explain that your current request/approval workflow was implemented on a specific date and show that all grants after that date have documentation. For legacy access, show that it has been reviewed and certified through your access review process.

**Q: How quickly must terminated employees be deprovisioned?**
A: Most auditors expect same-day deprovisioning for standard terminations and immediate deprovisioning for involuntary terminations. If your average is more than 24 hours, expect scrutiny. If any termination took more than 72 hours, expect a finding.

**Q: Can we use screenshots as audit evidence?**
A: Screenshots are accepted but are less reliable than system-generated reports. Auditors may request live demonstrations to verify screenshots are current. Where possible, provide exported reports with timestamps and metadata that prove authenticity.

**Q: What is the difference between a SOC 2 Type I and Type II audit for IAM?**
A: Type I evaluates the design of controls at a point in time (are the right controls in place?). Type II evaluates the operating effectiveness of controls over a period (are the controls working consistently?). Type II is more demanding for IAM because you must demonstrate that processes like access reviews and deprovisioning operated consistently throughout the audit period, not just that they exist.

## IAM Career Paths: From Analyst to Identity Architect
Source: https://startwithidentity.com/guides/career/iam-career-paths/
Last updated: 2026-07-08

Identity and access management has grown from a back-office IT function into one of the most in-demand specialties in security. As identity became the primary attack surface, the people who understand it became scarce and well paid. This is a map of the common paths and how to move along them.

## Start here: the learning path

If you are new, work through the career hub in this 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 concrete skills and hands-on steps.
3. [Identity security certifications](https://startwithidentity.com/guides/career/identity-security-certifications/) to validate fundamentals and pass HR filters.
4. [IAM interview questions](https://startwithidentity.com/guides/career/iam-interview-questions/) to prepare, plus the open-source [IAM interview questions bank](https://github.com/Start-With-Identity/iam-interview-questions) for hundreds of practice questions.
5. [How to get an IAM job](https://startwithidentity.com/guides/career/how-to-get-an-iam-job/) for resume, portfolio, and applying.
6. [IAM salary guide](https://startwithidentity.com/guides/career/iam-salary-guide/) to benchmark and negotiate, and [remote IAM jobs](https://startwithidentity.com/guides/career/remote-iam-jobs/) if you want to work remotely.

New to the concepts themselves? Begin with the [start-here learning path](https://startwithidentity.com/start-here/) and the [fundamentals](https://startwithidentity.com/guides/fundamentals/what-is-iam/).

## Where people start

- **IAM analyst / administrator:** runs the day-to-day. Joiner-mover-leaver, access requests, group management, MFA support. The best on-ramp because you learn how identity actually behaves in production.
- **Help desk or sysadmin crossover:** many strong IAM people arrive from IT operations after owning Active Directory, [Entra](https://startwithidentity.com/vendors/iam/microsoft-entra/), or [Okta](https://startwithidentity.com/vendors/iam/okta/).
- **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/).

## The main tracks

- **Engineering track:** IAM engineer to senior to **identity architect**, who designs federation, authentication, and authorization across the enterprise. Deep protocol knowledge ([SAML](https://startwithidentity.com/standards/saml-2-0/), OIDC, [SCIM](https://startwithidentity.com/standards/scim-2-0/), [WebAuthn](https://startwithidentity.com/standards/webauthn-fido2/)) is the differentiator.
- **Governance track:** access reviews and [IGA](https://startwithidentity.com/guides/fundamentals/what-is-iga/) into governance lead and identity risk roles, heavy on audit and compliance.
- **Privileged and security track:** [PAM](https://startwithidentity.com/guides/fundamentals/what-is-pam/) and [ITDR](https://startwithidentity.com/guides/fundamentals/what-is-itdr/) into identity security engineering and detection.
- **Leadership track:** identity program manager, head of identity, and ultimately the CISO office, where identity is now a board-level topic.

## How to move up

Specialize in protocols and patterns, not just one vendor's console. Learn one platform deeply, then a second to break vendor lock-in in your own head. Get hands-on with [passwordless](https://startwithidentity.com/guides/fundamentals/what-is-passwordless/), Zero Trust, and the emerging [non-human and AI identity](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/) problems, which are where demand is growing fastest.

## 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/), and [interview questions](https://startwithidentity.com/guides/career/iam-interview-questions/).

## 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-03-31

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 Azure AD Connect (now Entra Connect) is 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. 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. Deploy Entra Connect (formerly Azure AD Connect) on a dedicated, domain-joined server. Do not install it on 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. Enable Smooth SSO so domain-joined devices authenticate to cloud resources without prompting for credentials.
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. Switch Entra Connect to cloud-authoritative mode. New users are now created in the cloud and synced down to on-premises AD (reverse of the current flow).
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.

## Frequently Asked Questions

**How long does a typical AD-to-cloud migration take?**
For a mid-size enterprise (1,000-10,000 users), plan for 12-18 months from assessment to cutover. Large enterprises (10,000+ users) with complex application portfolios typically need 18-24 months. The hybrid coexistence phase accounts for most of this time.

**Can I keep some applications on-premises AD permanently?**
Yes. Hybrid permanent is a valid end state for organizations with manufacturing systems, legacy applications, or regulatory requirements that prevent full cloud migration. The goal is to minimize the on-premises AD footprint, not necessarily eliminate it.

**What happens to on-premises file server permissions?**
File server permissions based on AD groups continue to work during hybrid coexistence (sync keeps groups updated). For the cutover, either migrate file shares to cloud storage (SharePoint, OneDrive) or deploy Entra ID Domain Services to provide AD-compatible authorization for on-premises file servers.

**How do I handle multi-forest environments?**
Entra Connect supports multi-forest sync using either a single sync server with multiple connectors or multiple sync servers (one per forest) syncing to a single Entra ID tenant. Consolidate forests where possible before migration to reduce complexity.

**What is the cost of cloud IAM vs. on-premises AD?**
On-premises AD has hidden costs: domain controller hardware, Windows Server licensing, backup infrastructure, patching labor, and ADFS maintenance. Cloud IAM has explicit per-user licensing costs (Entra ID P2 is approximately $9/user/month). For most organizations, the total cost is comparable, but operational overhead is significantly lower with cloud IAM.

**Should I migrate to Entra ID even if we do not use Azure for workloads?**
Entra ID works as a standalone identity platform regardless of where your workloads run. It integrates with AWS, GCP, SaaS applications, and on-premises resources. However, if your organization is heavily invested in Google Workspace or another ecosystem, evaluate their identity platform as the primary instead.

## IAM Disaster Recovery: Building Resilient Identity Infrastructure
Source: https://startwithidentity.com/guides/implementation/iam-disaster-recovery-guide/
Last updated: 2026-04-30

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:
- **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 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.
- **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.
- Use long, complex passwords (20+ characters) stored in a physical safe.
- Do not assign MFA (or use a FIDO2 key stored separately from the password).
- Exclude from all conditional access policies.
- Configure Azure Monitor alerts on any sign-in to these accounts.
- Test quarterly, verify the accounts can sign in and perform administrative actions.

**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.

## Frequently Asked Questions

**Q: Should we maintain a secondary IdP for failover?**
A: It depends on your risk tolerance and budget. A secondary IdP (e.g., on-premises ADFS as backup for Entra ID) provides true failover capability but adds significant complexity and cost. Most organizations rely on their cloud IdP's built-in HA and focus DR efforts on cached credential strategies and break-glass procedures.

**Q: How do we back up Entra ID / Okta configurations?**
A: Use the management APIs (Microsoft Graph, Okta Admin API) to export all configurations as JSON. Automate daily exports to a Git repository. Tools like Entra Exporter, AzureADConfigBackup, and Terraform can help. Treat identity configuration as code.

**Q: What is an acceptable RTO for identity services?**
A: For authentication and authorization services, target 5-15 minutes. Most organizations cannot tolerate longer because every connected application is affected. For non-critical identity functions (provisioning, reporting), 4-24 hours is typically acceptable.

**Q: How do we handle identity DR across multiple cloud providers?**
A: If you federate identity across AWS, Azure, and GCP, your IdP is the single point of failure for all three. Ensure your IdP's DR plan accounts for multi-cloud impact. Consider configuring each cloud provider's emergency access (AWS root account, GCP super admin) independently of your federated IdP.

**Q: Should break-glass accounts have MFA?**
A: This is debated. MFA on break-glass accounts adds security but risks locking you out during an MFA provider outage, which is exactly when you might need break-glass access. The common compromise is to use a hardware FIDO2 key stored in a physical safe, separate from the password, providing MFA without depending on a cloud MFA service.

## IAM Interview Questions: What Identity Roles Actually Test
Source: https://startwithidentity.com/guides/career/iam-interview-questions/
Last updated: 2026-07-08

Identity interviews probe whether you understand protocols, can reason about trade-offs, and know how identity fails in the real world. Memorizing definitions is not enough; you should be able to explain the why. Here are the themes that come up, with what a strong answer demonstrates.

> **Practice with the full question bank.** This page covers the themes. For hundreds of questions with model-answer notes, organized by topic and difficulty tier, 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.

## Protocol fundamentals

- **Explain the difference between authentication and authorization.** A strong answer is crisp and warns against the classic mistake of using an OAuth access token as proof of login. See [authentication vs authorization](https://startwithidentity.com/guides/fundamentals/authentication-vs-authorization/).
- **OAuth vs OIDC, and when you would use each.** Know that [OAuth is authorization, OIDC adds identity](https://startwithidentity.com/guides/fundamentals/oauth-vs-oidc/), and that the [authorization code flow with PKCE](https://startwithidentity.com/standards/oauth-2-1/) is the default.
- **SAML vs OIDC.** Know why enterprises still demand [SAML](https://startwithidentity.com/standards/saml-2-0/) and when OIDC is the better choice.
- **What is in a JWT, and how do you validate one?** Signature, issuer, audience, expiry, and key rotation via JWKS.

## Design and trade-offs

- **Design SSO and lifecycle for a 5,000-person company.** They want to hear SSO via OIDC/SAML, [SCIM](https://startwithidentity.com/standards/scim-2-0/) provisioning, MFA policy, and clean joiner-mover-leaver.
- **RBAC, ABAC, or ReBAC for a given app?** Reason from the access model, not the buzzword. See [RBAC vs ABAC vs ReBAC](https://startwithidentity.com/guides/fundamentals/rbac-vs-abac-vs-rebac/).
- **How would you roll out MFA without breaking the org?** Sequence, legacy apps, recovery. See the [MFA rollout playbook](https://startwithidentity.com/guides/authentication/mfa-rollout/).

## Security and incident reasoning

- **How do attackers defeat MFA?** Strong candidates cite [MFA fatigue](https://startwithidentity.com/breaches/mfa-fatigue-push-bombing/), [help-desk social engineering](https://startwithidentity.com/breaches/scattered-spider-helpdesk-social-engineering/), and [session/token theft](https://startwithidentity.com/breaches/infostealer-session-hijacking/), then explain phishing-resistant defenses.
- **Walk through a real identity breach.** Pick one from the [breach teardowns](https://startwithidentity.com/breaches/) and explain root cause and the control that would have stopped it.

## How to prepare

Build something, read the [standards](https://startwithidentity.com/standards/), study the [breaches](https://startwithidentity.com/breaches/), and practice explaining trade-offs out loud. Depth and clear reasoning win these interviews. Then drill systematically with the topic-organized [IAM Interview Questions repository](https://github.com/Start-With-Identity/iam-interview-questions), which tags every question Junior, Mid, or Senior so you can focus on your level.

## Your next step

Once you are interview-ready, 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 [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-06-24

IAM and identity security are among the better-paid specialties in security, because the work is
business-critical, increasingly regulated, and the experienced talent pool is small. This guide
gives broad 2026 pay ranges and, more usefully, explains what actually moves a number up.

A caveat first: salary depends heavily on region, company size and funding, industry, and your
specialty. The ranges below are broad US market estimates for 2026 and will differ elsewhere. Treat
them as orientation, not a quote, and benchmark any offer against your own market and cost of living.

## Typical 2026 US ranges (base salary)

- **IAM analyst / administrator:** ~75,000 to 110,000. Entry to the field, often access requests,
  joiner-mover-leaver, and ticket-driven work.
- **IAM engineer (mid):** ~110,000 to 150,000. Builds and runs SSO, MFA, provisioning, and
  integrations.
- **Senior IAM engineer:** ~150,000 to 200,000. Owns architecture decisions within a domain, leads
  projects, mentors.
- **Identity architect:** ~180,000 to 240,000+. Designs the identity fabric across the organization.
  See [IAM career paths](https://startwithidentity.com/guides/career/iam-career-paths/).
- **IAM / IGA manager:** ~170,000 to 230,000. People and program leadership.
- **Director of IAM / Head of Identity:** ~200,000 to 300,000+. Strategy, budget, and org ownership.
- **CISO (identity-heavy remit):** widely variable, often 250,000 to 450,000+ in total comp.

Total compensation, with bonus and equity, runs meaningfully above base at larger and venture-backed
companies. Consulting and vendor field roles trade some base for commission and travel.

## What moves IAM pay up

- **Specialty.** PAM, CIEM, and identity threat detection (ITDR) sit at the top because the risk is
  high and the experts are few. See [what is PAM](https://startwithidentity.com/guides/fundamentals/what-is-pam/) and
  [what is ITDR](https://startwithidentity.com/guides/fundamentals/what-is-itdr/).
- **Cloud and automation depth.** Engineers who can wire identity across AWS, Azure, and GCP and
  automate provisioning with code command more than those who only operate a console.
- **Scale and regulation.** Experience at large, regulated organizations (finance, healthcare,
  government) raises both the floor and the ceiling.
- **Architecture and outcomes.** Moving from running tools to designing systems, and being able to
  point to measurable results (audit findings closed, access reviews automated, breaches prevented),
  is the clearest path to the higher bands.

## How to use this in a negotiation

Anchor on your specialty and the scope of the role, not just the title. Bring evidence: what you
built, what it reduced or prevented, and which of the in-demand skills above you hold. If the base is
fixed, negotiate on bonus, equity, learning budget, or remote flexibility.

To grow into the higher bands, see [how to become an identity engineer](https://startwithidentity.com/guides/career/how-to-become-an-identity-engineer/),
[identity security certifications](https://startwithidentity.com/guides/career/identity-security-certifications/), and the current
[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-07-08

Certifications will not make you an identity engineer on their own, but the right ones validate fundamentals, satisfy HR filters, and structure your learning. Here is how the main options actually fit, vendor-neutral first.

## Vendor-neutral

- **IDPro CIDPRO (Certified Identity Professional):** the closest thing to a vendor-neutral identity certification, based on the IDPro Body of Knowledge. Best signal that you understand identity as a discipline, not one product.
- **CISSP / CISM:** broad security and security-management certifications. Not identity-specific, but widely required for senior and leadership roles, and identity is a major domain within them.

## Vendor certifications (deep, but tied to a platform)

- **Microsoft SC-300 (Identity and Access Administrator):** highly relevant given how many organizations run [Entra ID](https://startwithidentity.com/vendors/iam/microsoft-entra/). Strong, practical, and in demand.
- **Okta certifications** (Professional, Administrator, Consultant, Developer): valuable if you work in [Okta](https://startwithidentity.com/vendors/iam/okta/) shops, which are many.
- **SailPoint, CyberArk, Ping, Saviynt certifications:** worthwhile when you specialize in [governance](https://startwithidentity.com/vendors/iga/) or [privileged access](https://startwithidentity.com/vendors/pam/). CyberArk's Defender/Sentry track is well regarded in PAM-heavy enterprises.

## How to choose

- Early career: start with SC-300 or an Okta cert (whatever your employer runs) plus the IDPro Body of Knowledge to build breadth.
- Governance or privileged specialists: add SailPoint or CyberArk credentials.
- Aiming at leadership: CISSP or CISM carries weight with hiring committees.

Treat certifications as a complement to hands-on work and protocol depth, not a substitute. An engineer who can debug a broken [SAML](https://startwithidentity.com/standards/saml-2-0/) assertion or design [zero standing privileges](https://startwithidentity.com/guides/implementation/zero-standing-privileges-rollout/) beats a wall of logos.

## Your next step

With a certification in progress, prepare for interviews using 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 the wider arc, see [IAM career paths](https://startwithidentity.com/guides/career/iam-career-paths/).

## Identity Controls for DORA
Source: https://startwithidentity.com/guides/compliance/identity-controls-for-dora/
Last updated: 2026-08-29

The EU Digital Operational Resilience Act (DORA) applies to financial entities and their critical ICT providers, and it makes strong identity and access management an explicit operational-resilience requirement. It began to apply in January 2025.

## What DORA expects of identity

DORA's ICT risk-management requirements translate into concrete identity controls:

- **Strong authentication and access management** for ICT systems, with least privilege and segregation of duties.
- **[Privileged access](https://startwithidentity.com/vendors/pam/) controls**, since privileged accounts are the highest operational risk.
- **Logging and monitoring** that supports incident detection and reporting, with tight timelines.
- **Third-party (ICT provider) access governance**, because DORA extends scrutiny to your supply chain.

## What good looks like

- Phishing-resistant [MFA](https://startwithidentity.com/vendors/mfa/) for workforce and especially privileged access.
- [IGA](https://startwithidentity.com/vendors/iga/) for least privilege, segregation of duties, and evidenced access reviews.
- [PAM](https://startwithidentity.com/vendors/pam/) with session recording and [just-in-time](https://startwithidentity.com/guides/implementation/zero-standing-privileges-rollout/) elevation.
- [ITDR](https://startwithidentity.com/vendors/itdr/) feeding the monitoring and incident-reporting obligations.
- Governed, time-bound access for third-party providers, with full audit.

## Common pitfalls

- Treating DORA as a documentation exercise rather than implementing detection and response.
- Ignoring third-party and ICT-provider access, which DORA explicitly covers.
- Privileged access without monitoring, incompatible with the resilience and reporting expectations.

## Related

[Financial services vertical](https://startwithidentity.com/verticals/financial-services/), [insurance vertical](https://startwithidentity.com/verticals/insurance/). Vendors: [PAM](https://startwithidentity.com/vendors/pam/), [ITDR](https://startwithidentity.com/vendors/itdr/), [IGA](https://startwithidentity.com/vendors/iga/).

## 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 demonstrate it works under stress. For identity that translates into 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 within your reporting window.** DORA's initial notification timelines are tight, and an intrusion that authenticates normally produces no alert unless something watches identity behaviour specifically.
- **You can operate during degradation.** If your identity provider is unavailable, what happens? A tested break-glass path is an operational resilience control, not an IT convenience.

## Third-party ICT access is the exposure

DORA extends scrutiny to critical ICT providers, and vendor access is consistently the least governed path in a financial institution: standing accounts, shared credentials, and remote sessions nobody records.

Practical shape: time-bounded access granted through an approval workflow, session recording for anything touching production, an owner per provider, and an inventory you can produce on request. The August 2026 N-able compromise, where attackers used a management platform's own remote session capability to reach downstream customer networks, is the concrete version of this risk.

## Evidence to keep

Access review output with revocation rates, privileged session recordings, the MFA exemption list with review dates, third-party access grants and their expiry, and incident timelines showing detection to notification. See [access certification](https://startwithidentity.com/glossary/access-certification/) and [zero standing privileges](https://startwithidentity.com/glossary/zero-standing-privileges/).

## Where to start

## Identity Controls for HIPAA
Source: https://startwithidentity.com/guides/compliance/identity-controls-for-hipaa/
Last updated: 2026-08-29

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.

## 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. The August 2026 McKesson incident began with voice phishing against employees from a lookalike domain, yielded [Okta](https://startwithidentity.com/vendors/iam/okta/) credentials, and used the resulting single sign-on session to reach Salesforce and 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

## Identity Controls for ISO 27001
Source: https://startwithidentity.com/guides/compliance/identity-controls-for-iso-27001/
Last updated: 2026-08-29

ISO/IEC 27001 is the international standard for information security management. It does not prescribe products, but its Annex A controls lean heavily on identity, and auditors will expect you to show how access is granted, reviewed, and removed. This maps the identity-relevant controls to what you actually build.

## What ISO 27001 expects of identity

The 2022 revision groups controls into themes. The identity-relevant ones include access control, identity management, authentication information, and privileged access:

- **Access control (A.5.15):** a documented policy and least-privilege enforcement.
- **Identity management (A.5.16):** a managed lifecycle for every identity, human and [non-human](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/).
- **Authentication information (A.5.17):** secure handling of credentials, pushing toward MFA and [passwordless](https://startwithidentity.com/guides/fundamentals/what-is-passwordless/).
- **Access rights (A.5.18):** provisioning, review, and prompt removal, the [joiner-mover-leaver](https://startwithidentity.com/glossary/joiner-mover-leaver/) lifecycle.
- **Privileged access (A.8.2):** restricted, monitored, and time-bound.

## What good looks like

- SSO and [MFA](https://startwithidentity.com/vendors/mfa/) across in-scope systems, with phishing-resistant factors for privileged users.
- Automated provisioning and [deprovisioning](https://startwithidentity.com/glossary/deprovisioning/) via [SCIM](https://startwithidentity.com/standards/scim-2-0/), so leavers lose access promptly.
- Periodic [access reviews](https://startwithidentity.com/glossary/access-certification/) with evidence, typically through [IGA](https://startwithidentity.com/vendors/iga/).
- [PAM](https://startwithidentity.com/vendors/pam/) for privileged accounts with session logging.

## Common pitfalls

- Access reviews that happen but are not evidenced; auditors want the artifact.
- Orphaned and service accounts outside the lifecycle.
- Privileged access granted permanently rather than [just in time](https://startwithidentity.com/guides/implementation/zero-standing-privileges-rollout/).

## Related

[IAM audit preparation](https://startwithidentity.com/guides/compliance/iam-audit-preparation-guide/), [SOC 2 for identity](https://startwithidentity.com/guides/compliance/soc2-for-identity/). Vendors: [IGA](https://startwithidentity.com/vendors/iga/), [PAM](https://startwithidentity.com/vendors/pam/).

## Mapping identity to Annex A

The identity-relevant controls in the 2022 Annex A cluster tightly, and mapping them explicitly saves argument during certification:

- **A.5.15 Access control** and **A.5.18 Access rights**: policy, provisioning, review, and removal. This is where [access certification](https://startwithidentity.com/glossary/access-certification/) evidence lands.
- **A.5.16 Identity management**: unique identities, lifecycle, and the handling of non-human identities.
- **A.5.17 Authentication information**: credential issuance, [MFA](https://startwithidentity.com/glossary/mfa/), and secure recovery.
- **A.8.2 Privileged access rights**: allocation, review, and restriction of elevated access.
- **A.8.5 Secure authentication** and **A.8.15 Logging**: the technical implementation and its audit trail.

## What certification actually tests

Auditors test operation, not intent. The recurring findings in identity are predictable: access reviews completed but with no revocations, leavers removed from single sign-on while local and vendor accounts stayed live, privileged rights granted for a project and never withdrawn, and an MFA exemption list that has grown without review.

The corresponding 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 justification per entry.

## Where the ISMS scope bites

ISO 27001 lets you scope the ISMS, and identity systems have a way of straddling the boundary. If your 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 rather than during the audit, and treat the identity provider itself as tier-zero infrastructure. See [what is IGA](https://startwithidentity.com/guides/fundamentals/what-is-iga/) and [zero standing privileges](https://startwithidentity.com/glossary/zero-standing-privileges/).

## Where to start

## Identity Controls for NIS2
Source: https://startwithidentity.com/guides/compliance/identity-controls-for-nis2/
Last updated: 2026-08-29

The EU NIS2 Directive raises baseline cybersecurity obligations for essential and important entities across many sectors, and identity controls are central to its risk-management requirements. Member-state transposition has made these expectations enforceable, with management accountability attached.

## What NIS2 expects of identity

NIS2 requires appropriate technical and organizational measures, and the identity-relevant ones include:

- **Access control policies** and least privilege.
- **Multi-factor or continuous authentication** for relevant access.
- **Asset and identity management**, including [non-human identities](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/) in operational environments.
- **Supply-chain security**, which includes governing third-party and vendor access.

## What good looks like

- [MFA](https://startwithidentity.com/vendors/mfa/) across the workforce, with phishing-resistant factors for privileged and remote access.
- [PAM](https://startwithidentity.com/vendors/pam/) for operational-technology and IT privileged access, a priority in NIS2's industrial and infrastructure sectors.
- [IGA](https://startwithidentity.com/vendors/iga/) for least privilege, joiner-mover-leaver, and evidenced reviews.
- Governed third-party access and [ITDR](https://startwithidentity.com/vendors/itdr/) to detect identity-based attacks and meet reporting duties.

## Common pitfalls

- Assuming NIS2 is only for IT; its sectors include energy, manufacturing, transport, and more, where OT access is the gap.
- Unmanaged vendor and contractor access in scope of supply-chain requirements.
- No detection capability to support the incident-reporting timelines.

## Related

[Energy & utilities](https://startwithidentity.com/verticals/energy-utilities/) and [manufacturing](https://startwithidentity.com/verticals/manufacturing/) verticals. Vendors: [PAM](https://startwithidentity.com/vendors/pam/), [ITDR](https://startwithidentity.com/vendors/itdr/), [IGA](https://startwithidentity.com/vendors/iga/).

## 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/).
- **Third-party access inventory** with time-bounded grants and an owner per vendor.
- **Detection coverage** mapped to the incident-reporting timeline, since the 24-hour early warning 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 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.

## Where to start

## Identity Controls for PCI DSS
Source: https://startwithidentity.com/guides/compliance/identity-controls-for-pci-dss/
Last updated: 2026-08-29

PCI DSS governs how organizations that handle payment card data protect it, and several of its requirements are squarely about identity. PCI DSS 4.0 raised the bar on authentication in particular. This maps the identity-relevant requirements to practice.

## What PCI DSS expects of identity

- **Requirement 7:** restrict access to cardholder data by business need to know, with role-based access and least privilege.
- **Requirement 8:** identify and authenticate access. PCI DSS 4.0 expands MFA, requires it for all access into the cardholder data environment (CDE), and tightens password and credential rules.
- **Requirement 8.6:** application and system accounts (non-human identities) must be managed, with credentials protected and not hardcoded.

## What good looks like

- [MFA](https://startwithidentity.com/vendors/mfa/) for all access to the CDE, including administrative and remote access, ideally [phishing-resistant](https://startwithidentity.com/glossary/phishing-resistant-mfa/).
- Role-based access ([RBAC](https://startwithidentity.com/guides/fundamentals/rbac-vs-abac-vs-rebac/)) scoped tightly to the CDE, with documented business justification.
- [Secrets management](https://startwithidentity.com/guides/fundamentals/what-is-secrets-management/) for application and service accounts so credentials are vaulted and rotated, never hardcoded.
- [Privileged access](https://startwithidentity.com/vendors/pam/) controls with logging for anyone administering the environment.

## Common pitfalls

- Treating MFA as satisfied by a single factor plus a password reset question.
- Shared admin accounts into the CDE with no individual attribution.
- Hardcoded application credentials, a direct 8.6 failure and a real breach risk.

## Related

[IAM audit preparation](https://startwithidentity.com/guides/compliance/iam-audit-preparation-guide/). Vendors: [MFA](https://startwithidentity.com/vendors/mfa/), [secrets](https://startwithidentity.com/vendors/secrets/), [PAM](https://startwithidentity.com/vendors/pam/).

## Scoping is where identity programmes get this wrong

Under version 4.0 the MFA requirement extends to all access into the cardholder data environment, not just remote administrative access. That changes scope in ways teams underestimate: every account that can reach the environment counts, including [service accounts](https://startwithidentity.com/glossary/service-account/), vendor support logins, and application identities.

The exercise worth doing first is an inventory of everything that can authenticate into scope, not everything that has 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 answer is not an exemption, it is replacing the static credential with something the platform can attest. See [workload identity](https://startwithidentity.com/glossary/workload-identity/).

## What good looks like

- **Unique identification** for every user and every non-human account, with no shared credentials in scope.
- **[Phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/)** for administrative and remote access, ahead of the minimum, because relayable factors are defeated routinely.
- **Privileged access controls** with session recording for administrative work in the environment.
- **Quarterly review** of accounts with access to the environment, evidenced by revocations.
- **Rotation and ownership** for every application credential in scope, tested rather than documented.

## Retail and e-commerce specifics

For merchants the customer-facing side matters as much as the environment: [credential stuffing](https://startwithidentity.com/glossary/credential-stuffing/) against consumer accounts and [account takeover](https://startwithidentity.com/glossary/account-takeover/) drive fraud losses that sit outside the compliance boundary but inside the risk. 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

## Identity Federation Implementation Guide: Protocols, Trust, and Cross-Domain SSO
Source: https://startwithidentity.com/guides/authentication/identity-federation-implementation-guide/
Last updated: 2026-04-12

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 (Azure AD, 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 Azure AD 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:**

- 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:

- **Azure AD B2B Collaboration / Cross-tenant Access:** Automates trust configuration between Azure AD 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 (Ping Federate, 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 (typically 2-4 weeks). 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), validate InResponseTo/nonce, and implement token binding where supported.

**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.

## Frequently Asked Questions

**Can I federate between different IdP vendors?**
Yes. Federation protocols (SAML, OIDC) are interoperable by design. An Okta IdP can federate with an Azure AD SP, a Keycloak IdP can federate with a Ping Identity SP, and so on. The protocol provides the common language. Minor implementation differences exist, but metadata exchange handles the negotiation.

**How many federation partners can a single IdP support?**
There is no hard protocol limit. Enterprise IdPs routinely support hundreds of federation trusts. The practical limit is management overhead: each trust requires certificate monitoring, attribute mapping maintenance, and periodic access reviews. Use a federation gateway to manage large numbers of partners.

**What happens when a federation partner is compromised?**
Immediately disable the federation trust to stop new authentications. Disable all guest accounts associated with the partner. Review access logs for suspicious activity during the compromise window. Re-establish the trust only after the partner has remediated the incident and issued new signing certificates.

**Is SAML being replaced by OIDC?**
OIDC adoption is growing, particularly for modern and cloud-native applications. However, SAML remains dominant in enterprise federation because the installed base is massive and migration offers limited benefit for existing integrations. New implementations increasingly choose OIDC, but SAML will remain relevant for years. Plan to support both.

**How do I handle federation for users who belong to multiple partner organizations?**
This is the "multi-home" identity problem. The cleanest solution is to assign each user a primary identity domain and use that IdP for all federation. If a user truly needs to authenticate from multiple IdPs, implement account linking in the SP: the first authentication creates the account, subsequent authentications from other IdPs link to the existing account using a verified email address or other stable identifier.

## Identity Governance Program Guide: Building an Effective IGA Framework
Source: https://startwithidentity.com/guides/implementation/identity-governance-program-guide/
Last updated: 2026-05-06

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, Saviynt, One Identity, or similar IGA platform. 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 (target: 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.

## Frequently Asked Questions

**Q: How often should we run access certifications?**
A: Quarterly for high-risk and regulated applications, semi-annually for standard applications. Event-triggered certifications (role changes, extended leave returns) should supplement scheduled campaigns.

**Q: What is a reasonable certification campaign completion rate target?**
A: Target 95% on-time completion. Below 90% indicates either unrealistic scopes, poor reviewer engagement, or inadequate escalation. Escalate incomplete certifications to the reviewer's manager and ultimately to the governance committee.

**Q: How do we handle access that is revoked during certification but the user still needs it?**
A: The user should re-request the access through the standard request workflow. This ensures the new access grant has a fresh approval, current business justification, and SoD evaluation. This is governance working as designed.

**Q: Should we buy an IGA platform or build on our IdP's governance features?**
A: If your environment is predominantly one vendor ecosystem (e.g., all Microsoft), the IdP's built-in governance features (Entra ID Governance) may be sufficient. For multi-vendor, multi-platform environments with complex SoD requirements, a dedicated IGA platform (SailPoint, Saviynt) provides more complete capabilities.

**Q: How many SoD rules should we start with?**
A: Start with 10-20 rules focused on your highest-risk business processes (financial transactions, IT change management, data access). Quality matters more than quantity. Poorly defined rules generate false positives that erode trust in the program.

## Identity Threat Detection and Response (ITDR) Guide
Source: https://startwithidentity.com/guides/security/identity-threat-detection-response-guide/
Last updated: 2026-03-01

Identity is the most targeted attack vector. Over 80% of breaches involve compromised credentials, 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, Azure AD, 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, Azure AD, Okta, cloud IAM (AWS, GCP, Azure), VPN, PAM, RADIUS, and application authentication logs.
- **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, Microsoft Defender for Identity, Semperis) or a set of detection rules and playbooks built on your existing SIEM (Splunk, Sentinel, Chronicle).

## 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 for 2-4 weeks 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. Target under 5 minutes for critical detections.
6. **Mean time to respond (MTTR):** Measure how long it takes from alert to containment. 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.

## FAQs

**Q: Do I need a dedicated ITDR product or can I build on my existing SIEM?**
A: You can build effective ITDR on your existing SIEM (Splunk, Sentinel, Chronicle) using custom detection rules. Dedicated ITDR products (CrowdStrike Falcon Identity, Microsoft Defender for Identity) add pre-built detections, AD-specific sensors, and identity-focused analytics that accelerate deployment. The choice depends on your team's capacity and budget.

**Q: What are the highest-priority detection rules to deploy first?**
A: DCSync detection, Kerberoasting detection, password spray detection, privilege escalation (sensitive group changes), and impossible travel. These cover the most common and impactful identity attack techniques.

**Q: How do I handle the volume of identity events?**
A: Identity event volumes can be massive (millions per day in large enterprises). Use event filtering at the source to forward only security-relevant events. Use tiered storage (hot for 30 days, warm for 1 year) to manage costs while retaining forensic data.

**Q: Should automated response disable accounts without human approval?**
A: For high-confidence, high-severity detections (DCSync from a non-DC, Golden Ticket), yes, the risk of not acting immediately exceeds the risk of a false positive. For medium-confidence detections, require human approval within a time-bounded SLA.

**Q: How does ITDR relate to XDR?**
A: ITDR is a specialized capability that can operate standalone or as a component of an XDR (Extended Detection and Response) platform. XDR correlates signals across endpoint, network, email, and identity. ITDR provides the identity-specific depth that generic XDR may lack.

## Identity-first architecture: principles that hold up at scale
Source: https://startwithidentity.com/guides/architecture/identity-first-architecture/
Last updated: 2026-07-16

The network perimeter dissolved, and identity is what remains as the reliable control point across clouds, devices, and remote work. Identity-first architecture takes that reality seriously: it treats identity as the primary decision point for access, not a layer bolted behind a firewall. These seven principles repeatedly separate architectures that scale from architectures that get redesigned at every order of magnitude. For the strategy view that frames why this matters, see [identity-first security strategy](https://startwithidentity.com/articles/identity-first-security-strategy/).

## 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 and federate them at the point of the access decision.

## Principle 2: Authentication and authorization are separate concerns

Conflating them produces brittle policy. [Authentication](https://startwithidentity.com/guides/fundamentals/authentication-vs-authorization/) answers "who is this?" Authorization answers "what can they do here?" Make them different services, and different teams where you can afford it, so each can change without destabilizing the other.

## Principle 3: Short-lived credentials by default

Long-lived API keys, service-account passwords, and 90-day rotating secrets are the leading cause of credential incidents. Issue short-lived credentials, valid for minutes rather than months, from a central authority. [Workload identity](https://startwithidentity.com/guides/fundamentals/what-is-machine-identity/) via SPIFFE or cloud-native equivalents is the modern baseline, and it removes the standing secret an attacker most wants to find.

## Principle 4: Risk signals at every decision point

Static role assignments lose context the moment they are granted. Feed risk signals, device posture, location, behavior, and time of day into every meaningful access decision. The identity provider is one source of signal, not the whole picture, and the [authorization service](https://startwithidentity.com/guides/fundamentals/rbac-vs-abac-vs-rebac/) should be able to consume more than a role name.

## Principle 5: Audit logs are first-class

Every identity-affecting event must produce a structured audit log entry. The compliance assessor needs them, the security operations team needs them to investigate, and enterprise customers need them for their own audits. Build for that requirement from the first commit, because retrofitting complete audit coverage is far harder than emitting it as you go.

## Principle 6: Recover gracefully

The hard part of identity is the failure modes: lost devices, departed admins, compromised credentials. Design recovery flows before you design the happy path, because attackers target recovery precisely because it is usually the weakest and last-designed part of the system.

## Principle 7: Federate, don't replicate

If you find yourself copying user data from one system to another, you are building a synchronization problem you will regret. Federate to the source of truth wherever you can, and treat replication as a deliberate exception with an owner, not a default.

## A reference shape for the access path

These principles converge on a common shape. A request carries an identity assertion from an identity provider; a policy decision point evaluates that identity plus live context signals against policy; a policy enforcement point at the resource allows or denies; and every step emits an audit event. Authentication issues the assertion, authorization renders the decision, and short-lived credentials carry it, so no component holds a standing secret longer than it needs. This is the enforcement backbone that a [zero-trust](https://startwithidentity.com/guides/fundamentals/what-is-zero-trust/) program depends on.

## Where these principles came from

These patterns recur across identity architectures in financial services, healthcare, retail, and SaaS. They are not the only way to build, but each one 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-05-18

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, 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.

## Frequently Asked Questions

**Q: Is ABAC harder to audit than RBAC?**
A: It can be, because access is determined dynamically rather than through static role assignments. Compensate by logging every authorization decision with the full input (subject, action, resource, environment attributes) and the policy that produced the decision. This audit trail is actually richer than RBAC audit logs.

**Q: Can ABAC work with legacy applications?**
A: Yes, but the PEP placement differs. For legacy applications that cannot be modified, enforce ABAC at the network layer (API gateway, reverse proxy) or through a data access layer. For applications that can be modified, embed the PEP directly.

**Q: How do we handle ABAC when the policy engine is down?**
A: Define a fail-closed or fail-open strategy per resource type. Security-critical resources should fail closed (deny access). User-facing non-critical resources might fail open with logging. Always deploy the policy engine with high availability (multiple replicas, health checks, circuit breakers).

**Q: What is the relationship between ABAC and Zero Trust?**
A: ABAC is a core enabler of Zero Trust. Zero Trust requires continuous verification based on context, exactly what ABAC provides. Every access decision in a Zero Trust architecture should evaluate user identity, device health, network location, and resource sensitivity, which is ABAC by definition.

**Q: How many attributes is too many in a single policy?**
A: There is no hard limit, but policies with more than 5-7 attribute conditions become difficult to understand and test. If a policy requires many conditions, consider decomposing it into smaller, composable policies.

## Implementing Passkeys in the Enterprise
Source: https://startwithidentity.com/guides/authentication/implementing-passkeys-enterprise/
Last updated: 2026-02-18

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/)) added this support in 2023-2024.
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
  const approvedAAGUIDs = [
    "2fc0579f-8113-47ea-b116-bb5a8db9202a",  // YubiKey 5 NFC
    "fa2b99dc-9e39-4257-8f92-4a30d23c4118",  // YubiKey 5 USB-A
    "cb69481e-8ff7-4039-93ec-0a2729a154a8",  // YubiKey 5 USB-C
    // Add other approved AAGUIDs
  ];

  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 may break with firmware updates that change the AAGUID. Use it 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):**
```xml
<!-- Require Touch ID enrollment -->
<key>RequireTouchID</key>
<true/>

<!-- Allow iCloud Keychain passkey sync (for general workforce) -->
<key>AllowCloudKeychainSync</key>
<true/>

<!-- Minimum firmware version for secure enclave support -->
<key>MinimumOSVersion</key>
<string>14.0</string>
```

**Windows (Intune):**
```json
{
  "windowsHelloForBusiness": {
    "state": "enabled",
    "pinMinimumLength": 6,
    "biometricsAllowed": true,
    "enhancedSignInSecurity": true,
    "useSecurityKeys": true
  }
}
```

**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 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. 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.

## FAQs

**Q: Can passkeys completely replace passwords today?**
A: For most users, yes. The main exceptions are shared workstations without security key support, legacy applications that cannot integrate with the IdP, and edge cases where no biometric hardware is available. Plan for 90-95% coverage at enforcement, with exceptions managed on a case-by-case basis.

**Q: What happens to passkeys when an employee leaves?**
A: Disable the employee's IdP account. The passkeys become useless because they are bound to your domain (RP ID). The ex-employee may still have the credentials on their device, but they cannot use them to authenticate since the IdP rejects the account.

**Q: Are passkeys compliant with regulations (SOX, HIPAA, PCI-DSS)?**
A: Yes. Passkeys meet or exceed the authentication requirements of all major compliance frameworks. FIDO2/WebAuthn is recommended by NIST (SP 800-63B AAL2 and AAL3), and the phishing resistance it provides often exceeds what auditors expect.

**Q: How do passkeys work on shared devices (kiosks, conference rooms)?**
A: Use hardware security keys ([YubiKey](https://startwithidentity.com/vendors/mfa/yubico/), Feitian) that users carry with them and badge into the shared device. Alternatively, use the cross-device authentication flow where the user scans a QR code on the shared device's screen with their phone.

**Q: Should I use attestation?**
A: For general workforce, no, it adds complexity without proportional benefit. For privileged users in regulated environments, yes, it ensures only approved hardware authenticators are registered.

## Implementing Privileged Access Management: Architecture, Vaulting, and JIT Access
Source: https://startwithidentity.com/guides/architecture/implementing-privileged-access-management/
Last updated: 2026-04-06

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. Despite representing less than 1% of total user accounts, privileged identities are involved in an estimated 80% of security breaches.

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, Azure AD, 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 (CyberArk, Delinea, BeyondTrust, HashiCorp Vault) implement the vault as a dedicated appliance or clustered service with its own encryption key hierarchy, tamper detection, and audit logging.

### 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:**

- **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; a typical 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:** A mid-size enterprise with 500 daily privileged sessions generates approximately 2-5 TB of recording data per month. Plan retention based on compliance requirements, most frameworks require 1-3 years. 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.

**Azure AD Privileged Identity Management (PIM)** provides native JIT for Azure AD roles. CyberArk, 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. 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.

## Frequently Asked Questions

**How long does a PAM implementation typically take?**
A realistic timeline for an enterprise PAM deployment is 6-12 months. Initial deployment and Tier 0 account onboarding takes 2-3 months. Extending to Tier 1 and Tier 2 accounts adds another 3-6 months. Full maturity, including JIT access and complete session recording, typically takes 9-12 months.

**What is the difference between PAM and PIM?**
Privileged Access Management (PAM) focuses on securing and managing how privileged credentials are stored, accessed, and used. Privileged Identity Management (PIM), particularly as used by Microsoft in Azure AD PIM, focuses on just-in-time role activation for privileged directory roles. In practice, a complete privileged access strategy requires both credential vaulting (PAM) and role-based JIT activation (PIM).

**Can PAM work in a fully cloud-native environment?**
Yes. Modern PAM platforms support cloud-native deployments and can manage privileged access to AWS, Azure, GCP, and SaaS applications. Cloud-native PAM often uses API-based credential rotation rather than agent-based approaches, and it integrates with cloud provider IAM services for JIT role assumption.

**How do you handle PAM for DevOps and CI/CD pipelines?**
DevOps pipelines need privileged credentials (deploy keys, API tokens, database passwords) but cannot go through interactive approval workflows. Use the PAM platform's API to programmatically check out credentials at pipeline runtime, with short TTLs and automatic rotation after use. HashiCorp Vault and CyberArk Conjur are purpose-built for this use case.

**What compliance frameworks require PAM?**
Most major compliance frameworks either require or strongly recommend PAM controls: PCI DSS (Requirement 7 and 8), SOX (IT general controls), HIPAA (access controls for ePHI), NIST 800-53 (AC-6 Least Privilege), ISO 27001 (A.9 Access Control), and SOC 2 (CC6.1 Logical Access). Auditors increasingly expect dedicated PAM tooling rather than manual privileged account management.

**How do you measure PAM program success?**
Key metrics include: percentage of privileged accounts vaulted (target: 100% for Tier 0 and Tier 1), average time to rotate credentials after use, percentage of privileged sessions recorded, number of standing privileged access grants (target: approaching zero), mean time to provision emergency access via break-glass, and number of PAM policy violations detected and remediated.

## Implementing RBAC in the Enterprise
Source: https://startwithidentity.com/guides/authorization/implementing-rbac-enterprise/
Last updated: 2026-03-19

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, Azure AD, SailPoint, 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. A healthy ratio is 1:10 to 1:20 (one role for every 10-20 users). If the ratio 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:  # More than 1 role per 3 users
        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 20-30 business roles for a 5,000-person organization and add more only when justified.
- **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.

## FAQs

**Q: How many roles should I have?**
A: For a 5,000-person organization, 20-50 business roles and 100-200 technical roles is a healthy range. The exact number depends on the diversity of job functions and the number of applications. Track the role-to-user ratio and aim for 1:10 to 1:20 for business roles.

**Q: Should I use RBAC or ABAC?**
A: Use RBAC for coarse-grained, relatively static access (which applications a user can access). Use ABAC for fine-grained, context-dependent access (which records within an application a user can see, based on department, location, or project). Most enterprises need both.

**Q: How do I handle exceptions to roles?**
A: Allow direct permission grants for exceptions, but track them separately. If the same exception is granted to more than 5 users, it should be incorporated into a role. Review exceptions quarterly and reduce them over time.

**Q: What about temporary access?**
A: Implement time-limited role assignments. The user requests a role for a specific duration (e.g., 7 days for a project), the request is approved, and the role is automatically removed at expiry. This is especially important for privileged roles.

**Q: How do I migrate from a legacy permission model to RBAC?**
A: Start with role mining to understand current access patterns. Define roles based on clusters of common access. Assign users to roles that match their current access (no disruption). Then gradually tighten roles by removing unused permissions over 2-3 certification cycles.

**Q: How does RBAC relate to zero trust?**
A: RBAC defines what access a user is authorized for. Zero trust adds continuous verification of identity, device, and context before granting that access. They are complementary: RBAC provides the authorization model, zero trust provides the enforcement model.

## 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-05-12

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** (v1.27+), Managed (EKS, AKS, GKE) or self-managed.
- **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, AWS Secrets Manager, 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

Kubernetes Secrets are base64-encoded, not encrypted at rest by default. 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, enable the cloud provider's KMS integration (AWS KMS, Azure Key Vault, GCP 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 enforces read-only root filesystems.

## 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 tools like kube-hunter or kube-bench to identify RBAC misconfigurations and service account vulnerabilities.

## 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.

## Frequently Asked Questions

**Q: Should we use RBAC or ABAC in Kubernetes?**
A: RBAC. ABAC is a legacy authorization mode that requires API server restarts to update policies. RBAC is dynamic, auditable, and the standard for Kubernetes authorization.

**Q: How do we manage RBAC at scale across many clusters?**
A: Use GitOps tools (Flux, ArgoCD) to manage RBAC manifests as code across clusters. For policy enforcement, use tools like OPA Gatekeeper or Kyverno to enforce RBAC standards.

**Q: Can pods assume different cloud IAM roles dynamically?**
A: With workload identity federation, a pod assumes the cloud IAM role mapped to its Kubernetes service account. To change roles, you would need different service accounts or pods. Dynamic role assumption within a single pod is not the standard pattern.

**Q: How do we handle third-party operators that need cluster-wide access?**
A: Review the operator's RBAC requirements carefully. Many operators request more permissions than they need. Create custom ClusterRoles with the minimum required permissions and bind them to the operator's service account. Monitor the operator's API calls to verify it uses only what it needs.

**Q: Is there an equivalent to AWS IAM policies for Kubernetes?**
A: Kubernetes RBAC is the equivalent. For more complex policy needs (ABAC-like conditions, resource-level constraints), use admission controllers like OPA Gatekeeper, which allows Rego-based policies that can evaluate request attributes, resource labels, and annotations.

## Machine Identity Management Guide
Source: https://startwithidentity.com/guides/machine-identity/machine-identity-management-guide/
Last updated: 2026-02-24

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. Gartner estimates that machine identities outnumber human identities by a factor of 45:1 in typical enterprises, and that ratio is growing.

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, AWS Secrets Manager, Azure Key Vault, 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 is the emerging standard for 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.

## FAQs

**Q: How do I start if I have no machine identity inventory?**
A: Begin with discovery. Scan your network for certificates, query Active Directory for service accounts, audit cloud IAM for service principals, and run a secrets scanner across your code repositories. Build the inventory incrementally.

**Q: Should I use a separate vault for each environment?**
A: Yes. Production, staging, and development should have separate vault instances (or at minimum separate namespaces with strict access controls). This prevents development credentials from accidentally being used in production and limits blast radius.

**Q: How often should API keys be rotated?**
A: At minimum every 90 days. For high-sensitivity integrations, rotate every 30 days. If possible, use dynamic credentials (OAuth client credentials with short-lived tokens) instead of static API keys.

**Q: What is SPIFFE and do I need it?**
A: SPIFFE is a standard for workload identity that assigns each service a cryptographic identity. You need it if you run microservices and want to authenticate service-to-service communication without managing individual certificates. It is especially valuable in Kubernetes environments.

**Q: How do I handle machine identities in hybrid environments?**
A: Use a secrets vault that spans both on-premises and cloud (HashiCorp Vault with multi-datacenter replication). For authentication, use SPIFFE for cross-environment workload identity or OAuth 2.0 client credentials for API-based integration.

**Q: What is the cost of machine identity management?**
A: Secrets management platforms range from free (HashiCorp Vault open source) to $50K+/year for enterprise features. Cloud-native managed identities are free. The biggest cost is the engineering effort to migrate from static credentials to dynamic ones, which is a one-time investment that pays off in reduced breach risk and operational overhead.

## MFA Implementation Best Practices
Source: https://startwithidentity.com/guides/authentication/mfa-implementation-best-practices/
Last updated: 2026-02-05

Multi-factor authentication (MFA) remains the single most effective control against account compromise. Microsoft reports that MFA blocks 99.9% of automated credential attacks. 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. 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. Implement token binding, 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.

## FAQs

**Q: Should I disable password-only login immediately?**
A: Require MFA enforcement as quickly as feasible, but give users a grace period (7-14 days) to enroll. Abrupt enforcement without warning leads to mass lockouts and help-desk overload.

**Q: Is TOTP still acceptable for enterprise use?**
A: TOTP is acceptable for Tier 1 (standard) users as a transitional method, but it is not phishing-resistant. Plan to migrate to FIDO2-based methods over 12-18 months.

**Q: How many security keys should I buy per user?**
A: Two per user, one primary and one backup. Store the backup in a secure location (safe, locked drawer). For high-privilege users, consider three: one on their person, one at home, one in a company safe.

**Q: What about biometric-only MFA (no password)?**
A: Biometric authentication through a platform authenticator (Touch ID, Windows Hello) is excellent and counts as two factors (possession of the device + inherence of the biometric). This is the passwordless MFA model.

**Q: How do I handle MFA for APIs and service accounts?**
A: Interactive MFA does not apply to APIs. Protect API access with OAuth 2.0 client credentials, mTLS, or managed identities. Rotate secrets regularly and monitor for anomalous usage.

**Q: What is the cost of MFA?**
A: TOTP apps are free. Push notification services are typically included in IdP licensing ($3-8/user/month). FIDO2 security keys cost $25-70 per key. Platform authenticators (passkeys) are free on modern devices.

## MFA rollout: a practical sequence that doesn't break the org
Source: https://startwithidentity.com/guides/authentication/mfa-rollout/
Last updated: 2026-06-17

## Problem statement

Every breach report says MFA would have prevented this, and the data backs it up: Microsoft reports phishing-resistant MFA blocks over 99% of identity 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. Worse, not all MFA is equal. 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 not just MFA, it is [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/) everywhere it matters.

## A sequence that works

1. **Inventory.** Every app that touches sensitive data. Tag each with MFA capability (native, via IdP federation, or none).
2. **Phase 1, admin accounts only.** Enforce phishing-resistant MFA (FIDO2 hardware keys or [passkeys](https://startwithidentity.com/guides/authentication/passkeys-101/)) on every admin. Two weeks, no exceptions. 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.
5. **Phase 4, phishing-resistant for everyone.** Move the general population from push to FIDO2 and passkeys over the following year, 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.

## 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.
- 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. Compare options in [MFA and passwordless vendors](https://startwithidentity.com/vendors/mfa/) 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.
- Executive exceptions that creep across the org chart.
- 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 on phishing-resistant MFA. Percent of apps 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-06-17

## Why migrate off AD FS

Active Directory Federation Services did its job for a decade, but running your own federation servers now means patching, certificate management, capacity planning, and a single on-prem dependency in the critical login path. Moving federation to [Microsoft Entra ID](https://startwithidentity.com/vendors/iam/microsoft-entra/) removes that operational burden and enables modern controls: Conditional Access, Identity Protection risk signals, [passwordless](https://startwithidentity.com/guides/fundamentals/what-is-passwordless/) and [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/), and a cloud-scale federation endpoint you do not operate.

## Before you start

- Inventory every AD FS relying party (the applications federated through it) and how each authenticates ([SAML](https://startwithidentity.com/standards/saml-2-0/), [WS-Fed](https://startwithidentity.com/glossary/federation/), or [OIDC](https://startwithidentity.com/standards/openid-connect/)).
- Confirm Entra Connect is syncing identities and decide your authentication method: password hash sync (simplest and resilient), pass-through authentication, or federation. For most organizations, password hash sync plus Conditional Access is the target.
- Baseline current sign-in volume and any custom claim rules, which are the part that takes real work to reproduce.

## The migration sequence

1. **Stand up the foundation.** Entra Connect healthy, Conditional Access policies authored and tested in report-only mode, MFA registration campaign underway.
2. **Use the migration tooling.** Microsoft provides an AD FS application activity report and a migration experience that flags which relying parties are ready to move. Start with the simple, standards-based apps.
3. **Migrate app by app.** Re-point each relying party from AD FS to Entra, reproduce its claim mapping, and test with a pilot group before cutover. Keep AD FS authoritative until each app is verified.
4. **Move authentication off federation.** Convert the domain from federated to managed (password hash sync) so logins no longer depend on AD FS.
5. **Decommission AD FS.** Only after every relying party is migrated and sign-in logs confirm AD FS is idle. Keep it powered but unused for a grace period, then retire.

## Claim rules and the long tail

The hard part is rarely the common apps; it is the handful with custom AD FS claim rules. Translate these to Entra claims mapping policies, and be prepared to update a few apps that hardcoded AD FS endpoints. Budget time for this tail rather than assuming a clean lift.

## Common pitfalls

- Cutting over authentication before all relying parties are migrated, breaking logins.
- Forgetting certificate and endpoint references hardcoded in older applications.
- Not running Conditional Access in report-only mode first, then surprising users at cutover.
- Decommissioning AD FS before confirming, via sign-in logs, that nothing still uses it.

## Related

Guide: [IAM cloud migration](https://startwithidentity.com/guides/implementation/iam-cloud-migration-guide/), [conditional access policies](https://startwithidentity.com/guides/implementation/conditional-access-policies-guide/). Vendor: [Microsoft Entra ID](https://startwithidentity.com/vendors/iam/microsoft-entra/). Standards: [SAML 2.0](https://startwithidentity.com/standards/saml-2-0/), [OpenID Connect](https://startwithidentity.com/standards/openid-connect/).

## 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-06-23

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, 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.

## Frequently Asked Questions

**Q: Should we use a single IdP or cloud-native identity for each provider?**
A: Use a single IdP for human identity, federated into each cloud. This provides consistent MFA, lifecycle management, and governance. For workload identity, use each cloud's native mechanisms (IAM roles, managed identities, service accounts) with workload identity federation for cross-cloud access.

**Q: How do we handle acquisitions that bring a new cloud provider?**
A: Federate the new cloud provider into your existing hub IdP. Map the acquired company's roles to your organizational permission model. Run a parallel period where both the old and new IAM configurations are active, then sunset the acquired company's independent identity setup.

**Q: What about cloud providers that do not support SAML or OIDC?**
A: Most modern cloud and SaaS providers support at least SAML 2.0. For providers that only support API keys or basic authentication, use a secrets management vault as an intermediary and implement your own access governance layer around credential issuance.

**Q: How do we audit access across all clouds?**
A: Aggregate audit logs from all clouds into a single SIEM. Create standardized reports that show who accessed what, in which cloud, and when. Use your IGA platform for access certification campaigns that span all clouds.

**Q: Is it realistic to manage all cloud IAM through IaC?**
A: For planned, steady-state IAM configurations, yes. IaC should be the standard path for all IAM changes. However, you need emergency/break-glass processes for urgent changes, with a reconciliation process that brings manual changes back into IaC afterwards.

## Non-Human Identity (NHI) Security: The 2026 Guide
Source: https://startwithidentity.com/guides/machine-identity/non-human-identity-security/
Last updated: 2026-06-30

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. CyberArk reports machine identities outnumber people by more than 80 to 1, and cloud-native estimates run higher still. 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.

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-02-12

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, Azure AD), 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.

**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.

### Step 6: Protect the Resource Server

The resource server must validate the access token on every request:

```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 introspection endpoint (`/introspect`) 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.

## FAQs

**Q: Is the implicit flow still acceptable?**
A: No. The OAuth 2.0 Security Best Current Practice (RFC 9700) recommends against the implicit flow. Use the authorization code flow with PKCE for all clients, including SPAs.

**Q: Should I use opaque or JWT access tokens?**
A: JWT access tokens enable local validation at the resource server, reducing latency. Opaque tokens require introspection but allow immediate revocation. For most architectures, JWT access tokens with short lifetimes (5-15 minutes) strike the right balance.

**Q: How do I handle token storage in an SPA?**
A: The safest approach is the Backend-for-Frontend (BFF) pattern: the SPA communicates with a backend proxy that handles token exchange and stores tokens in an HTTP-only, secure, SameSite cookie. Storing tokens in localStorage or sessionStorage exposes them to XSS attacks.

**Q: Can I use OAuth 2.0 for authentication?**
A: OAuth 2.0 alone is an authorization protocol and should not be used for authentication. Use OIDC, which adds the ID token and standardized identity claims on top of OAuth 2.0.

**Q: How do I handle multi-tenant APIs?**
A: Include the tenant identifier in the scope or audience claim. The resource server should validate that the token's tenant matches the requested resource's tenant. Consider using separate authorization server instances per tenant for strong isolation.

**Q: What is the Backend-for-Frontend (BFF) pattern?**
A: The BFF is a lightweight backend server that acts as a confidential OAuth client on behalf of the SPA. The SPA authenticates to the BFF using session cookies, and the BFF handles all token exchange with the authorization server. This keeps tokens out of the browser entirely.

## OAuth 2.0 vs OpenID Connect: What's the Difference?
Source: https://startwithidentity.com/guides/fundamentals/oauth-vs-oidc/
Last updated: 2026-08-29

OAuth 2.0 and OpenID Connect are constantly confused, and using the wrong one creates real security holes. The short version: **OAuth is for authorization, OIDC is for authentication.**

## OAuth 2.0 is about access, not identity

OAuth 2.0 lets an application get **delegated access** to resources on a user's behalf, for example "let this app read my calendar." It issues access tokens scoped to permissions. Crucially, OAuth was never designed to tell you **who the user is**, and using an access token as proof of login is a classic mistake.

## OpenID Connect adds identity

OIDC is a thin layer on top of OAuth 2.0 that adds an **ID token** (a signed JWT) describing the authenticated user and a standard userinfo endpoint. When you need to log a user in, you want OIDC.

## A simple rule

- "Log this user in" → **OIDC**.
- "Let this app act on the user's resources" → **OAuth 2.0**.
- Securing machine-to-machine or AI agents? See [non-human identity](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/) and our [authorization](https://startwithidentity.com/vendors/authorization/) category.

## Why the confusion causes real bugs

Two failure modes account for most of the damage:

**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](https://startwithidentity.com/glossary/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, meant to be validated once at sign-in. Resource servers should receive [access tokens](https://startwithidentity.com/glossary/access-token/). Sending an ID token to an API usually means the API is validating the wrong audience, or not validating at all.

## 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](https://startwithidentity.com/glossary/pkce/) for every client**, confidential ones included. There is no reason to omit it in new code.
- **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.
- **Rotate [refresh tokens](https://startwithidentity.com/glossary/refresh-token/) on use** and detect reuse of a spent token, which is the signal that a copy is circulating.

## Where OAuth is heading

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. The 2026 work on AI agent authorization builds on the same machinery, with [token exchange](https://startwithidentity.com/glossary/token-exchange/) narrowing scope at each hop in a delegation chain.

## Where to start

## Where to start

Read the [OAuth 2.0 and OIDC implementation guide](https://startwithidentity.com/guides/implementation/oauth-2-openid-connect-implementation/), and the related [SAML vs OIDC](https://startwithidentity.com/guides/fundamentals/saml-vs-oidc/) comparison.

## Passkeys 101: What they are and when to ship them
Source: https://startwithidentity.com/guides/authentication/passkeys-101/
Last updated: 2026-08-29

## 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. Unit 42 recovered synced private keys from Chrome's Google Password Manager on Windows by extracting the Security Domain Secret from process memory, and there is no rotation mechanism for that secret. Every published attack started from malware already on the endpoint, 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.
- **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 shipped multiple passkeys per account in August 2026 for exactly this reason.
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-01-30

Passwords are the oldest and weakest link in authentication. They are phishable, reusable, guessable, and expensive to manage. The average enterprise spends 30-50% of its help-desk budget on password resets. 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, Azure AD, 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).
- **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, SoloKey):
- 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)

```javascript
// Registration endpoint
app.post('/api/webauthn/register/begin', async (req, res) => {
  const user = await getAuthenticatedUser(req);

  const challenge = generateSecureRandom(32);
  await storeChallenge(user.id, challenge);  // Store in session or cache with TTL

  const options = {
    rp: { name: "Your Company", id: "yourcompany.com" },
    user: {
      id: Buffer.from(user.id),
      name: user.email,
      displayName: user.name
    },
    challenge: challenge,
    pubKeyCredParams: [
      { type: "public-key", alg: -7 },
      { type: "public-key", alg: -257 }
    ],
    authenticatorSelection: {
      residentKey: "required",
      userVerification: "required"
    },
    timeout: 60000,
    attestation: "none",
    excludeCredentials: await getUserCredentials(user.id)  // Prevent duplicate registration
  };

  res.json(options);
});

app.post('/api/webauthn/register/complete', async (req, res) => {
  const user = await getAuthenticatedUser(req);
  const { credential } = req.body;
  const expectedChallenge = await getStoredChallenge(user.id);

  // Verify the registration response
  const verification = await verifyRegistration({
    response: credential,
    expectedChallenge,
    expectedOrigin: "https://yourcompany.com",
    expectedRPID: "yourcompany.com"
  });

  if (verification.verified) {
    // Store the credential
    await storeCredential({
      userId: user.id,
      credentialId: verification.registrationInfo.credentialID,
      publicKey: verification.registrationInfo.credentialPublicKey,
      counter: verification.registrationInfo.counter,
      transports: credential.response.getTransports?.() || []
    });

    res.json({ success: true });
  }
});
```

Use a well-tested library like `@simplewebauthn/server` (Node.js), `py_webauthn` (Python), or `webauthn-rs` (Rust) rather than implementing the cryptographic verification yourself.

### Step 4: Implement Authentication (Server Side)

```javascript
// Authentication endpoint
app.post('/api/webauthn/login/begin', async (req, res) => {
  const challenge = generateSecureRandom(32);

  // For discoverable credentials (passkeys), no need to specify allowCredentials
  const options = {
    challenge: challenge,
    rpId: "yourcompany.com",
    userVerification: "required",
    timeout: 60000
    // allowCredentials omitted for passkey/discoverable credential flow
  };

  await storeChallengeForSession(req.sessionId, challenge);
  res.json(options);
});

app.post('/api/webauthn/login/complete', async (req, res) => {
  const { credential } = req.body;
  const expectedChallenge = await getChallengeForSession(req.sessionId);

  // Look up the credential by ID
  const storedCredential = await getCredentialById(credential.id);
  if (!storedCredential) {
    return res.status(401).json({ error: "Unknown credential" });
  }

  const verification = await verifyAuthentication({
    response: credential,
    expectedChallenge,
    expectedOrigin: "https://yourcompany.com",
    expectedRPID: "yourcompany.com",
    authenticator: {
      credentialPublicKey: storedCredential.publicKey,
      counter: storedCredential.counter
    }
  });

  if (verification.verified) {
    // Update the counter to detect cloned authenticators
    await updateCredentialCounter(
      storedCredential.id,
      verification.authenticationInfo.newCounter
    );

    // Create session
    await createSession(storedCredential.userId, req);
    res.json({ success: true });
  }
});
```

### 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:** Simulate a counter mismatch (indicating a cloned authenticator) and verify that your server rejects the authentication.
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.** The authenticator increments a counter with each use. If the counter goes backward, it may indicate a cloned authenticator. Alert and investigate.

## 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, attack vectors that account for the majority of breaches.

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.

## FAQs

**Q: What happens if a user loses their phone?**
A: If the user registered a synced passkey, their credential is available on any other device signed into the same cloud account. If they registered a device-bound credential, they need a backup authenticator (e.g., security key) or must go through account recovery.

**Q: Are passkeys secure enough for enterprise use?**
A: Yes. Passkeys are phishing-resistant, cannot be reused across sites, and require user verification (biometric or PIN). For the highest security roles, supplement synced passkeys with device-bound hardware security keys.

**Q: Can I use WebAuthn without an IdP?**
A: Yes. You can implement WebAuthn directly in your application using a server library. However, using an IdP simplifies credential management and provides a centralized authentication experience across multiple applications.

**Q: Do passkeys work on shared computers?**
A: Platform passkeys on shared computers are problematic because they are tied to the OS user profile. Use roaming authenticators (security keys) or QR-code-based cross-device authentication for shared workstations.

**Q: What about users who cannot use biometrics?**
A: WebAuthn authenticators support PIN as an alternative to biometrics. Users with accessibility needs can enter a PIN instead of scanning a fingerprint. Hardware security keys also support PIN-based user verification.

## Passwordless: a strategy that survives reality
Source: https://startwithidentity.com/guides/authentication/passwordless-strategy/
Last updated: 2026-07-16

"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.

## Choose by threat model

- **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, 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, default new accounts to passkeys.
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. 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

Encourage users to enroll a second passkey or a hardware key up front, so a lost device is an inconvenience rather than a lockout.

## 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. Compare providers in the [best passwordless CIAM providers](https://startwithidentity.com/rankings/best-passwordless-ciam-providers/) ranking and the [top passwordless authentication platforms](https://startwithidentity.com/articles/top-7-passwordless-authentication-platforms/) article. 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: Choosing an Authorization Model
Source: https://startwithidentity.com/guides/fundamentals/rbac-vs-abac-vs-rebac/
Last updated: 2026-08-29

**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 present on the request, and ReBAC when access follows from 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 has held the top position in the OWASP Top 10 since the 2021 revision, which is a good reason to choose the model deliberately rather than letting one accrete.

## RBAC (role-based)

Access is granted through **roles** (admin, editor, viewer). Simple, well understood, and easy to audit, but it tends toward **role explosion** as you add exceptions and fine-grained needs.

## ABAC (attribute-based)

Decisions use **attributes** of the user, resource, action, and context (department, region, time, sensitivity). Far more expressive than roles, but policies can get complex and hard to reason about.

## ReBAC (relationship-based)

Access flows from **relationships** between objects, the model behind Google Zanzibar. Ideal for sharing, hierarchies, and nested ownership ("can this user view this document because they belong to its parent folder's team"). It needs a relationship store and careful modeling.

## How to choose

- Simple apps with clear roles: **RBAC**.
- Rules driven by attributes and context: **ABAC**.
- Sharing, hierarchies, multi-tenant graphs: **ReBAC**.

Many teams externalize this to a dedicated engine. Browse [authorization vendors](https://startwithidentity.com/vendors/authorization/) and compare [OpenFGA vs Cerbos](https://startwithidentity.com/compare/openfga-vs-cerbos/).

## What real systems actually do

The models are presented as alternatives and used as layers. The pattern that holds up is roles for the coarse grant, attributes or relationships for the fine-grained condition:

```
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/), because expressing "can view because they belong to the parent folder's team" in roles or attributes is painful.
- **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.

## 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, not an implementation detail.

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. See [OpenFGA vs Cerbos](https://startwithidentity.com/compare/openfga-vs-cerbos/) for how the two shapes differ in practice, and [fine-grained authorization](https://startwithidentity.com/glossary/fga/).

## Where to start

## Where to start

Read [implementing RBAC](https://startwithidentity.com/guides/authorization/implementing-rbac-enterprise/) and [RBAC to ReBAC](https://startwithidentity.com/guides/authorization/rbac-to-rebac/).

## Remote IAM Jobs: How to Find and Land Them in 2026
Source: https://startwithidentity.com/guides/career/remote-iam-jobs/
Last updated: 2026-06-24

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, so a large share
of IAM roles are remote or hybrid. Here is how to find and land one.

## Why IAM suits remote work

SSO, MFA, provisioning, governance, and cloud identity are managed through consoles, APIs, and code.
The collaboration is largely asynchronous: design documents, access policies, runbooks, and reviews.
That makes distributed work natural, and it means strong written communication is a real hiring
signal, not a soft skill.

## Which roles are commonly remote

- **Most remote-friendly:** cloud identity, CIAM, IGA, and platform or automation engineering.
- **Often remote or hybrid:** identity security and ITDR, directory and SSO engineering.
- **More likely on-site or in-country:** government, defense, and some highly regulated finance roles,
  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/) here filters by work type, so you can show only remote roles.
- Apply directly through employer career pages for identity, IGA, PAM, CIAM, and identity security
  titles.
- Watch identity-focused communities and vendor ecosystems (Okta, Microsoft, SailPoint, CyberArk),
  where remote roles are common.

## How pay works for remote roles

Remote offers are frequently benchmarked to a national or lower-cost band rather than a top-metro
range. That can mean less than an in-office offer in an expensive city but more than the local market
elsewhere. Judge an offer against your own cost of living and the role's scope, not against a single
headline number. For ranges, see the [IAM salary guide](https://startwithidentity.com/guides/career/iam-salary-guide/).

## How to stand out

Remote identity work rewards people who document clearly and operate independently. Build a portfolio
that proves it: a working demo with SSO, MFA, and SCIM, a clear write-up of the design decisions, and
evidence that you automate rather than click through consoles. Pair that with deep protocol knowledge
and you read as someone who can own identity work across time zones. For the full path in, see
[how to get an IAM job](https://startwithidentity.com/guides/career/how-to-get-an-iam-job/).

## Your next step

Prepare for remote 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), 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/).

## Reusable Identity and KYC with Verifiable Credentials
Source: https://startwithidentity.com/guides/decentralized-identity/reusable-identity-and-kyc-with-verifiable-credentials/
Last updated: 2026-07-06

Of all the promises around decentralized identity, reusable identity verification has the clearest and nearest-term return. This guide explains the model, the economics, and the honest limits. For the wider context, see [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 verification: 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 for businesses, a source of drop-off at onboarding, and it scatters copies of sensitive documents across dozens of databases, each a breach waiting to happen.

## The verify-once, reuse-many model

Reusable identity flips it. A trusted [issuer](https://startwithidentity.com/glossary/issuer-holder-verifier/) verifies the person once and issues a [verifiable credential](https://startwithidentity.com/standards/verifiable-credentials/) attesting to the result. The person holds it in a [wallet](https://startwithidentity.com/glossary/digital-wallet/) and presents it to the next service, which checks the signature and issuer instantly, without re-running the whole process or contacting the issuer live.

With [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/), the person shares only what each service needs. Proving you are over 18 and a verified customer need not reveal your full document. [Zero-knowledge proofs](https://startwithidentity.com/glossary/zero-knowledge-proof/) push this further.

## What it saves

- **Cost:** a signature check replaces repeated document capture and manual review.
- **Conversion:** onboarding that took minutes becomes a tap, cutting abandonment.
- **Data risk:** verifiers collect and store far less sensitive data, shrinking breach exposure and easing [privacy compliance](https://startwithidentity.com/regulations/).
- **Fraud:** signed, tamper-evident credentials from strong issuers are harder to forge than uploaded document images.

## The high-assurance sources arriving now

Reusable KYC gets much stronger when the underlying credential comes from a government source:

- **[eIDAS 2.0 and the EUDI Wallet](https://startwithidentity.com/standards/eidas-2-eudi-wallet/)** issue high-assurance identity attestations to every EU citizen.
- **[Mobile driver's licenses (mDL)](https://startwithidentity.com/standards/iso-18013-5-mdl/)** provide a signed government ID in a phone wallet, presentable online via 18013-7.
- **National digital IDs** across many countries can seed reusable credentials. Browse them in [digital IDs by country](https://startwithidentity.com/digital-ids/).

These connect directly to the [identity verification vendor](https://startwithidentity.com/vendors/identity-verification/) market, which is where reusable credentials meet existing AML and onboarding workflows.

## The honest limits in 2026

- **Regulatory reliance:** using someone else's verification must still satisfy your AML and KYC obligations. Confirm assurance levels with compliance; do not assume a credential is sufficient.
- **Acceptance network:** the value depends on enough issuers and verifiers participating. Government wallets are bootstrapping this, but coverage is uneven.
- **Liability and governance:** who is responsible if a reused credential was wrongly issued? [Trust frameworks](https://startwithidentity.com/glossary/trust-registry/) are still maturing.

## How to start

Begin as a **verifier**: accept a government or specialist-issued credential for one onboarding flow as an alternative to full document capture, with a fallback. Measure conversion and cost, then expand. 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/). Standards: [Verifiable Credentials](https://startwithidentity.com/standards/verifiable-credentials/), [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-06-17

## What zero standing privileges means

[Zero standing privileges](https://startwithidentity.com/glossary/zero-standing-privileges/) (ZSP) is the strongest form of [least privilege](https://startwithidentity.com/glossary/least-privilege/): no human holds permanent elevated access. Instead, privileges are granted just in time, scoped to a task, and expire automatically. The payoff is direct: if no one carries standing admin rights, a compromised account or stolen [session](https://startwithidentity.com/glossary/session-hijacking/) has far less to abuse, and lateral movement and [privilege escalation](https://startwithidentity.com/glossary/privilege-escalation/) get much harder.

## Why it matters now

Most breaches escalate through over-permissioned accounts and dormant admin rights. Standing privilege is the fuel. Cloud made it worse: identities accumulate entitlements across AWS, Azure, and GCP that nobody uses but attackers can. ZSP, delivered through just-in-time access, removes that standing attack surface.

## 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/). Tools in [CIEM](https://startwithidentity.com/vendors/ciem/) and [PAM](https://startwithidentity.com/vendors/pam/) surface effective permissions.
2. **Right-size first.** Remove unused and excessive entitlements before automating. You cannot grant just in time if the baseline is already bloated.
3. **Introduce just-in-time access.** Route elevation through an approval and time-box workflow, starting with the highest-value targets (cloud admin, production, domain admin).
4. **Automate grant and revoke.** Access is requested, approved (or auto-approved by policy), granted for a fixed window, and revoked automatically. Self-service with guardrails keeps it usable.
5. **Add break-glass.** A tightly controlled [break-glass account](https://startwithidentity.com/glossary/break-glass/) for emergencies, with strong vaulting, alerting, and regular testing.
6. **Measure standing privilege down to near zero.** Track the count of accounts with permanent elevated rights and drive it toward zero over successive quarters.

## Make it usable, or it fails

ZSP dies if elevation is slow or annoying; people route around it. Invest in fast approvals (chat-based, policy-driven auto-approval for low-risk requests), clear audit, and good defaults. The aim is that getting access just in time is easier than hoarding it.

## Common pitfalls

- Automating JIT on top of an un-right-sized, over-permissioned baseline.
- Forgetting non-human identities and service accounts, which often hold the broadest standing rights.
- A break-glass account that is never tested and fails during a real incident.
- Friction so high that users demand standing exceptions, recreating the problem.

## Related

Guide: [what is PAM](https://startwithidentity.com/guides/fundamentals/what-is-pam/), [how to choose a PAM solution](https://startwithidentity.com/guides/buyer-guides/how-to-choose-a-pam-solution/). Vendors: [PAM](https://startwithidentity.com/vendors/pam/), [CIEM](https://startwithidentity.com/vendors/ciem/). Glossary: [zero standing privileges](https://startwithidentity.com/glossary/zero-standing-privileges/), [least privilege](https://startwithidentity.com/glossary/least-privilege/).

## SAML vs OIDC: Which Federation Protocol Should You Use?
Source: https://startwithidentity.com/guides/fundamentals/saml-vs-oidc/
Last updated: 2026-08-29

SAML and OpenID Connect (OIDC) both enable single sign-on, but they come from different eras and fit different jobs. Choosing well saves you years of integration pain.

## SAML 2.0

SAML is an XML-based standard from 2005, deeply entrenched in **enterprise web SSO**. If you sell to enterprises, you will be asked for SAML, because that is what their identity providers speak. It is mature and universally supported, but XML and its signing rules are heavy and error-prone.

## OpenID Connect (OIDC)

OIDC is a modern identity layer built on top of [OAuth 2.0](https://startwithidentity.com/guides/fundamentals/oauth-vs-oidc/), 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.

## How to choose

- Building consumer or developer-facing apps, mobile, or APIs: prefer **OIDC**.
- Integrating with enterprise customers or legacy IdPs: you will likely need **SAML** too.
- 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 genuinely hard: canonicalization, parser differentials between the library that validates and the library that reads, and assertion wrapping have produced a long run of authentication bypasses where a service provider accepted a forged assertion as valid.

The August 2026 miniOrange SAML plugin flaws are a clean example. The validation function performed a loose boolean check on the tri-state integer PHP's `openssl_verify()` returns, so the error value of -1 read as success. An attacker sent a deliberately malformed signature, triggered an OpenSSL error, and signed in as WordPress administrator. The cryptography worked perfectly; the calling code asked the wrong question.

If you operate a SAML service provider, audit for exact-match comparison on verification results, reject unexpected signature algorithms rather than falling through, pin the expected signing certificate, and check that the assertion is addressed to you, is recent, and has not been replayed. See the [identity CVE catalog](https://startwithidentity.com/cves/) for how often this class recurs.

OIDC is not immune, and its equivalent failure modes are [JWT](https://startwithidentity.com/glossary/jwt/) validation errors: accepting `alg: none`, confusing HMAC and RSA verification, skipping the audience check, or trusting a `kid` that points at attacker-controlled key material. The difference is that 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 needs OIDC because that is what your own application uses. Plan for both rather than picking.
- **SCIM is a separate question.** Federation gets a user logged in; it does not create or remove the account. [SCIM](https://startwithidentity.com/standards/scim-2-0/) handles [provisioning](https://startwithidentity.com/glossary/provisioning/), and enterprise buyers usually ask for both together.
- **Metadata and certificate rotation** are the operational tasks that break SAML integrations in production. Automate metadata refresh where the partner supports it.
- **OIDC discovery** lets a client self-configure from one well-known URL, which is the practical superpower and why new integrations are faster.

## Where to start

## Where to start

See our [SSO implementation guide](https://startwithidentity.com/guides/authentication/complete-guide-implementing-sso/) and [federation providers](https://startwithidentity.com/vendors/iam/). For the OAuth relationship, read [OAuth vs OIDC](https://startwithidentity.com/guides/fundamentals/oauth-vs-oidc/).

## 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-06-30

AI agents are the newest and most dynamic kind of [non-human identity](https://startwithidentity.com/guides/machine-identity/non-human-identity-security/). 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 research on non-human identity and AI security, most organizations still manage AI identities with legacy IAM tools and manual processes that were never designed for autonomous, high-velocity systems, and a meaningful share do not track AI-related identities at all.

## 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.
- **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. 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.

## What good looks like

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. The Model Context Protocol (MCP) authorization work and OAuth token exchange are moving the ecosystem toward this model. See the [agentic identity](https://startwithidentity.com/glossary/agentic-identity/) definition for the underlying concept.

## What to do now

- **Inventory your agents.** Treat every agent as a non-human identity in your [NHI program](https://startwithidentity.com/guides/machine-identity/non-human-identity-security/). You cannot govern what you cannot see.
- **Default to scoped, short-lived tokens.** Treat standing agent credentials as technical debt, and vault anything static with [secrets management](https://startwithidentity.com/guides/fundamentals/what-is-secrets-management/).
- **Log the delegation chain.** Capture which user an agent acted for, on every call.
- **Enforce least privilege at the boundary.** Authorize each tool and API call, not just the initial login. See [just-in-time access](https://startwithidentity.com/articles/top-5-just-in-time-access-tools/).
- **Monitor and be ready to revoke.** Watch for anomalous agent behavior with [identity threat detection](https://startwithidentity.com/guides/fundamentals/what-is-itdr/), and make revocation instant.

## 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-01-15

## What auditors test in identity

SOC 2 isn't prescriptive, it tests controls you've defined against the Trust Services Criteria. For identity, the controls auditors expect to find are:

- Access provisioning tied to a documented process (HR ticket or workflow)
- Access reviews on a defined cadence (typically quarterly for sensitive systems)
- Deprovisioning that completes within a defined window (often 24 hours for terminations)
- MFA enforcement on all production systems and admin accounts
- Privileged access controls with logging
- Logical access logs retained for the audit period

## Evidence the audit needs

- Provisioning tickets with approval trail
- Access review records with reviewer attestation
- Deprovisioning logs showing time-to-revoke for sample terminations
- MFA enforcement evidence (config screenshots, policy exports)
- Sample audit log entries for privileged actions
- Background check records for new hires (if your controls include them)

## Vendor capabilities that pay off at audit

SCIM provisioning with audit trail. Access certification campaigns built into the IGA tool. Reports of "who has access to what" exportable on demand. Audit log retention configurable to match audit period. MFA enforcement reports per app and per user.

## Common pitfalls

- "Manual deprovisioning checklist" as a control, auditors find the misses
- Access reviews done in a spreadsheet, not in the IGA tool
- MFA exceptions for executives that are never documented
- Audit logs that exist but can't be exported in a usable format
- Production access by engineers without ticket-tied approval

## The pragmatic path

If you're pre-SOC 2 and want to build for it without overengineering:

1. Pick an IdP and IGA combination (or all-in-one) that can produce the evidence above
2. Wire HR-driven joiner/leaver flows from day one
3. Run a quarterly access review even when you have 20 employees
4. Document your controls in a single page; refine over time

The Type 1 audit tests design. The Type 2 audit tests that you actually did the thing for 6-12 months. The latter is what tells you whether your controls hold up.

## The Complete Guide to Implementing Single Sign-On (SSO)
Source: https://startwithidentity.com/guides/authentication/complete-guide-implementing-sso/
Last updated: 2026-01-20

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, Azure AD, 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, Azure AD, 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, Azure AD), 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 NameID Format `emailAddress`** for SAML unless the SP specifically requires a persistent opaque identifier.
- **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.** Implement token binding or sender-constrained tokens (DPoP) where possible. Log every token issuance event and alert on anomalies (e.g., tokens used from unexpected geographies).
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.

## FAQs

**Q: Should I choose SAML or OIDC?**
A: If your portfolio is mostly enterprise SaaS apps, SAML is the safe bet since nearly every enterprise app supports it. If you are building modern web or mobile applications, OIDC is simpler and more developer-friendly. Most organizations end up supporting both.

**Q: How long does an SSO rollout take?**
A: A typical enterprise SSO project takes 3 to 6 months from protocol selection to full production rollout. The first SP integration takes the longest (2-4 weeks); subsequent ones take 1-3 days once the process is established.

**Q: Do I need Single Logout (SLO)?**
A: SLO is desirable but not always practical. SAML SLO in particular is fragile across many SPs. A common alternative is short IdP sessions (e.g., 8 hours) combined with SP sessions of 1 hour, so users are naturally re-authenticated frequently.

**Q: What happens if the IdP goes down?**
A: Users cannot authenticate to any federated application. Mitigate this with IdP high availability (active-active or active-passive), and maintain break-glass accounts (local admin accounts) on critical applications for emergency access.

**Q: Can I enforce SSO and block direct login?**
A: Yes. Most SaaS apps allow you to disable local password login once SSO is configured. Do this after a stabilization period to ensure SSO is working reliably. Always keep at least one break-glass admin account with local credentials.

**Q: How do I handle applications that do not support SSO?**
A: Use an Enterprise Password Manager (EPM) or a secure web gateway that can inject credentials. Long-term, pressure the vendor to add SAML or OIDC support, or consider replacing the application.

## User Lifecycle Management: Automating Joiner-Mover-Leaver Processes
Source: https://startwithidentity.com/guides/implementation/user-lifecycle-management-guide/
Last updated: 2026-04-24

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, Okta, 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.

## Frequently Asked Questions

**Q: How quickly should accounts be disabled after termination?**
A: Best practice is within 15 minutes of the HR termination event. For high-risk departures (involuntary terminations, security incidents), target immediate disablement, ideally before the employee is notified.

**Q: What about employees who return (boomerang hires)?**
A: Design your joiner process to check for previously disabled accounts. If a match is found, reactivate and update rather than creating a duplicate. Preserve the original employee ID for audit continuity.

**Q: How do we handle identity lifecycle for acquisitions?**
A: Treat acquired employees as a bulk joiner event. Create a temporary "acquisition" department, provision baseline access, then execute movers as org structures are finalized. Plan for 6-12 months of coexistence with the acquired company's identity systems.

**Q: Should we automate access removal for movers or require manager approval?**
A: Use a hybrid approach. Automatically add entitlements for the new role, but place old entitlements in a grace period with manager notification. If the manager does not explicitly retain old access within the grace period, remove it automatically.

**Q: How do we measure the effectiveness of lifecycle automation?**
A: Track these metrics: average time from HR event to provisioning completion, orphan account count over time, access-related helpdesk tickets, and audit findings related to stale access. All four should trend downward after implementation.

## Verifiable Credentials Implementation Guide
Source: https://startwithidentity.com/guides/decentralized-identity/verifiable-credentials-implementation-guide/
Last updated: 2026-07-06

This guide is for teams that have decided to build with verifiable credentials and need to know how the pieces fit. 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/).

## 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:

- **Issuer:** you sign credentials and deliver them to wallets. You need signing keys, a schema, and an issuance endpoint.
- **Verifier (relying party):** you request and check presentations. This is the most common starting point and the lowest lift.
- **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 formats and protocols

Two decisions shape everything downstream:

- **Credential format.** [SD-JWT VC](https://startwithidentity.com/standards/verifiable-credentials/) is the pragmatic default: JWT-based, supported broadly, and favored by [eIDAS 2.0](https://startwithidentity.com/standards/eidas-2-eudi-wallet/). Choose **W3C VC with Data Integrity and [BBS signatures](https://startwithidentity.com/glossary/bbs-signature/)** when you need unlinkable [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/). Consider [AnonCreds](https://startwithidentity.com/glossary/anoncreds/) only inside ecosystems already built on it.
- **Transport protocol.** [OpenID4VC](https://startwithidentity.com/standards/openid4vc/) is the answer for most: [OpenID4VCI](https://startwithidentity.com/glossary/openid4vci/) for issuance, [OpenID4VP](https://startwithidentity.com/glossary/openid4vp/) for presentation. It layers on OAuth, so you extend infrastructure you already know. Align to the HAIP profile if you need EU-wallet interoperability.

## Identifiers and keys

Issuers need a resolvable identifier so verifiers can fetch the signing key. For most, a [`did:web`](https://startwithidentity.com/standards/decentralized-identifiers-did/) anchored to a domain you control is the right balance of standards compliance and operational simplicity, no ledger required. See [DID methods compared](https://startwithidentity.com/guides/decentralized-identity/did-methods-compared/) for the tradeoffs. Treat issuer key management like any high-value signing key: hardware-backed, rotated, with a tested recovery plan.

## Revocation and status

A credential outlives its issuance, so verifiers must be able to tell whether it is still valid. Publish status through a [revocation registry](https://startwithidentity.com/glossary/revocation-registry/) or status list. Design this early; 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 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 your verifiers will learn which issuers are authoritative before you go past a pilot.

## A staged rollout

1. **Verifier pilot:** accept one credential type from one issuer for one flow (for example, a reusable proof at onboarding). Prove the plumbing.
2. **Add issuance** if you own credentials worth making portable.
3. **Formalize trust** with a registry and a documented governance model.
4. **Scale formats and wallets** you accept as the ecosystem matures, keeping a non-credential fallback.

## Common mistakes

- Building issuance before you have a verifier that will accept the output.
- Picking a format your target wallets do not support.
- 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/) and [best platforms](https://startwithidentity.com/rankings/best-decentralized-identity-platforms/).

## What Is a Non-Human Identity (NHI)?
Source: https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/
Last updated: 2026-08-29

A non-human identity (NHI) is any identity that is not a person: service accounts, API keys, OAuth tokens, certificates, workloads, bots, and increasingly **AI agents**. In most organizations, NHIs now 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. Leaked keys and over-permissioned service accounts are a leading cause of cloud breaches. See our [secrets sprawl data](https://startwithidentity.com/research/) for the scale of leaked credentials.

## The new wave: AI agents

AI agents act on behalf of users, call APIs, and chain tools together. They need identities that are **scoped, delegated, auditable, and revocable**, which traditional service accounts do not provide. This is the focus of the emerging [agentic and AI identity](https://startwithidentity.com/vendors/ai-identity/) category and protocols like MCP authorization.

## How to manage them

Discover every NHI, remove standing privileges, rotate and vault [secrets](https://startwithidentity.com/vendors/secrets/), and govern lifecycle like you would human accounts. [Machine and workload identity](https://startwithidentity.com/vendors/machine-identity/) and [PKI](https://startwithidentity.com/vendors/pki/) tools handle the cryptographic side.

## Start with ownership, not discovery

The instinct is to buy a discovery tool, and the result is an inventory of 40,000 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.

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.
4. **Replace static credentials** with platform-attested [workload identity](https://startwithidentity.com/glossary/workload-identity/) wherever the runtime can vouch for the caller.
5. **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.

The standards moved quickly in 2026. Okta's Cross App Access was adopted as the Enterprise-Managed Authorization extension for the Model Context Protocol, MCP authorization settled on OAuth 2.1 with PKCE, and Microsoft Entra Agent ID reached general availability. That gives agents short-lived, revocable, identity-provider-issued tokens instead of static API keys.

The governance did not move as fast. Okta's own research puts the share of organizations applying human-grade controls to agents at 34 percent. 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/).

## Where to start

## Where to start

For the full picture, read the [non-human identity security guide](https://startwithidentity.com/guides/machine-identity/non-human-identity-security/), the deep dive on [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/). When you are choosing tools, see [best machine identity for enterprises](https://startwithidentity.com/rankings/best-machine-identity-for-enterprises/).

## What Is an Identity Fabric?
Source: https://startwithidentity.com/guides/fundamentals/what-is-identity-fabric/
Last updated: 2026-06-23

An identity fabric is a composed, multi-vendor identity 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 to cover distributed, multi-cloud, and hybrid
environments. Instead of forcing everything through one platform, an identity fabric connects
specialized systems and keeps policy, lifecycle, and visibility consistent across all of them.

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, Okta for cloud SSO, a separate CIAM
platform for customers, CyberArk or Delinea for privileged access, SailPoint or 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. 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).
  Ping DaVinci and Strata Maverics lead here.
- **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 intelligence.** Unified identity analytics that correlate events across the fabric
  to detect threats and surface excess access.

## Why organizations adopt it

The alternative to a fabric is either a single vendor that cannot cover every need, or a sprawl of
disconnected tools with inconsistent policy and blind spots between them. A fabric accepts that
heterogeneity is permanent and manages it deliberately. The payoff is consistent policy enforcement,
unified lifecycle management, centralized visibility, and the freedom to swap or add components
without re-engineering applications.

## 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. Start with your most pressing gap, deploy a solution that addresses it, then connect it to the
rest of your infrastructure through orchestration. Over time the fabric grows to cover authentication,
governance, privileged access, and analytics. 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.

For the vendors that supply each layer, see our analysis of 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/).

## What Is Cloud Infrastructure Entitlement Management (CIEM)?
Source: https://startwithidentity.com/guides/fundamentals/what-is-ciem/
Last updated: 2026-08-29

Cloud Infrastructure Entitlement Management (CIEM) discovers and right-sizes the identities and permissions that exist across AWS, Azure, and GCP. In the cloud, permissions sprawl fast, and most identities, human and machine, end up with far more access than they use.

## 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.

## Core capabilities

- **Discovery** of every human and [non-human identity](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/) and its permissions.
- **Effective-permission analysis** across tangled policies and roles.
- **Right-sizing** toward [least privilege](https://startwithidentity.com/glossary/least-privilege/), often with just-in-time access.
- **Risk detection** for cross-account access, privilege escalation paths, and toxic combinations.

## CIEM vs IGA vs CSPM

[IGA](https://startwithidentity.com/guides/fundamentals/what-is-iga/) governs access broadly, including on-prem and SaaS. CSPM finds cloud resource misconfigurations. CIEM is specifically about cloud identities and entitlements, and increasingly ships inside cloud security platforms.

## 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 effective answer depends on 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.

## 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. See [non-human identity](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/).

## 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.
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](https://startwithidentity.com/glossary/jit-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.

## Where to start

## Where to start

Browse [CIEM vendors](https://startwithidentity.com/vendors/ciem/) and compare [Wiz vs Sonrai](https://startwithidentity.com/compare/wiz-vs-sonrai-security/).

## What Is Customer Identity and Access Management (CIAM)?
Source: https://startwithidentity.com/guides/fundamentals/what-is-ciam/
Last updated: 2026-08-29

Customer Identity and Access Management (CIAM) is identity built for the people who use your product rather than the people who work at your company. It handles sign-up, login, social and passwordless authentication, consent, and profile management at consumer scale.

## How CIAM differs from workforce IAM

Workforce [IAM](https://startwithidentity.com/guides/fundamentals/what-is-iam/) optimizes for control and governance. CIAM optimizes for **conversion, scale, and experience**: every extra field or friction point in a signup flow costs real revenue. CIAM systems also carry privacy and consent obligations that internal systems usually do not.

## B2C vs B2B CIAM

- **B2C** serves individual consumers: high volume, social login, progressive profiling, fraud and bot defense.
- **B2B / SaaS** serves organizations: tenants, enterprise SSO and SCIM for your customers, and delegated administration. This is the fastest-growing slice, and many developer-first platforms specialize here.

## Common capabilities

Passwordless and [passkeys](https://startwithidentity.com/guides/authentication/passkeys-101/), social login, multi-factor authentication, bot and account-takeover defense, consent capture, and APIs and SDKs for developers.

## What makes CIAM hard

The technical 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](https://startwithidentity.com/glossary/credential-stuffing/) from unrelated breaches and real-time relay kits that capture a valid session. Your rate limiting will not stop distributed attempts from residential proxies.
- **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.
- **Cost curves.** Per monthly active user pricing that is reasonable at 50,000 users can dominate the product's unit economics at 5 million.

## Where CIAM is heading

Two shifts are visible in 2026. First, [passkeys](https://startwithidentity.com/glossary/passkey/) have crossed into mainstream consumer deployment, with WhatsApp shipping multiple passkeys per account and platform support now broad enough to make passkey-first flows viable. Second, regulation is pushing toward holder-presented credentials: the [EUDI Wallet](https://startwithidentity.com/glossary/eudi-wallet/) deadline of 24 December 2026 means regulated services in the EU will need to accept wallet presentations, which changes identity verification at the front of the funnel rather than replacing CIAM.

Neither removes the need for a customer identity system. Both change what it has to accept.

## Where to start

## Where to start

Compare [CIAM platforms](https://startwithidentity.com/vendors/ciam/), read our [how to evaluate CIAM](https://startwithidentity.com/guides/buyer-guides/how-to-evaluate-ciam/) guide, or see head-to-head [comparisons](https://startwithidentity.com/compare/) like Auth0 vs Clerk.

## What Is Decentralized Identity?
Source: https://startwithidentity.com/guides/fundamentals/what-is-decentralized-identity/
Last updated: 2026-07-06

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)** because the holder, not a platform, controls the credential.

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

Decentralized identity rests on two W3C standards plus a presentation layer:

- **[Decentralized Identifiers (DIDs)](https://startwithidentity.com/glossary/decentralized-identifier/)** are identifiers the subject controls, resolvable to a [DID document](https://startwithidentity.com/glossary/did-document/) containing public keys and service endpoints. No central registrar issues them. See the [W3C DID Core specification](https://www.w3.org/TR/did-core/).
- **[Verifiable Credentials (VCs)](https://startwithidentity.com/glossary/verifiable-credential/)** are tamper-evident, signed claims that follow the [W3C VC Data Model](https://www.w3.org/TR/vc-data-model-2.0/). Read our [Verifiable Credentials standard deep dive](https://startwithidentity.com/standards/verifiable-credentials/).
- **Presentation protocols** move credentials between wallets and verifiers. The [OpenID for Verifiable Credentials](https://openid.net/sg/openid4vc/) family (OpenID4VCI for issuance, OpenID4VP for presentation) is emerging as the dominant transport.

## Privacy: selective disclosure and zero-knowledge proofs

A key advantage is that holders can reveal the minimum needed. With [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/) and formats like [SD-JWT](https://startwithidentity.com/glossary/sd-jwt/), you can prove you are over 18 without showing your birth date or full ID. [Zero-knowledge proofs](https://startwithidentity.com/glossary/zero-knowledge-proof/) and [BBS signatures](https://startwithidentity.com/glossary/bbs-signature/) push this further, proving a statement is true without revealing the underlying data.

## Where it is being used

- **Reusable identity verification and KYC**: verify once, reuse the credential, instead of repeating document checks at every service. This connects directly to the [identity verification](https://startwithidentity.com/vendors/identity-verification/) market.
- **Government and cross-border ID**: the EU's [eIDAS 2.0 and the EUDI Wallet](https://startwithidentity.com/glossary/eudi-wallet/) mandate a wallet for every citizen, and [mobile driver's licenses](https://startwithidentity.com/glossary/mobile-drivers-license/) (ISO/IEC 18013-5) are rolling out across US states. See our [digital IDs by country](https://startwithidentity.com/digital-ids/) directory and [identity regulations](https://startwithidentity.com/regulations/) hub.
- **Workforce**: verifiable employment, certification, and access credentials that survive job changes.

## Decentralized vs federated identity

Federated identity ([SAML](https://startwithidentity.com/standards/saml-2-0/), [OIDC](https://startwithidentity.com/standards/openid-connect/)) is mature, centralized, and excellent for enterprise SSO, but the identity provider is a single point of control and failure. Decentralized identity removes the runtime dependency on that provider and gives the holder portability and privacy, at the cost of a younger ecosystem and wallet adoption still in progress. The two will coexist: expect [identity fabrics](https://startwithidentity.com/guides/fundamentals/what-is-identity-fabric/) to bridge federated and decentralized credentials.

## Where to start

Read [what is self-sovereign identity](https://startwithidentity.com/guides/fundamentals/what-is-self-sovereign-identity/) for the philosophy and history, the [Verifiable Credentials standard](https://startwithidentity.com/standards/verifiable-credentials/) for the data model, and 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/).

## What Is IDaaS (Identity-as-a-Service)?
Source: https://startwithidentity.com/guides/fundamentals/what-is-idaas/
Last updated: 2026-06-23

IDaaS stands for Identity-as-a-Service: identity and access management delivered from the cloud as
a subscription. Instead of installing and running identity servers in your own data center, you use
a provider that handles authentication, single sign-on, multi-factor authentication, and user
provisioning for you. It is the cloud-delivery model of [IAM](https://startwithidentity.com/guides/fundamentals/what-is-iam/).

## 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.
- **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.
- **Access policies.** Conditional and risk-based rules that decide when to allow, challenge, or
  block access.

## 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.

## Workforce vs customer IDaaS

IDaaS comes in two flavors. **Workforce IDaaS** secures employees and contractors, emphasizing
governance, provisioning, and integration breadth; the leaders are Okta, Microsoft Entra, and Ping.
**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.

## 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. 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/).

## What Is Identity and Access Management (IAM)?
Source: https://startwithidentity.com/guides/fundamentals/what-is-iam/
Last updated: 2026-08-29

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. It covers how identities are created, authenticated, authorized, governed, and eventually removed.

## The core building blocks

- **Authentication** proves who someone is (passwords, [MFA](https://startwithidentity.com/guides/fundamentals/authentication-vs-authorization/), passkeys).
- **Authorization** decides what they can do once authenticated.
- **Lifecycle and provisioning** create, update, and deprovision accounts, often automated from an HR system through SCIM.
- **Governance** reviews and certifies access so it does not drift out of control over time.
- **Federation and SSO** let one identity work across many applications.

## Workforce vs customer identity

IAM usually refers to **workforce identity**: employees, contractors, and the internal apps they use. The customer-facing equivalent is [CIAM](https://startwithidentity.com/guides/fundamentals/what-is-ciam/), which optimizes for sign-up conversion and scale rather than internal governance. Adjacent disciplines include [Privileged Access Management](https://startwithidentity.com/guides/fundamentals/what-is-pam/) for admin accounts and [Identity Governance](https://startwithidentity.com/guides/fundamentals/what-is-iga/) for access reviews.

## Why it matters

Most breaches involve stolen or misused credentials, which is why identity has become the primary security perimeter. See our [research data points](https://startwithidentity.com/research/) for the numbers, and our [Zero Trust explainer](https://startwithidentity.com/guides/fundamentals/what-is-zero-trust/) for the architecture that puts identity at the center.

## What actually goes wrong

IAM programs rarely fail at authentication. Login is a solved problem. They fail in four places:

- **Movers.** Joiners get access because someone is waiting to work and leavers get removed because HR triggers it, but internal transfers accumulate entitlements from every role a person has ever held. This is the single most common audit finding.
- **Accounts outside SSO.** Local administrator accounts on appliances, vendor support logins, and SaaS bought on a corporate card never enter the identity provider, so removing someone from SSO does not remove their access.
- **Non-human identities.** Service accounts, [API keys](https://startwithidentity.com/glossary/api-key/), and workloads now outnumber employees by a wide margin in most environments, and they typically have no owner, no expiry, and no place in any review.
- **Session and token lifetime.** Once [SSO](https://startwithidentity.com/glossary/sso/) concentrates authentication, a stolen session is worth as much as a stolen password and survives a password reset. See [token theft](https://startwithidentity.com/glossary/token-theft/).

## Maturity, roughly

A useful way to locate yourself:

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](https://startwithidentity.com/standards/scim-2-0/); 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.

## What to do first

If you are early, the order that produces the most risk reduction per unit of effort is: enforce phishing-resistant MFA and shrink the exemption list, automate joiner-mover-leaver from the HR record, inventory accounts that live outside SSO, then start certification on the systems that matter rather than on everything.

## Where to start

## Where to start

Browse [workforce IAM platforms](https://startwithidentity.com/vendors/iam/), or use the [vendor selector](https://startwithidentity.com/tools/vendor-selector/) to narrow a shortlist by your requirements.

## What Is Identity Governance and Administration (IGA)?
Source: https://startwithidentity.com/guides/fundamentals/what-is-iga/
Last updated: 2026-08-29

Identity Governance and Administration (IGA) answers a deceptively hard question: who has access to what, why, and should they still have it? It is the control plane that keeps access correct and auditable over time.

## Core functions

- **Access requests and approvals** with a clear trail.
- **Access certifications** (periodic reviews) so managers confirm their people still need what they have.
- **Provisioning and deprovisioning** across connected systems.
- **Separation of duties (SoD)** to prevent toxic combinations of access.
- **Role management** to keep entitlements understandable.

## Why it matters

Access tends to accumulate. People change roles, projects end, and permissions linger. That drift is a top audit finding and a real breach risk. IGA exists to detect and reverse it, which is why it is central to compliance with SOC 2, ISO 27001, and similar frameworks. See our [audit preparation guide](https://startwithidentity.com/guides/compliance/iam-audit-preparation-guide/).

## IGA vs adjacent tools

[IAM](https://startwithidentity.com/guides/fundamentals/what-is-iam/) handles authentication and SSO; IGA handles governance. In the cloud, [CIEM](https://startwithidentity.com/vendors/ciem/) does entitlement right-sizing, and [PAM](https://startwithidentity.com/guides/fundamentals/what-is-pam/) governs privileged accounts specifically.

## 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. This is the most common audit finding in the discipline.

## 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: SailPoint acquired Entro Security in June 2026 specifically to extend governance to non-human identities. See [what is non-human identity](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/).

## Where to start

## Where to start

Browse [IGA platforms](https://startwithidentity.com/vendors/iga/), compare [SailPoint vs Saviynt](https://startwithidentity.com/compare/sailpoint-vs-saviynt/), or read [how to choose an IGA platform](https://startwithidentity.com/guides/buyer-guides/how-to-choose-an-iga-platform/).

## What Is Identity Threat Detection and Response (ITDR)?
Source: https://startwithidentity.com/guides/fundamentals/what-is-itdr/
Last updated: 2026-08-29

Identity Threat Detection and Response (ITDR) is the discipline and tooling for detecting and responding to attacks that target identity itself: stolen credentials, account takeover, privilege escalation, and lateral movement. As identity became the primary attack surface, prevention alone stopped being enough, and ITDR fills the runtime gap.

## 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/), and [session hijacking](https://startwithidentity.com/glossary/session-hijacking/). ITDR assumes breach and watches for the behaviors that follow.

## What ITDR covers

- **Directory protection** for Active Directory and Entra ID, including misconfiguration detection 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.
- **SaaS identity risk** and exposed-credential intelligence.

## ITDR vs ISPM vs CIEM

[ISPM](https://startwithidentity.com/glossary/ispm/) is the preventive posture side (find risky configurations before attack). [CIEM](https://startwithidentity.com/guides/fundamentals/what-is-iga/) right-sizes cloud entitlements. ITDR is the detection-and-response side at runtime. Mature programs use all three.

## What ITDR detects that nothing else does

The defining property of an identity attack is that nothing looks broken. There is no malware in a valid login with a stolen token, no exploit in a service principal assuming a role it was permitted to assume, and no failed authentication to alert on. Endpoint and network tooling sees none of it.

The 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.
- New OAuth consent grants to unfamiliar applications.
- 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.

## Hybrid is where attacks live

Attackers routinely 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. This is also why AD resilience is a distinct concern: restoring a compromised forest from ordinary backups can restore the attacker's persistence along with everything else. See [Silverfort vs Semperis](https://startwithidentity.com/compare/silverfort-vs-semperis/).

## Response is the harder half

Detection without a response playbook produces alerts. The identity-specific containment steps are different from endpoint response: revoke [refresh tokens](https://startwithidentity.com/glossary/refresh-token/) and sessions rather than only resetting the password, because a password reset leaves a stolen session alive; remove attacker-added authentication methods; check for registered devices you did not expect. See [token theft](https://startwithidentity.com/glossary/token-theft/) and the [infostealer session hijacking teardown](https://startwithidentity.com/breaches/infostealer-session-hijacking/).

## Where to start

## Where to start

Browse [ITDR vendors](https://startwithidentity.com/vendors/itdr/), compare [Silverfort vs Semperis](https://startwithidentity.com/compare/silverfort-vs-semperis/), and read [how to choose an ITDR solution](https://startwithidentity.com/guides/buyer-guides/how-to-choose-an-itdr-solution/).

## What Is Machine Identity?
Source: https://startwithidentity.com/guides/fundamentals/what-is-machine-identity/
Last updated: 2026-08-29

Machine identity is how non-human actors, workloads, services, containers, and devices, prove who they are to each other. 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.

## 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** 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.

## The frontier: AI agents

[Agentic identity](https://startwithidentity.com/guides/fundamentals/what-is-non-human-identity/) extends machine identity to AI agents that act for users, needing scoped, delegated, revocable credentials.

## The failure modes in practice

Machine identity incidents cluster in four places:

- **Expired certificates.** The one machine identity failure that causes a visible outage rather than a quiet compromise, which is why it gets budget. As lifetimes shorten under the CA/Browser Forum schedule, manual renewal stops being viable.
- **Credentials in repositories.** GitGuardian found 4,576 live n8n API tokens in public GitHub commits in August 2026, and roughly a third of reachable instances still accepted them. The pattern repeats across every platform with an API key.
- **Compromised build systems.** A CI runner holds registry tokens, cloud credentials, and signing keys. The August 2026 Rust crate poisoning gave attackers a 90-minute window during which any pipeline resolving fresh dependencies pulled an infostealer.
- **Unowned service accounts.** No owner means no rotation, no review, and no MFA. See [service account](https://startwithidentity.com/glossary/service-account/).

## 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](https://startwithidentity.com/glossary/spiffe/) as the vendor-neutral abstraction across both.

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.

## Where to start

## Where to start

Browse [machine and workload identity vendors](https://startwithidentity.com/vendors/machine-identity/) and read the [workload identity 101 guide](https://startwithidentity.com/guides/machine-identity/workload-identity-101/).

## What Is Passwordless Authentication?
Source: https://startwithidentity.com/guides/fundamentals/what-is-passwordless/
Last updated: 2026-08-29

Passwordless authentication verifies a user without a shared secret they have to remember. Instead of a password, the user proves identity with something they have (a device or security key) and something they are (a biometric) or know (a local PIN). Done well, it is both more secure and easier than passwords.

## Why move off passwords

Passwords are the largest single source of breaches through reuse, phishing, [credential stuffing](https://startwithidentity.com/glossary/credential-stuffing/), and [password spraying](https://startwithidentity.com/glossary/password-spraying/). Removing the shared secret removes the thing attackers steal.

## The passwordless spectrum

Not all passwordless is equal:

- **Phishing-resistant:** [passkeys](https://startwithidentity.com/guides/authentication/passkeys-101/) and [FIDO2](https://startwithidentity.com/glossary/fido2/) security keys, bound to the origin and impossible to replay. The gold standard.
- **Better than passwords but phishable:** [magic links](https://startwithidentity.com/glossary/magic-link/) and email or SMS [one-time codes](https://startwithidentity.com/glossary/totp/).

Aim for [phishing-resistant MFA](https://startwithidentity.com/glossary/phishing-resistant-mfa/) where it matters.

## Practical considerations

Plan for enrollment and account recovery, the steps attackers target once passwords are gone. Support more than one authenticator per user, and have a tested fallback.

## Passwordless is a UX claim, not a security claim

This is the distinction that matters and the one marketing collapses. [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 just as easily as it captures a password. Only origin-bound credentials, [passkeys](https://startwithidentity.com/glossary/passkey/) and FIDO2 security keys, remove both, because the authenticator refuses to sign for a domain other than the one that registered it.

Rank the options honestly:

| Method | Removes password | Phishing-resistant |
|---|---|---|
| Magic link | Yes | No |
| Email or SMS one-time code | Yes | No |
| Authenticator app code ([TOTP](https://startwithidentity.com/glossary/totp/)) | Only with a second factor | No |
| Push approval | Only with a second factor | No |
| Passkey or security key | Yes | Yes |

## 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.

Three rules that 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.

## What the 2026 research changed

Three research teams published passkey attacks in August 2026, and none of them broke the cryptography: they attacked event logs, sync key custody, and in-session key reuse, all starting from malware already on the endpoint. The practical consequence is tiering rather than retreat. Synced passkeys for consumers, device-bound hardware authenticators for administrators and production access. See [passkeys had a hard month](https://startwithidentity.com/blog/passkeys-first-hard-month/).

## Where to start

## Where to start

Read [Passkeys 101](https://startwithidentity.com/guides/authentication/passkeys-101/) and browse [MFA and passwordless vendors](https://startwithidentity.com/vendors/mfa/).

## What Is Privileged Access Management (PAM)?
Source: https://startwithidentity.com/guides/fundamentals/what-is-pam/
Last updated: 2026-08-29

Privileged Access Management (PAM) secures the most powerful accounts in an organization: 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/guides/security/identity-threat-detection-response-guide/).
- **Discovery** finds unmanaged privileged accounts before attackers do.

## 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

## 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/).

## What Is SCIM? Automated User Provisioning Explained
Source: https://startwithidentity.com/guides/fundamentals/what-is-scim/
Last updated: 2026-08-29

SCIM (System for Cross-domain Identity Management) is the open standard for automatically provisioning and deprovisioning user accounts across applications. When HR adds an employee or an admin assigns an app, SCIM pushes that change so accounts are created, updated, and, critically, removed without manual work.

## 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. SCIM closes that gap by automating the [joiner-mover-leaver](https://startwithidentity.com/glossary/joiner-mover-leaver/) lifecycle.

## How it works

SCIM defines a standard schema for users and groups (RFC 7643) and a REST protocol to manage them (RFC 7644). An identity provider acts as the client and pushes changes to applications that expose a SCIM endpoint.

## What to check

- Does the app support SCIM 2.0, and which attributes and groups?
- Is deprovisioning real-time or batch?
- For B2B SaaS, do you offer SCIM to your enterprise customers? It is often a deal requirement.

## Where SCIM implementations break

The standard is straightforward; the implementations vary enough that "supports SCIM 2.0" tells you less than it should. The recurring problems:

- **Deactivation versus deletion.** Some applications treat `active: false` as a soft delete and some ignore it entirely, which means your leaver is still able to log in. Test this specifically.
- **Group handling.** Group membership syncing is the least consistent part of the standard. Check whether groups push at all, whether nested groups flatten, and what happens when a group is renamed.
- **PATCH support.** Applications that only accept full PUT replacement will drop attributes your identity provider did not send.
- **Pagination and filtering.** Fine at 500 users, a real problem at 50,000.
- **Attribute mapping.** Custom attributes and enterprise extensions are where most integration time actually goes.

## The long tail is the real work

SCIM covers the applications that support it, and the residual is always the ones that do not: the on-premises tool, the appliance with a local user database, the SaaS product bought on a corporate card. Those are where [orphaned accounts](https://startwithidentity.com/glossary/orphaned-account/) accumulate, and no amount of SCIM coverage on the main estate fixes them.

Reconcile every account in every system against an authoritative owner at least once, and you will find the gap. See [deprovisioning](https://startwithidentity.com/glossary/deprovisioning/) and the [secure offboarding checklist](https://startwithidentity.com/templates/secure-offboarding-checklist/).

## If you sell B2B SaaS

SCIM plus [SAML](https://startwithidentity.com/standards/saml-2-0/) is a procurement gate above a certain deal size, and building it late is expensive. 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. See [best SSO and SCIM platforms for B2B SaaS](https://startwithidentity.com/rankings/best-sso-scim-platforms-b2b-saas/).

## Where to start

## Where to start

Read 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?
Source: https://startwithidentity.com/guides/fundamentals/what-is-secrets-management/
Last updated: 2026-08-29

Secrets management is how you store, distribute, rotate, and audit the credentials that applications and infrastructure use: API keys, database passwords, tokens, and certificates. 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. Industry research finds millions of secrets exposed in public code each year, and a large share remain active.

## 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 and logs.
- **Audit** of who and what accessed each secret.

## Related disciplines

Secrets management overlaps with [PAM](https://startwithidentity.com/guides/fundamentals/what-is-pam/) for privileged credentials, [PKI](https://startwithidentity.com/glossary/pki/) for certificates, and broader [non-human identity](https://startwithidentity.com/vendors/ai-identity/) governance.

## 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 15-minute 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.

Fixing that (single source of truth, references instead of copies, a tested rotation runbook) matters more than the interval you choose. See [secrets rotation](https://startwithidentity.com/glossary/secrets-rotation/).

## Automation platforms are credential concentrators

A category worth calling out specifically. 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.

GitGuardian demonstrated the consequence in August 2026: with a leaked n8n API token, an attacker does not need to read a stored secret, because they can build a workflow that uses the credential to call their own endpoint. Read-only access to a workflow engine is not read-only in effect. The same reasoning applies to CI systems and to MCP servers brokering agent access.

## Where to start

## Where to start

Browse [secrets management vendors](https://startwithidentity.com/vendors/secrets/) and the [machine identity vendors](https://startwithidentity.com/vendors/machine-identity/), and read 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-07-06

Self-sovereign identity (SSI) is a model in which individuals and organizations own and control their own digital identity and credentials directly, rather than renting that control from platforms, identity providers, or governments. It is the guiding principle behind [decentralized identity](https://startwithidentity.com/guides/fundamentals/what-is-decentralized-identity/).

## The idea

In today's systems your identity is scattered across accounts you do not really control. Each provider can lock you out, change terms, mine your data, or disappear. SSI flips the model: you hold cryptographically signed [verifiable credentials](https://startwithidentity.com/glossary/verifiable-credential/) in your own [wallet](https://startwithidentity.com/glossary/digital-wallet/) and present them peer to peer, so no single party sits between you and the services you use.

## Christopher Allen's ten principles

The modern framing comes from Christopher Allen's 2016 essay [The Path to Self-Sovereign Identity](http://www.lifewithalacrity.com/article/the-path-to-self-soverereign-identity/), which proposed ten principles: **existence, control, access, transparency, persistence, portability, interoperability, consent, minimalization, and protection**. In practice these reduce to three demands: the user must control the identity, the identity must be portable across providers, and disclosure must be minimized to only what a transaction needs.

## How SSI works in practice

SSI is realized through the same building blocks as decentralized identity:

- **[Decentralized Identifiers (DIDs)](https://startwithidentity.com/glossary/decentralized-identifier/)** the subject controls, defined by [W3C DID Core](https://www.w3.org/TR/did-core/).
- **[Verifiable Credentials](https://startwithidentity.com/standards/verifiable-credentials/)** issued, held, and presented within the [issuer, holder, verifier](https://startwithidentity.com/glossary/issuer-holder-verifier/) trust triangle.
- **[Selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/)** and [zero-knowledge proofs](https://startwithidentity.com/glossary/zero-knowledge-proof/) to satisfy the minimalization principle: prove you are eligible without oversharing.
- **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/) framework organizes this into technical and governance layers.

## Where SSI meets the real world

The principles are now colliding with regulation and rollout. The EU's [eIDAS 2.0 and EUDI Wallet](https://startwithidentity.com/glossary/eudi-wallet/) put a state-issued wallet in every citizen's hands, [mobile driver's licenses](https://startwithidentity.com/glossary/mobile-drivers-license/) are shipping in phone wallets, and reusable [identity verification](https://startwithidentity.com/vendors/identity-verification/) is turning SSI from theory into a KYC cost saver. Track national schemes in the [digital IDs directory](https://startwithidentity.com/digital-ids/).

## The honest tradeoffs

SSI is powerful but not free. Wallet recovery, issuer governance, revocation, and getting verifiers to actually accept credentials are hard, unfinished problems. Adoption depends on network effects that are still forming. For most enterprises the near-term reality is hybrid: [federated identity](https://startwithidentity.com/guides/fundamentals/saml-vs-oidc/) for existing SSO, decentralized 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 browse the [decentralized identity vendor directory](https://startwithidentity.com/vendors/decentralized-identity/) to see who is building it.

## What Is Zero Trust?
Source: https://startwithidentity.com/guides/fundamentals/what-is-zero-trust/
Last updated: 2026-08-29

Zero Trust is a security model that assumes no user, device, or network is trusted by default. Instead of a hard perimeter with a soft interior, every access request is verified explicitly using identity, device posture, and context, and is granted with the least privilege necessary.

## 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/guides/fundamentals/what-is-pam/).
- **Assume breach:** segment, monitor, and limit blast radius as if an attacker is already inside.

## 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/vendors/mfa/), continuous [authorization](https://startwithidentity.com/guides/fundamentals/rbac-vs-abac-vs-rebac/), and [identity threat detection](https://startwithidentity.com/vendors/itdr/).

## Zero Trust Network Access (ZTNA)

ZTNA is the access-layer implementation that replaces VPNs with identity-aware, per-application access. Browse [Zero Trust vendors](https://startwithidentity.com/vendors/zero-trust/) and our [zero-trust rollout guide](https://startwithidentity.com/guides/implementation/zero-trust-rollout/).

## What "implementing zero trust" actually means

Zero trust is a set of principles, not a product, and vendors sell very different things under the label. In practice a programme 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.
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](https://startwithidentity.com/glossary/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 honest limits

Two things are worth saying plainly. 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.

NIST SP 800-207 is the reference worth reading precisely because it is vendor-neutral enough to argue with.

## Where zero trust fails in practice

Exclusions. Every real deployment accumulates policy exemptions added for a migration, a vendor, or a legacy application, and they are never removed. Audit the exclusion list more often than the policy list, because that is where the actual access model lives.

## Where to start

## Where to start

Read the [Zero Trust architecture guide](https://startwithidentity.com/guides/architecture/zero-trust-architecture-implementation-guide/), then map your identity stack against the principles above.

## Workload identity 101: replacing long-lived secrets
Source: https://startwithidentity.com/guides/machine-identity/workload-identity-101/
Last updated: 2026-01-15

## The problem

Most production incidents start with a leaked API key. The key was issued years ago, lives in an environment variable, was committed to a git history, and authorizes more than it needed to. Workload identity replaces this pattern.

## What workload identity is

A cryptographic identity issued to a software workload (container, function, service), short-lived, and attested by the underlying platform. Instead of "here's my secret API key," the workload presents "here's a cryptographic credential proving I am the payments-service running in production cluster east-1."

## The standards

- **SPIFFE:** Identity specification. SPIRE is the reference runtime.
- **Cloud-native equivalents:** AWS IAM Roles for Service Accounts (IRSA), GCP Workload Identity, Azure Workload Identity, Kubernetes ServiceAccount tokens with OIDC trust.

These coexist. Most multi-cloud deployments end up running SPIFFE for cross-cloud identity and using cloud-native primitives where the trust path is internal.

## Implementation pattern

1. Workload starts. Platform attests it (running in this pod, in this namespace, in this cluster).
2. Workload requests a credential from the identity authority.
3. Identity authority issues a short-lived credential (SVID, JWT, x.509 cert) bound to the workload's identity.
4. Workload uses the credential to call other services. Receivers validate.
5. Credential expires in minutes. Workload renews.

## What this replaces

- Long-lived API keys in environment variables
- Service account passwords in vaults that workloads then read with another long-lived credential
- Mutual TLS with manually managed certificates
- Shared secrets between services

## What it doesn't replace

- Application-level authorization decisions (the workload identity tells you what service is calling, not whether that call is allowed)
- Database row-level security
- End-user identity in requests that originate from humans

## Common pitfalls

- Skipping platform attestation and just trusting whatever the workload claims it is
- Issuing workload identities with permissions that match historical API keys (carrying over over-privilege)
- Not federating SPIFFE with cloud-native identity, requiring workloads to handle multiple credential types
- Treating workload identity as a vault problem when it's an identity problem

## Zero Trust Architecture Implementation Guide
Source: https://startwithidentity.com/guides/architecture/zero-trust-architecture-implementation-guide/
Last updated: 2026-01-24

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.
- **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 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.

## FAQs

**Q: How long does a zero trust implementation take?**
A: A realistic timeline is 18-36 months for a complete deployment across a mid-to-large enterprise. However, you should see measurable security improvements within the first 3-6 months by focusing on your most critical protect surfaces.

**Q: Can I implement zero trust without replacing my firewall?**
A: Yes. Zero trust augments your existing infrastructure. Firewalls still play a role in macro-segmentation. Zero trust adds identity-aware policies, microsegmentation, and continuous verification on top of existing network controls.

**Q: What is the difference between ZTNA and zero trust?**
A: Zero Trust Network Access (ZTNA) is a specific technology, typically a cloud-hosted reverse proxy, that provides identity-aware access to applications without a VPN. It is one component of a broader zero trust architecture, not the whole thing.

**Q: Does zero trust eliminate the need for a VPN?**
A: In most cases, yes. ZTNA replaces VPN for application access. However, some use cases (e.g., raw network access for troubleshooting) may still require a VPN. The goal is to minimize VPN usage, not necessarily eliminate it on day one.

**Q: How does zero trust affect user experience?**
A: Done well, zero trust can actually improve UX by replacing VPN logins with smooth SSO-based access. Done poorly, it introduces friction at every step. The key is invisible security: strong controls that do not interrupt the user unless risk is detected.

**Q: Is zero trust applicable to OT/ICS environments?**
A: Yes, but with caveats. Many OT devices cannot run modern agents or support mTLS. Use network-based microsegmentation and passive monitoring for OT environments, and apply identity-based controls at the boundary between IT and OT.

## Zero Trust rollout: from VPN replacement to mature program
Source: https://startwithidentity.com/guides/implementation/zero-trust-rollout/
Last updated: 2026-07-16

Zero Trust is one of the most oversold terms in security, which makes a grounded rollout plan valuable. This is a staged sequence that starts where the value actually is, identity, and ends with a mature program rather than a product you bought and hoped for.

## What Zero Trust actually is

Zero Trust is a model, not a product. NIST SP 800-207 describes it as continuous verification of identity, device, and context for every access decision, with no trust granted by network location. The product category that delivers most of it is [Zero Trust Network Access](https://startwithidentity.com/guides/fundamentals/what-is-zero-trust/) (ZTNA), which brokers access to individual applications instead of dropping a connected user onto a flat internal network.

## 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 for admins. Conditional access policies written and tested in report-only mode before enforcement. This quarter is the one that 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 rather than network position.

**Quarters 3-4: ZTNA expansion.** Onboard the next tranche of applications, roughly twenty at a time. 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. Establish device posture signals as an input to access decisions.

**Year 2: Microsegmentation and continuous monitoring.** Add east-west controls to limit blast radius after a compromise, so a foothold in one segment does not become free movement across the estate. Integrate identity and access telemetry with the security operations center for real-time policy decisions.

**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."

## 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, Netskope, Palo Alto Prisma, and Tailscale represent different price-performance points; compare them in the [best Zero Trust tools](https://startwithidentity.com/rankings/best-zero-trust-tools/) ranking and the [top ZTNA tools](https://startwithidentity.com/articles/top-8-zero-trust-network-access-tools/) article. Microsegmentation is a separate purchase (Illumio, Akamai Guardicore, 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/).

## 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 you pay for the new model without retiring the old risk
- 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

## Decentralized Identifiers (DID)
Source: https://startwithidentity.com/standards/decentralized-identifiers-did/
Last updated: 2026-07-06

## 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/) that holds the public keys and service endpoints needed to interact with the subject, whether that subject is 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-core/).

## How it works

- **Resolution:** software resolves a DID to its DID document using the rules of the DID's method. The document lists verification methods (public keys) and services.
- **Control:** the subject holds the private keys, so only they can update the document or sign as the DID. There is no provider to revoke or reassign it.
- **Anchoring credentials:** an issuer's DID lets a [verifier](https://startwithidentity.com/glossary/issuer-holder-verifier/) fetch the issuer's public key and check a [verifiable credential](https://startwithidentity.com/standards/verifiable-credentials/) signature without a central directory.

## DID methods

The `method` segment determines how a DID is created and resolved. They fall into two broad camps, covered in depth in our [DID methods compared](https://startwithidentity.com/guides/decentralized-identity/did-methods-compared/) guide:

- **Ledgerless:** `did:web` (anchored to a domain over HTTPS, the pragmatic enterprise default), `did:key` (a self-contained key, no network lookup), `did:jwk`.
- **Ledger-anchored:** `did:ion` (Bitcoin, Sidetree), `did:ethr` (Ethereum), `did:indy` (Hyperledger Indy). These add decentralization at the cost of ledger dependency. See [DID method](https://startwithidentity.com/glossary/did-method/).

## Status

DID Core 1.0 has been a W3C Recommendation since July 2022. The DID Working Group continues to maintain resolution and specific method specifications. In practice, `did:web` dominates enterprise deployments because it needs no blockchain, while wallet and government programs increasingly reference DIDs alongside [SD-JWT VC](https://startwithidentity.com/standards/verifiable-credentials/) issuance.

## When to use it

Use DIDs when you need issuer and holder identifiers that are portable and not tied to one provider's namespace. For most enterprises starting out, `did:web` gives the benefits of the standard with the operational simplicity of DNS and TLS you already run.

## Pitfalls

- Key management and recovery are your responsibility; losing control of the keys means losing control of the DID.
- Method choice matters: ledger-anchored methods bring governance and cost considerations that `did:web` avoids.
- A DID is only an identifier. Trust still comes from the credentials issued and the [trust registries](https://startwithidentity.com/glossary/trust-registry/) that vouch for issuers.

## Related

Guides: [what is decentralized identity](https://startwithidentity.com/guides/fundamentals/what-is-decentralized-identity/), [DID methods compared](https://startwithidentity.com/guides/decentralized-identity/did-methods-compared/). Standards: [Verifiable Credentials](https://startwithidentity.com/standards/verifiable-credentials/), [OpenID4VC](https://startwithidentity.com/standards/openid4vc/). Glossary: [DID](https://startwithidentity.com/glossary/decentralized-identifier/), [DID document](https://startwithidentity.com/glossary/did-document/), [DID method](https://startwithidentity.com/glossary/did-method/). Vendors: [decentralized identity](https://startwithidentity.com/vendors/decentralized-identity/).

## 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-07-06

## 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). Its headline requirement is that every EU member state must offer citizens and residents a **European Digital Identity Wallet (EUDI Wallet)**: a state-recognized [digital identity wallet](https://startwithidentity.com/glossary/digital-wallet/) for holding and presenting identity attributes 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, so it sits at the intersection of a standard and a regulation.

This page covers the technical framework. For the legal picture across countries, see the [identity regulations hub](https://startwithidentity.com/regulations/) and the EU entry there.

## How it works

- **The wallet:** each member state issues or certifies a wallet app. Citizens store a Person Identification Data credential plus attribute credentials (diplomas, licenses, payment mandates). See [EUDI Wallet](https://startwithidentity.com/glossary/eudi-wallet/).
- **The ARF:** the Architecture and Reference Framework pins the technical choices, mandating [OpenID4VCI and OpenID4VP](https://startwithidentity.com/standards/openid4vc/) for issuance and presentation, [SD-JWT VC](https://startwithidentity.com/standards/verifiable-credentials/) and [mDL](https://startwithidentity.com/standards/iso-18013-5-mdl/) as credential formats, and [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/) so citizens share the minimum needed.
- **Relying parties:** many services, including "very large online platforms," will be required to accept the wallet where users choose to use it, which forces verifier-side adoption at scale.

## Status

The regulation entered into force in May 2024. Member states are building and certifying wallets against the ARF, with the obligation to make them available to all citizens landing in 2026, followed by phased relying-party acceptance. Large-scale pilots (the EU's LSPs) have tested payments, travel, education, and organizational identity. This is why [OpenID4VC](https://startwithidentity.com/standards/openid4vc/) interoperability profiles matured quickly.

## Why it matters

eIDAS 2.0 solves decentralized identity's chicken-and-egg problem by legislating both issuance (state-issued wallets) and acceptance (mandated relying parties). For any organization operating in or serving the EU, wallet acceptance is shifting from optional to expected, and the design choices in the ARF are becoming de facto global reference points for [reusable identity and KYC](https://startwithidentity.com/guides/decentralized-identity/reusable-identity-and-kyc-with-verifiable-credentials/).

## Pitfalls

- Timelines slip; member-state wallets and relying-party readiness are arriving unevenly.
- The regulation sets outcomes and the ARF sets architecture, but conformance and certification detail is still settling. Build to the mandated protocols and watch national profiles.
- Privacy safeguards (unlinkability, no over-collection) are central to the debate; design to the minimization intent, not just the letter.

## 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/). Standards: [OpenID4VC](https://startwithidentity.com/standards/openid4vc/), [Verifiable Credentials](https://startwithidentity.com/standards/verifiable-credentials/), [mDL](https://startwithidentity.com/standards/iso-18013-5-mdl/). Directories: [regulations by country](https://startwithidentity.com/regulations/), [digital IDs by country](https://startwithidentity.com/digital-ids/). Glossary: [EUDI Wallet](https://startwithidentity.com/glossary/eudi-wallet/), [eIDAS](https://startwithidentity.com/glossary/eidas/).

## 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-06-16

## 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.

## Status

FAPI 1.0 is widely deployed in open banking regimes (UK, Brazil, Australia and others). FAPI 2.0 simplifies and strengthens the profile and is the current target for new implementations.

## 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 FAPI certification on any platform you rely on.

## 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/), [OpenID Connect](https://startwithidentity.com/standards/openid-connect/).

## 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/).

## ISO/IEC 18013-5 Mobile Driver's License (mDL)
Source: https://startwithidentity.com/standards/iso-18013-5-mdl/
Last updated: 2026-07-06

## 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. It is one of the most widely deployed [verifiable credential](https://startwithidentity.com/standards/verifiable-credentials/) formats in the world because governments are shipping it into consumer wallets like Apple Wallet and Google Wallet. The companion standard **18013-7** extends presentation to online and unattended scenarios.

## How it works

- **Data model:** the license is a signed set of data elements (name, age, portrait, license class) using a mobile security object that a verifier checks against the issuing authority's public key.
- **Selective disclosure:** the holder can share only what a transaction needs. Buying alcohol can reveal an over-21 flag and a photo without exposing the address or document number. This maps directly to [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/) and the [mobile driver's license](https://startwithidentity.com/glossary/mobile-drivers-license/) glossary entry.
- **In person (18013-5):** presentation over Bluetooth or NFC to a reader, working offline.
- **Online (18013-7):** presentation to a website or app, increasingly bridged to [OpenID4VP](https://startwithidentity.com/standards/openid4vc/) so mDLs flow through the same rails as other credentials.

## Status

ISO/IEC 18013-5 was published in 2021 and 18013-7 in 2024. In the United States, the [AAMVA](https://www.aamva.org/) digital trust ecosystem and TSA acceptance at airport checkpoints have driven rollout across a growing list of states. The EU's [EUDI Wallet](https://startwithidentity.com/standards/eidas-2-eudi-wallet/) references mDL alongside [SD-JWT VC](https://startwithidentity.com/standards/verifiable-credentials/). Track which jurisdictions have shipped in the [digital IDs by country](https://startwithidentity.com/digital-ids/) directory.

## When to use it

mDL matters to any verifier that checks government ID: age-restricted retail, [identity verification and KYC](https://startwithidentity.com/vendors/identity-verification/), travel, and account onboarding. Accepting mDL can replace scanning and storing a full ID image with a signed, minimal, tamper-evident presentation, which reduces both fraud and data-retention risk.

## Pitfalls

- Reader and relying-party support is still uneven; plan a fallback to physical or document-scan verification.
- In-person and online profiles differ; build for the presentation channel you actually need.
- mDL is an ID document format, not a full identity system. Pair it with your existing [identity verification](https://startwithidentity.com/guides/decentralized-identity/reusable-identity-and-kyc-with-verifiable-credentials/) workflow.

## Related

Guides: [reusable identity and KYC with verifiable credentials](https://startwithidentity.com/guides/decentralized-identity/reusable-identity-and-kyc-with-verifiable-credentials/). Directories: [digital IDs by country](https://startwithidentity.com/digital-ids/), [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/). Glossary: [mobile driver's license](https://startwithidentity.com/glossary/mobile-drivers-license/), [digital identity wallet](https://startwithidentity.com/glossary/digital-wallet/).

## 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/).

## OAuth 2.0
Source: https://startwithidentity.com/standards/oauth-2-0/
Last updated: 2026-06-16

## What it is

OAuth 2.0 (RFC 6749) is the authorization framework behind "Sign in with..." and "Connect your account" buttons. It lets a user grant an application limited, scoped access to their resources at another service without sharing a password. Crucially, 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.

## How it works

The core actors are the resource owner (user), the client (app), the authorization server, and the resource server (API). The client redirects the user to the authorization server, the user consents, and the client receives an access token (and often a refresh token) it presents to the API.

- **Access token:** a short-lived credential scoped to specific permissions.
- **Refresh token:** exchanged for new access tokens without re-prompting the user.
- **Scopes:** the permissions being requested, such as `read:calendar`.
- **Grants (flows):** the [authorization code flow](https://startwithidentity.com/glossary/authorization-code-flow/) with [PKCE](https://startwithidentity.com/glossary/pkce/) for user-facing apps, and the [client credentials grant](https://startwithidentity.com/glossary/client-credentials/) for machine-to-machine.

## Status

RFC 6749 dates to 2012 and is universally deployed. The IETF published the OAuth 2.0 Security Best Current Practice as RFC 9700 in 2025, and [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/) consolidates that guidance into one specification.

## Pitfalls

- Treating an access token as authentication. Use OpenID Connect for login.
- The implicit and resource-owner-password grants are discouraged; do not use them in new builds.
- Always use PKCE, validate redirect URIs strictly, and keep tokens short-lived.

## Related

Glossary: [OAuth](https://startwithidentity.com/glossary/oauth/), [scopes and claims](https://startwithidentity.com/glossary/claims/), [token exchange](https://startwithidentity.com/glossary/token-exchange/). Guide: [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-06-16

## 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.

## 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. 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.

## 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.

## Related

[OAuth 2.0](https://startwithidentity.com/standards/oauth-2-0/), [OpenID Connect](https://startwithidentity.com/standards/openid-connect/), and the guide [OAuth vs OIDC](https://startwithidentity.com/guides/fundamentals/oauth-vs-oidc/).

## 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/).

## OpenID Connect (OIDC)
Source: https://startwithidentity.com/standards/openid-connect/
Last updated: 2026-06-16

## 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 and who they are. It is the modern foundation for single sign-on across consumer apps, mobile, and APIs.

## How it works

OIDC introduces the **ID token**, a signed [JWT](https://startwithidentity.com/glossary/jwt/) containing [claims](https://startwithidentity.com/glossary/claims/) about the authenticated user (subject identifier, name, email, authentication time). The app validates the token's signature against the provider's published keys ([JWKS](https://startwithidentity.com/glossary/jwks/)) and reads the claims. A standard userinfo endpoint returns additional profile data.

- **ID token:** proof of authentication, as a JWT.
- **Access token:** still OAuth, for calling APIs.
- **Discovery:** providers publish configuration at a well-known URL so clients can self-configure.

## Status

OIDC Core 1.0 is final and ubiquitous, supported by every major identity provider. It was republished as ITU-T Recommendation X.1285 in 2025. Extensions like the Shared Signals Framework and [CIBA](https://startwithidentity.com/glossary/ciba/) continue to evolve.

## 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.

## Pitfalls

- Always validate the ID token signature, issuer, audience, and expiry.
- Do not confuse the ID token (authentication) with the access token (authorization).

## Related

Guides: [OAuth vs OIDC](https://startwithidentity.com/guides/fundamentals/oauth-vs-oidc/), [SAML vs OIDC](https://startwithidentity.com/guides/fundamentals/saml-vs-oidc/). Glossary: [OIDC](https://startwithidentity.com/glossary/oidc/), [ID token](https://startwithidentity.com/glossary/id-token/).

## 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-07-06

## What it is

OpenID for Verifiable Credentials (OpenID4VC) is a family of [OpenID Foundation](https://openid.net/sg/openid4vc/) protocols that move [verifiable credentials](https://startwithidentity.com/standards/verifiable-credentials/) between issuers, wallets, and verifiers. If DIDs 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 actually 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 it reuses infrastructure and mental models that identity teams already have.

## The pieces

- **[OpenID4VCI](https://startwithidentity.com/glossary/openid4vci/) (Issuance):** how an issuer delivers a credential to a holder's wallet, including the credential offer, authorization, and the credential endpoint.
- **[OpenID4VP](https://startwithidentity.com/glossary/openid4vp/) (Presentation):** how a verifier requests, and a wallet returns, a [verifiable presentation](https://startwithidentity.com/glossary/verifiable-presentation/), including cross-device flows via QR code.
- **SIOPv2 (Self-Issued OpenID Provider):** lets a wallet act as its own OpenID Provider so a holder can authenticate with a [DID](https://startwithidentity.com/standards/decentralized-identifiers-did/) instead of a hosted IdP.
- **HAIP (High Assurance Interoperability Profile):** a tightly scoped profile that pins down formats (SD-JWT VC, mDL) and crypto so independent implementations interoperate.

## How it works

An issuer sends a credential offer, the wallet runs an OAuth authorization flow, and the credential endpoint returns a signed [SD-JWT VC](https://startwithidentity.com/standards/verifiable-credentials/) or [mDL](https://startwithidentity.com/standards/iso-18013-5-mdl/). Later, a verifier sends an OpenID4VP request describing what it needs, the wallet prompts the holder, and returns only the disclosed claims using [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/). Because it is layered on OAuth, existing authorization servers and libraries can be extended rather than replaced.

## Status

The **HAIP 1.0** profile reached Final in December 2025, a milestone that makes real interoperability testable. OpenID4VCI and OpenID4VP are the mandated protocols for the EU's [EUDI Wallet](https://startwithidentity.com/standards/eidas-2-eudi-wallet/), which is the single largest deployment driver. Wallet vendors, government programs, and [decentralized identity platforms](https://startwithidentity.com/vendors/decentralized-identity/) are converging on this family.

## When to use it

Use OpenID4VC when you are building issuance or verification into a product and want a standards-based path that verifiers and wallets will accept. Choosing it over a proprietary credential exchange is what keeps your credentials portable across the ecosystem, especially anything that must interoperate with EU wallets.

## Pitfalls

- The family is broad; align on a profile (HAIP) and credential format up front rather than the base specs alone.
- SIOPv2 and DID-based flows are less mature than the issuance and presentation cores; check what your target wallets actually support.

## Related

Guides: [verifiable credentials implementation guide](https://startwithidentity.com/guides/decentralized-identity/verifiable-credentials-implementation-guide/), [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/), [eIDAS 2 / EUDI Wallet](https://startwithidentity.com/standards/eidas-2-eudi-wallet/). Glossary: [OpenID4VCI](https://startwithidentity.com/glossary/openid4vci/), [OpenID4VP](https://startwithidentity.com/glossary/openid4vp/). 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/).

## SAML 2.0
Source: https://startwithidentity.com/standards/saml-2-0/
Last updated: 2026-06-16

## 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.

## 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.

## 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.

## 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-09-20

## What it is

SCIM, the System for Cross-domain Identity Management, is the open standard for automating the user 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. It is defined by RFC 7643 (the schema) and RFC 7644 (the protocol).

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.

## 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/).

## Verifiable Credentials & SD-JWT
Source: https://startwithidentity.com/standards/verifiable-credentials/
Last updated: 2026-07-06

## What it is

A Verifiable Credential (VC) is a cryptographically signed, tamper-evident digital credential that follows the [W3C VC Data Model](https://www.w3.org/TR/vc-data-model-2.0/). It is the data format at the heart of [decentralized identity](https://startwithidentity.com/guides/fundamentals/what-is-decentralized-identity/): a portable, machine-verifiable version of the paper and plastic credentials people carry today, from a diploma to a driver's license to a proof of employment.

The model defines three roles, the [issuer, holder, verifier](https://startwithidentity.com/glossary/issuer-holder-verifier/) trust triangle:

- An **issuer** signs a credential and gives it to a subject.
- A **holder** keeps it in a [wallet](https://startwithidentity.com/glossary/digital-wallet/) and controls when to present it.
- A **verifier** checks the signature, the issuer, and the credential status, without calling back to the issuer.

**SD-JWT** (Selective Disclosure JWT) is the IETF token format increasingly used to carry these credentials in a way that supports [selective disclosure](https://startwithidentity.com/glossary/selective-disclosure/).

## How it works

- **Issuance (issuer to holder):** an authority issues a signed credential to the user's wallet. Keys are often anchored by a [decentralized identifier (DID)](https://startwithidentity.com/standards/decentralized-identifiers-did/), so the verifier can resolve the issuer's public key without a central registry. The [OpenID4VCI](https://startwithidentity.com/glossary/openid4vci/) protocol standardizes this exchange.
- **Presentation (holder to verifier):** the holder assembles a [verifiable presentation](https://startwithidentity.com/glossary/verifiable-presentation/) and shares only what is needed. With selective disclosure they can prove they are over 18 without revealing their birth date. [OpenID4VP](https://startwithidentity.com/glossary/openid4vp/) standardizes the request and response.
- **Formats:** the two dominant credential formats are **SD-JWT VC** (JWT-based, favored by eIDAS 2.0 and IETF work) and **W3C VC with Data Integrity proofs** (JSON-LD, often paired with [BBS signatures](https://startwithidentity.com/glossary/bbs-signature/) for unlinkable disclosure). [AnonCreds](https://startwithidentity.com/glossary/anoncreds/) is a third format common in ledger-based ecosystems.
- **Revocation:** issuers publish status through a [revocation registry](https://startwithidentity.com/glossary/revocation-registry/) or status list so a verifier can tell whether a credential is still valid.

## Status

The W3C published the **VC Data Model 2.0** family as Recommendations in May 2025. **SD-JWT** and **SD-JWT VC** are active IETF drafts (draft-16 in 2026) and are referenced directly by EU digital identity work. The [OpenID for Verifiable Credentials](https://startwithidentity.com/standards/openid4vc/) protocols reached a High Assurance Interoperability Profile 1.0 Final in December 2025. Adoption is accelerating through [eIDAS 2.0 and the EUDI Wallet](https://startwithidentity.com/standards/eidas-2-eudi-wallet/) and [mobile driver's licenses](https://startwithidentity.com/standards/iso-18013-5-mdl/).

## When to use it

Reach for verifiable credentials when you need **reusable, portable proof** that a holder controls: verify once and reuse many times, with the user deciding what to share. The strongest current use cases are reusable identity verification and [KYC](https://startwithidentity.com/guides/decentralized-identity/reusable-identity-and-kyc-with-verifiable-credentials/), government and cross-border ID, and workforce credentials such as certifications that should survive a job change. For plain workforce SSO, mature [federated protocols](https://startwithidentity.com/standards/openid-connect/) are still the right tool.

## Pitfalls

- The ecosystem is still consolidating; interoperability depends on shared profiles like [OpenID4VC](https://startwithidentity.com/standards/openid4vc/) and HAIP rather than the base data model alone.
- Revocation, wallet recovery, and issuer governance are the hard parts, not the signing.
- Format fragmentation (SD-JWT VC vs W3C Data Integrity vs AnonCreds) means you must pick formats your verifiers actually accept.

## 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/). Standards: [DID](https://startwithidentity.com/standards/decentralized-identifiers-did/), [OpenID4VC](https://startwithidentity.com/standards/openid4vc/), [mDL](https://startwithidentity.com/standards/iso-18013-5-mdl/). 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/). Vendors: [decentralized identity](https://startwithidentity.com/vendors/decentralized-identity/).

## 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-06-16

## What it is

WebAuthn is the W3C browser API for public-key authentication, and FIDO2 is the broader FIDO Alliance specification set (WebAuthn plus the CTAP 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.

## How it works

Instead of a shared secret, the user's device holds a private key and registers a public key with the service. At login, the service sends a challenge, the authenticator signs it after a local user gesture (biometric or PIN), and the service verifies the signature.

- **Origin binding:** the credential is bound to the website's origin, so a phishing site cannot use it. This is the core security property.
- **No shared secret:** nothing reusable is transmitted or stored server-side, so there is nothing to steal in a breach.
- **Authenticators:** platform (Face ID, Windows Hello) or roaming (a [YubiKey](https://startwithidentity.com/vendors/mfa/yubico/)).

## Status

WebAuthn Level 2 is a W3C Recommendation (2021); Level 3 is in progress. Passkeys, built on these standards, are now supported by every major operating system and browser, with billions of accounts enabled.

## 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.

## Pitfalls

- Plan account recovery and enrollment carefully; these are the steps attackers target once passwords are gone.
- Support more than one authenticator per user, and have a tested fallback.

## Related

Guide: [Passkeys 101](https://startwithidentity.com/guides/authentication/passkeys-101/), [what is passwordless](https://startwithidentity.com/guides/fundamentals/what-is-passwordless/). Glossary: [FIDO2](https://startwithidentity.com/glossary/fido2/), [WebAuthn](https://startwithidentity.com/glossary/webauthn/), [passkey](https://startwithidentity.com/glossary/passkey/). Vendors: [MFA and passwordless](https://startwithidentity.com/vendors/mfa/).

## 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/).

# 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/)

## account-recovery
Source: https://startwithidentity.com/glossary/account-recovery/
Last updated: 2026-09-21

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/)

## 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/)

## active-directory
Source: https://startwithidentity.com/glossary/active-directory/
Last updated: 2026-09-21

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/)

## 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/)

## agentic-identity
Source: https://startwithidentity.com/glossary/agentic-identity/
Last updated: 2026-08-29

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/)

## 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/)

## 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/)

## 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/rfc/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/)

## break-glass
Source: https://startwithidentity.com/glossary/break-glass/
Last updated: 2026-08-29

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/)

## caep
Source: https://startwithidentity.com/glossary/caep/
Last updated: 2026-09-21

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/)

## certificate-lifecycle
Source: https://startwithidentity.com/glossary/certificate-lifecycle/
Last updated: 2026-08-29

Discovering, issuing, renewing, and revoking TLS and other 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. As lifetimes shorten toward 47 days under the CA/Browser Forum schedule, 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: [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/)

## ciam
Source: https://startwithidentity.com/glossary/ciam/
Last updated: 2026-08-29

Customer Identity and Access Management. The identity stack for end users of a product, distinct from workforce IAM. CIAM optimizes for self-service signup, conversion, branding, and consumer-scale user volumes.

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.

See also: [what is CIAM](https://startwithidentity.com/guides/fundamentals/what-is-ciam/), [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-08-29

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/)

## 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/)

## 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-08-29

Capturing, storing, and honoring user consent for data processing and communications, often to satisfy GDPR and similar laws. Central to customer identity and preference centers.

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/)

## credential-stuffing
Source: https://startwithidentity.com/glossary/credential-stuffing/
Last updated: 2026-08-29

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/)

## 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/)

## deprovisioning
Source: https://startwithidentity.com/glossary/deprovisioning/
Last updated: 2026-08-29

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/)

## 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-08-29

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/)

## 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/)

## dpop
Source: https://startwithidentity.com/glossary/dpop/
Last updated: 2026-08-29

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/)

## 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-09-20

The analysis of behaviour and relationships across all entities in an environment, human and non-human, to establish what normal looks like and surface deviations from it. An entity is any actor with an identity: an employee, a contractor, a service account, an API key, a workload, or an AI agent.

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/)

## 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/)

## 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-08-29

A trust relationship between identity providers and service providers that lets users authenticate once at their home IdP and access applications at the other party. Federation is the foundation of cross-organization SSO.

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-08-29

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 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/), [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/)

## 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/)

## 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 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-08-29

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/), [identity verification vendors](https://startwithidentity.com/vendors/identity-verification/)

## iam
Source: https://startwithidentity.com/glossary/iam/
Last updated: 2026-08-29

Identity and Access Management. Workforce identity for employees, contractors, and partners. Covers authentication, authorization, lifecycle, and audit. Distinct from CIAM (customer identity).

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/)

## id-token
Source: https://startwithidentity.com/glossary/id-token/
Last updated: 2026-08-29

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/)

## 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/), [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-08-29

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/)

## 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/)

## 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-08-29

Granting elevated permissions only when needed, for a limited duration, and revoking them automatically. JIT eliminates 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: [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-08-29

The three lifecycle events that drive identity changes: new hires (joiner), internal transfers (mover), and departures (leaver). JML automation is a core IGA capability.

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-09-21

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/)

## 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/)

## 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/)

## mfa
Source: https://startwithidentity.com/glossary/mfa/
Last updated: 2026-08-29

Multi-Factor Authentication. Requiring two or more factors from distinct categories: something you know (password), something you have (token), something you are (biometric). Not all MFA is equal, TOTP and SMS are phishable, FIDO2 is not.

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/)

## 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-08-29

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/)

## nist-800-63
Source: https://startwithidentity.com/glossary/nist-800-63/
Last updated: 2026-08-29

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/), [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/)

## 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/)

## 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/)

## 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/)

## pam
Source: https://startwithidentity.com/glossary/pam/
Last updated: 2026-08-29

Privileged Access Management. Controls for accounts and credentials with elevated permissions. Includes credential vaulting, session brokering, session recording, and just-in-time elevation.

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/), [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/)

## 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/)

## passkey
Source: https://startwithidentity.com/glossary/passkey/
Last updated: 2026-08-29

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 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/)

## 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 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/)

## phishing-resistant-mfa
Source: https://startwithidentity.com/glossary/phishing-resistant-mfa/
Last updated: 2026-08-29

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 a proxy in the middle 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/)

## 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-08-29

Public Key Infrastructure. The system of certificate authorities, certificates, and keys that binds public keys to identities. Underpins TLS, code signing, and machine identity.

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/)

## 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/)

## provisioning
Source: https://startwithidentity.com/glossary/provisioning/
Last updated: 2026-08-29

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/)

## 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/rfc/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-08-29

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/)

## 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/)

## 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/)

## 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-08-29

System for Cross-domain Identity Management. A REST-based protocol for automating user and group provisioning across identity providers and downstream applications.

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.

See also: [SCIM 2.0](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/)

## 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/)

## 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-08-29

Centralized storage, distribution, rotation, and audit of credentials used by applications and infrastructure. Modern secrets management issues short-lived dynamic credentials rather than long-lived static secrets.

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/)

## 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/)

## 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/)

## 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-09-21

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/)

## sim-swap
Source: https://startwithidentity.com/glossary/sim-swap/
Last updated: 2026-09-29

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/)

## soc2
Source: https://startwithidentity.com/glossary/soc2/
Last updated: 2026-08-29

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/)

## 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-08-29

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/), [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/)

## sso
Source: https://startwithidentity.com/glossary/sso/
Last updated: 2026-08-29

Single Sign-On. A user authenticates once and gains access to multiple applications without re-entering credentials. Implemented with SAML or OIDC in modern deployments. Critical for workforce identity to make MFA enforcement palatable to users.

SSO is the highest-leverage 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/)

## 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/)

## token-exchange
Source: https://startwithidentity.com/glossary/token-exchange/
Last updated: 2026-08-29

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/)

## 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/)

## totp
Source: https://startwithidentity.com/glossary/totp/
Last updated: 2026-08-29

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/)

## 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/)

## 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/)

## 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-09-29

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/)

## 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/)

## workload-identity
Source: https://startwithidentity.com/glossary/workload-identity/
Last updated: 2026-08-29

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/)

## workload-identity-federation
Source: https://startwithidentity.com/glossary/workload-identity-federation/
Last updated: 2026-09-29

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/)

## x509
Source: https://startwithidentity.com/glossary/x509/
Last updated: 2026-08-29

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/)

## 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-08-29

An access model where no one holds permanent elevated rights; privileges are granted just in time and expire automatically. The strongest form of least privilege for admin access.

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-08-29

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/), [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/)