Credential Overview

Credentials are the authentication secrets that non-human identities use to prove their identity when accessing resources. VeraID provides a centralized system for issuing, encrypting, rotating, and revoking credentials across your entire NHI estate.

Credential Format

All credentials issued by VeraID follow a structured format that encodes the environment context directly into the key:

kd_{env}_{random}

Segment	Description	Values
kd	VeraID prefix (constant)	Always kd
{env}	Environment indicator	live, test, jit
{random}	Cryptographically secure random string	32 characters (a-z, A-Z, 0-9)

Environment Prefixes

Prefix	Environment	Purpose
kd_live_	Production	Production workloads with full access to live resources
kd_test_	Test	Development and staging environments with isolated scope
kd_jit_	Just-In-Time	Short-lived temporary credentials with automatic expiration

Examples

kd_live_aB3cD4eF5gH6iJ7kL8mN9oP0qR1sT2u     # Production credential
kd_test_xY9zW8vU7tS6rQ5pO4nM3lK2jI1hG0fE     # Test credential
kd_jit_tE4mP5oR6aR7yK8eY9cH0aI1nN2oW3vA      # JIT temporary credential

Danger

Credentials are displayed only once at creation time. VeraID stores only a cryptographic hash of the credential — the plaintext value cannot be retrieved after the initial response. Ensure your automation captures and securely stores the credential immediately.

Credential Types

VeraID supports six credential types to cover the full spectrum of NHI authentication patterns.

Type	Description	Typical Use Case
API_KEY	Standard API key for request authentication	REST API access, webhook signatures, service-to-service calls
JWT	JSON Web Token with embedded claims	Stateless authentication, microservice mesh, token-based flows
OAUTH_TOKEN	OAuth 2.0 access/refresh token pair	Third-party integrations, SSO-connected applications
CERTIFICATE	X.509 certificate for mTLS authentication	Service mesh, mutual TLS, infrastructure-level identity
SSH_KEY	SSH key pair for secure shell access	Git operations, server management, CI/CD deployment
TEMPORARY	Short-lived credential with automatic expiry	JIT access, break-glass scenarios, time-boxed maintenance

Credential Status

Every credential has a status that reflects its current validity.

Status	Description
ACTIVE	Credential is valid and can be used for authentication
ROTATED	Credential has been superseded by a new version; may still be valid during a grace period
REVOKED	Credential has been permanently invalidated and cannot be used
EXPIRED	Credential has passed its expiresAt timestamp and is no longer valid

                rotate                     grace period ends
┌──────────┐ ──────────► ┌──────────┐ ──────────────────────► ┌──────────┐
│  ACTIVE  │             │ ROTATED  │                         │ REVOKED  │
└──────────┘             └──────────┘                         └──────────┘
      │                                                            ▲
      │                    revoke                                  │
      ├────────────────────────────────────────────────────────────┘
      │
      │                  time passes
      └──────────────────────────────────► ┌──────────┐
                                           │ EXPIRED  │
                                           └──────────┘

Encryption at Rest

All credentials are encrypted at rest using AES-256 envelope encryption. This industry-standard approach uses two layers of encryption to protect credential values.

How Envelope Encryption Works

1. Data Encryption Key (DEK) — Each credential is encrypted with a unique AES-256 key generated at creation time. The DEK never leaves the encryption service.
2. Key Encryption Key (KEK) — The DEK is itself encrypted by a master key managed in a hardware security module (HSM). The encrypted DEK is stored alongside the encrypted credential.
3. Decryption — When a credential needs to be verified, the KEK decrypts the DEK, which in turn decrypts the credential value. This operation occurs entirely in memory and is never logged.

Note

VeraID does not store plaintext credentials. The verification endpoint compares an incoming credential against the stored hash — the encrypted value is only used for rotation workflows where the system must issue a replacement.

Credential Features

TTL and Expiration

Every credential supports an optional expiresAt timestamp. When set, the credential automatically transitions to EXPIRED status after the specified time. This is mandatory for TEMPORARY and jit-prefixed credentials.

{
  "type": "TEMPORARY",
  "expiresAt": "2026-03-19T18:00:00Z",
  "ttlSeconds": 3600
}

Usage Limits

Credentials can be configured with usage limits to restrict the total number of times they can be used for authentication. Once the limit is reached, the credential is automatically revoked.

{
  "usageLimit": 1000,
  "usageCount": 247
}

Scoped Access

Credentials can be scoped to specific API endpoints, resource types, or actions. Scoped credentials provide defense-in-depth by ensuring that even a compromised credential can only access a limited set of resources.

{
  "scopes": [
    "identities:read",
    "credentials:read",
    "audit:read"
  ]
}

Tip

Follow the principle of least privilege when assigning scopes. A credential used for monitoring should not have identities:write or credentials:rotate scopes.

Credential Object

A complete credential object includes the following fields:

{
  "id": "crd_9f24d67e-a1b3-4c5d-8e7f-2a3b4c5d6e7f",
  "identityId": "idt_3a1f8c29-b7d4-4e2a-9c8f-1d5e7a2b4c6d",
  "type": "API_KEY",
  "status": "ACTIVE",
  "prefix": "kd_live_aB3c",
  "lastFour": "T2u",
  "scopes": ["identities:read", "credentials:read"],
  "usageLimit": 10000,
  "usageCount": 1423,
  "expiresAt": "2026-06-19T00:00:00Z",
  "lastUsedAt": "2026-03-19T08:42:11Z",
  "lastUsedIP": "10.0.1.42",
  "rotationPolicy": {
    "intervalDays": 90,
    "gracePeriodHours": 24,
    "notifyDaysBefore": 7
  },
  "createdAt": "2026-01-01T00:00:00Z",
  "updatedAt": "2026-03-18T22:15:44Z"
}

Note

The prefix and lastFour fields allow you to identify credentials in logs and on the dashboard without exposing the full key. The full credential value is only returned in the creation response.

Creating a Credential

Issue a new credential for an existing identity:

curl -X POST https://app.veraid.io/api/v1/credentials \
  -H "Authorization: Bearer kd_live_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "identityId": "idt_3a1f8c29-b7d4-4e2a-9c8f-1d5e7a2b4c6d",
    "type": "API_KEY",
    "scopes": ["identities:read", "credentials:read"],
    "expiresAt": "2026-06-19T00:00:00Z",
    "usageLimit": 10000,
    "rotationPolicy": {
      "intervalDays": 90,
      "gracePeriodHours": 24,
      "notifyDaysBefore": 7,
      "notifyChannels": ["email", "webhook"]
    }
  }'

Creation Response

The creation response is the only time the full credential value is returned:

{
  "id": "crd_9f24d67e-a1b3-4c5d-8e7f-2a3b4c5d6e7f",
  "credential": "kd_live_aB3cD4eF5gH6iJ7kL8mN9oP0qR1sT2u",
  "type": "API_KEY",
  "status": "ACTIVE",
  "prefix": "kd_live_aB3c",
  "lastFour": "T2u",
  "expiresAt": "2026-06-19T00:00:00Z",
  "createdAt": "2026-03-19T10:00:00Z"
}

Caution

Store the credential value securely in your secrets manager immediately. VeraID cannot recover or display this value after the initial response. If lost, you must rotate or create a new credential.

What’s Next

• Credential Rotation — Configure automated rotation with zero-downtime grace periods
• Credential Sync — Automatically push rotated credentials to external secret stores
• Credential Verification — Validate credentials at runtime via the verification API