Ask me how many applications are running in a typical enterprise cloud environment, and I’ll give you an estimate. Ask me again a few minutes later, and I might give you a completely different number. It’s not that I’m unsure on purpose — it’s just that the landscape shifts constantly.

From CI/CD pipelines redeploying workloads, to forgotten legacy applications hiding in the recesses of cloud accounts, to zombie services running on outdated scripts, it’s almost impossible to keep an accurate count. And let’s not forget the identity piece — with a web of IDPs scattered across environments, visibility is even harder to achieve.

Find out how to Rationalize IDPs without painful migrations. 

What I’ve learned is simple: If we can’t see what’s running, we can’t manage or secure it. This isn’t about audit checkboxes. It’s a real-time security blind spot. Threats include orphaned applications with no MFA, services still using outdated authentication, and misconfigured workloads that fly under the radar. That’s where bad actors strike.

With everything else becoming continuous — from development to deployment — why should discovery be any different?

Cloud fragmentation is real

In almost every organization I’ve worked with, applications are spread across AWS, Azure, GCP, and sometimes even private clouds. But fragmentation doesn’t stop at the cloud level — it’s inside each cloud too.

Take GCP for example. One app might live in App Engine, another in Cloud Run, and yet another on Kubernetes Engine. Some teams might use Compute Engine VMs or even Apigee Gateway. Azure and AWS follow similar patterns, each with their own sprawl of services.

And while tools like Terraform and IaC help, they aren’t silver bullets. Developers often bypass templates, spin things up manually, or forget to apply tags. That means even the most well-intentioned infrastructure team might miss something.

The invisible web of identity

It’s not just the application layer that’s fragmented. Identity is equally disjointed making interoperability nearly impossible

I’ve seen environments where internal tools use Okta, customer-facing apps rely on Microsoft Entra ID, and older services still use SiteMinder or on-prem Active Directory. That means different apps use different IdPs depending on the team, the project, or the timeline.

The result? A tangled mesh of login flows, policies, and access configurations that’s nearly impossible to untangle. Even checking whether MFA is enforced for a given app can turn into a multi-day investigation.

That level of fragmentation isn’t just inconvenient — it’s dangerous. Attackers don’t always need sophisticated exploits. Sometimes all it takes is an app that slipped through the cracks, using outdated auth or wide-open permissions.

Why one-time audits fall short

Traditional security audits don’t cut it in environments like this. I’ve seen the playbook: bring in a consulting firm, scan the environment, generate a glossy report, and move on. But by the time that report lands in your inbox, it’s already outdated.

Apps spin up and down with each pipeline trigger. Dev teams experiment, forget to notify security, or redeploy old code. And once-decommissioned services reappear because a CI/CD script was never updated.

Worse still, these audits only show a snapshot — a freeze-frame of a system that never stands still. The findings usually live in static documents that get shelved until the next cycle, offering no continuity and even less context.

The high cost of guessing

These static assessments aren’t just limited — they’re expensive. I’ve seen companies spend hundreds of thousands of dollars on third-party audits that generate great PowerPoint decks but offer little help when an engineer is trying to track down which IdP governs a legacy service on some forgotten cluster.

Meanwhile, attackers are scanning your perimeter in real-time. They’re not waiting for your audit to finish. They’re looking for the one API or container you forgot to check. That’s why continuous discovery isn’t just nice to have — it’s necessary.

What continuous discovery actually looks like

Many security teams feel like they’re playing blindfolded whack-a-mole. They find one untracked app, and suddenly three more appear. It’s not that the teams aren’t diligent — it’s that the environment changes faster than they can track it.

Continuous discovery changes the game. It turns visibility into a living, breathing capability — something embedded into your operations, not bolted on after the fact. Here’s what that means to me:

  • Cloud-native scanning: Querying APIs across cloud platforms like GCP, Azure, and AWS to surface deployments across services — from App Engine and Lambda to ECS and Cloud Run.
  • Identity correlation: Mapping each app to its IdP, validating MFA usage, and recording the auth pattern (SAML, OIDC, LDAP, or even header-based).
  • CI/CD awareness: Catching workloads that resurface unexpectedly because of outdated automation.
  • Tagging and classification: Organizing apps by compliance domains, business units, or data sensitivity to create a more meaningful inventory.

Continuous discovery connects the dots between identity and infrastructure. It builds the foundation for real-time risk detection, operational resilience, and a more responsive security posture.

Emphasizing uncertainty at scale

I’ll never forget a conversation I had with a CTO at a Fortune 500 company. When asked how many applications were running across her environment, she replied, “2,500.” Then she paused and added, “Actually, we just merged with another company. So… maybe 4,500?”

That number wasn’t pulled from a dashboard. It was an educated guess — based on headcount, experience, and assumption. There was no centralized system of record. No discovery tool to validate the claim.

This story isn’t unique. In many organizations, application counts live in spreadsheets, tribal memory, or not at all. And that uncertainty carries real risk. If leadership can’t answer a foundational question about app inventory, how can they ensure those apps are protected?

Why this matters to engineers and IAM teams

As someone who’s worked closely with identity teams, I’ve seen how overlooked apps become liability magnets. An internal tool using basic auth might not seem like a big deal — until it’s breached. And if your IAM spreadsheet is six months old, it’s not going to help when an auditor comes knocking.

With continuous discovery in place, you know:

  • What’s running
  • Who can access it
  • Whether it’s secure

And you can back that up with real data — not best guesses.

The future isn’t static

Discovery isn’t just about having an app inventory. It’s about making the invisible visible. That includes:

  • Old services nobody remembers deploying
  • Misconfigured containers running in shadow accounts
  • Legacy systems still quietly accruing cost and risk

When you have real-time visibility, you can act fast. You can respond to threats, close gaps, and stay ahead of compliance requirements — without playing catch-up.

To me, that’s what modern identity security is all about: being proactive, precise, and continuously aware.

Download the State of Multi-Cloud Identity 2025 to uncover how enterprise security leaders are navigating application sprawl, fragmented IdPs, and continuous discovery — and why real-time visibility is becoming the new baseline for identity security.

Share.

Comments are closed.