Disclaimer: This post is not legal, tax, or compliance advice. Regulatory questions should go to your attorney and compliance consultant. Some of the operational detail below comes from public discussions among IT providers on Reddit and cannot be fully verified. Confirm current requirements directly with LPL before making decisions about your practice.
The LPL cybersecurity mandate requires affiliated advisors to run LPL-selected software on the devices they use for firm business. Advisors have been told enforcement tightens at the end of September 2026. If you already work with an IT provider, the requirements overlap with, and in some cases replace, protections you already pay for.
Below is what LPL is requiring, why they moved, and what still sits with the advisor either way.
Three pieces, installed together:
Installation requires local administrator rights on the device.
The requirements have shifted since spring. LPL's original FAQ language, circulated to advisors in May, said existing RMM and security tools had to be removed. By August, IT providers on the r/msp forum were reporting a softer position: a non-NinjaOne RMM may stay, but EDR and SIEM tooling must go, and LPL's stack wins any conflict. Advisors have also been told different things about which EDR product is being deployed. If your understanding of the requirement dates from spring, confirm it in writing before you plan around it.
Two things happened, and they matter for how you respond.
First, the breach. In April 2026, Wealth Management reported that LPL notified regulators of an incident in which malware delivered through phishing reached a limited number of individual advisor devices. Attackers used that access to reach those advisors' accounts on LPL's web portal, which produced unauthorized securities transactions and financial transfers affecting 1,581 clients. A separate filing months earlier described compromised advisor accounts used in a securities manipulation scheme. The entry point in both cases was the advisor's own device, not LPL's core infrastructure.
Second, the regulation. Amendments to SEC Regulation S-P took effect for smaller entities on June 3, 2026. Covered firms must maintain a written incident response program, notify affected customers, oversee service providers, and keep records proving all of it. FINRA issued its own advisory on the compliance dates, and the SEC's Division of Examinations named Reg S-P a 2026 exam priority.
A broker-dealer supervising 32,000 advisors, most of whom handle their own IT, has a defensible reason to standardize endpoints. Whether the specific approach is the right one is a separate question from whether the motivation is real.
LPL's requirements are endpoint controls. Your regulatory obligations under Reg S-P are broader than your endpoints.
Nothing in the mandate addresses:
Installing the required agents does not make a practice Reg S-P compliant. It closes one gap that regulators and LPL both care about. Everything else still belongs to the advisor.
Independent IT providers supporting LPL advisors have been asking the same questions since May, in two long public threads on the r/msp forum: the original May thread and the August follow-up. These are anonymous accounts and they contradict each other on details. Three months in, there is still no consistent answer to the following.
An RMM agent can start a remote session, change settings, or run scripts. Which LPL personnel, third-party administrators, or vendor staff hold that access, and what approval is required before it happens? Ask for the answer in writing.
One IT provider reported that LPL told him the firm acts as incident response lead for any event on a covered device. Another attended LPL's May advisor webinar, asked directly who carries security liability when LPL's EDR sits alongside another provider's tools, and reported getting no answer. A Reg S-P incident response program has to name someone. Get LPL's position documented before you write yours.
If LPL's RMM manages Windows updates, your existing patch reporting may go dark. One provider described a similar arrangement at another firm where the incoming platform left systems unpatched for eight months while local monitoring showed nothing wrong.
An insurance broker who covers both advisors and IT firms noted in the August thread that he had not been able to obtain the LPL agreement and expected it to shift burden toward the advisor. Send the requirements to your carrier and your attorney. Ask whether removing tooling you previously attested to affects your coverage or your application answers.
Treat this as a scope change to your IT services, not a tooling argument.
IT providers who have kept their LPL advisor clients are generally doing this: LPL takes endpoint detection and response, and the IT provider keeps everything else. That usually means an alternate RMM for support and monitoring, privileged access management, DNS filtering, firewall management, backup, Microsoft 365 security, and end-user support.
Ask your IT provider to document the split in a written statement of work or service agreement addendum, not just in email. That document should name who detects, who responds, who notifies clients and regulators, and in what order. Reg S-P recordkeeping requires that written procedure to exist before an incident.
The mandate is prompting some advisors to look at other broker-dealers, or at going independent as an RIA. That decision turns on economics, payout, and client transition, not on browser policy. If a technology mandate is part of what is pushing you, ask the same questions of the next platform:
Independence turns on what a platform can require of the devices you own. Get those answers before you sign.
If a regulator asks about your Reg S-P compliance next year, "the broker-dealer handles security" is not a working answer. Your firm gets examined, not LPL.
Endpoint controls imposed by a custodian are one layer. A financial services practice still needs someone accountable for the network, the tenant, the backups, the people, and the documentation that proves it all works. PK Tech supports financial services firms and other regulated practices in Arizona and nationally, holds SOC 2 attestation, and works alongside platform-mandated tooling.
If you are working through what to keep, what to remove, and what to document before September, contact us to see if we're a fit.