Identity-first security for enterprise apps: what Gartner’s view means

At a glance

What this is: This is Orchid Security’s announcement of Gartner Cool Vendor recognition, framed around identity-first security for enterprise applications and hidden identity paths.

Why it matters: It matters because IAM teams need to judge whether their governance model can discover, analyse, and control application identities, service access, and hidden authentication flows across managed and unmanaged environments.

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Orchid Security’s perspective on identity-first security and Gartner recognition

Context

Identity-first security starts with a simple problem: most enterprises cannot see every application, secret, service account, or authentication flow that now carries access. When identity is embedded in code, cloud services, APIs, and unmanaged systems, traditional perimeter thinking misses the real control points.

Orchid Security’s announcement is really about a governance shift, not a product feature list. The question for IAM and IGA teams is whether their current programme can discover identity paths early enough, assess them continuously, and bring them into policy without turning onboarding into a manual bottleneck.

Key questions

Q: How should IAM teams govern application identities that are hidden in code and runtime flows?

A: Start by discovering where identities actually exist inside applications, not just where they are recorded in IAM. Then reconcile those findings with access policy, ownership, and review processes. Hidden application identities often include secrets, service accounts, and token-based trust that were never brought fully under governance.

Q: Why do hidden application identities create risk for identity-first security programmes?

A: Because governance cannot control what it cannot see. When access lives in code, config files, APIs, or runtime dependencies, certification and offboarding processes miss active trust paths. That leaves organisations with policy on paper and unmanaged access in production.

Q: What do security teams get wrong about identity visibility in modern environments?

A: They often treat directory completeness as the same thing as identity visibility. In reality, many of the highest-risk access paths are application-native, ephemeral, or inherited from integrations that never pass cleanly through central IAM records.

Q: How can organisations tell whether identity-first security is actually working?

A: Look for evidence that discovery feeds governance actions. If hidden accounts, embedded secrets, and application trust paths are being found but not remediated through onboarding, review, or offboarding, the programme is producing insight without control.

Technical breakdown

Identity-first security and hidden application identities

Identity-first security moves the control point from network boundary enforcement to the identity relationships inside applications, services, and workflows. In practice, that means authenticators, authorisers, secrets, and embedded access paths become the system of record for risk analysis. If those paths are invisible, governance is incomplete even when the IAM stack looks healthy. The hardest problem is not issuing access, but discovering where access already exists in code, configuration, and runtime dependencies.

Practical implication: build discovery around application behaviour, not only around directories and role catalogues.

Application authentication and authorisation flow analysis

Authentication and authorisation flow analysis traces how an application proves identity and decides access. That includes native login logic, token exchange, service-to-service trust, and privilege handoff between components. When teams analyse those flows continuously, they can spot drift between declared policy and actual runtime behaviour. This is especially relevant where apps were onboarded before current governance standards existed, because old assumptions persist long after the environment has changed.

Practical implication: compare declared IAM controls against observed application flows and treat mismatches as governance defects.

Infrastructural orchestration for identity governance

Orchestration in this context means coordinating discovery, prioritisation, and remediation across IAM, application, and security controls. It is not the same as automation for its own sake. The architectural value is that identity data from multiple layers can be correlated into one governance view, which matters when unmanaged systems, cloud workloads, and AI-adjacent services all create separate access paths. Without that correlation, security teams only see fragments of the identity picture.

Practical implication: connect discovery outputs to IAM and IGA workflows so unmanaged access paths do not remain outside governance.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity-dark-matter discovery is now a governance requirement, not a nice-to-have. Enterprises increasingly carry identity paths that are not represented cleanly in IAM inventories, especially inside applications, configs, and runtime integrations. That hidden layer creates blind spots in onboarding, review, and enforcement, and the result is governance based on incomplete evidence. Practitioners should treat discovery coverage as a control objective, not an observability bonus.

Identity-first security shifts the question from who has access to where access already exists. Traditional IAM models often start with users, groups, and provisioned entitlements, but modern applications create their own access fabric through APIs, secrets, tokens, and embedded trust. Gartner’s framing is useful because it reflects a broader reality: identity is no longer only an assignment problem. The practitioner implication is that governance must map actual access paths before it can certify them.

Application-native visibility is the missing layer in many IAM and IGA programmes. If onboarding only records what administrators intended to provision, it will miss the access that applications create for themselves during operation. That gap is especially material for unmanaged systems, shadow integrations, and AI-adjacent workflows that inherit credentials indirectly. The implication is that IGA cannot rely on directory completeness alone when the estate itself is generating identities and trust relationships.

Identity control planes will become a category pressure point as environments fragment further. The market is moving toward platforms that can connect discovery, analysis, and orchestration across cloud, application, and governance stacks. That does not eliminate IAM, but it does raise the bar for what counts as usable coverage. Practitioners should expect vendors to be judged less on claims of visibility and more on whether they can prove continuous control across the environments where identity actually lives.

Identity-first governance also has an autonomous-system preview, even when the article is not about AI agents. The same problem appears when software begins making runtime decisions about identity relationships faster than human review cycles can follow. That is why identity governance cannot remain a static provisioning discipline. The practitioner takeaway is to design for continuous evidence, because application-generated identity behaviour will keep outpacing periodic review.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• The 52 NHI Breaches Analysis shows how visibility gaps and credential exposure become breach-enabling conditions across real incidents.

What this signals

Identity-dark-matter governance will become a board-level measurement problem. If only 5.7% of organisations can see their service accounts fully, then discovery coverage is not a technical nicety. It is the baseline for credible oversight, and that makes hidden identity inventory a recurring management signal rather than a one-off clean-up activity.

Enterprises should expect application-native identity discovery to sit closer to IGA, secrets, and cloud governance over time. The practical shift is toward evidence-based onboarding, where every new application or integration must prove what it authenticates with and what it can reach before it is trusted in production.

The next maturity step is not more alerts. It is a tighter loop between what the application actually does and what governance says it is allowed to do, with continuous checks against NIST Cybersecurity Framework 2.0 principles and identity-first operating models.

For practitioners

• Inventory application-generated identity paths Map secrets, service accounts, token exchanges, and embedded trust relationships that live outside the directory. Prioritise applications where onboarding was manual, partial, or inherited from older architectures, because those paths are most likely to evade normal review.
• Reconcile declared access with observed flows Compare IAM records against real authentication and authorisation behaviour in production. Flag any app where the observed trust model differs from what governance systems say exists, then route those gaps into remediation as control failures.
• Treat hidden identity discovery as a recurring control Make coverage checks part of your governance cadence, not a one-time inventory exercise. Use the results to drive onboarding, recertification, and offboarding workflows so unmanaged identities do not persist between review cycles.

Key takeaways

• Identity-first security becomes relevant when organisations can no longer rely on directories alone to explain how access exists in real systems.
• Hidden application identities are a governance problem because they sit outside normal onboarding, review, and offboarding workflows.
• The practical response is continuous discovery and reconciliation, so identity policy reflects actual application behaviour rather than assumptions.

Key terms

• Identity-first security: An approach that places identity relationships at the centre of security design instead of treating the network boundary as the primary control. It focuses on who or what is proving identity, what it can access, and how those trust paths are governed across applications, services, and workflows.
• Identity dark matter: The identity footprint that exists in an environment but is not fully visible to governance teams. It includes hidden service accounts, embedded secrets, unmanaged integrations, and access paths created by applications themselves, which means policy and reality can drift apart without continuous discovery.
• Application-native identity: An identity or trust relationship created and used by an application rather than by central IAM provisioning alone. These identities may appear as service accounts, tokens, API keys, or embedded flows, and they often need separate discovery and governance because they are easy to miss in standard review cycles.

Deepen your knowledge

Identity-first security and application identity discovery are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is trying to govern hidden access paths across applications and services, it is worth exploring.

This post draws on content published by Orchid Security: Gartner Cool Vendor recognition in identity-first security. Read the original.