Notifications
Clear all
Topic starter
08/06/2026 4:24 pm
TL;DR: APT29’s use of hijacked legitimate accounts, OAuth traversal, and standing access shows why one-time session checks and legacy PAM are weak against modern intrusion patterns, according to StrongDM’s analysis. Continuous authorization, zero standing privilege, and just-in-time access become the control model that matters when attackers operate inside trusted accounts.
NHIMG editorial — based on content published by StrongDM: Unmasking Cozy Bear (APT29) and the urgent need for continuous authorization
By the numbers:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
- Only 5.7% of organisations have full visibility into their service accounts.
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
Questions worth separating out
Q: How should security teams handle trusted accounts after an intrusion starts?
A: They should assume the account can no longer be trusted just because it authenticated successfully.
Q: Why do standing credentials increase the risk of lateral movement in cloud environments?
A: Standing credentials remain usable long after the original business need has changed, so an attacker who inherits them can move across systems without re-authenticating.
Q: What do teams get wrong about continuous authorization?
A: Many teams think continuous authorization is just a stronger login check, but it is actually a runtime decision model.
Practitioner guidance
- Move from session approval to session re-evaluation Require continuous checks on device posture, location, role, and action sensitivity before privileged commands can proceed.
- Eliminate standing access on high-value accounts Review accounts that can reach databases, clusters, cloud consoles, and internal applications, then convert durable access into just-in-time access with automatic expiry and logged approvals.
- Harden OAuth and token governance Treat OAuth apps, tokens, and sessions as active privilege carriers.
What's in the full article
StrongDM's full blog covers the operational detail this post intentionally leaves for the source:
- A walkthrough of Continuous AuthZ checks across device, geography, role, and session duration.
- Examples of just-in-time access workflows and how requests, approvals, and revocations are handled.
- A closer look at access logs and reporting for audit and incident response use cases.
- The article's product-specific view of how access workflows fit into StrongDM's platform.
👉 Read StrongDM's analysis of APT29, continuous authorization, and zero trust →
APT29 and continuous authorization: are your access controls keeping up?
Explore further
08/06/2026 6:02 pm
Continuous authorization exposes the failure of one-time trust decisions. The access model assumed by many IAM and PAM programmes was designed for sessions that could be trusted after login. That assumption fails when an attacker can hijack a valid account and continue operating inside the approved boundary. The implication is that security teams must stop treating authorization as a front-door event and start treating it as a runtime condition.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to The Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why hidden privilege paths keep reappearing in incident response.
A question worth separating out:
Q: Who is accountable when an attacker reuses valid access to move through systems?
A: Accountability sits with the organisation that allowed access to persist without effective monitoring, revocation, or contextual re-checks. The attacker is responsible for the abuse, but the governance failure is allowing an identity to keep broad authority after the trust conditions have changed.
👉 Read our full editorial: Continuous authorization and zero standing privilege for APT29 risk
