Security guide

Secure IBM Cloud Architecture: Design and Checklist

A secure IBM Cloud architecture starts with who can do what, and where. IBM's account setup guidance centres on resource groups per environment, access groups mapped to them, least-privilege policies, and trusted profiles for federated users and for workloads so that nobody stores credentials. Around that you add VPC security groups, key management, private object storage and routed audit events.

This guide draws that design, explains each area in plain words, and ends with a decision checklist. Every claim comes from IBM Cloud documentation read on 4 November 2026. The Security and Compliance Center product documentation could not be fetched that day, so that area rests on IBM's announcement page and says what is unverified. The IBM Cloud Framework for Financial Services lists full reference architectures for regulated workloads; use it for deeper patterns.

Updated 4 November 2026 (last reviewed)

TL;DR

The short version

5 points

Structure: resource groups per environment, chosen before instances are created because the choice is final.
Access: access groups mapped to resource groups, least privilege, few full administrators; review inactive policies.
Identity: account-level MFA; trusted profiles for federated users and for compute workloads; API keys limited, expiring and rotated.
Network and data: VPC security groups per tier, root keys in Key Protect or Hyper Protect Crypto Services, Cloud Object Storage private by default.
Detection: Activity Tracker Event Routing to a searchable target such as IBM Cloud Logs; Security and Compliance Center for posture, with owners.

The reference architecture

Read the figure from the top: identity and access sit at the account, shared services and production are separate resource groups, keys wrap the data that production services hold, and audit events flow to a searchable place.

Figure 1. Reference architecture. The pieces (resource groups, access groups, trusted profiles, MFA, security groups, Key Protect or Hyper Protect Crypto Services, private COS buckets, Activity Tracker Event Routing, IBM Cloud Logs) come from the IBM pages cited below; the layout and names are our illustration.

Design areas and where IBM documents them

Area	What to do	Source
Account structure	Resource group per environment; plan before creating instances.	Resource groups, Account setup best practices
Access	Access groups mapped to resource groups; least privilege; few full administrators.	Access groups, Account setup best practices
Authentication	Account-level MFA; trusted profiles for federated users.	Multifactor authentication, Trusted profiles
Workload identity	Trusted profiles with compute conditions instead of service ID keys.	Trusted profiles
Credentials	API keys with expiry, leaked action, restricted creation, regular rotation.	API keys
Review	Inactive policies report and per-user access exports.	Auditing access policies
Network	VPC security groups per tier; careful use of the default group.	VPC security groups
Keys and data	Key Protect or Hyper Protect Crypto Services; private COS buckets.	Key Protect, Hyper Protect Crypto Services, COS public access
Logging and posture	Activity Tracker Event Routing to a searchable target; Security and Compliance Center.	Activity Tracker Event Routing, IBM Cloud Logs, SCC Workload Protection announcement

Account structure and access

IBM suggests one resource group per project environment such as Dev, Test and Prod, and says the group you pick when you create an instance is final, so plan first. The first group is named Default and cannot be deleted (Resource groups; Account setup best practices). An access group bundles users, service IDs and trusted profiles; members inherit its policies, so one policy replaces many. IBM suggests a group per level of access mapped to resource groups, least privilege, and notes there is a limit on the number of policies in an account. It also warns that administrator access to everything includes the ability to revoke other administrators, so keep it to a few people.

Review with the inactive policies report, which shows policies that have not permitted access in 30 days or longer, and per-user access exports in JSON or CSV. IAM keeps deleted policies for 10 days.

Authentication, trusted profiles and keys

Account-level MFA can apply to every user, to users with IBMids who do not use SSO, or to selected users. Federated staff can use trusted profiles: access from SAML attribute conditions, no account membership needed, a session duration, and one profile applied at login. For applications on compute resources, a trusted profile with conditions such as resource group or location removes the need for service IDs or API keys.

Where keys remain, IBM says to treat them like passwords, set expiry, configure the leaked action, rotate regularly and consider Restrict API key creation, which blocks creation for everyone, including the account owner, unless explicitly allowed. Monitor Activity Tracker Event Routing for suspicious use.

VPC network

Security groups are stateful and attach to resources such as network interfaces, endpoint gateways and load balancers; network ACLs are stateless and sit at the subnet. Traffic is blocked by default, and rules are permissive only. New groups deny inbound and allow outbound. A rule's remote source can be a CIDR, an IP or another security group, and an omitted source means 0.0.0.0/0. Edits to the default group affect all current and future members, and with several groups attached the least restrictive rule governs. The IBM pages we read for private endpoints and flow logs could not be fetched, so we make no claim about them.

Keys and Cloud Object Storage

Key Protect root keys wrap data encryption keys (envelope encryption); standard keys sit on FIPS 140-2 Level 3 HSMs; dual authorization for deletion and rotation schedules are supported; deleted keys and their data can never be recovered. Hyper Protect Crypto Services is single-tenant, on FIPS 140-2 Level 4 hardware, with Keep Your Own Key.

For Cloud Object Storage, bucket public access needs the account-level Public Access group enabled and exposes every object to anyone with the URL. The public-read header bypasses IAM checks, and pre-signed URLs from HMAC credentials give temporary access.

Logging and posture

Activity Tracker Event Routing routes auditing events, in the CADF format, with targets (Cloud Object Storage, IBM Cloud Logs, Event Streams, App Configuration) and routes that say where events go. IBM Cloud Logs lets you query, tail and visualize logs and needs two Cloud Object Storage buckets. IBM's announcement describes Security and Compliance Center Workload Protection as combining compliance and posture management with threat detection and vulnerability scanning; we could not verify setup steps from product documentation.

Decision checklist

Answer each with yes, partly or no. Every “no” is a design decision to make. For a scored version with per-domain gaps and export, use the IBM Cloud Security Checklist.

Are resources spread across resource groups per environment, with the group chosen before the instance is created?
Is access given through access groups mapped to resource groups, with per-user policies the exception?
Is full Administrator access limited to a few people?
Is MFA enabled at the account level, and are SSO users covered by their identity provider?
Do federated users and workloads reach the account through trusted profiles with conditions, and not shared keys?
Do API keys have expiry, a leaked-action setting and a rotation routine, and is creation restricted where practical?
Do you run the inactive policies report and export user access on a schedule?
Are VPC security groups per tier, with another security group or a specific CIDR as the remote source, and the default group left alone?
Are root keys in Key Protect (or Hyper Protect Crypto Services), with dual authorization for deletion and a rotation schedule?
Is the account-level Public Access group disabled unless needed, and are shares done with expiring pre-signed URLs?
Does Activity Tracker Event Routing have a target and a route that reach a searchable place, and does someone watch key use?
Is there an owner for each failing control reported by Security and Compliance Center?
Have you rehearsed the response to a leaked API key or a public bucket?

What this guide does not claim

The resource group layout in the diagram is illustrative. The IBM pages we read do not prescribe one.
The pages do not state a last-updated date in the text we read, so none is claimed. Last reviewed 4 November 2026.
Not verified: Security and Compliance Center product documentation (topic pages returned 404), VPC private endpoints and flow logs, the IAM overview and MFA factor options. We make no claims about them beyond the announcement page.
IBM has been changing its logging products; the Activity Tracker and IBM Cloud Logs pages we read stated no end-of-support dates. Check IBM's current notices before you plan.
This is not the CIS benchmark (CIS IBM Cloud benchmark (pointer) is a pointer only; we did not read it) and not a compliance opinion.

Frequently asked questions

What is a secure IBM Cloud architecture?

It is an IBM Cloud account where access and guardrails are designed before workloads arrive: resource groups per environment, access groups with least-privilege policies, account-level MFA, trusted profiles instead of stored keys, VPC security groups per tier, keys in Key Protect or Hyper Protect Crypto Services, private Cloud Object Storage buckets, and audit events routed to a searchable target.

Where does IBM publish reference architectures?

The IBM Cloud Framework for Financial Services documentation lists reference architectures for IBM Cloud VPC (with variants for virtual servers, Power virtual servers and Red Hat OpenShift), IBM Cloud Satellite and VMware regulated workloads. Its security topics include account setup, access management, secrets, networking, encryption, audit logging and compliance monitoring. It is written for regulated financial workloads, so read it as a source of patterns, not a required layout.

Why trusted profiles instead of API keys?

IBM documents trusted profiles as granting access without managing credentials. For applications on compute resources you are not required to create service IDs or API keys, and IBM calls trusted profiles a best practice for applications on its compute resources. For federated users, SAML attribute conditions and a session duration control who may apply a profile and for how long.

Key Protect or Hyper Protect Crypto Services?

IBM describes Key Protect as multi-tenant, with standard keys on FIPS 140-2 Level 3 HSMs. Hyper Protect Crypto Services uses the same key-provider API but is single-tenant on dedicated, customer-controlled HSMs built on FIPS 140-2 Level 4 hardware, with a Keep Your Own Key capability. Choose by how much control of the root of trust the workload needs.

Is a public Cloud Object Storage bucket ever acceptable?

Only as an exception. IBM says the Public Access group must be enabled at the account level before any bucket can be public, and that bucket-level public access exposes every object to anyone with the URL. Keep the account-level group disabled unless needed and use expiring pre-signed URLs for sharing.

Is this the same as CIS compliance?

No. The CIS IBM Cloud Foundations Benchmark is a separate checklist; we point to its CIS page and did not read its contents. This guide is design guidance. Use the IBM Cloud Security Checklist for a quick gap review.