Show Me What Authorized the Action
Issue 029 | Friday Brief | November 6, 2026
Weekly field intelligence for enterprise and mobile security leaders
When Binance reported an incident affecting billions of dollars in assets, the question I wanted answered was what the system checked before it permitted those transactions, and who owned that decision. A completed identity check can sit comfortably next to an unexplained permission. This week's exercise follows one completed MFA reset from approval into the action, with the record behind it.
Signals & Moves You Shouldn't Ignore
Binance describes the path to signing operations
Binance's November 3 preliminary report puts affected assets at approximately $6.34 billion, with $2.85 billion frozen or intercepted, subject to reconciliation and market prices. These are not final net-loss figures. [1]
Its account traces a fake interview and malware through an internal AI tool to additional compromised employees and a deployment token. On October 29, stolen credentials were used to deploy a container and trigger a malicious script. Binance reports unauthorized signing-service access and transactions outside its normal withdrawal process. The signer's complete approval logic remains undisclosed. [1]
Microsoft follows support impersonation into privileged access
Microsoft's October 30 investigation describes two intrusions that began with attackers impersonating help-desk staff through Teams and persuading employees to grant remote access, primarily through Quick Assist. The attackers then abused Active Directory Certificate Services to obtain certificates for privileged identities. Microsoft identifies insecure or overly permissive certificate-service configurations in these paths. [2]
The initial interaction and the privileges reached afterward both belong in the investigation. Calling the event social engineering should not end the review of the systems that made further access possible.
NIST gives recovery owners a benchmark
NIST's Digital Identity Guidelines specify account-recovery methods according to assurance level. For accounts that can authenticate at a maximum of AAL2, recovery requires a prescribed combination of methods or repeated identity proofing where applicable. Recovery also requires notification and instructions for disputing an unauthorized event. [3]
Those requirements give a team something specific to compare with its own procedure. "User verified" needs to lead to the method used and the evidence supporting the recovery decision.
The Control Gap
A successful identity check leaves another decision to explain: whether this person should be allowed to take this action, against this resource, under the conditions that apply now. A contractor can authenticate correctly and still hold access that is broader than the task requires or lasts beyond the assignment.
Authorization controls already exist. NIST's zero trust architecture explicitly treats authentication and authorization as separate functions. My concern is the deployed workflow where a successful check ends the conversation about what access is justified. [4]
For an MFA reset, the review needs to establish why the requester was entitled to recover that account, which authenticator change was permitted, and where the system enforced that limit. An approved policy can supply that authority for an automated workflow. The review does not require a new human approval for every event.
The phone makes these decisions tangible. A recovery code, a call and an approval prompt can each contribute different evidence. The workflow needs to define what that evidence establishes before using it to permit a change. Control of a communication channel needs to be assessed in the context of the recovery method and the account being recovered. [3]
Missing justification and an overbroad permission require different repairs. Access may already exist, with credentials and settings that can be restricted or revoked, even while its business purpose remains unexplained. An incomplete record leaves the reviewer with an unknown; it does not establish that the access was necessarily unauthorized.
My Take
I have been on the receiving end of a mandatory identity verification rollout. Everyone completed it, because completing it was the price of access. What I wanted to know was what passing the check entitled me to do, and that answer was the part nobody had written down.
I have also watched contractors pass MFA and keep standing access to a system or ticket queue after the work that justified it was over. Same gap from another angle: the check was real, the permission came along by default, and no one owned the question of when it ended.
Both times, the people closest to the problem were the ones raising it, and the organization had no place to put the question. What eventually worked was asking it in a form someone could act on: which action, which resource, under which conditions, and who owns the exception.
I care about helping the legitimate employee regain access as much as I care about keeping an attacker out. A good reset procedure serves that employee, with limits the technician can explain and a named owner for the hard cases. Leadership picks the evidence a workflow accepts and the access it grants. Make those choices explicit and record them. Give the person who raises a concern a named owner who must respond while the organization can still act.
-W
One Thing Worth Doing This Week
By November 13, have the help-desk and identity owners complete one Reset Fact Register for an MFA recovery from the previous 30 days. Choose a case that restored access to payroll, email or an administrative account. Use the records available when the decision was made.
Record the exact change. Identify the account, requester, operator and time. Describe which authenticator or recovery destination was replaced or added. Capture the relevant state before and after the reset.
List what supported approval. Record each check relied on, its source, when it was obtained and what it established. Explain how the evidence supported the requester's right to recover that account. Reference protected evidence instead of copying identity documents, secrets or recovery codes into the register. Keep enough to support the decision under appropriate access controls, with a defined purpose and retention rule.
Trace permission into execution. Identify the policy or delegated authority used, the permitted change and any exception approver. Locate the system event showing what actually changed. Record where the workflow enforced the approved scope. An undocumented enforcement point remains unknown until it can be established.
Resolve the result. Check the notification record and dispute route. Mark each conclusion supported, contradicted or unknown. Assign an owner and date to unresolved items. Keep the original record separate from later corrections and retests.
A hypothetical example: a ticket records a callback to the number on file, followed by enrollment of a new authenticator. The register should establish why that number was an acceptable recovery channel under the applicable policy, what permitted the enrollment and which system event records it. A completed callback supports only the check that method was capable of making.
The output is one completed register with evidence references and named owners for the unanswered questions. One case establishes a finding about that case. Use it to identify what needs examination across a defined population of resets.
Field Notes
The register separates the evidence supporting approval from the system change that followed. That lets a reviewer examine a reset that completed successfully while leaving its justification unresolved. It also gives the team a way to identify execution that exceeded an otherwise supported approval.
Insurers, auditors and control owners can meet on three things: the decision being changed, the control that enforces it, and the evidence needed to assess the effect on loss exposure. That is a proposition to test in a real workflow before anyone claims fewer losses or smaller claims. I am raising it with insurance carriers and underwriters around AfroTech this week. Binance says it is covering the financial impact from its own resources; the disclosures reviewed do not establish an outside insurer's payout. [5]
For Mobile Trust Boundary, the public requirement is "An authorization result your application can verify." The receiving application must enforce it, and the evidence and policy behind the result need to hold up under review.
In the reset you selected, which record establishes the authority for the change, and which system shows that the approved scope took effect?
William
EVERY FRIDAY. SIGNALS. ONE CONTROL GAP. ONE ACTION.
Sources
Reporting and guidance checked November 6, 2026. Binance's account remains preliminary. My Take reflects firsthand experience; it does not describe the complete design of any organization's controls. The recovery application, Reset Fact Register and proposed insurance-partner inquiry are the author's analysis.
[3] NIST. SP 800-63B-4, Authenticator Event Management, sections 4.2 and 4.6.
[4] NIST. SP 800-207, Zero Trust Architecture, sections 2 and 2.1.
[5] Binance. Security Incident Recovery Update 7. November 4, 2026.