Phishing-Resistant Authentication for Executive Support

Research question

What should an executive office measure when it replaces password and code-based sign-in with phishing-resistant authentication for executive support staff?

Executive assistants routinely cross system boundaries. A calendar change may begin in email, move to a travel portal, and end in a shared document. That breadth makes authentication design part of the support model, not an isolated IT setting. The relevant question is whether an attacker can reuse what a person enters at a convincing fake sign-in page.

What the standards say

NIST Special Publication 800-63B defines phishing resistance in terms of the authentication protocol. A resistant protocol prevents disclosure of authentication secrets or usable authenticator outputs to an impostor verifier without depending on the user's vigilance. The standard recognizes channel binding and verifier name binding as methods. WebAuthn is its named example of verifier name binding because the authenticator selects a secret for the authenticated domain.

That definition draws an important line. NIST says that authenticators requiring manual entry of an output, including one-time passwords and out-of-band codes, are not phishing-resistant. An attacker can relay a code from a fake page to the real verifier. A second factor can still improve security while failing this particular test.

The current NIST authentication guidance also covers replay resistance, authenticator binding, recovery, and lifecycle management. CISA's implementation guidance for phishing-resistant MFA points organizations toward FIDO/WebAuthn and public key infrastructure approaches. Neither source assigns permissions to an executive assistant. The office must still decide which systems warrant stronger controls and how recovery works when an assistant is traveling or covering another desk.

A control map for an executive office

Start with accounts, not job titles. List every place where the assistant signs in or approves a sign-in: executive email, calendar administration, travel booking, expense management, board portals, customer records, document storage, messaging, password management, and any identity provider used to reach them. Record whether the account is individual, delegated, or shared.

Shared credentials deserve their own line because they weaken attribution. If two people know one password, an access log cannot reliably show who acted. Moving to named accounts with delegated permissions can improve the evidence even before a stronger authenticator is introduced.

For each account, capture four facts: the available authentication method, the method currently enrolled, the recovery route, and the business owner. The distinction between available and enrolled matters. A system may support a passkey or hardware key while the user still signs in with a password and texted code.

The map should also identify high-impact actions. Reading an itinerary is different from changing a bank destination or granting mailbox access. The system owner can require a stronger step-up method for a sensitive action even when the base session uses another control.

Measures that reveal whether the change worked

Enrollment percentage is the obvious starting measure, but it is not enough. The numerator should be in-scope named accounts with at least two approved phishing-resistant authenticators enrolled. The denominator should be all in-scope named accounts. Two authenticators provide a recovery path without immediately dropping the user back to a weaker method.

Next, measure actual use. Sign-in logs can show the authentication method presented for successful sessions. Report the share of in-scope sign-ins that used the approved resistant method. If enrollment is high and use is low, a legacy path, remembered session, or application-specific login may be bypassing the design.

Recovery events need a separate register. Count resets, lost authenticators, temporary bypasses, and help desk overrides. For every event, record who verified the request, which factor was used, how long any bypass remained valid, and when normal enrollment returned. A resistant front door paired with an easily manipulated recovery desk is not a complete control.

Finally, inspect exception age. An executive may need an urgent temporary exception during travel. The operational failure is not the existence of an exception; it is an exception with no owner or expiry. Track the median and oldest open exception, then review the oldest cases rather than treating a single average as proof.

How to run the review without collecting too much

Authentication logs can contain sensitive device, location, and account information. The review does not need message content, calendar subjects, travel details, or executive correspondence. A compact evidence table can use account identifier, system, method, event time, exception status, owner, and expiry.

Store the working extract only long enough to complete the review. Aggregate reporting can show rates by system or control class. Restrict row-level records to the identity or security owner and the person reconciling the sample.

Sampling makes the result more credible. Select ordinary successful sessions alongside failures. Confirm that the log's method label means what the analysis assumes. Some products use broad labels such as "MFA" even when the underlying methods differ. The reviewer should trace a sample to the product's method documentation and enrollment record.

Test an account used for temporary coverage as well as the primary assistant account. Coverage can expose a second enrollment path, an old recovery number, or permission inherited from a group. Record the observed method and owner without attempting a live attack or asking anyone to disclose an authenticator secret.

A practical before-and-after design

Choose a baseline period before migration and a follow-up period after the rollout has settled. Keep the account list stable or mark additions and removals. Compare method use, recovery volume, exception age, and help desk contacts. A surge in recovery during the first week may reflect migration work rather than a lasting burden.

Do not claim that the rollout prevented attacks simply because no incident was reported. The defensible claim is narrower: a defined share of observed sign-ins used protocols that meet the chosen phishing-resistance standard, and recovery exceptions were or were not closed within the office's rule.

Segment results by system. The identity provider may pass while a travel or board application retains its own password and code flow. The executive's exposure follows the weakest reachable route, especially when email can reset the downstream account.

The assistant's operating experience also belongs in the review. Note whether travel, device replacement, or coverage duties created friction. A control that works only at the primary desk has not been tested against the role's real conditions. This is not a satisfaction score. It is evidence about whether the design supports the work it is meant to protect.

Decision rules for support leaders

Set an investigation trigger before looking at the results. One reasonable trigger is any high-impact system that still permits password-only access or manually entered codes for the accepted batch of executive support accounts. Another is a recovery bypass that remains open past its stated expiry. The exact threshold belongs to the accountable security owner.

When a trigger fires, choose a specific response: remove the legacy method, narrow access, issue a second authenticator, repair recovery verification, or accept a time-limited exception with a named owner. Avoid turning the review into a general security score.

The assistant should not decide authentication assurance levels, incident severity, or legal obligations. Security and system owners make those determinations. Executive support can maintain the account inventory, coordinate enrollment, test documented recovery, and surface exceptions quickly.

Limits of the evidence

NIST guidance is written for digital identity systems and does not certify a vendor or an executive support arrangement. CISA guidance helps with implementation direction, but an organization's threat model and application estate determine scope. Sign-in logs may be incomplete, retained for different periods, or use inconsistent method names.

A successful authentication does not prove that the endpoint was safe, the session was used appropriately, or the account permissions were necessary. Those questions require endpoint, access, and activity reviews. This analysis should sit beside the site's research library and the service description for a C-suite executive assistant, not replace specialist judgment.

An organization evaluating its own executive support controls can use the four measures here as a review brief. If the account map exposes unclear ownership or a weak recovery path, contact the team to discuss how the support workflow should be documented before access expands.