A customer identity platform signs the tokens every customer-facing application trusts, so whoever controls its admin console, management API or signing keys can sign in as any customer, change any account or switch off the defences that stop account takeover. Most CIAM security work focuses on the customer journey: registration, sign-in, recovery and fraud. The platform's own control plane gets less attention, yet it is where a single stolen admin session or leaked management API secret becomes a breach of millions of accounts. This guide is for identity engineers, platform owners and security architects who run a hosted or self-managed CIAM service. It covers tenant administrators, management API clients, token signing keys, custom domains, extensibility code, the platform's own logs and the lifecycle. It is vendor-neutral: confirm exact setting names in your product's documentation. For customer sign-in design, see the Customer IAM (CIAM) Guide.
Key takeaways
- The signing key is the crown jewel. Anyone holding a token signing private key can forge valid tokens for any customer; keep it in hardware-backed or platform-managed storage, rotate it and be ready to revoke it quickly.
- Management API clients are privileged non-human identities. A back-end client that can read and update every user profile is as powerful as a tenant administrator and needs the same scoping, ownership and monitoring.
- Tenant administrators need workforce-grade controls. Separate admin accounts, phishing-resistant MFA, few standing super-admins and no shared logins.
- Extensibility code runs inside the trust boundary. Hooks, actions and custom scripts can read credentials and change token claims, so treat them as production code with review and secrets handling.
- Watch configuration, not just sign-ins. Disabled MFA policies, new redirect URIs, new connections and new admin roles are the changes attackers make; alert on them from outside the platform.
Why the CIAM control plane is a high-value target
Under NIST SP 800-63C-4, the identity provider signs the assertions relying parties trust, using approved cryptography. If that signing material is stolen, relying parties cannot tell forged assertions from real ones. The Microsoft Storm-0558 incident showed this in practice: a stolen consumer account signing key was used to forge tokens. See the Microsoft Storm-0558 Key Breach 2023. The Okta support system breach showed a second route: a compromised support system exposed customer session material uploaded for troubleshooting. See the Okta Support System Breach 2023.
The component table reflects a common architecture and is NHI Mgmt Group's view, not a description of any one product.
| Component | What it holds or can do | If an attacker controls it | Primary control |
|---|---|---|---|
| Admin console | Policies, connections, applications, MFA and bot settings, admin roles | Disables MFA or bot defences, adds redirect URIs, creates admins | SSO for admins, phishing-resistant MFA, least-privilege roles |
| Management API and its clients | Create, read, update and delete users; change configuration | Bulk export of customer profiles, takeover by changing email or MFA factors | Narrow scopes, private key client authentication, IP restriction |
| Token signing keys | Sign ID tokens, access tokens and SAML assertions | Forges tokens for any customer (T1606) | Hardware-backed storage, rotation, published key set hygiene |
| Application client secrets | Authenticate confidential clients at the token endpoint | Impersonates an application, obtains tokens | Private key JWT or mutual TLS, rotation |
| Extensibility code and its secrets | Runs during sign-in; may call internal APIs with stored secrets | Steals credentials in flight, injects claims (T1556) | Code review, secrets store, change control |
| Custom domain and DNS | Hosts login pages under your brand | Phishing on a trusted domain, certificate misuse | DNS change control, certificate monitoring |
| Audit and log streams | Evidence of sign-ins and admin changes | Stops log export to hide activity (T1685) | Export to a SIEM administrators cannot alter |
Tenant administrators
- Federate admin sign-in: sign administrators in through your workforce identity provider rather than local CIAM accounts, so joiners, movers and leavers and conditional access apply. Keep one documented break-glass local admin. See the Break-Glass Account Guide.
- Phishing-resistant MFA: require FIDO2 security keys or platform passkeys for every admin. See the Phishing-Resistant MFA Guide.
- Role design: separate tenant owner, configuration editor, user support (read profile, reset factors on request), security analyst (read logs) and developer (applications in non-production only). Most CIAM products offer predefined roles; map yours to them and remove everyone from the top role who does not need it.
- Support is a takeover path: the support role that can reset MFA or change an email address is how help desk social engineering becomes account takeover. Require a ticket, customer verification and a second approver for high-value accounts. See the Help Desk Identity Verification Policy Template.
- Vendor support access: know whether the vendor's staff can access your tenant, how you approve it and how you see it in logs. Never upload browser session captures (HAR files) without removing cookies and tokens first.
- Admin devices: follow the NCSC secure system administration principles and use privileged access workstations for tenant owners. See the Privileged Access Workstations Guide.
Management API clients and application secrets
Back-end systems use the management API to create accounts, sync profiles, delete users and build support tools. Each client is a non-human identity, and the scopes it is granted usually cover every customer in the tenant.
| Client | Typical needs | Avoid | Credential pattern |
|---|---|---|---|
| Registration or profile service | Create users, update profile attributes | Delete users, change MFA factors, read all users | Private key JWT client authentication, scoped token |
| Support portal back end | Read profile, trigger password reset, unenrol a factor | Change email without verification, bulk read | Separate client, per-agent attribution passed through |
| Data sync or CRM connector | Read selected attributes | Full profile including factors and metadata | Read-only scope, attribute filtering |
| Infrastructure as code pipeline | Change tenant configuration | Standing access from developer laptops | Workload identity federation from the pipeline, approval gates |
| Customer-facing applications | Authenticate at the token endpoint | Shared client secrets across environments | Private key JWT or mutual TLS (RFC 9700 recommends sender-constrained and asymmetric methods) |
- One client per system: never share a management client between applications; you cannot attribute or revoke it cleanly.
- Short-lived tokens: management API access tokens should expire in minutes, not days, and be requested at run time rather than stored.
- Prefer asymmetric client authentication: RFC 9700, the OAuth 2.0 Security Best Current Practice, recommends asymmetric methods such as private key JWT or mutual TLS for client authentication. Where only secrets are available, keep them in a secrets manager and rotate them. See the OAuth 2.0 Security BCP (RFC 9700) Guide.
- Inventory: record every client with owner, scopes, credential type and last use; remove clients unused for 90 days (our suggested default). See the API Key Management Guide.
Token signing keys
OpenID Connect Core 1.0 section 10.1.1 describes rotation: the signer publishes its public keys in a JWK Set at its jwks_uri, puts the key ID (kid) in each signed message, adds new keys over time and can switch whenever it chooses; a verifier that sees an unknown kid re-fetches the set, and recently retired keys stay published for a reasonable transition period. NIST SP 800-63C-4 (August 2025) section 3.6 requires identity providers to store signing keys securely subject to FIPS 140 requirements, and requires key updates to follow the process in the trust agreement over an authenticated protected channel.
- Know who holds the key: for hosted CIAM, find out whether the provider manages signing keys, whether you can bring your own, whether keys are in hardware security modules and how fast the provider can revoke one.
- Separate keys by environment: development, test and production never share signing keys or tenants.
- Rotate on a schedule and on demand: rotate signing keys at a planned interval and rehearse an emergency rotation, including relying parties that cache keys. See the JWKS and Signing Key Rotation Guide.
- Retire old keys from the key set: keep a retired key published only for the transition period; a key left in the set indefinitely remains trusted by every relying party, and a compromised key must be removed at once.
- Relying parties validate properly: check issuer, audience, expiry and algorithm, and never accept keys or algorithms from the token header alone. See the JWT Security Guide.
For self-managed CIAM, store signing keys in an HSM or cloud key management service and restrict the sign operation to the token service identity. See Securing the cloud key management service (KMS) itself and the HSM Deployment and Operations Guide.
Configuration that attackers change
| Setting | Abuse | Control |
|---|---|---|
| Redirect URIs and allowed origins | Add an attacker URI to capture authorisation codes or tokens | Exact string matching (required by RFC 9700), change approval, alert on new entries |
| Identity provider connections (social, enterprise, SAML) | Add a connection they control and link it to existing accounts | Change approval, verified email before account linking |
| MFA, step-up and bot or breached password policies | Disable to enable credential stuffing (T1110.004) | Alert on any downgrade, policy as code |
| Token lifetimes and refresh policy | Lengthen to keep stolen tokens alive | Maximum values in policy as code |
| Custom claims and extensibility code | Add roles or entitlements to tokens, exfiltrate credentials | Code review, signed deployments, secrets store |
| Log streams and webhooks | Redirect or stop logs | Alert on change, heartbeat from the SIEM |
Manage tenant configuration as code where your platform supports it: changes go through review, the pipeline identity applies them, and drift from the repository raises an alert. Custom login domains need the same care; protect the DNS records and watch for dangling entries. See the Subdomain Takeover and Dangling DNS Guide.
The platform's own logs
| Event | Why it matters | Alert? |
|---|---|---|
| Admin role granted, admin created, admin MFA reset | Persistence in the control plane | Always |
| Management client created or new scope granted | New privileged NHI | Always |
| Signing key added, rotated or revoked | Key compromise or unplanned change | Always |
| Policy downgrade (MFA, bot, breached password, lockout) | Preparation for account takeover | Always |
| Bulk user export or high-volume profile reads | Customer data theft | Above a set volume |
| Mass email or factor changes | Takeover at scale | Above a set volume |
| Log stream changed or paused | Hiding activity (T1685) | Always |
Stream audit and sign-in logs to a SIEM or archive the CIAM administrators cannot alter (NIST SP 800-53 AU-9(2)); hosted services often keep logs only for a short period. The CISA and FBI Secure by Demand guide asks providers to include security logs in the baseline product, covering configuration changes and sign-in and token activity, and to keep them for at least six months. Alert on silence from the SIEM side. See the Identity Threat Hunting Guide.
Lifecycle: buy, deploy, run, retire
| Stage | Security actions |
|---|---|
| Buy | Ask the Secure by Demand questions (SSO for admins at no extra cost, MFA by default, logs in the base product, vulnerability disclosure policy, SBOM). Ask how signing keys are stored, who at the vendor can access tenants, and how fast keys can be revoked. See the CIAM Buyer's Guide. |
| Deploy | Separate tenants per environment; federate admin sign-in; configuration as code from day one; log streaming before go-live. See the Customer identity (CIAM) platform rollout playbook. |
| Run | Quarterly review of admins, management clients, scopes, redirect URIs and connections; planned key rotation; emergency rotation drill once a year (our recommendation). |
| Retire | Migrate users and hashes under contract; revoke management clients and secrets; remove signing keys from published key sets; delete the tenant and obtain written deletion confirmation; keep audit logs for your retention period. See the Customer identity (CIAM) platform migration playbook. |
Test changes such as narrowing management scopes in a non-production tenant first, then in production for one client at a time; roll back by restoring the previous configuration from the repository.
Decision guidance: hosted or self-managed
- Hosted CIAM: the provider runs infrastructure, patching and key storage; you own admins, clients, configuration and logs. Your key risk is the provider's own support and key handling, so contract for access transparency and incident notification.
- Self-managed: you control keys and data location but must run HSMs, patching, availability and the full logging stack. Suits regulated sectors with a mature platform team.
- Small organisations: start with federated admin sign-in, phishing-resistant MFA, one management client per system and log streaming; these four controls close most of the control plane risk.
Detection and measurement
- Number of standing tenant owners (target: two or three) and percentage of admins with phishing-resistant MFA (target: 100 per cent).
- Management clients with an owner, scoped permissions and use in the last 90 days, as a percentage of all clients.
- Days since last signing key rotation and time taken in the last emergency rotation drill.
- Configuration drift events between repository and tenant, and time to resolve.
- Time to detect a policy downgrade or new admin, measured in a test.
- Percentage of confidential clients using private key JWT or mutual TLS rather than shared secrets.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ATT&CK threat addressed |
|---|---|---|---|
| Tenant administrators | AC-2, AC-6(5), IA-2(1) | PR.AA-05 | T1078.004 Cloud Accounts |
| Management API clients | IA-5, AC-6 | PR.AA-01 | T1528 Steal Application Access Token |
| Signing keys | SC-12, SC-13 | PR.DS-01 | T1606 Forge Web Credentials, T1552.004 Private Keys |
| Configuration and extensibility | CM-6, SI-7 | PR.PS-04 | T1556 Modify Authentication Process |
| Audit log export | AU-6, AU-9(2), AC-6(9) | DE.CM-01 | T1685 Disable or Modify Tools |
| Provider and support access | SA-9, SR-3 | GV.SC-07 | T1199 Trusted Relationship |
Common failure patterns
- A god-mode management client: one client with every scope, a static secret in several services and no owner.
- Local admin accounts with SMS codes: tenant owners sign in outside workforce SSO with phishable MFA.
- Signing keys never rotated: nobody knows how to rotate, so a suspected leak cannot be handled quickly. The Storm-0558 case shows the cost of a signing key that stays usable.
- Session data shared with support: browser captures with live session cookies sent to a vendor ticket, as in the Okta support system breach.
- Wildcard redirect URIs: left from development and still accepted in production.
- Logs kept only in the platform: short retention and no export, so a slow account takeover campaign is invisible by the time it is noticed.
Practitioner checklist
- Federate admin sign-in, enforce phishing-resistant MFA and keep two or three tenant owners plus one break-glass account.
- Give every management API client its own owner, minimum scopes and asymmetric authentication where supported.
- Confirm how signing keys are stored and rehearse an emergency rotation.
- Separate tenants and keys for development, test and production.
- Manage configuration as code and alert on drift, redirect URI changes and policy downgrades.
- Review extensibility code and move its secrets to a secrets store.
- Stream audit and sign-in logs to a SIEM and alert on silence.
- Control support and vendor access, and sanitise any browser captures before sharing.
- Run a quarterly review of admins, clients, connections and domains.
Standards and references
- NIST: SP 800-63C-4 Digital Identity Guidelines, Federation and Assertions
- OpenID Foundation: OpenID Connect Core 1.0
- IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- CISA and FBI: Secure by Demand Guide
- NCSC: Secure system administration
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: T1606 Forge Web Credentials
Related NHI Mgmt Group resources: Customer IAM (CIAM) Guide · Customer identity (CIAM) platform integration security guide · If your customer identity (CIAM) platform is compromised · Signing keys and certificates in breaches · Securing the Identity Verification and KYC Platform Itself