> ## Content Index > Fetch the complete content index at: https://insights.securesalt.com/llms.txt > Use this file to discover other available public pages before exploring further. # Session authority and recipient assurance: research notes - URL: https://insights.securesalt.com/research/session-authority-and-recipient-assurance-research-notes/ - Published: 2026-10-25T04:43:58.000Z - Updated: 2026-10-27T17:28:36.000Z - Description: Strong authentication. What does it establish for the recipient? - Author: Chris Econn - Tags: #needs-refinement, Research notes & evidence An authenticated session, a verified person, and authority to make a request answer different questions. Our probe examined what an existing Microsoft browser session could satisfy without another interaction with the user's phone. This matters because the person receiving a message has to decide what to do with it. A familiar account and a successful sign-in can look reassuring. Neither, on its own, establishes who approved the request or whether they have authority to make it. The recipient needs a say in what evidence is required. The system then needs to establish that the requirement was actually met—not leave the recipient to infer it from an address, a login, or a badge. That is the recipient-advocacy argument we introduced in [The Fox Guarding the Henhouse](https://insights.securesalt.com/articles/the-fox-guarding-the-henhouse/). This research examines one part of it: when does an existing session suffice, and when does the configured requirement demand independent proof again? The recovered session record contains two distinct results. An earlier run completed through session reuse. After correcting the probe to request an access token for the intended API resource, a later attempt required the passkey again. Combining those results into a single claim about a bypass would misrepresent the experiment. ## What we ran The probe was a local Go program with an OAuth callback at 127.0.0.1:8765\. It validated signed token evidence and recorded observations. It did not authorize Salt Mail enrollment or test message delivery.The test used a dedicated enrollment-probe client and a separate probe API, with the enrollment.probe scope and a requested Conditional Access authentication context, c1. The recovered material is a saved conversation record of commands, reported prompts, and interpretations. It is not a recovered raw HTTP request/response log. ## The earlier session-reuse result In an earlier run, the existing browser session completed the probe without a new phone approval. The probe reported validated identity-token evidence containing c1. That was an observation of browser-session reuse. It did not establish that the intended API resource's Conditional Access policy had been evaluated, or that an Every time requirement had failed. The original session includes a correction to that interpretation. Receiving c1 in an ID token was not enough to demonstrate enforcement of the intended API policy. This distinction is part of the finding, not a detail to omit. ## The corrected API-targeted resultThe probe was then changed to request an access token for the intended probe API. The recorded positive baseline validated the intended audience, enrollment.probe scope, fido and mfa methods, and c1 context. The user confirmed completing the phone's passkey authentication. Earlier run Existing session Probe request Completed Session reuse is normal. No new phone interaction was needed. This run did not establish enforcement of the intended API policy. Corrected API-targeted run Existing session Intended API request Passkey required again The existing session alone did not complete the corrected request. The requirement matters. So does proving it was enforced. The recipient needs a stated assurance requirement and evidence that it was met. A successful sign-in alone does not establish approval of a particular request or authority to make it. Provider test results from the recovered session record. Not a demonstrated Salt Mail prevention result. The user also reported a successful evaluation of the probe’s c1 passkey policy in the corresponding sign-in record. An initial Not Applied report was corrected after the policy result appeared. Next, the same browser session was tested again after the planned wait of more than five minutes, with instructions to leave the phone untouched. The saved exchange records that the request stopped for authentication and offered a security-key or passkey prompt. The session alone did not complete that corrected request. This supports the narrower conclusion that the configured provider requirement demanded an allowed passkey again on that tested path. It does not establish resistance to every kind of stolen token or session reuse. ## What the retained logs add The separate Entra archive preserves four original exports: 94 interactive records, 1,807 non-interactive records, 19 application records, and an empty managed-identity export. It includes sorted timelines and a file-hash manifest. There are 22 probe-application records, spanning September 20, 2026, from 05:04:20 to 08:15:01 UTC. The wider probe-user timeline contains 287 records across applications. These are provider-event counts, not counts of attacks or messages. The exports provide authentication and policy context. Individual events still need to be correlated with the distinct runs before assigning exact timestamps to their results. A later provider reauthentication rejection is not a Salt Mail block. ## What remains separate The Revolut reporting concerns fraudulent requests received through a legitimate government email domain. This probe does not reconstruct that incident or establish how the account involved was accessed. It also does not demonstrate theft of a Microsoft token. It tested an existing browser session, first with an inadequately established policy context and then against the corrected API resource. Initial factor enrollment, replacement and recovery, and reuse within an allowed freshness window are separate questions. The corrected result does not settle them.A running-Salt Mail comparison remains outstanding in the reviewed record. To support a Salt Mail control claim, the test must demonstrate the recipient's requirement being enforced, an unsatisfied request remaining held, and legitimate completion releasing the intended message exactly once. ## Why this matters The corrected test shows why provider controls deserve careful evaluation, not dismissal. It also shows why a successful login or a claim appearing in a token cannot stand in for evidence that the intended requirement was enforced. Recipient advocacy needs that precision. The recipient should be able to rely on a clearly stated requirement and an understandable result, without being asked to investigate how the system reached it. ## Download the evidence The recovered probe transcript and supporting authentication records are available together. The bundle includes the corrected interpretation, our method, 22 redacted probe-application records, and file hashes. These materials document the tested authentication boundary. The transcript contains recorded probe results and operator observations; it is not a complete raw HTTP request/response capture. Original logs and private correspondence are not included. [Probe transcript and supporting authentication logsRedacted research bundle • transcript excerpts, 22 authentication records, method and integrity hashessalt-probe-transcript-and-authentication-evidence.zip8 KBdownload-circle](https://insights.securesalt.com/content/files/2026/10/salt-probe-transcript-and-authentication-evidence.zip "Download")