Living Dossier 01Cybersecurity & TechIdentity & Access
After Login: Zero Trust, Tokens and Revocable Trust in 2026
A public revisit of Zero Trust Identity Security: The Modern Defense Framework for Access Control, six months after it was written.
In April 2026 this site argued that identity had become the control plane of modern security. Six months of new guidance and incident data say the core holds: attackers still exploit trusted access, and much of the risk begins after login. Two things need correcting. Identity is not the only way in: in two of the largest 2026 incident datasets, the most common entry point is an exploited software flaw, not a stolen login. And the April piece paid too little attention to how long trust lives once it has been granted.
The claim this dossier tests: trust is not a state you reach at login. It is authority that must stay scoped, conditional, temporary, observable and revocable.
- Original observation Published as an explanatory essay. Kept online, unchanged, as a record.
- Revisited Rebuilt as an evidence-backed dossier with an inspectable model.
- Next review When a trigger fires Triggers are listed in the research record at the end.
How to read this dossier
- E01 A sourced statement. The number points to the evidence ledger at the end, which records what each source supports and where it stops.
- Emerging Technology, guidance or practice that is still forming.
- Darja Rihla interpretation Our own synthesis. Read it as an argument, not as a finding.
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.
| Question | April 2026 article | October 2026 dossier |
|---|---|---|
| Why do attackers target identity? | “The attacker is not breaking the wall. They are borrowing legitimacy.” | Held. Microsoft’s 2026 report sums up what its responders see in three words: “threat actors follow trust.” E05 |
| Where is the boundary? | “The perimeter has dissolved. What remains is identity.” | Revised. Identity is a primary control plane, not the only one. In 2026 incident data, exploited software is the most common way in. E09 E10 |
| What makes authentication strong? | Phishing-resistant MFA as “the modern baseline for privileged access”, and a warning that visible friction is not strength. | Held, and now defined. NIST states that passwords, one-time codes and out-of-band approvals are not phishing-resistant, however much effort they add. E02 |
| What happens after login? | Tokens and session cookies “become the new trust objects.” | Held, and extended. Attackers harvest “long-lived OAuth tokens and session cookies.” E09 Tokens now have NIST and CISA guidance on signing keys, lifetime, binding and revocation. E01 |
| How does a session stay honest? | Continuous Access Evaluation is “strategically important.” | Extended. Sessions are being bound to devices, and revocation signals now have open standards. E06 E07 E11 E13 |
| Where does the human system give way? | “Support teams are often rewarded for restoring access quickly.” | Held. Voice phishing reached 11% of intrusions in M-Trends 2026, and help desks are a named target. E08 E09 |
| Who holds authority? | “A user, administrator, service account, or workload.” | Revised. AI agents now act with delegated authority, and how to identify them is an open standards question. E12 E14 |
| How is the argument built? | An explanatory essay without external sources. | Revised. Confidence labels, an evidence ledger, a thesis that states how it could fail, and a model you can test. |
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.
Before the session Decide whether authority should exist
- Identity claimWho or what says it is acting?
- AuthenticationWhat evidence backs the claim, and can it be phished?
- Device or workload assuranceIs the endpoint or runtime known and healthy?
- Context signalsLocation, time, behaviour and threat intelligence.
- Policy decisionGiven all of the above, what is allowed?
- AuthorizationWhich resource, which action, which scope?
After the session starts Govern the authority that now exists
- Token and session issuanceAuthority leaves the decision point and starts to travel.
- Continuous evaluationDo new signals change the answer?
- OutcomeEach evaluation ends in one of four results.
Stages 08 and 09 repeat for as long as the session lives.
- AllowThe authority still fits the signals. Continue.
- ChallengeAsk for stronger evidence before going on.
- RestrictKeep access, but narrow its scope.
- DenyRefuse. In a live session, revoke the session and its tokens.
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.
- Who issued it?
- What does it prove?
- What can it authorize?
- How long is it valid?
- 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.
Sign-in chain
- Recovery channelcan recreate
- Human identitysigns in on
- Devicereceives
- Tokenopens
- Session
Delegation chain
- Human identitydelegates to
- AI agentcalls
- Applicationruns on
- Workload
Anchor
Human identity
Proves that someone was enrolled, not that the same person is present now.
Five answers: human identity
- Who issued it?
- The identity provider, at enrollment, ideally after identity proofing.
- What does it prove?
- That a person was enrolled once. Not that the same person is present now.
- What can it authorize?
- Nothing directly. Every other object traces back to it.
- How long is it valid?
- Until deprovisioning, which often lags behind the end of a job.
- How can it be revoked?
- Disable the account, then revoke the sessions and tokens it produced.
Context
Device
Raises confidence in other decisions, but rarely grants access on its own.
Five answers: device
- Who issued it?
- Device registration or management enrollment.
- What does it prove?
- A known endpoint in a known state, strongest when its keys are hardware-backed.
- What can it authorize?
- It raises assurance for other decisions. It rarely grants access on its own.
- How long is it valid?
- Until it is unregistered, retired or falls out of compliance.
- How can it be revoked?
- Remove the registration or mark the device non-compliant.
Authority in transit
Token
Works for whoever holds it, unless it is bound to a device or key.
Five answers: token
- Who issued it?
- An identity provider or authorization server, after authentication.
- What does it prove?
- That an issuer signed a statement about a subject, for an audience.
- What can it authorize?
- Whatever its scopes allow, for whoever presents it, unless it is bound.
- How long is it valid?
- NIST IR 8587: one hour or less for access and identity tokens. Refresh tokens live longer. E01
- How can it be revoked?
- Revocation and continuous evaluation events. Key rotation if forgery is suspected.
Continuing authority
Session
Proves that a sign-in succeeded at some earlier moment, often days ago.
Five answers: session
- Who issued it?
- The application, usually as a cookie, after accepting a token.
- What does it prove?
- That a sign-in succeeded at some earlier moment.
- What can it authorize?
- Continued use without signing in again.
- How long is it valid?
- Set by each application. Often days.
- How can it be revoked?
- Server-side invalidation. Binding it to a device makes stolen copies far less useful.
Registered client
Application
Holds the permissions it was granted, which are often broader than its use.
Five answers: application
- Who issued it?
- An administrator or developer who registered it, plus user or admin consent.
- What does it prove?
- That a client was registered. Not that its code or publisher is trustworthy.
- What can it authorize?
- The permissions it was granted, often broader than its actual use.
- How long is it valid?
- Until consent is withdrawn. Client secrets until they expire.
- How can it be revoked?
- Remove consent, rotate or delete secrets, disable the registration.
Service identity
Workload
Short-lived when the platform issues it. Indefinite when it is a static secret nobody rotates.
Five answers: workload
- Who issued it?
- The hosting platform, ideally as a short-lived credential tied to the runtime.
- What does it prove?
- Which service is running, and where.
- What can it authorize?
- Service-to-service calls within its role.
- How long is it valid?
- Minutes to hours when issued by the platform. Indefinitely for static secrets nobody rotates.
- How can it be revoked?
- Platform policy, credential rotation, removal of the role.
Delegated authority Emerging
AI agent
Acts on delegated authority that is often undocumented. Practice still varies.
Five answers: AI agent
- Who issued it?
- An agent registry or identity provider. Practice still varies.
- What does it prove?
- Which agent acted, and whether it acted for itself or for a person.
- What can it authorize?
- Its delegated scopes and the tools it is allowed to call.
- How long is it valid?
- Ideally one task or session. Often undocumented today.
- How can it be revoked?
- Disable the agent identity, withdraw the delegation, remove tool access.
Authority factory
Recovery channel
Can create new authenticators, often from weak evidence.
Five answers: recovery channel
- Who issued it?
- Backup method enrollment and helpdesk procedures.
- What does it prove?
- Often little: a phone number, personal data, a convincing voice.
- What can it authorize?
- The creation of new authenticators, and therefore new authority.
- How long is it valid?
- Indefinitely, unless someone reviews it.
- How can it be revoked?
- Redesign the process. Demand evidence as strong as the authenticator being replaced.
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.
-
Entry
Attack
Relay the sign-in through a lookalike page, an adversary in the middle.
Defense
Phishing-resistant authentication bound to the real origin.
Limit Does nothing against a token stolen after sign-in, or malware on the signed-in device.
-
Second factor
Attack
Push fatigue, a SIM swap or a helpdesk MFA reset.
Defense
No phishable fallback. Recovery as strong as the factor it replaces, with call-back verification.
Limit Does nothing against insider collusion, or pressure that bypasses the process.
-
Token
Attack
Copy the session cookie or refresh token after sign-in.
Defense
Device-bound sessions, sender-constrained tokens and signing keys held in hardware.
Limit Does nothing against abuse of a live session from the bound device itself.
-
Replay
Attack
Present the stolen token from attacker infrastructure.
Defense
Continuous evaluation: a new device or location triggers a challenge or revocation.
Limit Works only if the event fires, and revocation can take minutes to propagate. E11
-
Privilege
Attack
Use standing admin rights or an over-consented application.
Defense
Least privilege, just-in-time elevation and consent review.
Limit Does not shrink broad roles granted before the policy existed.
-
Persistence
Attack
Register a new MFA method, app or agent to keep access.
Defense
Alert on new authenticators, apps and agents. One identity per workload and agent, each with a named owner.
Limit Does nothing against prompt injection or unsafe tool use inside permissions that were correctly granted.
-
Objective
Attack
Export mail, files or customer records in bulk.
Defense
Data-level limits and alerts on unusual export.
Limit An alert detects an export. It does not undo one.
-
Outside the chain
Attack
Skip the chain: exploit an unpatched, internet-facing system.
Defense
Patch exposed systems quickly and keep an inventory of them.
Limit No identity control sees this path. For how often it happens, see Where this thesis could be wrong.
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.
- On whose behalf is it acting?
- With which tools?
- 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.
The live calculation needs JavaScript. Below is the worked example for the default selection, and every rule the model uses is printed after it.
Trust decision
Challenge
Why
- Phishable MFA+2A code or push approval can be relayed through a lookalike page.
No added risk from: Human user, Managed and compliant, Nothing unusual.
2 risk points. High sensitivity tolerates no risk signal: 0 points is allowed, 1 to 3 is challenged, 4 to 5 is restricted, 6 or more is denied.
No hard rule or floor changed the result.
What happens
Ask for stronger evidence before going on.
What would change the decision
- Step up to a phishing-resistant method, such as a passkey.
Educational model. Real Zero Trust decisions require organization-specific policy, telemetry and risk context.
How the model decides
Step 1. Hard rules
- A revocation signal denies the request, whatever the points.
- High sensitivity with a single secret is denied.
Step 2. Risk points
- Authentication: phishing-resistant 0, phishable MFA 2, single secret 3.
- Device or runtime: compliant 0, not compliant 1, unknown 2.
- Session: nothing unusual 0, anomaly 2.
- Actor: AI agent 1, because one more party stands between the person and the action.
Step 3. Thresholds and a floor
- Low: 0 to 4 allow, 5 to 6 challenge, 7 or more restrict.
- Moderate: 0 to 2 allow, 3 to 4 challenge, 5 to 6 restrict, 7 or more deny.
- High: 0 allow, 1 to 3 challenge, 4 to 5 restrict, 6 or more deny. Any risk signal at all, including an AI agent, means at least a challenge.
- Floor: high sensitivity from an unknown device is at least restricted.
- Allow
- Proceed within the granted scope, and keep evaluating while the session lives.
- Challenge
- Ask for stronger evidence before going on.
- Restrict
- Allow a narrower version: read-only, no download or export, a shorter session, fewer tools.
- Deny
- Refuse the request. In a live session, end it and revoke its tokens.
Where this thesis could be wrong
A thesis that cannot be wrong is not useful. The claim under test is that trust and authority lifecycle management are becoming central to modern access security. Here is the evidence that would weaken it, and some of that evidence already exists.
Exploitation is the most common way in
The Verizon 2026 Data Breach Investigations Report states that “31% of breaches now start with software vulnerabilities, beating stolen passwords as the top way attackers get in.” E10 M-Trends 2026 reports that exploits were the most common initial infection vector for the sixth consecutive year, at 32% of intrusions. E09 Microsoft counts nearly 40,000 CVEs published in the first half of 2026, a median time from discovery to weaponization of well below 24 hours, and enterprise remediation of critical external vulnerabilities that can take 30 to 60 days. E05 An attacker who exploits an unauthenticated flaw never meets the trust decision engine at all.
The device can sit beneath the session
Binding a session to a device protects against theft from somewhere else. It does not stop malware that runs on the same device and acts inside a legitimate, bound session. If endpoint compromise becomes the dominant path, identity controls shift from prevention to damage limitation.
Complexity has a cost
Continuous evaluation adds moving parts: signal producers, receivers, policies and exceptions. Microsoft documents that propagation of revocation events can take up to 15 minutes. E11 Misconfigured policies can block legitimate work or silently allow what they were meant to stop. Where operational complexity grows faster than the security benefit, simpler controls such as patching and least privilege may deliver more.
Agent risk may be mostly software risk
The NCCoE concept paper treats prompt injection as its own control question, next to identity and authorization. E12 If most agent incidents turn out to be prompt injection inside correctly scoped permissions, agent identity will matter more for accountability than for prevention.
What survives the test
The same sources also cut the other way. In Microsoft’s 2026 report, Defender Experts data attributes 30% of observed initial access to user execution and another 20% to valid accounts, and the report argues that the rise of AI should not pull attention away from identity, data protection, software security, exposure management or Zero Trust. E05 The defensible conclusion is narrower than the April article: identity is not everything. It is the layer where many other compromises are converted into durable authority, and where that authority can still be limited, observed and withdrawn.
Darja Rihla interpretation What would change this dossier’s conclusion: two consecutive years of incident data in which valid accounts and token abuse fall sharply as a share of initial access and post-compromise activity, while exploitation keeps rising.
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
- The April article’s core survives: attackers prefer borrowed legitimacy, and much of the risk begins after login.
- Phishing resistance is now a defined property. Passwords, codes and push approvals do not have it; origin-bound cryptographic authenticators do.
- 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.
- Recovery channels create authority. Hold them to the same standard as the authenticators they replace.
- 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.
- 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.
-
E01 Tokens and assertions need lifecycle protection: signing keys, verification, lifetime, revocation and monitoring.
-
E02 Passwords, one-time codes and out-of-band approvals are not phishing-resistant; AAL2 must offer a phishing-resistant option.
-
E03 Zero Trust removes implicit trust based on network location, and authentication and authorization happen before a session.
-
E04 Passkeys and FIDO2 credentials can only be used with the relying party they were registered with.
-
E05 Threat actors follow trust; agent controls must extend to identities, permissions, data and tools; exploitation is fast.
-
E06 Device Bound Session Credentials are generally available in Chrome on Windows.
-
E07 Shared Signals, CAEP and RISC were approved as final OpenID specifications.
-
E08 Attackers impersonate employees to helpdesks to reset passwords and move MFA; FIDO/WebAuthn resists push bombing and SIM swaps.
-
E09 Exploits lead initial access, voice phishing is second, and attackers harvest OAuth tokens and session cookies.
-
E10 Software vulnerabilities overtook stolen passwords as the top way into breaches.
-
E11 Continuous Access Evaluation revokes on critical events, allows longer-lived tokens and can take minutes to propagate.
-
E12 Identity, authorization and audit for AI agents are open standards questions.
-
E13 Token protection binds sign-in session tokens to a registered device, and is not a complete solution.
-
E14 Agents need their own identities to make least privilege, revocation and audit possible.
-
E15 One large organization already inventories more than 500,000 agents.
Darja Rihla research record
- Dossier
- Living Dossier 01: Zero Trust after login
- Original observation
- , Zero Trust Identity Security: The Modern Defense Framework for Access Control
- Revisited
- Version
- 1.0, first dossier edition
- Sources reviewed
- 15 ledger entries: NIST, CISA and FBI, W3C, Microsoft, Google, Mandiant and Verizon primary sources, plus one specialist news report.
- Method
- Drafted with AI assistance inside a controlled workflow. External claims checked against the cited sources on the date above, and April quotations against the published original. Interpretation labelled separately. Human editorial review before publication.
- Next review triggers
- NIST or NCCoE guidance on agent identity and authorization; a revision of NIST SP 800-207; device-bound sessions in more browsers; the 2027 editions of DBIR and M-Trends.
