1. Map What Your Application Estate Actually Looks Like
Not what your IGA thinks it looks like.
Most identity teams start with a directory. The directory knows about users. Your IdP knows about the SaaS apps that support SSO. Your IGA knows about what got onboarded. But none of them know about the 400 custom apps, self-hosted tools, and disconnected systems that process your most sensitive data - because those were never integrated.
This is identity dark matter. It has mass. It exerts force. You can't see it from your identity tooling, but attackers can find it.
The practice isn't just "centralize your identity management." It's: **understand what's actually in your application estate and how each application handles identity.** Which apps use hardcoded
credentials? Which run legacy protocols? Which have their own local account stores? Which external identity integrations did your team not configure?
You can't govern what you can't see. And you can't see it by checking your IGA.
Discovery is the starting point. But discovery alone isn't enough. You need to understand how authentication and authorization actually work inside each application - not just which ones are listed in a spreadsheet.
2. Eliminate Embedded and Hardcoded Credentials
This one hasn't changed. It's still one of the most common findings in any serious application estate review. And it's still being tolerated.
Hardcoded passwords in configuration files. Service account credentials embedded in application code. API keys are stored in deployment scripts that were committed to a repo years ago and have never been rotated. These aren't theoretical risks. They're found in most enterprise environments, especially in custom-built and legacy applications that never underwent a modern development security review.
The challenge isn't awareness. Everyone knows hardcoded credentials are bad. The challenge is finding them systematically across a sprawling, mixed environment - especially in compiled binaries or running application behavior that doesn't show up in static code analysis.
The practice: treat credential hygiene as a continuous audit process, not a one-time scan. Rotate secrets on schedule. Track service accounts. Get visibility into how credentials are actually being used at runtime - not just how they were declared. An embedded credential that's still being actively used is far more dangerous than one sitting inert in an archived repo.
3. Verify Authentication Enforcement, Not Just Configuration
Your IdP says MFA is required. But does every application actually enforce it?
The gap between what your identity policy says and what applications actually do is where real risk lives. An application integrated with your SSO provider may have a fallback authentication path - a local admin account, a legacy LDAP integration, a developer backdoor - that bypasses your IdP entirely. Your logs show clean. Your configuration shows compliance. The application is still exploitable.
MFA is essential. FIDO2 and passkeys are the right direction - phishing-resistant, hardware-backed, and increasingly the standard for high-value access. But the question that actually matters isn't "is MFA configured?" It's: Does the application respect the authentication policy you've set?
Enforce SSO where it's supported. Mandate MFA at the application layer, not just at the IdP. Audit whether applications honor your policies - not by reviewing documentation, but by examining how they actually behave. Many don't comply. Most teams never check.
4. Govern Access Where Enforcement Actually Happens
IGA systems provision and deprovision. That's necessary. But provisioning access correctly doesn't mean access is being enforced correctly.
Inside an application, authorization logic is usually custom-built. Role checks, permission gates, and access controls are written by developers - and they're often inconsistent, overly permissive, or simply wrong. An employee can be deprovisioned from your IGA and still retain access through an application-side session, a local account that was never tied to your identity stack, or a role assignment that persisted after their offboarding.
The practice isn't just "run access reviews." It's: **understand how authorization actually works inside your applications.** Map the entitlement paths. Find orphaned accounts your IGA doesn't know about. Identify where access gets granted inside the app, outside your provisioning process.
Least privilege has to be enforced where decisions are made - inside the application - not just at the point of entry. If your access reviews are evaluating declared permissions while the actual enforcement logic does something different, you're certifying something that isn't true.
5. Make Authorization Behavior Visible
Zero trust is a sound philosophy. But you can't zero-trust your way through an application's internal authorization model.
Most identity teams have reasonable visibility into who authenticated. Far fewer have visibility into what those identities actually did after authentication - which resources they accessed, which permissions they invoked, which authorization checks passed or failed. That's a problem because lateral movement and privilege escalation typically occur through authorization paths that appear entirely normal. The user authenticated. The session is valid. The access looks clean. But they're traversing paths that were never intended to be accessible.
The practice: get observability into authorization behavior, not just authentication events. Know which entitlements are actually used versus just assigned. Flag anomalous permission invocations. Understand the difference between what a role is allowed to do and what it actually does.
This is harder than it sounds - especially across a mixed application estate where authorization logic is custom for each app. But it's where the real control is. You cannot detect abuse, you cannot observe.
6. Non-Human Identities and AI Agents Are Your Fastest-Growing Risk
Every service account is a potential path to a breach. Every API key is an identity. Every AI agent running in your environment is an actor with application-level permissions, and it needs to be governed.
Most teams know they have a non-human identity problem in theory. The practical steps: no hardcoded credentials for service accounts, rotation policies in place, minimal privilege scoping, and audit trails for machine-to-machine activity. These are table stakes at this point.
What most teams are not ready for is AI agents. An AI agent receives instructions. It has context. It takes actions inside applications with real permissions. And unlike a deterministic service account, its behavior is dynamic, which means the blast radius of a compromised or misconfigured AI agent can be unpredictable and large.
Governing AI agents means governing their identity: what they can access, what they're allowed to do, under what conditions they're permitted to act, and whether every action is traceable back to an auditable identity chain. If you can't answer those questions, you have an ungoverned actor with application access.
Non-human identities aren't a footnote to your identity security program. They're the fastest-growing segment of your identity surface. A model that only governs human users is already behind.
7. Build Audit Evidence That Holds Up
When an auditor asks you to demonstrate identity security controls, what do you show them?
Logs from your IdP. Exported reports from your IGA. Screenshots and spreadsheets assembled in the weeks before the audit. Evidence that documents configuration - not behavior.
That gap between documented configuration and what actually happened is where most audit programs fall short. Regulators are increasingly asking for evidence of enforcement, not just evidence of intent. "Our policy requires MFA" is not the same as "here is a continuous, timestamped record showing that every authentication event on this system enforced MFA." The first is a control. The second is evidence.
The practice: build continuous, audit-ready evidence of identity governance - captured at the application layer, not assembled from logs after the fact. That means security-qualified identity events tied to specific applications and users. Clear records of what identities accessed and what they did. The ability to reconstruct the identity chain for any action on any system, on demand.
Audit readiness shouldn't require three weeks of manual prep. It should be a function of continuous observability. If it takes that long, the program isn't running - it's performing.
Final words
None of these practices are optional anymore. Application sprawl, AI agent proliferation, fragmented IAM coverage, and tightening regulatory requirements have made identity security harder - and more consequential.
The teams that handle this well share one trait: they've moved beyond visibility into actual observability. They don't just know who has access. They understand what identities do inside applications, how enforcement actually works, and what evidence they can produce when it's challenged.
Traditional IAM governs the front door. Control breaks down inside the application. Start from there.
