In IBM Cloud, almost every serious exposure comes back to an identity: an API key in a repository, a service ID with an account-wide Administrator policy, or a user who can create keys nobody tracks. IBM Cloud IAM is an attribute-based model with users, service IDs, trusted profiles, API keys and resource identities, layered with context-based restrictions, account settings and audit events routed by Activity Tracker Event Routing. This guide explains how those pieces fit, which account settings to change first, how to replace stored API keys with trusted profiles and dynamic credentials, how Key Protect and Hyper Protect Crypto Services protect encryption keys, and how to monitor the account with audit events and posture management. It is written for cloud platform, security and IAM teams, including those in regulated financial services who use the IBM Cloud Framework for Financial Services. Facts are taken from IBM Cloud documentation, checked on 27 October 2026.
Key takeaways
- Nothing is granted by default except to the account owner. Users and service IDs start with no access, so every permission in the account traces back to a policy someone assigned.
- Two policies make a full administrator. Administrator plus Manager on All Identity and Access enabled services, and Administrator on All Account Management services; review both kinds of policy when hunting for admins.
- API keys are the main machine credential. Restrict who can create user API keys and service IDs, set expirations and configure the leaked key action to disable keys found by secret scanning.
- Trusted profiles remove stored keys. Compute resources and federated users can obtain access through a trusted profile instead of a long-lived API key.
- Context-based restrictions are a second gate. They do not grant access; they check network zone, endpoint type and MFA level, and can run in report-only mode first for supported services.
How identity and access work in IBM Cloud
IBM Cloud IAM grants access by policy to an identity or a group of identities. A policy combines a subject, a target (account, resource group, service instance or individual resource) and roles, and may carry time-based, network or resource attribute conditions. IBM describes the model as attribute-based access control (ABAC).
| Identity type | What it is | Typical use | Main risk |
|---|---|---|---|
| User | IBMid, SoftLayer ID, App ID user or federated user, each with an IAM ID such as IBMid-... | People | Weak or missing MFA; standing admin |
| User API key | Credential tied to a user; carries the user's access across every account the user belongs to | CLI and scripts run as the person | Leaks; access in other accounts; survives role changes if not reviewed |
| Functional ID | A user in your IdP not tied to a person, invited to the account | Services that need a user identity, for example some cluster creation | Shared passwords; more power than a service ID |
| Service ID and service ID API key | Identity for an application or service, accessing IAM-enabled resources only | Applications outside IBM Cloud, pipelines | Long-lived keys; account-wide roles |
| Trusted profile | An identity applied by federated users that meet SAML conditions, by compute resources, by IBM Cloud services, or by a service ID from another account | Federated access without invitations; keyless workload access | Over-broad conditions that match too many users or workloads |
| Resource identity | A resource's cloud resource name (CRN) | Service-to-service authorisations | Authorisations that outlive the integration |
Roles
| Role type | Roles | What they control |
|---|---|---|
| Platform management | Viewer, Operator, Editor, Administrator | Creating and deleting instances, managing credentials, and (Administrator) assigning access to others. Operator and Editor can manage credentials, which makes them more sensitive than their names suggest |
| Service access | Reader, Writer, Manager (common set; each service maps its own actions) | Data plane actions, for example Writer on Cloud Object Storage can create and destroy buckets and objects |
| Custom | Defined by the account owner or an Administrator on the Role management service | Any combination of a service's actions |
IBM notes that roles do not inherit the actions of lesser roles, so policies often carry several roles. Access groups collect users, service IDs and trusted profiles, and access group rules can add federated users dynamically from IdP attributes.
Admin roles and privileged access
- Account owner: automatically the account administrator. Keep this identity for break-glass use with security key MFA, and do not use a functional ID as owner (IBM points classic infrastructure accounts to an alternative account owner instead).
- Full access requires two policies: All Identity and Access enabled services with Administrator and Manager, and All Account Management services with Administrator. Administrators of account management services can change other users' access and remove other administrators.
- Account management services are privileged: they include IAM Access Groups, IAM Identity, IAM Access Management, Role management, User Management, Billing, Context-based restrictions, Enterprise and Security and Compliance Center. Grant them separately and narrowly.
- Use trusted profiles for elevation: IBM describes federated users choosing a Developer or Admin profile at login so privileged actions happen only under the privileged profile, and switching back without logging out.
- Time-based conditions: add a time window to temporary privileged policies so access ends without a manual clean-up.
- Enterprise accounts: enterprise-managed IAM templates push access groups, trusted profiles and account settings to child accounts to limit drift.
For PAM approaches that apply across clouds, see the Multi-Cloud Identity Guide.
Integrations, API tokens and service IDs
IBM Cloud API keys are exchanged for IAM tokens and are the credential most often leaked. The platform gives you controls for each stage of their life.
| Control | Where | Effect |
|---|---|---|
| Restrict API key creation | Manage > Access (IAM) > Settings; Terraform restrict_create_platform_apikey = "RESTRICTED" | Only identities with explicit access, including the owner, can create user API keys; service ID keys are not affected |
| Restrict service ID creation | IAM account settings | Everyone, including account owners, needs explicit access to create service IDs |
| API key expiration | Set when a key is created or updated | Key invalid after the date; expired keys are deleted 90 days later; notification sent a few days before expiry |
| Leaked key action | Per key | IBM uses secret scanning from platforms such as GitHub and GitLab; a leaked key can be automatically disabled (IBM's recommendation for most keys) or deleted |
| Key locking | --lock on service ID key creation | Prevents accidental deletion or change of a key in use |
| Trusted profiles for compute | IAM > Trusted profiles | Applications on a compute resource obtain a token from the resource identity and exchange it for a profile token, with no stored API key |
| Dynamic IAM credentials | Secrets Manager IAM credentials secret type | A service ID and API key generated on access with a time-to-live, so credentials expire automatically |
| Inactive identities report | Manage > Access (IAM) > Inactive identities | Lists users, service IDs, trusted profiles and API keys unused for 30 days |
IBM's documentation warns that an attacker with a leaked key may create additional IDs or API keys to keep access after rotation, so incident response must look for new identities as well as revoking the exposed key. For rotation procedures see the Secrets Rotation Runbook Template and the API Key Management Guide.
- Public Access group: all users and service IDs are members by default, and a policy assigned to it opens the resource to anyone without authentication. Review it and disable public access where it is not needed.
- Service-to-service authorisations: review authorisations between services (for example a storage service allowed to read a Key Protect key) as part of every access review.
- Functional IDs: where a service needs a user API key, IBM recommends a functional ID key scoped to what the service needs rather than a person's key.
Logging and detection
Activity Tracker Event Routing (atracker) routes global and location-based audit events, recorded in the Cloud Auditing Data Federation (CADF) model of initiator, action, target, observer and outcome, to targets you choose.
| Target type | Use |
|---|---|
cloud_object_storage | Long-term retention; IBM names it for Financial Services compliance |
cloud_logs | Search and dashboards in IBM Cloud Logs (IAM events appear under subsystems prefixed iam-) |
event_streams | Streaming to a SIEM, data lake or other tools |
IAM events worth alerting on
| Event | Why it matters |
|---|---|
iam-identity.user-apikey.create, iam-identity.serviceid-apikey.create | New long-lived credentials; correlate with change tickets |
iam-identity.user-apikey.login, iam-identity.serviceid-apikey.login | Key use from unexpected IPs or after a leak notification |
iam-identity.account-serviceid.create, iam-identity.account-profile.create | New machine identities or trusted profiles, a common persistence step |
iam-am.policy.create, iam-am.policy.update | Policy changes, especially Administrator or Manager on account-wide targets |
iam-groups.member.add | Additions to privileged access groups |
iam-identity.account-settings-template.update and account settings changes | Weakening MFA, session or creation restrictions |
Workload Protection, IBM's cloud-native application protection platform, adds cloud detection and response rules written in Falco syntax against audit events (source: ibm_activitytracker), plus agent-based runtime detection for workloads. For general cloud audit practice see the Google Cloud Audit Logs and Log Sinks Guide, whose principles carry over.
Hardening baseline
CIS publishes a CIS IBM Cloud Foundations Benchmark, and Workload Protection's posture management includes it as a predefined policy alongside the IBM Cloud Framework for Financial Services (v1.1 and v2.0), DORA, FedRAMP High and Moderate baselines and an IBM Cloud Sovereignty Assessment. See the CIS Benchmarks Guide.
| Area | Setting | Recommended value |
|---|---|---|
| MFA | IAM > Settings > Authentication (API constants NONE, NONE_NORPC, TOTP4ALL, TOTP, LEVEL1, LEVEL2, LEVEL3) | LEVEL2 (TOTP) at minimum for all users; LEVEL3 (security key) for administrators and the owner. Do not leave NONE; since 3 May 2023 password-only CLI logins are disabled by default for users with MFA set to None |
| Federation | IdP integration and trusted profiles with SAML conditions | Federate workforce users so joiner-mover-leaver happens in the IdP |
| Sessions | Login session settings | Short sign-out due to inactivity and a bounded active session (the maximum is 720 hours); the lowest value applies when a user is in several accounts |
| Credential creation | Restrict API key creation; Restrict service ID creation | Enabled, with explicit grants to platform teams |
| Network | Context-based restrictions: network zones, endpoint types, MFA level | Private endpoints and corporate ranges for IAM, Key Protect and storage; start in report-only where offered |
| Public access | Public Access group | No policies unless a public resource is intended |
| Encryption keys | Key Protect root keys or Hyper Protect Crypto Services | Customer root keys for data services; automatic rotation policy (intervals in 30-day steps); dual authorisation for deletion |
| Audit | atracker routes | Global and all-region events routed to COS with retention and to a SIEM |
Encryption key management
Key Protect provides envelope encryption with root keys protecting data encryption keys, using AES-GCM and 256-bit key material, in a multi-tenant Standard offering (master keys managed by IBM) and a single-tenant Dedicated offering (you own the master keys). IBM describes Key Protect HSMs as FIPS 140-2 Level 3 certified, while Hyper Protect Crypto Services uses FIPS 140-2 Level 4 certified HSMs that you initialise and own (keep your own key). Dual authorisation policies require two administrators to delete a key, and can be set per instance so new keys inherit them. See the BYOK, HYOK and External Key Management Guide.
Rollout order
- Inventory: export users, service IDs, API keys, trusted profiles, access groups and policies; run the inactive identities report.
- Protect the top: security key MFA for the owner and administrators; remove unneeded All Account Management and account-wide Administrator policies.
- Lock credential creation: enable both creation restrictions after granting platform teams explicit access; announce the change, because the owner is also blocked without a grant.
- Fix existing keys: set expirations, configure the leaked key action to disable, and move workloads to trusted profiles or Secrets Manager dynamic credentials.
- Add context-based restrictions: report-only first, review atracker events for denied contexts, then enable. Roll back by switching the rule to report-only or disabled.
- Monitor: route audit events, alert on the IAM events above, and attach posture policies.
Common misconfigurations
- User API keys for automation: a person's key carries all of their access in every account they belong to, and breaks or lingers when they move roles. Use service IDs, trusted profiles or dynamic credentials.
- Service IDs with Administrator on All Identity and Access enabled services: one leaked key gives control of every resource and the ability to create more identities.
- Operator or Editor treated as low risk: both include managing credentials on services.
- MFA set to None or email-only for admins: email-based MFA is IBM's lowest MFA level.
- Policies on the Public Access group: resources become reachable without authentication.
- Leaked key action left unset: a key found by secret scanning keeps working until someone notices. Pair it with repository secret scanning; see the Generic API Key Detection Guide.
Framework mapping
| IBM Cloud control | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| Policies, roles, access groups, time-based conditions | AC-2 Account Management; AC-6 Least Privilege | PR.AA-05 |
| MFA levels, federation, sessions | IA-2 Identification and Authentication; AC-12 Session Termination | PR.AA-03 |
| API keys, service IDs, trusted profiles | IA-5 Authenticator Management; IA-9 Service Identification and Authentication | PR.AA-01 |
| Context-based restrictions | AC-3 Access Enforcement; SC-7 Boundary Protection | PR.IR-01 |
| Key Protect, Hyper Protect Crypto Services | SC-12 Cryptographic Key Establishment and Management; SC-28 Protection of Information at Rest | PR.DS-01 |
| Activity Tracker Event Routing, Workload Protection | AU-2 Event Logging; AU-6 Audit Record Review; SI-4 System Monitoring | DE.CM-09 |
Metrics
- Admin MFA strength: share of administrators on LEVEL3 security key MFA (target 100 percent).
- Key hygiene: API keys without expiration or leaked key action, and keys inactive for 30 days or more.
- Keyless workloads: share of workloads on trusted profiles or dynamic credentials instead of static keys.
- Privileged policy count: account-wide Administrator or Manager policies held by service IDs.
- Posture: pass rate against the CIS IBM Cloud Foundations Benchmark or the Financial Services framework profile.
Practitioner checklist
- Require security key MFA for the account owner and every administrator, and at least TOTP for all users.
- Enable Restrict API key creation and Restrict service ID creation, with explicit grants to platform teams.
- Set expiration and the disable action for leaked keys on every API key.
- Replace stored API keys with trusted profiles for compute or Secrets Manager dynamic IAM credentials.
- Remove account-wide Administrator policies from service IDs and review Operator and Editor grants.
- Apply context-based restrictions to IAM, Key Protect and storage, report-only first.
- Route all audit events to Object Storage and a SIEM, and alert on API key, service ID, profile and policy changes.
- Use customer root keys with rotation and dual authorisation for deletion, and run the inactive identities report monthly.
Standards and references
- IBM Cloud Docs: Identity types for users, services, and workloads
- IBM Cloud Docs: Platform and service access roles
- IBM Cloud Docs: Understanding API keys
- IBM Cloud Docs: Layered security with context-based restrictions
- IBM Cloud Docs: About Activity Tracker Event Routing
- IBM Cloud Docs: About Key Protect
- IBM Cloud Docs source: IAM documentation repository
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Multi-Cloud Identity Guide · API Key Management Guide · Cloud IAM Review Checklist · Financial Services Identity Security Guide · Tencent Cloud Security Guide