An MSP can have skilled technicians, mature processes and strong customer references – and still lose a regulated-market opportunity because a foundational tool can’t meet the buyer’s cryptographic or evidence requirements. The remote monitoring and management (RMM) platform matters most here because it connects broadly, moves administrative data and can execute privileged actions across customer systems.
That’s why Kaseya’s September 2 announcement deserves more than a product-update mention. The company says Datto RMM will add FIPS 140-3 validated cryptography at no additional charge starting in October 2026, through an account-wide toggle that’s off by default. The option is built to protect core communication channels while preserving patching, monitoring, automation and remote-control functions. Kaseya also announced native Apple MDM capabilities for macOS, iOS and iPadOS.
The Datto RMM update is commercially meaningful because requirements buried deep in an MSP’s stack can determine which customers the provider is even qualified to serve. But it also highlights a distinction sales teams often blur: a validated cryptographic module doesn’t make a provider, product deployment or customer compliant by itself.
Crypto requirements reach the management plane
FIPS 140-3 sets security requirements for cryptographic modules. Under the federal Cryptographic Module Validation Program, modules are tested by accredited laboratories and validated by NIST and the Canadian Centre for Cyber Security. NIST says U.S. federal agencies must use validated cryptography when cryptographic protection is required; non-validated cryptography is treated as providing no protection for that federal requirement.
An RMM falls within that conversation because it authenticates agents, protects management traffic, transfers scripts and files, and supports remote sessions. If a solicitation, prime contractor or customer security plan requires validated cryptography, an MSP can’t assume strong commercial encryption is an acceptable substitute.
The issue extends beyond the logo on the product page. Buyers may ask for the module certificate number, the exact tested version, the operational environment, the approved mode and the data paths it covers. A vendor may validate one cryptographic component while other integrations, export functions or remote-access paths sit outside that boundary.
There’s also a timing issue, and it’s tighter than most MSPs assume. NIST states that FIPS 140-2 modules can be used for new systems only until September 21, 2026, after which active certificates move to the historical list. And getting a new module validated isn’t a quick fix: independent tracking of NIST’s Cryptographic Module Validation Program shows average processing time has stretched to 542 days for FIPS 140-3, a 42% increase over the 367-day average under FIPS 140-2. A provider that discovers a gap during a live procurement doesn’t have time to close it alone – which is exactly why a vendor-supplied, already-validated module is worth more than it might look on a feature list.
Validation does not equal compliance
FIPS validation answers a narrow but important question about a cryptographic module. It doesn’t prove that an MSP enabled the correct mode, restricted access appropriately, retained sufficient logs or met every requirement in a customer’s framework.
Configuration matters. Since Kaseya’s validated mode is opt-in at the account level, the MSP needs a controlled procedure for enabling it, testing customer workflows and recording the result. Staff also need to know whether turning the option on affects integrations, performance, device support or existing automation.
Scope matters, too. An RMM may use validated cryptography while the PSA, documentation system, backup tool or a technician’s remote-access utility doesn’t. A regulated buyer will evaluate the whole service chain, not just its strongest component. Map how credentials, commands, files and evidence move between platforms, and flag every point where protected data leaves the validated boundary.
Finally, proof matters. A screenshot of a toggle is weak evidence. Stronger evidence includes the vendor’s validation record, the customer-specific configuration, change approval, test results and periodic verification that the setting stays enabled.
Sales qualification should happen early. Before investing in a regulated-sector proposal, get the buyer’s applicable control set, data types, contracting clauses and required evidence. “Healthcare,” “financial services” and “government” aren’t interchangeable compliance scopes. A tool can be technically capable and still fail a deal because the service description, subcontractor chain or evidence package doesn’t match the customer’s written requirement.
Use the VALID test
MSPs can screen management tools with a five-part VALID review: Verify, Activate, Limit, Integrate and Document. Verify the certificate, version and applicable operating environment. Activate the approved mode through controlled change. Limit privileged access and unsupported data paths. Integrate the tool only with systems that preserve required protections. Document configuration, testing, exceptions and ongoing monitoring.
Apply the review during vendor selection and before bidding on regulated work. Procurement questionnaires should ask vendors for certificate details, shared-responsibility boundaries, audit-log retention, tenant isolation and notice periods for cryptographic changes. Contract teams should hold off promising compliance until technical staff confirm the actual deployment.
Build one artifact now, before the next regulated RFP lands: a one-page map of your top regulated customer’s data paths, showing exactly where FIPS-validated cryptography covers the RMM session and where it stops – PSA, backup, documentation, remote-access tool. An assessor will ask for this eventually. Having it ready turns a scramble into a five-minute conversation.
The Apple MDM addition reinforces the broader point. Native device coverage may simplify the stack, but regulated-market readiness still depends on whether policies, logs and enforcement satisfy the customer’s requirements across every supported operating system.
Compliance can open attractive verticals, but it starts with architectural honesty. The MSP that knows precisely what its RMM validates – and what it doesn’t – is in a stronger position than the provider relying on a badge and hoping the assessor never asks for evidence.
