Untracked changes create risk because they weaken visibility, break the audit trail, and allow misconfigurations to persist across AWS, Azure, and Google Cloud. In multi-cloud environments, a small change can affect compliance, availability, and security posture differently in each platform. Teams need continuous monitoring and review so changes are logged, understood, and corrected before they spread.
Why Untracked Changes Create Disproportionate Risk
Untracked infrastructure changes are dangerous because multi-cloud systems amplify small mistakes into organisation-wide exposure. A change that seems harmless in AWS can alter identity boundaries, logging, network reachability, or encryption posture differently in Azure or Google Cloud. That makes visibility the first control to fail, and once the audit trail is broken, detection and rollback become slower and less reliable.
The risk is especially pronounced when infrastructure is managed by humans and agents through a mix of consoles, scripts, and automation pipelines. NHIMG’s 2024 Non-Human Identity Security Report found that 35.6% of organisations cite consistent access across hybrid and multi-cloud environments as their top NHI security challenge. That lines up with broader cloud governance guidance in the NIST Cybersecurity Framework 2.0, which treats asset visibility, change management, and continuous monitoring as foundational rather than optional.
In practice, many security teams discover the real impact only after drift has already propagated across accounts, subscriptions, and projects, rather than through intentional change review.
How It Works in Practice
In a multi-cloud environment, every untracked change creates a gap between what teams believe is true and what is actually deployed. That gap matters because identity, storage, networking, and logging controls are not identical across providers. A policy update, permissive role assignment, or exposed secret can create inconsistent enforcement that is easy to miss if the change is not captured in a single source of truth.
Practical control starts with change attribution. Teams should know who or what made the change, through which pipeline, and under what approval. That includes human admins, Terraform plans, CI/CD workflows, and non-human identities such as service accounts and workload identities. If infrastructure is touched by automation, the identity attached to that automation must be traceable and bounded. Current best practice is to pair cloud-native activity logs with external change records and compare them continuously.
Security teams usually reduce risk by combining:
- Infrastructure as code so intended state is reviewable before deployment.
- Cloud activity logging and configuration drift monitoring so deviations are caught quickly.
- Privilege review for non-human identities so automation cannot silently expand access.
- Alerting on high-risk changes such as key vault policy edits, security group broadening, or storage exposure.
NHIMG’s Top 10 NHI Issues and the Ultimate Guide to NHIs both highlight that unmanaged workload identity and secret sprawl frequently become the mechanism through which untracked changes persist. For technical control mapping, NIST SP 800-53 Rev 5 Security and Privacy Controls remains the clearest reference point for configuration management and audit logging expectations.
These controls tend to break down when teams allow direct console changes in multiple cloud tenants because the resulting drift is fragmented, time-sensitive, and difficult to reconcile after the fact.
Common Variations and Edge Cases
Tighter change control often increases operational overhead, so organisations must balance speed against the cost of review and reconciliation. That tradeoff becomes more visible in platform teams supporting incident response, temporary access, or emergency remediation.
Some changes are not malicious at all. Auto-scaling events, managed service updates, and agent-driven remediation can introduce legitimate drift that still needs tracking. Guidance is evolving on how to govern these cases, but the current direction is clear: approval workflows should be lighter for low-risk automation and stricter for anything that affects identity, network exposure, or secrets. The more autonomy a system has, the more important runtime evidence becomes.
Multi-cloud also introduces edge cases where a single control has different blast radius by provider. A logging misconfiguration in one cloud may be recoverable; the same gap in another may leave no reliable forensic record. That is why security teams should define control baselines per platform while still enforcing one common change record. NHIMG’s 230M AWS environment compromise and Codefinger AWS S3 ransomware attack illustrate how quickly misconfiguration and identity gaps can convert into broad exposure once changes are no longer tracked.
In short, untracked changes are not just a process problem. They are a visibility problem, an identity problem, and a recovery problem at the same time.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM | Continuous monitoring is central to detecting untracked multi-cloud drift. |
| NIST SP 800-63 | Identity assurance matters when admins and automation can alter cloud resources. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Static or unmanaged workload secrets let changes persist without traceability. |
| NIST AI RMF | GOVERN | Agent-driven infrastructure changes need accountability and oversight. |
Implement continuous asset and config monitoring, then alert on deviations from approved state.
Related resources from NHI Mgmt Group
- Why do multi-cloud environments create more identity risk than single-cloud estates?
- Why do cloud infrastructure changes create more risk than software deployments?
- Why do traditional vaults create risk in DevOps and multi-cloud environments?
- Why do fragmented vulnerability and exposure tools create more risk in multi-cloud environments?
