Sculptural devices connected by branching stone paths, with a small gate controlling one route.

The IT provider’s report says multifactor authentication is enabled. Staff approve a sign-in on their phones, the principal has a second step on email, and the office reasonably believes that a stolen password is no longer enough to open those accounts. What the report may not show is which kinds of approval are allowed, whose device an approval gives access to, or who can end that access when something goes wrong.

Those are different questions from whether the second factor is switched on. For a family office, the useful requirement is not another security setting for the principal to manage. It is a provider standard that covers how people sign in, what they can be persuaded to authorize, and what happens to access after the sign-in succeeds.

Keep multifactor authentication, but ask which kind

Multifactor authentication, usually shortened to MFA, asks for more than one kind of evidence before granting access. A password combined with proof from an enrolled device is a familiar example. It remains an important defense against someone using a stolen password, but the methods are not interchangeable.

A code typed into a sign-in page can be passed to the real service by a fraudulent page. An approval prompt can be accepted without the person understanding what initiated it. Adding a step improves the sign-in process without necessarily making it resistant to this kind of deception.

Phishing-resistant authentication addresses the impostor-page problem differently. Rather than relying on the person to recognize the right website, it uses a cryptographic check that binds the authentication to the legitimate service. Passkeys and appropriately configured security keys can provide this protection. In its 2025 digital identity guidance, the US National Institute of Standards and Technology distinguishes phishing-resistant methods from manually entered authentication codes, which do not meet that definition.

Ask the provider to identify which methods are enforced on each important service, not merely which methods are available. If a stronger method is offered but a weaker alternative remains usable, the report should disclose that alternative. Start with email, the accounts used to administer systems, and services holding sensitive family information; document what cannot yet meet the standard and who has accepted the exception.

A genuine sign-in page can authorize the wrong device

Some services let a person authorize one device by signing in on another. This is useful when the first device has limited means of entering a username and password. The service supplies a code, and the person enters it through a separate sign-in page to approve access.

The risk is that a person can be persuaded to approve a code for a device they do not control. The sign-in page may be genuine, and the person may complete the required authentication correctly, while the resulting access goes to the party that started the request.

This is not a newly discovered flaw in the idea of two-factor authentication. The Internet Engineering Task Force’s 2019 device-authorization standard explicitly describes remote phishing in which an attacker persuades someone to enter a code for an attacker-controlled device. Microsoft’s September 2026 investigation of device-code phishing documents campaigns exploiting that distinction to obtain account access.

Phishing-resistant sign-in protects against an impostor verifier. It does not, by itself, establish that a separate device-authorization request serves the person’s intended purpose. A family office therefore needs both stronger authentication and a policy governing these alternative routes to access.

Have the provider identify whether device-code authorization is allowed, where it is needed, and whether it can be restricted elsewhere. Microsoft recommends blocking the flow where possible in the environment covered by its investigation. The office’s provider should establish the legitimate dependencies before changing a policy, with any necessary exceptions limited and recorded.

Access continues after the sign-in

A successful sign-in normally lets someone keep working without repeating every authentication step. Services maintain sessions and issue digital credentials, often called tokens, that allow subsequent access. This convenience is part of ordinary use, but it means that securing the initial sign-in and controlling continuing access are separate responsibilities.

NIST’s session-management guidance distinguishes authentication sessions from access tokens and notes that tokens can remain valid after the authentication session has ended. Possession of an access token does not establish that the person is still present.

The executive does not need to learn the different token formats. The relevant questions are what the provider can observe after authentication, which activity it treats as suspicious, and what it can do about that activity. A report that counts enrolled users does not answer any of them.

Require the provider to explain the coverage in ordinary language. Which services supply useful access records? Who reviews alerts, including outside office hours? What can the provider see in office-managed accounts, and what falls outside its remit in personal accounts or an advisor’s systems? Treat those boundaries as part of the service agreement rather than assuming that one monitoring arrangement covers the family’s entire digital life.

Make ending access a tested responsibility

Changing a password should not be used as shorthand for removing every form of unauthorized access. In Microsoft’s documented identity environment, the effect of a password change or reset depends on the type of credential and the reset mechanism. Some are revoked; others can remain valid.

There can also be a distinction between ending access at the central identity service and ending a session within an application. Microsoft’s access-revocation guidance explains that an application may issue its own session credentials, which the central identity provider cannot directly revoke. These are specific implementation details, not a universal timetable for every service an office uses.

Ask the provider to demonstrate containment using a controlled test account. The exercise should establish which access stops, which access may continue, and what additional action is necessary. It should not interrupt a principal’s working account or depend on discovering missing administrative permissions during an incident.

The response procedure should identify the person authorized to disable an account, revoke continuing access, and involve an application provider when needed. It should also cover checking for unauthorized changes that could preserve access or redirect information. Ending a session is not evidence that everything done during that session has been undone.

Connect this procedure to the office’s incident-response arrangements, so the technical actions have a named decision-maker and an escalation route. The provider should be able to explain any delay between a containment instruction and its effect, rather than promise that a single button ends all access immediately.

Put the evidence in the provider agreement

The provider standard should describe an outcome that the office can verify, with responsibilities assigned between the office, its IT provider, and any specialist monitoring service. Annapurna’s role is to define and oversee that standard, not to imply that independent advisory replaces day-to-day system administration.

NIST’s Cybersecurity Framework 2.0, published by the US standards body, includes cybersecurity requirements in supplier agreements and supplier participation in incident planning and response. It does not prescribe one configuration for every family office or create a general legal obligation to adopt this framework.

For authentication and continuing access, require the provider to maintain:

  • An account and service coverage record. Identify the important services, the accounts covered by the provider, and any family or external-advisor accounts outside that scope.
  • An authentication and exception record. Show the methods enforced, weaker alternatives still allowed, permitted device-authorization routes, and the owner and review date for each exception.
  • A monitoring and escalation agreement. State which activity is monitored, who receives alerts, when someone is available to act, and how the office is contacted.
  • A tested containment procedure. Record who can end access, what each action stops, application-specific limitations, and the result of the most recent controlled test.

Ask for evidence that these arrangements work in the office’s environment. A provider’s general description of its security capabilities is not proof that those capabilities have been configured for this client. Equally, a screenshot showing an enabled setting is not evidence that an alert reaches someone with authority to act.

Agree on response expectations that the provider can support and test. Keep exceptions visible when a service cannot meet the preferred standard, rather than allowing a qualified implementation to become an unqualified assurance in the next report.

Give people a rule they can use

Staff and family members should not have to diagnose an authentication protocol when a message arrives. Give them a practical instruction: approve a sign-in or enter a device-authorization code only when they initiated the specific activity and understand what account or device will receive access.

If someone sends a code and asks for it to be entered on a genuine sign-in page, the genuine page is not sufficient reason to proceed. Unexpected requests should go to the known support route, not to contact details supplied in the request. An unexplained approval prompt should be declined and reported.

Teach the same rule to assistants and others who handle access on a principal’s behalf. Make reporting easy when someone has already approved a request, because the response team needs to know which account was involved and what happened. Do not require the person to prove an attack occurred before asking for help.

This instruction complements, rather than replaces, technical restrictions. It also differs from verifying a familiar person’s request: even a convincing conversation should not make an unexplained authorization appropriate. Identity, permission, and the destination of access each need to make sense.

What to ask at the next provider review

Request a walkthrough of one important account from sign-in through containment. Use a controlled account with comparable policies, and ask the provider to show the authentication methods that work, any alternative route that remains available, the evidence generated by access, and how that access is ended.

Use the walkthrough to produce a short action record: the gap, the person responsible, the agreed change, and how completion will be verified. Where a restriction would disrupt a legitimate service, record the dependency and decide how the exception will be limited. Revisit the record when a provider or important service changes, as well as at the office’s scheduled security review.

Keep existing MFA in place while improving it. The decision is not whether to abandon a second factor, but whether the office can explain what its authentication protects, what it does not, and who can contain access that should never have been granted.

Sources