A cloud compromise rarely begins with an exotic exploit. More often, it starts with an overprivileged identity, a public storage policy, an exposed management port, or a token left in a deployment system. The best cloud hardening checklist turns those ordinary failure paths into explicit engineering controls – owned, tested, and continuously enforced.
This is not a vendor-specific baseline. AWS, Azure, and Google Cloud use different services and policy syntax, but the hardening objectives are consistent: reduce standing privilege, limit reachability, protect the control plane, secure workloads, and keep secrets out of places they do not belong.
Start With Control Plane Visibility
Hardening cannot compensate for an unknown environment. Before changing configurations, establish a complete inventory of cloud accounts or subscriptions, regions, projects, identities, workloads, data stores, registries, and externally reachable endpoints. Tagging standards matter here. Every production resource should identify an owner, environment, data classification, and application or service.
Centralize audit logs before tuning other controls. Record control-plane activity, identity events, network flow where appropriate, workload logs, and critical data-access events. Send them to a dedicated security account or project with restricted administrative access and retention that matches operational and regulatory requirements. An attacker who can alter the workload should not be able to erase the evidence of doing so.
Enable organization-level policy guardrails. These should prevent high-risk actions by default, such as disabling logging, creating public object storage, attaching public IP addresses without approval, or using services outside approved regions. Guardrails are not a replacement for review, but they stop a single rushed change from becoming an incident.
Best Cloud Hardening Checklist: Identity First
Identity and access management is the highest-value hardening surface. Cloud consoles, APIs, CI/CD systems, support tools, and third-party integrations all converge here. Treat every permission as a production dependency with a clear purpose.
Remove permanent administrative access
Use centralized identity federation and require phishing-resistant multi-factor authentication for privileged roles. Avoid day-to-day use of root, owner, or global administrator accounts. Store break-glass credentials under documented, monitored procedures, and test recovery without normal identity-provider access.
Replace long-lived access keys with short-lived role sessions or workload identity. Where a legacy key cannot yet be removed, identify its owner, scope it to the smallest feasible permission set, rotate it on a fixed schedule, and alert on anomalous use. “Temporary” credentials routinely become permanent attack paths.
Enforce least privilege with evidence
Build roles around job functions and application actions, not broad service categories. A deployment role may need permission to update one service in one environment; it does not need unrestricted access to every database, storage bucket, or identity policy.
Review effective permissions, not just policy documents. Group inheritance, resource policies, service roles, permission boundaries, and cross-account trust relationships can combine in unexpected ways. Use access activity data to remove unused grants, but account for infrequent operational tasks such as disaster recovery and certificate rotation before deleting access.
Pay particular attention to cross-account and third-party access. Require external IDs or equivalent anti-confusion controls, restrict trusted principals, set short session durations, and review each trust relationship on a schedule. Vendor support access should be time-bound whenever the platform allows it.
Make Network Exposure Deliberate
A private subnet is useful, but it is not a security strategy by itself. Workloads need explicit ingress and egress rules, and those rules must reflect actual data flows rather than broad convenience ranges.
Do not expose administrative protocols directly to the internet. Use identity-aware access paths, managed session services, bastions with tight controls, or private connectivity. Restrict management interfaces by source, require strong authentication, and log every session.
For application traffic, place internet-facing services behind managed edge controls and load balancers. Terminate and enforce modern TLS, enable rate limiting and web application protections where they fit the threat model, and segment application, data, and management planes. Internal services should authenticate each other; network location alone is not sufficient proof of trust.
Egress deserves the same scrutiny as ingress. Unrestricted outbound access makes command-and-control and data exfiltration easier after a compromise. Full allowlists are not practical for every engineering organization, especially where dependencies change frequently. Start by routing and logging egress centrally, blocking known bad destinations, and limiting sensitive workloads to approved destinations where feasible.
Harden Compute, Containers, and Serverless Workloads
Compute hardening depends on the execution model. A managed serverless function does not need the same operating-system baseline as a virtual machine, but both need constrained identity, secure configuration, observability, and patch discipline.
For virtual machines, use approved hardened images, remove unnecessary packages and services, enforce endpoint protection where appropriate, require encrypted volumes, and patch against defined service-level objectives. Do not permit drift indefinitely. Rebuild from updated images when possible rather than treating production hosts as manually maintained artifacts.
For containers, pin base image versions or digests, scan images before release, sign artifacts, and admit only trusted images into production. Run as non-root, drop unneeded Linux capabilities, use read-only filesystems where compatible, and apply runtime restrictions. A container registry is part of the software supply chain, not just a storage location.
For serverless workloads, scope execution roles tightly and validate event-source permissions. Watch for functions that can access broad storage prefixes, entire databases, or unrestricted network routes. Environment variables are configuration, not a safe secret store. Encrypt them and minimize them, but prefer runtime retrieval from a dedicated secret system for credentials.
Protect Data and Encryption Boundaries
Classify data before selecting controls. Customer records, payment-related data, production backups, credentials, source code, and telemetry do not carry the same consequences if exposed. Classification drives retention, access review frequency, encryption key management, and monitoring priorities.
Encrypt data in transit and at rest using provider-managed services or customer-managed keys when control requirements justify the added operational burden. Customer-managed keys can support separation of duties and faster access revocation, but they also introduce key-policy complexity and availability dependencies. Use them deliberately, not as a checkbox.
Disable public access to storage by default. Require explicit exceptions with an owner and expiry date. Version critical objects, protect backups from deletion or alteration, and test restoration regularly. Encryption does not help if an attacker with valid access can delete every recoverable copy.
Treat Secrets as a Separate Attack Surface
Secrets move through more systems than most teams expect: ticketing tools, chat, CI variables, local shell histories, vendor onboarding forms, and incident channels. Cloud hardening fails when credential collection is informal.
Use a dedicated secret manager or vault for application credentials. Limit retrieval through workload identity, rotate automatically where supported, and avoid passing secrets through build logs or plaintext configuration. Scan repositories, container images, and CI output for accidental disclosure, then maintain a revocation process that is measured in minutes rather than days.
For collecting credentials from clients, contractors, or third parties, remove email and chat from the process. Securitae provides account-free Secure Links for controlled secret submission, with encrypted handling and options such as burn-on-view or synchronization to approved vault workflows. The security benefit is not merely encryption; it is eliminating uncontrolled copies and reducing who can see a credential during intake.
Make the Checklist Continuous
A hardening checklist used only before an audit will decay quickly. Convert the highest-confidence controls into policy-as-code, infrastructure-as-code checks, admission rules, and CI gates. Alert on drift for controls that must never change, such as public storage access or disabled audit logging. Route lower-risk findings to engineering backlogs with owners and due dates.
Measure the program using operational indicators: percentage of privileged users on phishing-resistant MFA, number of long-lived keys, public exposure count, mean time to remediate critical misconfigurations, patch compliance, secret rotation coverage, and restoration test success. Metrics should expose risk concentration, not create reporting theater.
Exceptions are inevitable. A legacy integration may require a static credential, or a customer-facing service may need public ingress. Document the business reason, compensating controls, owner, and expiration date. An exception without an expiry date is simply an undocumented security decision.
Cloud hardening is most effective when it becomes part of how teams ship: a clear identity model, safe defaults in reusable infrastructure, controlled secret flows, and evidence that the controls still work after the next deployment.