A company can require multifactor authentication for employees while allowing an external administrator to use a different access path. That administrator may enter through a vendor portal, a shared support account, or a remote-management service. The effective authentication boundary includes all of these routes.
An access review can identify the method actually used for each privileged route, the permissions it grants, and what happens when the normal authentication method is unavailable.
MFA methods have different properties
CISA's phishing-resistant MFA guidance explains why FIDO/WebAuthn-based authentication provides protection against credential phishing that manually entered codes do not provide in the same way. Number matching can improve some push-based workflows, but it is not equivalent to phishing-resistant authentication. CISA's implementation guidance describes these distinctions.
An assurance statement that says MFA enabled leaves the method unspecified. For a vendor with administrative access, the review can request the enforced method, enrollment process, fallback routes, and scope of enforcement for the particular service being accessed.
Review the access path the vendor uses
Consider an illustrative support provider that authenticates to its own management platform and then opens a session into the customer's environment. The customer may not directly observe the provider's authentication event. Available evidence may include provider configuration records, session logs, contractual controls, and a supervised demonstration.
These forms of evidence have different limits. A policy document describes a requirement; a configuration record describes a setting; a controlled access attempt describes observed enforcement. Record which evidence supports each conclusion instead of treating the documents as interchangeable.
Include fallback and shared accounts
Inspect emergency access, lost-device recovery, and any accounts excluded from the normal policy. A vendor's named-user accounts may be well controlled while a shared technical account remains available through another interface. Identify the business reason and owner for each exception.
Permissions also matter after authentication. A support task might require access to one application for a limited period. Broad, persistent administrator access increases the operations available to the session regardless of how the person authenticated.
Verify removal and accountability
In a controlled exercise, grant a test vendor identity the agreed role, confirm its permitted task, and remove access. Check active sessions and separate remote-access tools. Record the individual or service identity associated with each action so the customer can distinguish vendor activity from internal administration.
The assessment can produce a route-by-route access record: authentication method, privilege, expiration, fallback, logging, and removal behavior. This gives the business a specific basis for accepting or changing external access. It also identifies questions that cannot be answered without additional evidence from the provider.
Sources
NIST: Phishing Resistance. The support-provider scenario is illustrative.
