Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

Identity policy and trust boundaries: are your controls keeping up?


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 15374
Topic starter  

TL;DR: Identity breaches increasingly exploit valid credentials rather than malware, with one incident chain moving through a trusted OAuth integration to 700-plus Salesforce environments and another 165-company warehouse campaign using stolen passwords, according to the source article and referenced cases. The governance lesson is clear: access policy must evaluate context and privilege in the sign-in path, not just authenticate the subject.

NHIMG editorial — based on content published by Newcore: security-first identity policy and context-aware access control

By the numbers:

  • In August 2025, one attacker group stole OAuth tokens from a single trusted integration and walked into the Salesforce environments of more than 700 organizations.
  • In 2024, attackers walked into the data warehouses of about 165 companies just by reusing stolen passwords.

Questions worth separating out

Q: How should security teams handle trusted OAuth integrations that can reach critical systems?

A: Treat every trusted integration as a standing access path that needs its own lifecycle, scope review, and revocation criteria.

Q: Why do valid credentials remain such a major enterprise risk?

A: Valid credentials work because they bypass many traditional perimeter controls and often inherit legitimate access.

Q: What do organisations get wrong about posture tools and access policy?

A: They confuse detection with enforcement.

Practitioner guidance

  • Map all trusted integrations that can reach crown-jewel systems Inventory OAuth apps, service connections, and delegated tools that can access finance, customer, or admin data.
  • Move access decisions into the identity provider path Use policy enforcement that can step up, deny, or terminate a session before the request reaches the target application.
  • Bind authentication strength to resource criticality Require phishing-resistant authenticators for high-impact applications and privileged roles rather than applying one factor level everywhere.

What's in the full article

Newcore's full article covers the operational detail this post intentionally leaves for the source:

  • How the source article maps access policy to application worth and risk scoring in practice
  • The comparison between identity policy enforcement and posture tools in the sign-in path
  • Examples of stronger authenticator levels for higher-value access decisions
  • The article's own explanation of secure split key infrastructure and device-bound synced passkeys

👉 Read Newcore's analysis of security-first access policy for identity control →

Identity policy and trust boundaries: are your controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 3 months ago
Posts: 14958
 

Identity policy is now the control plane, not an adjacent control. The article is right that posture reporting alone cannot stop misuse once a token or password is accepted. The field needs to stop treating identity policy as a settings layer and start treating it as the enforcement point where access, risk, and business context intersect. Practitioners should frame every identity decision around where enforcement actually happens.

A few things that frame the scale:

  • 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
  • Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.

A question worth separating out:

Q: How should teams decide when to require stronger authentication for an application?

A: Base the requirement on the value of the application and the power of the role, not on a generic enterprise standard. Admin access to a customer system, ledger, or policy engine should face stronger proof than low-risk read-only access, because the same login has very different consequences.

👉 Read our full editorial: Identity policy must move from logging in to controlling risk



   
ReplyQuote
Share: