Why is multi-cloud harder to secure?

Each provider has different identity models, default network exposure, logging formats, and service naming, so a single policy cannot be expressed identically across them. Assets are also created by many teams through many mechanisms, which makes a complete inventory difficult to maintain.

How should exposures be prioritised?

Prioritise by exploitability and business impact rather than raw severity score. An internet-facing service with a known exploited vulnerability and access to production data outranks a critical-rated flaw on an isolated internal host.

Kinematic Digital | Enterprise Digital Transformation

Q: What is attack surface management?

Attack surface management is the continuous discovery, inventory, and reduction of everything an attacker could reach from outside the organisation — domains, hosts, APIs, cloud storage, exposed services, credentials, and third-party assets operating under your brand.

Ask a security team to list every internet-facing asset the organisation owns and you will get an answer. Run external discovery against the organisation's domains and cloud accounts and you will get a longer one — typically 20 to 40 percent longer. That delta is where breaches start.

Multi-cloud did not create the problem, but it industrialised it. Assets are now created in minutes by dozens of teams, through consoles, pipelines, and SaaS integrations, and nothing forces them into a central inventory.

Discovery must be continuous and adversarial

Inventory built from what teams declare will always be incomplete. Build it the way an attacker would, from the outside in: enumerate domains and subdomains including certificate transparency records, map cloud accounts and their public resources, catalogue exposed services and APIs, identify assets registered by marketing or agencies under your brand, and search for leaked credentials and keys in public repositories and paste sites.

Then reconcile external discovery against internal records. The unmatched items are the real finding: forgotten staging environments, decommissioned marketing microsites still resolving, storage buckets with public listing enabled, and admin interfaces exposed because a security group was widened "temporarily".

The recurring multi-cloud exposures

Exposure	Typical cause
Public object storage	Permission widened for a one-off integration and never reverted
Management interfaces on the internet	Convenience access from a broad IP range
Unauthenticated internal APIs	Assumed network isolation that no longer exists
Dangling DNS records	Resource deleted, record retained — subdomain takeover
Over-privileged service identities	Broad roles granted during development
Unmanaged SaaS integrations	OAuth grants issued by staff without review

Dangling DNS deserves specific attention because it is trivially exploitable, invisible to internal scanning, and lets an attacker serve content from your own domain.

Prioritise by exploitability, not severity score

Vulnerability counts are not a workplan. Rank each exposure on four factors: is it reachable from the internet, is there a known exploited vulnerability, does it hold or reach sensitive data, and does compensating control exist. An internet-facing service with an actively exploited flaw and a path to production data is an emergency; a critical-rated issue on an isolated host with no route in is scheduled work.

Publish this ranking logic. Engineering teams comply with remediation requests far more readily when the reasoning is transparent and consistent.

Reduce, then prevent

Reduction is the fast win: decommission what is not needed, move management interfaces behind identity-aware access, close public storage by default, and remove stale DNS records. Prevention is what stops regression:

Guardrails as policy. Deny public storage and open inbound rules organisation-wide, with a documented exception process.
Infrastructure as code with policy checks. Block exposure-creating changes in CI rather than detecting them afterwards.
Mandatory ownership tags. An asset with no owner cannot be remediated; enforce tagging at creation.
Automated DNS hygiene. Tie record lifecycle to resource lifecycle.
SaaS grant review. Periodically review and revoke OAuth grants issued to third-party applications.

Validate continuously

Configuration state and real-world exploitability are different things. Complement scanning with periodic validation: external penetration testing focused on the newly discovered surface, breach and attack simulation against detection coverage, and a red team exercise annually for organisations with mature controls.

Track three metrics: percentage of internet-facing assets with a named owner, mean time to remediate internet-facing critical exposures, and the count of newly discovered unknown assets per month. The last one measures whether your prevention guardrails are actually working — if unknown assets keep appearing, discovery is treating symptoms.

Frequently asked questions

What is attack surface management?

Continuous discovery, inventory, and reduction of everything reachable from outside the organisation — domains, hosts, APIs, cloud storage, exposed services, credentials, and brand-adjacent third-party assets.

Why is multi-cloud harder?

Different identity models, default exposure, and logging per provider, combined with asset creation by many teams through many mechanisms, make uniform policy and complete inventory difficult.

How should we prioritise?

By exploitability and business impact — internet reachability, known exploited vulnerabilities, data sensitivity, and compensating controls — not by raw severity rating.

How often should discovery run?

Continuously, with weekly review. Cloud assets appear and disappear daily, so quarterly scanning guarantees blind spots.

Attack Surface Management for Multi-Cloud Enterprises