Tencent Cloud Security Guide: CAM, API Keys, CloudAudit

In Tencent Cloud, a single SecretId and SecretKey pair can carry the full power of the identity it belongs to, and Tencent's own guidance is to never create one for the root account. Access in Tencent Cloud is governed by Cloud Access Management (CAM): a root account, sub-users and user groups, roles with temporary credentials, and JSON policies with conditions. Activity is recorded by CloudAudit, and CIS publishes two Tencent Cloud benchmarks to measure configuration against. This guide explains how those pieces fit, how to contain the root account and privileged sub-users, how to manage API keys and replace them with roles, what CloudAudit keeps and for how long, and what a hardening baseline looks like. It is for cloud platform, security and IAM teams running workloads in Tencent Cloud, often alongside other providers. Facts come from Tencent Cloud and CIS documentation checked on 27 October 2026.

Key takeaways

Keep the root account out of daily use. Tencent advises against using or sharing root credentials and against creating root access keys, because root has full access to all services, resources and billing.
Each sub-user can hold two API keys. SecretIds start with IKID, and since 30 November 2023 the SecretKey is shown only once at creation, so lost keys must be replaced, not recovered.
Roles carry no long-term credentials. Services, other accounts and identity providers assume roles and receive temporary credentials, which is the way to retire embedded keys.
CloudAudit history is short. Operation records cover the last 30 days; create tracking sets that ship logs to a COS bucket every five minutes for anything longer.
Two CIS benchmarks apply. CIS lists Tencent Cloud Foundation (v1.0.1) and Tencent Cloud Enterprise Foundation (v1.0.0) as current versions.

How identity and access work in Tencent Cloud

CAM is the service for managing access to Tencent Cloud services and resources. Identities are created under a root (main) account; policies define what each may do.

Identity	What it is	Credentials	Use
Root account	The account you first create; full access to every service, resource and billing	Console login; access keys possible but discouraged	Account recovery and a few owner tasks only
Sub-user	An identity created in CAM for a person or application	Console password and/or up to two API keys	Everyday human and programmatic access
Collaborator	Another Tencent Cloud account added to yours	Its own login; up to two API keys in your account	Partners and managed service providers
Message recipient	A contact for notifications, not a login identity	None	Alerts and billing messages
User group	A set of sub-users sharing policies	None	Job-function permissions
Role	A virtual identity with attached policies, assumed by an account, a service or an IdP	Temporary credentials only	Cross-account access, service access, federation, binding to instances

Policies

A CAM policy is JSON with lowercase elements: version (required, "2.0"), statement, effect (allow or explicit deny), action, resource and an optional condition. principal is used only in role trust policies and COS bucket policies, and is set through APIs and policy syntax rather than the console. Resources use a six-segment format, for example qcs::cos:ap-beijing:uid/1238423:bucketA-1238423/*. Conditions combine an operator, a key and a value, such as ip_equal on qcs:ip to restrict source addresses.

Policy design choice	When to use	Trade-off
Preset policies	Small teams, quick starts, read-only roles	Often broader than a task needs
Custom policies scoped to resources	Production, regulated data, automation identities	More effort; needs product-specific resource formats
Conditions (source IP, time)	Keys used from fixed egress points; admin actions	Breaks when networks change; test before enforcing
Explicit deny statements	Guardrails such as blocking deletion of audit buckets	Must be maintained as products add actions

For a cross-cloud view of the same concepts see the Multi-Cloud Identity Guide.

Admin roles and privileged access

Root account: protect with MFA, do not create access keys, document the recovery process and keep the root email inbox accessible, as Tencent's CAM security best practices advise.
Separation of duties: Tencent recommends that no single sub-account manages users, permissions and resources together, and that one CAM user does not hold both a console password and access keys. Split human administrators from automation identities.
Groups by function: attach permissions to groups by job role and add users to them, so a change to the group updates every member.
Login and operation protection: enable MFA for all accounts with login protection and sensitive-operation protection. Identity security settings are managed per sub-user under Users > User List > Security > Identity Security; when virtual MFA verification is enabled, the sub-user must bind an MFA device at next login. Tencent specifically recommends MFA for accounts that log in by email or WeChat.
Federation: use SSO with your enterprise IdP, through users or roles, so joiner-mover-leaver processes run in one place, and disable or delete administrator accounts when staff leave.
Collaborators: review collaborator access like any third party; their keys work in your account. See the Third-Party Access Guide.

Integrations, API tokens and service accounts

Tencent Cloud API calls are signed with an access key made of a SecretId, which acts like a username and starts with IKID, and a SecretKey, which acts like a password. Without one, a sub-user cannot call the API.

Fact or control	Detail	Why it matters
Key limit	At most two API keys per sub-user or collaborator	Two keys allow overlap during rotation; more keys per identity are not possible
SecretKey visibility	Shown only at creation since 30 November 2023, for root and sub-accounts	Store the key in a secrets manager immediately; the console cannot reveal it later
Disable before delete	Disabled keys block all requests and can be re-enabled; deleted keys cannot be recovered	Disable first as a reversible test, then delete
Access records	Latest 20 records from the past three months, successful and failed, with roughly an hour's delay; Last Access Time per key	Find unused keys and confirm which systems use a key before rotating
Credential report	Download from CAM to review each sub-account's password, access key and security settings status	Evidence for audits and a source for key age metrics
Roles instead of keys	Services that support roles reach your resources without embedded long-term keys; roles can be bound to resources such as container and cloud server instances	Removes static keys from instances and containers

Rotating a sub-user key without an outage

Find the consumers: use Last Access Time, access records and CloudAudit source IPs to list every system using the key.
Create the second key: the two-key limit leaves room for exactly one replacement; store the SecretKey at creation.
Deploy and verify: update consumers, then check that the old key's Last Access Time stops advancing.
Disable, wait, delete: disable the old key as a reversible step, watch for failures, then delete it. Roll back by re-enabling if a missed consumer breaks.

Leaked Tencent keys are found by the same methods as other cloud keys; see the Generic API Key Detection Guide and the API Key Management Guide.

Logging and detection

CloudAudit records operations performed under the account, including the event name, event source, resource type and name, key ID, region, source IP address, request ID, error code and username.

CloudAudit feature	Behaviour	Recommendation
Operation records	Last 30 days, searchable in the console	Treat as triage only, not retention
Tracking sets	Ship logs to a specified COS bucket every five minutes, one file per hour under `bucket/prefix/{year}/{month}/{day}/`; can be created, edited, disabled and deleted (up to five during the beta described in the documentation)	Create at least one tracking set to a dedicated, access-restricted bucket and forward to your SIEM
Cross-account delivery	Documented for group accounts	Centralise logs from member accounts in a security account

What to alert on

Root activity: any root console login or API call, and any root access key creation.
Key lifecycle: API key creation, enablement and use from new source IPs; failed calls from a key that previously succeeded.
Policy and group changes: new or edited custom policies with wildcard actions or resources, users added to administrator groups, and changes to role trust policies (principal).
Protection changes: MFA, login protection or operation protection disabled for a sub-user.
Audit tampering: tracking sets disabled or deleted, or changes to the COS bucket that holds them. Map these to ATT&CK T1685 Disable or Modify Tools.
Permission errors: Tencent notes that CloudAudit shows operations that failed for insufficient permissions, a useful signal of a compromised key exploring the account.

Hardening baseline

CIS lists two current benchmarks on its Tencent Cloud page: Tencent Cloud Foundation v1.0.1 and Tencent Cloud Enterprise Foundation v1.0.0 (older versions are archived in CIS WorkBench). Use the Foundation benchmark for single accounts and the Enterprise Foundation benchmark where you run a multi-account organisation. See the CIS Benchmarks Guide.

Area	Baseline	Source
Root account	MFA on; no access keys; recovery documented; not used day to day	Tencent CAM security best practices
Human access	One sub-user per person or SSO federation; groups by job function; offboarding disables accounts	Tencent CAM security best practices
MFA and protection	MFA, login protection and sensitive-operation protection for every sub-user	Tencent CAM security best practices; Identity Security settings
Passwords	CAM password policy with length and character rules	Tencent CAM security best practices
Programmatic access	Separate automation sub-users with keys only; roles for services and instances; regular rotation; unused keys deleted	Tencent CAM best practices and key management documentation
Policies	Custom least-privilege policies, source IP conditions for keys used from fixed networks, explicit denies for audit resources	CAM policy syntax
Audit	Tracking set to a protected COS bucket, forwarded to a SIEM, cross-account delivery for groups	CloudAudit documentation
Assurance	Regular credential reports and benchmark assessment	CAM; CIS

Rollout order

Inventory: download the credential report and list sub-users, collaborators, groups, roles, custom policies and API keys with last access times.
Secure the root account: MFA, remove any root access keys after moving their workloads to sub-users or roles.
Turn on audit retention: create a tracking set before making other changes, so the remediation itself is recorded.
Enforce MFA and protection: enable for administrators first, then all users; communicate the device binding at next login.
Reduce privilege: replace broad preset policies on automation users with custom policies; add IP conditions in a test account first, because a wrong range blocks the workload.
Retire keys: move services and instances to roles, rotate remaining keys and set a review cadence.

Common misconfigurations

Root access keys in scripts: a single leak exposes every resource and billing; Tencent's guidance is not to create them.
One sub-user for console and API: a stolen key then carries the same rights as the administrator's console session.
No tracking set: after 30 days the operation history is gone, which usually means an investigation cannot establish when a key was first misused.
SecretKeys in tickets or chat: because the console shows the SecretKey only once, teams paste it somewhere "for safekeeping". Store it in a secrets manager at creation.
Collaborator access never reviewed: partner accounts keep keys and policies long after a project ends.
Static keys on instances: keys in configuration files on servers and containers, where a bound role would have issued temporary credentials.

Framework mapping

Tencent Cloud control	NIST SP 800-53 Rev. 5	NIST CSF 2.0
Sub-users, groups, custom policies	AC-2 Account Management; AC-6 Least Privilege	PR.AA-05
Separation of user, permission and resource administration	AC-5 Separation of Duties	PR.AA-05
MFA, login and operation protection, password policy	IA-2 Identification and Authentication; IA-5 Authenticator Management	PR.AA-03
API keys and roles	IA-5 Authenticator Management; IA-9 Service Identification and Authentication	PR.AA-01
CloudAudit and tracking sets	AU-2 Event Logging; AU-9 Protection of Audit Information; AU-11 Audit Record Retention	DE.CM-09
CIS benchmarks	CM-6 Configuration Settings	PR.PS-01

Metrics

Root exposure: root access keys in existence (target zero) and root logins per month.
MFA coverage: share of sub-users with MFA and login protection enabled.
Key age: API keys older than your rotation period, and keys with no access in 90 days.
Keyless workloads: share of services and instances using roles rather than keys.
Audit coverage: accounts with an active tracking set delivering to a protected bucket.
Benchmark pass rate: against CIS Tencent Cloud Foundation or Enterprise Foundation.

Practitioner checklist

Enable MFA on the root account, remove any root access keys and document root recovery.
Create a CloudAudit tracking set to a dedicated COS bucket and forward it to your SIEM.
Give every person a sub-user or federated login, organised into groups by job function.
Enable MFA, login protection and sensitive-operation protection for all sub-users.
Separate automation sub-users (keys only) from human administrators (console only).
Store every SecretKey in a secrets manager at creation and rotate using the two-key overlap.
Move services and instances to roles with temporary credentials.
Review the credential report and assess against the CIS Tencent Cloud benchmarks on a fixed schedule.

Tencent Cloud Security Guide: Hardening CAM, API Keys and CloudAudit