A CNAPP or CSPM platform holds trusted roles into every cloud account you own and keeps a ranked list of your weaknesses, so an attacker who controls it gets both a map of the estate and the credentials to walk it. To work, these platforms read configuration across accounts, subscriptions and projects, often snapshot and scan workload disks, run agents or admission controllers in Kubernetes clusters, connect to code repositories and registries, and sometimes hold write roles to remediate findings automatically. This guide is for cloud security engineers, platform teams and owners of the tool. It covers admin roles, the integration roles the platform uses in each cloud, scanning and remediation permissions, the sensitive data the platform stores, its own audit trail, findings exceptions and the lifecycle. It is vendor-neutral: confirm exact setting names and the permission sets in your vendor's documentation. For what a CNAPP is and how to run the programme, see the CNAPP Guide.
Key takeaways
- Treat the platform and its cloud roles as privileged NHIs. A read role that spans every account is a reconnaissance gift; protect it as you would an organisation-level administrator.
- Keep posture read only, and isolate anything that writes. Remediation and response roles belong in separate identities, limited to named actions and accounts, with approval for anything irreversible.
- Use trust conditions, not long-lived keys. Cross-account roles with a unique external identifier or workload identity federation beat stored access keys and client secrets.
- Treat findings and snapshots as sensitive data. A list of exposed, vulnerable assets with attack paths is an attacker's plan; disk snapshots can contain secrets and personal data.
- Exceptions are blind spots. Every suppressed finding needs an owner, a reason and an expiry, and changes to exceptions should alert.
Why the platform is a high-value target
The NSA and CISA Top Ten Cloud Security Mitigation Strategies (March 2024) include using secure cloud identity and access management practices, secure key management, and mitigating risks from managed service providers. A CNAPP sits across all three: it is a third-party service holding identities and keys inside your cloud. The NCSC secure system administration principles apply to its console as much as to your cloud consoles.
The component table reflects a common architecture and is NHI Mgmt Group's view, not a sourced description of any one product; your platform may name, merge or split these components differently.
| Component | What it holds or can do | If an attacker controls it | Primary control |
|---|---|---|---|
| Console and API | Inventory, findings, attack paths, exceptions, integrations, user roles | Reads the estate map, suppresses findings about their foothold, exports data | SSO with phishing-resistant MFA, least-privilege roles, API key scoping |
| Posture (read) role in each account | Read configuration and identity policy across the organisation | Full reconnaissance; sometimes reads data if the role is broader than configuration | Read-only configuration permissions, trust condition, alert on use outside expected sources |
| Agentless scanning role | Create disk snapshots, share them to a scanning account, use keys for encrypted disks | Copies workload disks and their secrets (T1530) | Separate role, limited to snapshot actions, key use scoped and logged |
| Remediation or response role | Change configuration, revoke keys, isolate workloads | Weakens controls or causes outages across accounts | Separate role, named actions, approval, protected resources |
| Kubernetes agents and admission controllers | Cluster-level read, runtime sensors, sometimes admission decisions | Cluster takeover, or a failing controller blocks deployments | Minimal cluster roles, signed images, documented fail mode |
| Code, pipeline and registry integrations | Tokens to read repositories and images, comment on pull requests | Source code theft, tampered pipeline checks | Read-only app installations scoped to named repositories |
Admin roles and console access
- Role design: define at least platform administrator (connectors, roles, integrations), policy author (custom rules and frameworks), exception approver, analyst (read findings for owned scopes) and responder (run response actions). Keep full administrators to a handful.
- Scope by account or business unit: most teams only need their own accounts' findings. Scoped visibility limits what a single compromised analyst account reveals.
- Authentication: sign in through your identity provider with SSO and phishing-resistant MFA. The CISA and FBI Secure by Demand guide asks vendors for standards-based SSO at no additional cost and MFA by default; use those as procurement questions. Keep one documented break-glass account. See the Break-Glass Account Guide.
- Just-in-time elevation: grant administrator and responder roles for a time-bound window through your privileged access process, with a reason recorded. See the Cloud PAM and CIEM Guide.
- Admin devices: administer from privileged access workstations. See the Privileged Access Workstations Guide.
Integration roles in each cloud
Onboarding usually deploys a role or service principal into each account, often through an organisation-wide template. Read the template before running it: it defines the platform's real power in your estate.
| Identity | Needs | Avoid | Credential pattern |
|---|---|---|---|
| Posture read role | Read configuration, metadata and identity policy | Broad read roles that include reading object data, secrets values or database contents | Cross-account role with a unique external identifier, or workload identity federation; no stored access keys |
| Agentless scanning role | Create, share and delete snapshots; use encryption keys for scanning | Rights to modify instances, or key use beyond decrypting for scans | Separate role; key grants limited to the scanner; snapshot actions alerted when unexpected |
| Remediation role | Specific write actions, such as re-enabling logging or removing public access | Administrator or owner roles "to fix anything" | Separate role per action family, limited to opted-in accounts |
| Log and event reader | Read audit logs and flow logs from a central log account | Write or delete on the log store | Read-only on the log bucket or workspace |
| Kubernetes integration | Read cluster resources; runtime sensor host rights as documented | Cluster-admin bindings for the posture component | Dedicated service account with a namespaced or read-only cluster role |
- Confused deputy protection: a cross-account trust that any customer of the same vendor could assume is a risk. Require a unique external identifier or equivalent condition on the trust and check it in the template. See the Cross-Account and Cross-Tenant Access Guide.
- Bind roles to the vendor's documented sources: where the cloud supports it, add conditions so the role can only be used from the vendor's documented principals or network ranges, and alert on any other use (T1078.004).
- Watch for added credentials: alert when a secret or certificate is added to the platform's app registration or service principal outside change (T1098.001).
- Prefer federation over keys: where an integration needs a credential, use workload identity federation instead of static keys. See the Workload Identity Federation Guide.
- Inventory: record each platform identity, per account, with owner, permissions and template version in your NHI inventory.
Scanning, snapshots and the data the platform holds
Agentless workload scanning typically snapshots disks and analyses them in a scanning environment, which means copies of production data, including secrets on disk, leave the workload for a time. The platform then stores findings, attack paths, secrets it detected and sometimes data classification samples.
- Ask where scanning runs: in your account or the vendor's, in which region, and how quickly snapshots are deleted. Record the answer in your data protection records.
- Control key use for encrypted disks: scanning customer-managed encrypted volumes needs key access. Grant it to the scanning role only, and alert on key use by that role outside expected scan windows.
- Mask detected secrets: secrets findings should show a fingerprint or partial value, not the whole secret. Rotate any real secret found, then close the finding. See the Secrets Management Guide.
- Restrict exports and reports: limit who can export the full inventory or attack path data, and alert on bulk export through the console or API.
- Data residency and retention: confirm where findings and samples are stored, how long they are kept, and how deletion is confirmed.
Remediation and response guardrails
Automated remediation is where a CNAPP turns from an observer into an actor across every account. Keep the scope small and reversible.
- Start in recommendation mode: run every remediation rule in notify-only mode in a non-production account first.
- Allow only reversible actions automatically: re-enabling logging or removing public access from a resource tagged non-public are good candidates; deleting resources or changing identity policy go to a ticket.
- Protected resources: exclude break-glass identities, the platform's own roles, logging accounts and security tooling from any automated change.
- Caps and approval: cap automated changes per run, require a human approver for response actions such as disabling access keys, and log the approver.
- Kill switch: document how to pause all remediation and response in one step, and test it twice a year (our recommendation).
Findings exceptions and policy integrity
Suppressing a finding or excluding an account is the quietest way to hide a misconfiguration. Treat exceptions as security changes.
- Owner, reason, expiry: each exception gets all three; 90 days is our suggested default for anything other than an accepted architectural risk.
- Approval separate from request: the team that owns the resource can request an exception; a different role approves it.
- Policy as code: keep custom policies and framework mappings in a repository and review changes. Compare deployed policies with the repository and alert on drift.
- Coverage checks: alert when an account, subscription or project is disconnected, a region is excluded or a scanner stops returning results. A new account that never gets connected is the most common gap.
The platform's own audit trail
| Event to capture | Why it matters | Alert? |
|---|---|---|
| Role assignment, new local user, SSO or API key change | Persistence in the platform | Always |
| Account disconnected, connector role changed, region excluded | Loss of coverage | Always |
| Exception created or widened; policy disabled | Blind spot | Always, with approver |
| Remediation or response action run | Changes across accounts | Bulk actions and protected resources |
| Bulk export of inventory, findings or secrets findings | Reconnaissance or data theft | Above a set volume |
Export the platform audit log to your SIEM or a log archive that platform administrators cannot alter (NIST SP 800-53 AU-9(2)). Cross-check it with the cloud providers' own audit logs: every action the platform's roles take in your accounts is also recorded there, and an action in the cloud log with no matching platform record is a red flag. Alert on changes to the cloud audit logging the platform depends on (T1685.002). See the Cloud Logging and Audit Trail Guide. Secure by Demand asks SaaS providers to retain security logs for at least six months at no extra charge; check your contract.
Lifecycle: buy, deploy, run, retire
| Stage | Security actions |
|---|---|
| Buy | Ask the Secure by Demand questions (SSO, MFA by default, security logs in the base product, vulnerability disclosure policy, SBOM). Ask for the exact permission set per feature, where scanning runs, vendor staff access to tenant data and breach notification terms. See the CNAPP Buyer's Guide and CNAPP RFP Template. |
| Deploy | Review the onboarding template; deploy read roles first; add scanning and remediation roles only to accounts that opt in; enable SSO and audit log export on day one. |
| Run | Quarterly review of roles, API keys, exceptions and connected accounts; template version tracking; apply vendor security updates to agents and controllers promptly and subscribe to the vendor's security advisories page. |
| Retire | Remove roles and trust relationships from every account (organisation templates can leave stragglers); revoke app consents, repository installations and API keys; remove cluster agents and controllers; obtain written confirmation of data deletion. |
Roll back a permission reduction by keeping the previous template version and re-granting only the specific permission a feature reports as missing, never by attaching a broad administrator policy.
Detection and measurement
- Percentage of connected accounts whose platform roles use a trust condition or federation rather than stored keys (target: 100 percent).
- Number of accounts where the platform holds any write role, against the number that opted in.
- Exceptions past expiry without re-approval (target: zero).
- Coverage: percentage of cloud accounts, subscriptions and projects connected, and time from account creation to connection.
- Platform role use from unexpected principals or networks per month (target: zero unexplained).
- Percentage of platform admin actions with a matching change or case reference.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ATT&CK threat addressed |
|---|---|---|---|
| Console roles and scoping | AC-2, AC-6, AC-6(5) | PR.AA-05 | T1078 Valid Accounts |
| Cloud integration roles and keys | IA-5, SC-12 | PR.AA-01 | T1078.004 Cloud Accounts, T1098.001 Additional Cloud Credentials |
| Snapshot and findings data | AC-6, SC-12 | PR.AA-05 | T1530 Data from Cloud Storage |
| Exceptions and policy change control | CM-3, CM-6 | PR.PS-04 | T1685 Disable or Modify Tools |
| Audit trail | AU-6, AU-9(2), AC-6(9) | PR.PS-04, DE.CM-01 | T1685.002 Disable or Modify Cloud Log |
| Third-party service risk | SA-9, SR-3 | GV.SC-07 | T1199 Trusted Relationship |
Common failure patterns
- Administrator role for convenience: the onboarding template grants a broad administrator or owner role so every feature works, and nobody narrows it later.
- Trust without a condition: the cross-account role trusts the vendor's account with no unique external identifier.
- Stragglers after retirement: a replaced platform's roles remain in dozens of accounts, still trusted.
- Auto-remediation everywhere: write roles deployed organisation-wide when only a few accounts opted in.
- Exceptions that never expire: a suppressed public storage finding outlives the reason it was accepted.
- Analysts see everything: every user can read every account's attack paths and secrets findings.
Practitioner checklist
- Classify the platform and its integration roles as privileged NHIs and record them per account in your inventory.
- Enforce SSO with phishing-resistant MFA and keep one tested break-glass account.
- Review the onboarding template and keep the posture role read only for configuration.
- Require a unique external identifier or federation on every trust; remove stored keys.
- Deploy scanning and remediation roles separately, only where needed, with protected resources and caps.
- Scope analyst visibility to owned accounts and restrict bulk export.
- Give every exception an owner, reason and expiry and alert on exception changes.
- Export the platform audit log and reconcile it with cloud provider audit logs.
- Review roles, keys, exceptions and coverage quarterly, and remove every trust on retirement.
Standards and references
- NSA and CISA: Top Ten Cloud Security Mitigation Strategies
- CISA and FBI: Secure by Demand Guide
- NCSC: Secure system administration
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-57 Part 1 Rev. 5 Recommendation for Key Management
- MITRE ATT&CK: T1530 Data from Cloud Storage
Related NHI Mgmt Group resources: CNAPP Guide · Cloud Security Posture Management (CSPM) Guide · Cross-Account and Cross-Tenant Access Guide · Securing the PAM Vault Itself · Securing the identity threat detection and response (ITDR) tool itself