April 2026: what held and what did not

The original article, published on 12 April 2026, made one central move. It replaced the old perimeter question, “Are you inside the network?”, with a different one:

Can you continuously prove that you should still be trusted right now?

Darja Rihla, Zero Trust Identity Security, 12 April 2026

Around that question it built five ideas: identity as the control plane through which access is granted, limited or denied; attackers who no longer break walls but borrow legitimacy; a shift from credential theft to trust theft; the warning that much of the real risk begins after login, in tokens and sessions; and the observation that people mistake visible friction for security strength.

The table sets the April answers next to what the evidence of 2026 supports. Each October answer opens with a verdict: held, extended or revised.

Darja Rihla interpretation The security landscape did not move away from the April article’s problem. It moved closer to it and made it wider: more kinds of actors now hold authority, and that authority lives longer than the login that created it.

The thesis: trust is temporary authority

Zero Trust is usually summarized as “never trust, always verify”. The slogan describes a posture. It does not describe what verification produces. Every successful check creates authority: a session, a token, a delegated permission. That authority then travels, often for hours, and is accepted by systems that never saw the original check.

This dossier works from a more precise statement.

Trust in modern access control is not binary. It is scoped, conditional, temporary, observable and revocable.

• Scoped. It applies to a defined resource, action and audience, not to everything.
• Conditional. It holds only while the signals that justified it still hold.
• Temporary. It expires by design, not when someone remembers to remove it.
• Observable. Its use leaves records that someone can inspect.
• Revocable. It can be withdrawn before it expires, and the systems that rely on it will notice.

The April article reached for the same idea in three short lines: “Trust is dynamic. Trust decays. Trust must be re-earned.” The five properties turn that intuition into something you can check. For any token, session or delegation you can ask whether it is scoped, conditional, temporary, observable and revocable, and expect an answer.

A second statement keeps the first one honest. Identity is a primary control plane, but it sits inside a larger system of devices, software, tokens, sessions, workloads, agents, privileges and recovery mechanisms. A perfect identity layer does not repair an unpatched server. Zero Trust is therefore one part of a wider cybersecurity system in which identity, infrastructure, policy and human behaviour constrain one another.

Darja Rihla interpretation Read this way, Zero Trust is less a login problem than an authority lifecycle problem: how authority is issued, carried, checked, narrowed and withdrawn.

The Trust Decision Engine

The April article called Zero Trust “a sequence of trust decisions” and then walked through two of them: the identity claim and the strength of authentication. The engine below completes the sequence. It follows NIST’s Zero Trust architecture, which removes implicit trust based on network location and treats authentication and authorization as “discrete functions performed before a session to an enterprise resource is established.” E03 Then it continues past the point where many diagrams stop: the moment authority leaves the decision point and starts to travel.

Most of the incidents discussed in this dossier happen in the second half of the engine: a valid token replayed somewhere else, a session that outlives the conditions that justified it, a recovery request that quietly creates new authority. The split into before and after the session is this dossier’s way of drawing the model: NIST describes the decisions, not the two phases.

Five questions for every trust object

Most Zero Trust writing is organized around users. In practice, authority is carried by objects: a device registration, an OAuth client, a refresh token, a session cookie, a recovery phone number. Each of them can be stolen, copied, over-scoped or forgotten. The Trust Object Map asks the same five questions of each one.

1. Who issued it?
2. What does it prove?
3. What can it authorize?
4. How long is it valid?
5. How can it be revoked?

Weak answers cluster in predictable places. Tokens prove less than people assume, because whoever holds a bearer token can use it. Recovery channels authorize more than people assume, because they can create new authenticators. Agents are the newest object and the hardest to answer for, because the delegation they carry is often undocumented. Each card below states the weak point first; the five answers sit underneath it.

Darja Rihla interpretation The Five Questions are a review tool, not a standard. Their value is that they force the same questions onto objects that are usually managed by different teams: identity, endpoints, application owners and the helpdesk.

Before login: what phishing resistance actually means

The April article was right that not all MFA is equal. NIST has since made the distinction formal. Its Digital Identity Guidelines, finalized on 31 July 2025, define phishing resistance as a property of the authenticator: its output is cryptographically bound to the specific verifier and to the authentication request, so it cannot be relayed to a different site. E02

The same guideline is unusually direct about the alternatives. It states that passwords are not phishing-resistant, that OTP authentication is not phishing-resistant and that out-of-band authentication, which includes the familiar push approval, is not phishing-resistant. Verifiers at authentication assurance level 2 must offer at least one phishing-resistant option, and federal agencies must require phishing-resistant authentication for their staff, contractors and partners. E02

Passkeys and other FIDO2 credentials meet this bar because of how WebAuthn scopes them: a credential can only be used with the relying party it was registered with. E04 A convincing fake login page on another domain receives nothing it can replay. The CISA and FBI advisory on the Scattered Spider group draws the practical conclusion: FIDO/WebAuthn or PKI-based MFA is “not susceptible to push bombing or SIM swap attacks.” E08

The April point about security theater survives intact. Extra prompts, repeated codes and forced resets feel strong because they are visible. A passkey can be faster and stronger at the same time. For the attacker side of this story, see Why MFA Doesn’t Stop Phishing and What Is AiTM Phishing and Why It Bypasses MFA.

Phishing resistance protects one moment: the authentication ceremony. It says nothing about what the system issues once that ceremony succeeds, and that is where the next part of the chain begins.

After login: tokens, sessions and the authority they carry

After a successful sign-in, an identity provider issues statements about the user. NIST IR 8587, published by NIST and CISA on 15 September 2026, separates identity tokens and assertions, which carry authentication and identity attributes, from access tokens, which authorize a specific resource, and refresh tokens, which extend a session without a new sign-in. E01 Applications then usually set a session cookie of their own. Each of these is a trust object with its own lifetime.

Theft: the bearer problem

Many tokens and cookies are bearer credentials: whoever presents them is treated as the subject. M-Trends 2026 describes attackers “harvesting long-lived OAuth tokens and session cookies,” and stealing keys and personal access tokens from SaaS vendors to pivot into downstream customer environments. E09 None of this requires defeating the original sign-in. The mechanics are covered in Why Session Cookies Matter More Than Your Password and Session vs Credential Theft.

Forgery: the issuer problem

Forgery is worse than theft, because the attacker mints new authority instead of copying existing authority. NIST’s announcement of IR 8587 recalls an incident in which a foreign actor “accessed agency email systems using forged tokens derived from a single stolen commercial signing key” and took more than 60,000 emails from a single agency. E01 That is why the guidance starts with key protection: for moderate-impact systems and above, signing keys must not be stored persistently on application servers, and hardware security modules or isolated key management systems are the recommended alternatives. E01

Lifetime, binding and revocation

IR 8587 recommends that access and identity tokens be valid for no more than one hour, that expired tokens be rejected, and that issuers support revocation and continuous monitoring. It names proof-of-possession, for example DPoP or mutual TLS binding, as a way to make a stolen token useless elsewhere, but presents it as a capability rather than a requirement. E01

Binding is arriving in products. Google made Device Bound Session Credentials generally available in Chrome on Windows on 28 May 2026; the feature binds a session cookie to the device the user authenticated from. E06 Microsoft Entra token protection binds sign-in session tokens to a registered device, and Microsoft describes it as one layer of defense in depth rather than a complete solution, with browser support still limited. E13

Revocation now has open standards. The OpenID Foundation approved the Shared Signals Framework, the Continuous Access Evaluation Profile (CAEP) and RISC as final specifications in September 2025. E07 Microsoft’s Continuous Access Evaluation, which is based on CAEP, reacts in near real time to events such as an account being disabled, a password reset, an administrator revoking refresh tokens or high user risk being detected. E11

Emerging, and in tension The two strategies disagree about time. NIST IR 8587 recommends token lifetimes of one hour or less. Microsoft documents that clients using Continuous Access Evaluation can receive tokens valid for up to 28 hours, because revocation is driven by events rather than by expiry. E01 E11 Short lifetimes limit the damage of a theft nobody noticed. Event-driven revocation limits the damage of a theft somebody did notice. This dossier records the disagreement rather than resolving it: both strategies depend on a signal arriving, either from the clock or from an event.

One architecture, two directions

The April article described the access chain as “identity → authentication → token issuance → session continuity → authorization” and added that “a weakness anywhere in that chain creates a usable trust artifact.” The model below reads a longer version of that chain twice: once as an attacker moves through it, once as a defender breaks it. From the attacker’s side, the rows follow the familiar sequence from initial access through persistence to an objective, expressed here as the trust objects an attacker needs at each step. Each row pairs a move with the control designed to stop it, and with the limit of that control. Zero Trust programs rarely fail for lack of a control. They fail when a control is assumed to cover more than it does.

No single row is sufficient. Phishing-resistant sign-in does nothing against a token stolen afterwards, and token binding does nothing against an attacker who talks a helpdesk into registering a new authenticator. The defense path only works as a sequence, and the last row is a reminder that some attackers never enter it. Controls are named generically here; product names elsewhere in this dossier are illustrations, not endorsements. For policy design in practice, see How Conditional Access Reduces Identity Attack Damage.

Recovery and the human system

The April article’s strongest human insight was about incentives: “Support teams are often rewarded for restoring access quickly.” Since then it has become one of the best documented attack paths there is.

The joint CISA and FBI advisory on Scattered Spider, last revised on 29 July 2025, describes actors who “posed as employees to convince IT and/or helpdesk staff to provide sensitive information, reset the employee’s password, and transfer the employee’s MFA to a device they control.” E08 M-Trends 2026 reports that highly interactive voice phishing grew to 11% of intrusions and describes groups that target IT help desks to bypass multifactor authentication. E09

In the language of the Trust Object Map, a recovery channel is the most powerful object in the system: it does not use authority, it creates it. A helpdesk reset can undo a phishing-resistant rollout in one phone call.

Darja Rihla interpretation Recovery should require evidence at least as strong as the authenticator it replaces. If a passkey protects the account, a caller who knows a date of birth and a manager’s name should not be able to replace it. That is a process design rule, and it is usually cheaper than another product.

The behavioural point from April also holds. People think in doors: logged in or logged out. The April article answered that Zero Trust works less like a door than like a negotiation. With six more months of evidence, a lease is the closer image: authority granted for a term, under conditions, that can be ended early. For the wider human picture, see Human Error in Cybersecurity.

Agents: a new population of identities

The April article listed workloads and managed identities among the things that can make an identity claim. It did not anticipate how quickly software agents would start acting on behalf of people. This is the largest addition in the dossier, and also the area with the least settled evidence.

Microsoft’s 2026 Digital Defense Report states that “as AI systems and agents enter the environment, those same controls need to extend to their identities, permissions, data, and tools,” and warns that “an AI agent with excessive permissions can create a new path to data, applications, or infrastructure.” E05

Microsoft’s security guidance from May 2026 treats agent identity as a security primitive, and the reasoning is practical rather than philosophical. When an action is taken, you need to know whether the user executed it, whether the agent acted on its own behalf or whether it acted on the user’s behalf. And “you cannot scope permissions to a specific agent if you cannot distinguish that agent from other agents or a human user.” Its conclusion: “Identity is not a feature you add later.” E14

Scale is real but hard to measure. Microsoft reports visibility into more than 500,000 agents through its own Agent 365 deployment, a figure about one large company’s internal environment, not the industry. E15 Standards are still forming. NIST’s National Cybersecurity Center of Excellence published a concept paper in February 2026 that asks how agents should be identified and authorized, how their actions can be audited and attributed, and how prompt injection can be prevented and mitigated. E12 NIST IR 8587 leaves agentic AI out of scope and notes that NIST and CISA recognize the gap. E01

Zero Trust used to ask whether this user should reach this resource. The five questions from the Trust Object Map still apply to an agent: who issued its identity, what that identity proves, what it can authorize, for how long, and how it is revoked. Delegation adds three questions that a human sign-in never had to answer.

6. On whose behalf is it acting?
7. With which tools?
8. Against which data?

Emerging Agent identity, delegation and audit are active standards work, not settled practice. Treat any claim of a complete solution with care. E12

Simulate a trust decision

The simulator turns the engine into something you can test. Change one signal at a time and watch three things: which signal moves the decision, how the sensitivity of the request shifts the threshold, and what would have to change for a different answer. Every rule the model uses is printed underneath. The numbers are illustrative; the shape of the reasoning is the point.

What I would write differently now

This section is written in the first person because it concerns my own method, not the threat landscape. Each change can be checked against the April text, which stays online unchanged.

• I would not write “What remains is identity.” It was a rhetorical simplification, and the 2026 incident data contradicts it. I would write that identity is the layer where many compromises become durable authority.
• I would finish the sequence I announced. April promised “a sequence of trust decisions” and described two of them. The engine in this dossier is that sequence, carried past the login into issuance, evaluation and revocation.
• I would link every institutional claim. April said what Microsoft and CISA “emphasize” without linking a document. Here every external claim points to a ledger entry, and the ledger also records which sources I did not reread.
• I would say how I could be wrong. April had no failure condition. This dossier states one in the previous section, and the research record at the end names the reports that will test it.

Key takeaways

1. The April article’s core survives: attackers prefer borrowed legitimacy, and much of the risk begins after login.
2. Phishing resistance is now a defined property. Passwords, codes and push approvals do not have it; origin-bound cryptographic authenticators do.
3. Tokens and sessions are authority in transit. Protect the keys that sign them, keep them short-lived or bound, and make revocation reach every system that relies on them.
4. Recovery channels create authority. Hold them to the same standard as the authenticators they replace.
5. AI agents are a new class of identity. Ask them the same five questions as any other trust object, plus three more: for whom they act, with which tools, against which data.
6. Identity is a primary control plane, not the whole system. In 2026 data, exploited software is the most common way in.

The April 2026 original stays online, unchanged, as the record this dossier revisits: Zero Trust Identity Security: The Modern Defense Framework for Access Control.

Evidence ledger and research record

Each entry records what a source actually supports, which is often narrower than the claim it is used for. All sources were consulted on 6 October 2026. Primary sources are preferred; one entry relies on specialist journalism and says so.

1. E01 Tokens and assertions need lifecycle protection: signing keys, verification, lifetime, revocation and monitoring.

   Source

   NIST IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse, NIST and CISA, with the NIST announcement

   Date

   15 September 2026

   Evidence type

   Government guidance

   What it supports

   Key protection, token verification, a validity of one hour or less for access and identity tokens, revocation and logging. Names DPoP and mutual TLS binding as proof-of-possession options. Places agentic AI out of scope. The announcement describes the forged-token incident and the 60,000 emails.

   Limits

   Written for US federal agencies and cloud providers. Conformance is voluntary unless set by policy.

2. E02 Passwords, one-time codes and out-of-band approvals are not phishing-resistant; AAL2 must offer a phishing-resistant option.

   Source

   NIST SP 800-63B-4, Authentication and Authenticator Management, part of the Digital Identity Guidelines

   Date

   31 July 2025

   Evidence type

   Federal standard

   What it supports

   The definition of phishing resistance, the AAL2 requirement to offer a phishing-resistant option, the requirement for federal staff, contractors and partners, and the statements that passwords, OTPs and out-of-band methods are not phishing-resistant.

   Limits

   Normative for US federal systems. Elsewhere it is a reference, not a rule.

3. E03 Zero Trust removes implicit trust based on network location, and authentication and authorization happen before a session.

   Source

   NIST SP 800-207, Zero Trust Architecture

   Date

   August 2020

   Evidence type

   Federal architecture guideline

   What it supports

   The core definitions used in the Trust Decision Engine, including the quoted sentence on authentication and authorization as discrete functions.

   Limits

   Predates current work on token binding and agent identity.

4. E04 Passkeys and FIDO2 credentials can only be used with the relying party they were registered with.

   Source

   W3C, Web Authentication: An API for accessing Public Key Credentials, Level 2

   Date

   8 April 2021

   Evidence type

   W3C Recommendation

   What it supports

   Relying party scoping of credentials, the mechanism behind phishing resistance in the browser.

   Limits

   Protects the authentication ceremony, not the tokens issued after it.

5. E05 Threat actors follow trust; agent controls must extend to identities, permissions, data and tools; exploitation is fast.

   Source

   Microsoft, 2026 Digital Defense Report

   Date

   1 October 2026

   Evidence type

   Vendor threat intelligence

   What it supports

   The quoted sentences on trust, agents and excessive permissions; nearly 40,000 CVEs in the first half of 2026; weaponization well below 24 hours; remediation of 30 to 60 days; user execution at 30% and valid accounts at 20% of observed initial access.

   Limits

   Microsoft telemetry and incident response view. This dossier used the report’s web page, not the full PDF.

6. E06 Device Bound Session Credentials are generally available in Chrome on Windows.

   Source

   Google Workspace Updates, DBSC now generally available in Chrome for Windows

   Date

   28 May 2026

   Evidence type

   Vendor product announcement

   What it supports

   That DBSC binds a session cookie to the device the user authenticated from, and is enabled for Google accounts in Chrome on Windows.

   Limits

   Covers Google accounts on one platform. It is not a statement about other sites or browsers.

7. E07 Shared Signals, CAEP and RISC were approved as final OpenID specifications.

   Source

   Help Net Security, OpenID Foundation sets new standards for real-time security event sharing

   Date

   22 September 2025

   Evidence type

   Specialist journalism

   What it supports

   The approval of three final specifications, and that CAEP defines how systems communicate session changes.

   Limits

   Secondary source. The specification texts at openid.net were not reread for this version.

8. E08 Attackers impersonate employees to helpdesks to reset passwords and move MFA; FIDO/WebAuthn resists push bombing and SIM swaps.

   Source

   CISA and FBI, Cybersecurity Advisory AA23-320A, Scattered Spider

   Date

   29 July 2025 (revision of 16 November 2023)

   Evidence type

   Government advisory

   What it supports

   The quoted helpdesk tactic, SIM swapping, MFA fatigue, and the recommendation of FIDO/WebAuthn or PKI-based MFA.

   Limits

   Describes one actor group.

9. E09 Exploits lead initial access, voice phishing is second, and attackers harvest OAuth tokens and session cookies.

   Source

   Mandiant, M-Trends 2026

   Date

   23 March 2026

   Evidence type

   Incident response report

   What it supports

   Exploits at 32% for a sixth year, voice phishing at 11%, harvesting of long-lived OAuth tokens and session cookies, and help desks targeted to bypass MFA.

   Limits

   Based on Mandiant investigations, which lean toward serious intrusions.

10. E10 Software vulnerabilities overtook stolen passwords as the top way into breaches.

    Source

    Verizon, 2026 Data Breach Investigations Report

    Date

    2026 edition

    Evidence type

    Breach dataset report

    What it supports

    The quoted 31% figure for breaches that start with software vulnerabilities.

    Limits

    Taken from the report’s web page. The full report was not reread for this version.

11. E11 Continuous Access Evaluation revokes on critical events, allows longer-lived tokens and can take minutes to propagate.

    Source

    Microsoft Learn, Continuous access evaluation

    Date

    Living documentation, read on 6 October 2026

    Evidence type

    Vendor documentation

    What it supports

    That CAE is based on CAEP, the list of critical events, tokens of up to 28 hours for CAE-capable clients, and propagation delays of up to 15 minutes.

    Limits

    Describes one vendor’s implementation. The page can change without notice.

12. E12 Identity, authorization and audit for AI agents are open standards questions.

    Source

    NIST NCCoE, Accelerating the Adoption of Software and AI Agent Identity and Authorization (concept paper)

    Date

    5 February 2026

    Evidence type

    Concept paper for public comment

    What it supports

    That NIST asks how agents should be identified and authorized, how their actions can be audited, and how prompt injection can be mitigated.

    Limits

    It asks questions. It does not yet answer them.

13. E13 Token protection binds sign-in session tokens to a registered device, and is not a complete solution.

    Source

    Microsoft Learn, Token protection in Conditional Access

    Date

    Living documentation, read on 6 October 2026

    Evidence type

    Vendor documentation

    What it supports

    Device binding of sign-in session tokens, limited browser support, and Microsoft’s own statement that it belongs inside a defense-in-depth strategy.

    Limits

    Platform coverage changes often. Check the page before relying on a specific scenario.

14. E14 Agents need their own identities to make least privilege, revocation and audit possible.

    Source

    Microsoft Security Blog, Defense in depth for autonomous AI agents

    Date

    14 May 2026

    Evidence type

    Vendor engineering guidance

    What it supports

    The quoted reasoning on distinguishing user, agent and on-behalf-of actions, and the sentence “Identity is not a feature you add later.”

    Limits

    One vendor’s design position.

15. E15 One large organization already inventories more than 500,000 agents.

    Source

    Microsoft Inside Track, Implementing Agent 365

    Date

    6 August 2026

    Evidence type

    Vendor case study

    What it supports

    Visibility into more than 500,000 agents inside Microsoft, and registration that gives each agent a formal identity.

    Limits

    A self-report about one company. Not an industry figure.