TL;DR: Identity failures increasingly happen through valid logins and trusted integrations, not malware, with one OAuth token theft opening more than 700 Salesforce environments and another warehouse campaign reaching about 165 companies, according to Newcore. Identity policy now has to evaluate context, privilege, and application criticality at the decision point, because sign-in alone no longer expresses real risk.
At a glance
What this is: This analysis says identity policy must move from basic authentication to risk-based decisions that account for context, privilege, and application criticality.
Why it matters: IAM, PAM, and NHI teams need policies that can intervene at sign-in and mid-session, because valid credentials and trusted integrations now carry most of the blast radius.
By the numbers:
- almost 70% of security incidents it investigated last year were identity-related weaknesses.
Context
Identity policy is the control point that decides whether a login should be allowed, stepped up, limited, or blocked. The article argues that this decision cannot stop at authentication because the real problem is not just who signed in, but what that identity can reach once inside.
For IAM programmes, the gap is between sign-in assurance and access governance. The article frames application sensitivity, privilege level, and live session risk as inputs that need to be enforced in the path, not only recorded after the fact.
The same shift affects NHI and agentic AI governance as well as human IAM. If the control only checks identity at login, it misses trusted tokens, delegated access, and machine-initiated sessions that can move faster than manual review cycles.
Key questions
Q: What breaks when identity checks focus only on sign-up verification?
A: Abuse shifts downstream. A profile can pass onboarding and still be synthetic, duplicated, or coordinated with other accounts. When teams stop at initial verification, they miss behavioural reuse, bonus cycling, and account hopping that only becomes visible after the first transaction or betting pattern emerges.
Q: Why do trusted integrations create a larger breach risk than direct credential theft?
A: Trusted integrations often bypass the usual suspicion that follows direct credential theft because they are already authorised to act. That means an attacker can use valid access paths, appear normal to monitoring, and reach multiple systems or datasets without creating obvious authentication failures. The result is slower detection and a much larger blast radius.
Q: What are the signs that a storage access policy is failing in practice?
A: Warning signs include shared URLs that grant broader permissions than users expect, long-lived tokens that remain valid indefinitely, and security alerts that are repeatedly dismissed as false positives. Another indicator is when access review depends on outside discovery rather than internal monitoring. If users can accidentally overexpose backups or credentials, the policy is not tight enough.
Q: Should organisations prioritise in-path policy over posture scoring?
A: Yes, when the goal is to stop risky access rather than just document it. Posture scoring helps identify weak accounts and integrations, but only in-path policy can change the outcome at the moment of access. The right sequence is visibility first, enforcement in the access path second.
Technical breakdown
Why sign-in controls fail after authentication
Traditional identity control treats authentication as the main gate, then assumes the subject remains safe enough for the rest of the session. That model breaks when the credential is already trusted, because a valid token, session, or OAuth grant can bypass friction without tripping alerts. The important technical distinction is that authentication proves possession or assertion at a point in time, while authorisation should still evaluate the request in context. The article’s core point is that the identity provider, not a sidecar posture tool, is the only place where policy can intervene before access becomes usable.
Practical implication: move policy decisions into the access path so the system can deny, limit, or step up before a session reaches high-value resources.
How application criticality should shape access policy
The article describes application worth as a governance input, not a static tag. An app’s sensitivity changes over time, and the same application carries different risk depending on who is signing in, which role they hold, what environment they are in, and how much data they can reach. That is why policy must be context-aware rather than rule-only. The mechanism is straightforward: the identity layer can use signals already present at sign-in to infer the protection level required and then adjust authenticators or access decisions accordingly. This is closer to dynamic risk governance than to simple MFA enforcement.
Practical implication: classify applications and privileges by business criticality, then align challenge strength and session controls to that criticality.
Why posture tools cannot replace in-path policy
A posture tool can identify weak accounts, exposed apps, or risky configurations, but it sits beside the identity provider rather than inside the authentication path. That means it can report on problems without stopping access at the moment of decision. In practice, that separation creates a governance gap: detection sees the issue after the fact, while policy must act before trust is extended. The article also distinguishes human logins from the new reality of AI agents and machine-mediated access, where the speed of access makes delayed remediation even less useful.
Practical implication: use posture tooling for visibility, but reserve real enforcement for the identity control that makes the allow or deny decision.
Threat narrative
Attacker objective: The objective is to turn legitimate identity trust into broad access across high-value environments without raising alarms.
- Entry occurs through valid credentials, trusted tokens, or delegated access rather than malware or password cracking.
- Credential use succeeds because the token or login is already trusted by the target environment and no stronger step-up control is triggered.
- Impact follows when the attacker or unauthorised session reaches sensitive data, administrative functions, or connected SaaS environments at scale.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
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 policy is now a runtime control, not a reporting layer: A policy that only records risk after sign-in is already too late for today’s credential-led attacks. Trusted tokens, delegated access, and long-lived sessions require the allow or deny decision to happen where access is actually consumed. The implication is that identity teams must stop treating policy as administrative metadata and treat it as an execution control.
Context, not identity alone, determines real access risk: The same account can be low-risk in one application and catastrophic in another, which makes static app labels structurally weak. The article correctly points to business criticality, privilege level, and environment as live inputs to access decisions. Practitioners should read that as a warning that manual sensitivity tagging is a governance shortcut, not a control.
Valid credentials are the new breach primitive: The article’s breach examples show that attackers do not need to defeat authentication when they can borrow trust already issued by the ecosystem. That shifts the security problem from password strength to trust boundary design, especially where SaaS integrations and machine credentials are involved. For identity governance, the decisive question becomes how much access a valid session can inherit before it is reevaluated.
Security-first access policy is a control-plane issue, not a product feature: Putting smarter decisions into the identity provider changes the shape of governance because it gives the organisation a place to enforce context-sensitive risk decisions in real time. That matters across human IAM, NHI, and agentic access because the same policy mistake can now propagate across all three. The practical conclusion is that programme design must centre on in-path enforcement, not post-event cleanup.
Ephemeral trust debt: Access models that issue trust once and assume it remains valid for the life of the session create hidden exposure that grows with every connected app and integration. That is the kind of debt that makes valid logins more dangerous than failed logins, because nothing appears broken until the wrong system is reached. Identity teams should recognise this as a structural governance issue, not a tuning problem.
From our research library:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- Read next: OAuth 2.0 and OpenID Connect Guide for Identity Teams
What this signals
Identity programmes should treat every trusted connector as part of the access plane, not as a back-office convenience. Once OAuth grants and delegated sessions can move into core business systems, the boundary between human sign-in and machine-to-machine trust becomes a governance boundary that needs active enforcement.
Ephemeral trust debt: When policy decisions are made once and never revisited, access accumulates hidden risk across applications, roles, and integrations. Teams need to watch for environments where visibility exists but enforcement still depends on manual review or after-the-fact reporting.
The strongest next step for practitioners is to test whether application criticality, role, and session context actually change the challenge or deny decision. If they do not, the organisation has analytics, not policy.
For practitioners
- Embed risk decisions in the access path Make the identity provider the enforcement point for allow, deny, and step-up decisions so policy can react before access is granted.
- Tie challenge strength to application criticality Use the value of the target application, the role being used, and the current environment to determine whether the session needs stronger proof.
- Review standing trust in SaaS integrations Inventory integrations, tokens, and delegated access that can reach customer, financial, or administrative data without fresh evaluation.
- Separate visibility from enforcement Keep posture tools for detection and reporting, but require in-path policy for the actual access decision when risk changes.
- Test policies against real user and agent journeys Simulate who gets through, which roles fail, and where legitimate work would be blocked before you enforce new rules broadly.
Key takeaways
- Valid credentials and trusted integrations now account for much of the practical breach path, so identity risk is less about breaking in than about abusing existing trust.
- The article’s evidence points to identity-related weaknesses as a dominant issue, which means static sign-in policy is no longer enough on its own.
- Access decisions need to move into the live path, where context and privilege can shape the outcome before a session reaches sensitive systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centres on identity decisions that fail after a trusted login or token is already accepted. |
| NHI-05 — Overprivileged NHI | Trusted integrations and delegated access can carry more reach than the session should have. | |
| Recommendation — Strengthen authentication decisions so valid credentials still face context-aware checks before access is granted. Review non-human and delegated accounts for excess reach and reduce privileges to the minimum needed. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The article’s core issue is that broad access remains available after login unless privilege is constrained in context. |
| Recommendation — Apply least-privilege access so session scope stays proportional to the application and role being used. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The piece is about making access decisions based on entitlements, permissions, and live context. |
| Recommendation — Align permissions and authorizations with the current risk context instead of relying on static sign-in trust. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The cited breach pattern uses valid credentials and trusted integrations to move across connected environments. |
| Recommendation — Map trusted-token abuse to credential access and lateral movement techniques in detection and response planning. | ||
Key terms
- In-Path Policy: An access decision made inside the authentication or authorisation flow, before the session is fully trusted. In-path policy can allow, deny, or step up based on live context, which makes it different from posture reporting or offline review.
- Application Criticality: The business value and sensitivity of the system being accessed, such as a finance ledger, customer database, or privileged admin console. It is a governance input that should influence authentication strength, authorisation logic, and session monitoring rather than being left as a static label.
- Trusted Integration: A third-party or internal connection that is already authorised to act on behalf of a user, service, or application. These integrations are powerful because they inherit trust from the platform, which is exactly why stolen or over-scoped tokens can cause broad downstream access.
- Posture Tool: A control that identifies weak identities, risky configurations, or exposure conditions without being in the live access path. Posture tools are useful for visibility, but they cannot by themselves prevent a session from reaching a protected resource.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 11, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org