| Internet-Draft | PSEA | February 2026 |
| Yossif | Expires 11 August 2026 | [Page] |
Modern security architectures assume that trust established at login can safely extend to all subsequent actions within a session. This assumption is fundamentally flawed. Sessions preserve the memory of authentication but not the certainty of authority. Post-Session Execution Assurance (PSEA) is an architectural security model that addresses this gap by requiring cryptographic proof of real human presence, device trust, and execution authority at the exact moment a sensitive action is approved — independent of prior authentication or session state. This paper defines the PSEA model, its core principles, its distinction from existing security paradigms, and its implications for regulated and mission-critical systems.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 11 August 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
For decades, session-based security has operated on a single foundational assumption: that a successful authentication event at login time can be trusted to represent the user's identity and authority for the duration of the session. This assumption was reasonable when systems were simple, sessions were short, and interactions were linear. This document is published as an Informational Internet-Draft and does not define a standard.¶
It is no longer reasonable.¶
Modern systems operate in environments where actions occur long after the initial authentication event. Context drifts continuously — devices change hands, network environments shift, and authorization states evolve. Sessions persist across these changes without re-evaluating whether the conditions that justified the original trust decision still hold.¶
The problem is structural. Sessions are designed to reduce friction by avoiding repeated authentication. In doing so, they create an implicit trust window during which any actor — human or automated — operating within that session inherits the authority of the original authenticator. This inheritance is unconditional. It does not account for elapsed time, changes in device posture, delegation of access, or environmental degradation.¶
In practice, this means that a session authenticated by a legitimate user at 9:00 AM carries identical authority at 3:00 PM, even if the device has been compromised, the user has stepped away, or an automated process has assumed control of the session. The session does not know. It was not designed to know.¶
This is not a vulnerability in any particular implementation. It is a structural flaw in the session model itself.¶
Post-Session Execution Assurance (PSEA) is an architectural security model that requires cryptographic proof of real human presence, device trust, and execution authority at the exact moment a sensitive action is approved — independent of prior authentication or session state.¶
This definition establishes PSEA as a model concerned exclusively with the moment of execution. It does not replace authentication, session management, or access control. It addresses the specific problem of verifying authority when an action is approved — a problem that existing models leave unresolved.¶
The term "post-session" does not imply that sessions are absent. It means that the assurance provided by PSEA operates independently of session state. Whether a session is active, expired, or absent, the execution assurance requirement remains the same: cryptographic proof of human presence, device trust, and authority at the moment of action.¶
The PSEA model is built on five core principles. Each addresses a specific dimension of the authority gap.¶
Authority must be validated at the moment an action is executed, not at any prior point. A proof generated at login time, or at any time before the action, does not satisfy this requirement. The temporal binding between proof and action is non-negotiable.¶
The model requires verification that a real human being is present and actively approving the action. This is distinct from identity recall, where a system infers human presence from a prior authentication event. Presence must be demonstrated, not assumed.¶
Execution approval must be bound to a specific, trusted device state. The device from which the approval originates must be verified as part of the assurance chain. An approval that cannot be tied to a known, trusted device does not meet the PSEA requirement.¶
Trust is established through cryptographic mechanisms, not inferred from session tokens, cookies, or bearer credentials. The proof must be independently verifiable and resistant to replay, forgery, and delegation.¶
PSEA is designed to function in environments with intermittent, degraded, or absent network connectivity. The model does not depend on real-time communication with a central authority for the generation of execution proof. Verification may be deferred, but the proof itself must be generated at execution time regardless of connectivity state.¶
Clarity about the boundaries of PSEA is essential to prevent conflation with existing security paradigms.¶
PSEA is not Multi-Factor Authentication. MFA strengthens the login boundary by requiring multiple credential types. It does not address authority at execution time. Once MFA is completed, the resulting session carries the same inherited trust as any other session.¶
PSEA is not Continuous Authentication. Continuous authentication monitors behavioral or biometric signals throughout a session to detect anomalies. It is a monitoring and risk-scoring mechanism. It does not require proof of authority at the moment of a specific action.¶
PSEA is not Session Hardening. Session hardening techniques — short timeouts, token rotation, binding to IP addresses — reduce the window of exposure. They do not verify who is executing an action within that window.¶
PSEA is not Risk-Based Authentication. Risk-based systems evaluate contextual signals to adjust authentication requirements dynamically. They operate at or near the login boundary. They do not provide execution-time proof.¶
PSEA is not a rebranding of Zero Trust. Zero Trust architectures reduce implicit trust between system components and enforce verification at network and application boundaries. PSEA addresses a different problem: the absence of verified authority at the point of action execution, which persists even within Zero Trust environments.¶
Each of these paradigms addresses a legitimate security concern. None of them solve the specific problem that PSEA defines: the absence of cryptographic, human-verified, device-bound proof of authority at execution time.¶
The authority gap has acute consequences in regulated and mission-critical environments where the cost of unauthorized execution is severe.¶
Financial systems process high-value transactions within authenticated sessions. Fraud, insider misuse, and session compromise result in unauthorized transactions that are technically valid from the session's perspective. Regulatory frameworks increasingly require proof that specific individuals authorized specific transactions. PSEA provides the architectural basis for such proof.¶
Government systems handle classified operations, policy decisions, and infrastructure controls. Delegation of authority, shared workstations, and long-duration sessions create conditions where session-based trust is insufficient. PSEA addresses the requirement for verifiable human authority over specific actions in these environments.¶
Healthcare systems authorize prescriptions, access to patient records, and clinical decisions. Shared terminals, shift-based workflows, and emergency access create scenarios where the authenticated user may not be the person executing the action. PSEA provides a mechanism for binding execution authority to a verified human at the point of action.¶
Industrial control systems, energy grids, and transportation networks require human authorization for sensitive operational changes. These environments frequently operate in degraded connectivity conditions. PSEA's connectivity-independent design addresses the need for execution-time authority verification even when centralized systems are unreachable.¶
PSEA is an architectural model, not a product specification. It defines what must be proven at execution time without prescribing how the proof is generated, transmitted, or verified.¶
Implementations of PSEA may vary in their choice of biometric modalities, cryptographic schemes, device attestation mechanisms, and verification architectures. The model is intentionally agnostic to these choices, provided the core principles are satisfied.¶
Yuthent is one implementation of the PSEA model, designed for regulated and mission-critical environments. It is not the only possible implementation. The PSEA model exists independently of any specific product or vendor.¶
Organizations adopting PSEA may implement it through existing infrastructure, custom development, or third-party solutions. The requirement is adherence to the model's principles, not adoption of a specific technology.¶
The security architecture of modern systems contains a structural gap between authentication and execution. Sessions bridge this gap with inherited trust — a mechanism that was adequate for simpler systems but is fundamentally insufficient for environments where authority must be verified at the moment of action.¶
Post-Session Execution Assurance defines the requirement that this gap be closed. It is not a feature, not a product category, and not a rebranding of existing security paradigms. It is an architectural correction: a formal recognition that authority is temporal, context-dependent, and must be proven — not assumed — at the moment it is exercised.¶
The absence of execution-time authority verification is not a theoretical concern. It is the operational reality that enables fraud, insider misuse, and unauthorized actions across banking, healthcare, government, and critical infrastructure. PSEA provides the conceptual and architectural foundation for addressing this reality.¶
To reference this document, use the following citation:¶
Khalil Yossif, M. (2026). Post-Session Execution Assurance (PSEA): A Security Model for Verifying Authority at the Moment of Action (Version 1.0). Yuthent. https://yuthent.com/psea¶
Canonical URL: https://yuthent.com/psea¶
GitHub: https://github.com/yuthent/psea-spec¶