Access Control and MFA for RIAs, Broker-Dealers, and Funds

In plain language

No SEC rule says the words multi-factor authentication. Examiners ask about it anyway, because it is the control that most reliably prevents the incident that triggers every other obligation in this library. The defensible position is MFA on everything that reaches client data — staff, vendors, and service accounts — with the exceptions written down, owned, and shrinking.

Why examiners ask about MFA when no rule requires it

There is no SEC or FINRA rule that says “implement multi-factor authentication.” The obligation is indirect, and it is worth understanding the chain because it determines what “enough” looks like.

Regulation S-P requires safeguards reasonably designed to protect customer records and information. Rule 206(4)-7 requires policies reasonably designed to prevent violations. Both standards are relative to known risk and available controls. Account takeover through credential theft is the most common route into a financial firm’s client data, and multi-factor authentication is inexpensive and widely deployed.

A firm that protects customer information with passwords alone is therefore not failing a specific rule. It is holding a position on reasonableness that is difficult to defend, and the SEC staff’s IM Guidance Update 2015-02 already pointed at access controls, data encryption, and restricting access to systems as areas for advisers to address.

Coverage is the whole question

Firms rarely fail on whether they have MFA. They fail on where it does not reach. The identities that get missed are consistent:

Service accounts and API integrations. Belong to no person, so no person enrols them.
Shared mailboxes and shared logins. Often the credential most widely known inside the firm.
Vendor and contractor accounts. Created as an exception during an implementation and never brought under policy. See vendor oversight.
Break-glass administrative accounts. Deliberately exempt, which is reasonable, and frequently unmonitored, which is not.
Legacy authentication protocols. The policy says MFA is required; an unblocked legacy endpoint means the requirement is advisory. This is the single most common way a well-intentioned MFA deployment gets bypassed.

The useful artifact is a coverage report that enumerates every identity — not just staff — and reconciles the unenrolled ones against an exception register. If the unenrolled list and the exception register do not match, the difference is the firm’s real exposure.

Not all factors are equal

Ranked by how they behave against the attacks that actually happen:

Phishing-resistant — passkeys, FIDO2 security keys, certificate-based authentication. Cannot be relayed by a real-time phishing proxy, because the credential is bound to the origin. This is the appropriate standard for administrative access, remote access, and anyone who can authorise a payment.

App-based push with number matching, or time-based codes. A reasonable general standard. Push notifications without number matching are vulnerable to fatigue attacks — the user approves the fifteenth prompt at 2am.

SMS and voice. Defeated by SIM swapping and interception, and relayed as easily as a code from any other source. Better than a password alone; appropriate only as a documented, expiring exception.

The practical posture for most firms: phishing-resistant for privileged and remote access, app-based for everyone else, SMS only where a client-facing platform offers nothing better and the exception is recorded.

Least privilege, stated usefully

“Least privilege” is easy to assert and hard to evidence. Three concrete rules carry most of the value:

No standing administrative privilege. Elevation is requested, time-bounded, and logged. Daily work happens under a non-privileged identity, so a compromised session during routine work does not hand over the environment.
Every account is attributable. One account, one accountable owner — including non-human identities, which get a registered human owner. Shared credentials make incident scoping impossible, which is what makes them a notification-cost problem as well as a security problem.
Entitlements follow role changes, not just departures. The mover case is the leak. Someone moves from operations to advisory and keeps both sets of access. Departures are usually handled; internal moves accumulate.

Access reviews that mean something

A review that approves everything is not a review. Make it produce decisions by narrowing what it asks:

Review privileged access quarterly and general access annually.
Give the reviewer the last-used date alongside each entitlement. Entitlements unused for 90 days are the candidates; without usage data the reviewer has nothing to reason from.
Require an affirmative removal decision — the reviewer either removes or states why the access is still needed.
Track the completion of removals, not just the review. The gap between “flagged for removal” and “removed” is where findings come from.
Keep the output, including the periods where nothing changed.

Evidence an examiner will ask for

MFA coverage report by identity, with the exception register from the same date
The last two access reviews, with the removals they produced and proof of completion
Privileged role assignments, showing whether privilege is standing or just-in-time
Sign-in logs demonstrating that legacy authentication paths are closed
A departure, traced end to end: last day, revocation timestamps, device return
The non-human identity inventory with owners

Regulation S-P for the safeguards standard, vendor oversight for third-party access, Reg S-ID for the authentication anomalies that are red flags, and incident response and exam evidence for what these logs are needed for later.

Pylon’s service view is on RIA cybersecurity and Cybersecurity.

Primary sources

Frequently Asked Questions

Is MFA legally required for RIAs and broker-dealers?

Not by a rule that names it. The requirement is that safeguards be reasonably designed to protect customer information under Regulation S-P, and that an adviser's policies be reasonably designed to prevent violations under Rule 206(4)-7. Given how account takeover works and how available MFA is, a firm relying on passwords alone for access to customer information will have difficulty describing that choice as reasonable.

Is SMS-based MFA good enough?

It is much better than nothing and materially weaker than the alternatives, because SIM swapping and interception defeat it and it does not resist a real-time phishing proxy. The defensible pattern is phishing-resistant factors — passkeys, FIDO2 security keys, or certificate-based authentication — for privileged and remote access, with app-based push or codes as the general standard and SMS reserved for documented exceptions.

How often should access reviews happen?

Quarterly for privileged accounts and annually for everything else works for most firms, with an immediate review triggered by a role change or departure. What makes the review count is that it results in removals. A review that confirms every account should keep its access every time is usually a review that did not look.

What is the most commonly missed access control at an examination?

Accounts that are not people. Service accounts, shared mailboxes, API keys, and vendor support logins frequently sit outside MFA and outside the review cycle because they belong to no individual. They are also the accounts an attacker prefers, precisely because nobody notices their activity.

Scheduled actions

The recurring work this section implies. Each action carries a stable action-id so it can be tracked in a compliance calendar and rolled up on all scheduled actions.

Review every account holding administrative or elevated privilege, confirm each is still required, and remove the ones that are not.

Cadence:: Quarterly
Owner archetype:: IT, MSP
Source:: 17 CFR 248.30
action-id:: act.access-mfa.privileged-access-review

Review standard user access to systems holding customer information, confirm entitlements match current role, and record the removals.

Cadence:: Annually
Owner archetype:: CCO, IT
Source:: 17 CFR 248.30
action-id:: act.access-mfa.user-access-review

Produce an MFA coverage report across all identities — staff, vendors, service accounts, shared mailboxes — and reconcile the unenrolled list against the approved exception register.

Cadence:: Quarterly
Owner archetype:: IT, MSP
Source:: SEC IM Guidance 2015-02
action-id:: act.access-mfa.mfa-coverage-report

Review each MFA and access-control exception against its expiry date, and either close it or re-approve it with a new date and a reason.

Cadence:: Quarterly
Owner archetype:: CCO, IT
Source:: 17 CFR 275.206(4)-7
action-id:: act.access-mfa.exception-expiry-review

Provision, change, or revoke access within the firm's stated window of a joiner, role change, or departure, and record the completion against the person.

Cadence:: On change
Owner archetype:: IT, MSP
Source:: 17 CFR 248.30
action-id:: act.access-mfa.joiner-mover-leaver

Re-inventory non-human identities — service accounts, API keys, integration credentials, shared mailboxes — with an owner and a justification for each, and retire the unclaimed ones.

Cadence:: Quarterly
Owner archetype:: IT, MSP
Source:: 17 CFR 248.30
action-id:: act.access-mfa.service-account-inventory

Rotate shared and service credentials that cannot be replaced with managed identities, and record the rotation.

Cadence:: Quarterly
Owner archetype:: IT, MSP
Source:: SEC IM Guidance 2015-02
action-id:: act.access-mfa.credential-rotation

Configuration touchpoints

Where this section lands in a real environment. Each touchpoint is stated as a plain configuration rule — not a vendor setting — and carries a stable config-id.

Configuration rule	Applies to	config-id
Multi-factor authentication is enforced, not optional, for every identity that can reach firm systems or customer information — including vendors, contractors, and interactive service accounts.	Identity provider conditional access	`cfg.access-mfa.mfa-enforced-all-identities`
Administrative, remote, and finance-authorising access requires a phishing-resistant factor rather than a code a user can be talked into reading aloud.	Identity provider, privileged access	`cfg.access-mfa.phishing-resistant-privileged`
Legacy and basic authentication protocols that bypass multi-factor enforcement are blocked at the platform, since an unblocked legacy path makes the MFA policy advisory.	Mail platform, identity provider	`cfg.access-mfa.legacy-auth-blocked`
Administrative privilege is requested and time-bounded rather than permanently assigned, and day-to-day work happens under a non-privileged identity.	Identity provider, privileged access management	`cfg.access-mfa.no-standing-admin`
Every account maps to one accountable person or one registered owner; there are no shared logins whose activity cannot be attributed.	Identity provider, line-of-business applications	`cfg.access-mfa.unique-attributable-accounts`
Sessions expire, devices re-authenticate on a defined interval, and unmanaged devices do not hold a persistent session against client data.	Identity provider session policy	`cfg.access-mfa.session-controls`
Authentication successes, failures, MFA enrolment changes, and privilege grants are logged and retained long enough to scope an incident.	Identity provider audit log, log retention	`cfg.access-mfa.auth-events-logged`
Every identity exempt from a standard access control appears in an exception register with an owner, a reason, a compensating control, and an expiry date.	Exception register	`cfg.access-mfa.exception-register`