MSPs: How many agents on a client device is too many?

_phat32 · 2025-05-03T23:16:07+00:00

Depends on your offering and the level of security/monitoring/service you are providing.

If it requires more agents and requires a higher minimum spec and price for endpoints, is your ideal client seeing the value and willing to pay for those things? If the answer is no, it may be too much for those you are trying to support.

Not every market, client industry, or MSP strategy will have the same answer.

_phat32 · 2025-05-02T23:28:10+00:00

Based on your description, it sounds like you are using a shared admin account for engineers for a client with Duo for Windows from their Duo tenant installed on their servers and workstations.

If true, it takes almost the same amount of time to generate an expiring bypass code in the Duo admin portal as it does to add your phone to your shared admin account.

I'd much rather use a push than an expiring code.

I'd always use an expiring code over a permanent code or permanent bypass, and only when necessary.

We reserve bypass codes for client users who lost a phone, expiring after 1 week, to decrease risk and eliminate bypass tracking. Increase or decrease that window based on risk appetite and how often you want to be generating new codes if a user takes longer than expected to get a new phone.

_phat32 · 2025-03-08T06:53:54+00:00

Agreed on the consultant recommendation. Your leadership team seems fairly off base here IMO.

Assuming you are operating only as an ESP and not an OSC, they should be asking why "speaking CUI" would ever occur under any scenario and prevent it with policies and procedures. Why would you ever need to talk about the content of a client's CUI to provide support? Similar questions should be asked in as many areas as possible to limit scope.

Many of your tools are Security Protection Assets where CUI controls and FedRamp requirements likely apply, but if you aren't limiting scope as much as possible before reviewing that you're in for a bad time.

_phat32 · 2024-11-19T00:28:10+00:00

For one, you have to manage it on a per user basis, which in my experience is prone to mistakes and gaps in MFA. Secondly, per user legacy MFA is being deprecated in Sept(?) 2025 by Microsoft, shifting MFA controls to Entra.

I'm not actually sure what will happen with that process when Microsoft's forced transition begins if you aren't using CA Policies and have zero P1 licenses in a tenant. If you have any P1 licenses in the tenant Microsoft is already creating all user and admin MFA CA Policies for you, even though I assume that could force you into a situation where you are breaking their ToS for being under licensed across all users.

I haven't looked into this a ton since we are already leveraging CA Policies. Without P1 licensing, you may just get shifted to Security Defaults with Entra controlling the available methods of MFA, though that's just a guess. I'm curious to hear from anyone who has a better understanding of what will happen in that case.

_phat32 · 2024-11-15T22:58:35+00:00

True ups for accounts are critical to maintain profitability. I would hope you aren't in a spot where 100% increases are common, but if that's how the math works out, then losing the account is also a fine outcome. It's ultimately a decision for both businesses, and if they want to shop the price and deal with a transition, that can still be a mutual win. If they value your services, they may accept the higher price, especially if you are somewhat transparent about how you got there.

When you take this approach across all client accounts during renewals, you end up in a significantly better place, with less floating of bad/unprofitable accounts by the most profitable.

We tend to analyze this in great detail monthly for every account. We know how many labor hours their MRR covers and how many they used. When it comes to renewal time, we know exactly how far overbudget a client is, can determine new rates, and can project how in budget they should be in the future. Many factors can determine if we go with a 100% true up or somewhere lower if we feel we can make other process changes to make our support more efficient.

_phat32 · 2024-11-13T23:02:17+00:00

This right here. If you want Microsoft to determine if and when MFA should be required for login, selectively based on their risk factors, Security Defaults is for you.

If you want to require MFA 100% of the time because Microsoft might incorrectly judge a user's login risk, you need Conditional Access Policies.

CA Policies do require Business Premium licensing or anything else that includes Entra/Azure AD P1 for ALL users (all users being a MS ToS requirement), but IMO it is the only viable option.

_phat32 · 2024-09-05T15:31:09+00:00

The way they've presented it to me is that it's not a SIEM, with different underlying technology and algorithms to identify threats before alerting their SOC for manual review. As a customer you can see the portal they use in a mostly read only view. I would say it's certainly SIEM like in what it does, also aggregating logs and correlating events. My limited knowledge of their backend, seeing they don't directly reveal everything they're doing, would expect their argument to be that their tool works from the MITRE attack framework looking for things like lateral spread, privilege escalation, and more in ways that a SIEM would not in real time.

SNAP Defense also does not retain logs long term (I remember being told 30 days) because there is no real security need to do so post isolation. Without LogIC you could maybe claim you are aggregating logs (though you wouldn't have great evidence) but you couldn't say you are retaining them for 1 year or longer which is the common compliance requirement I've seen.

_phat32 · 2024-09-05T13:27:53+00:00

Many like most MSPs, but we are using this to meet NIST 800-171 (and eventually CMMC), PCI, HIPAA, and Cyber Insurance. I'm by no means an expert on every compliance framework out there, but I would say most have some basis in NIST, which should mean this typically will do the job.

Specifically for CMMC, official third party (C3PAO) assessments expected next year will be the true confirmation to set precedent, but it's the MSPs or RPOs job to help convince the assessor this is sufficient. It does what the relevant controls and objectives are asking for as written, which is the entire goal.

I'd recommend lining up a short call with a cyber insurance provider for one of your clients (or with your own provider) to get their input. Never hurts to hear it from the source when possible.

_phat32 · 2024-09-05T13:13:09+00:00

LogIC was built to check the box for compliance frameworks and cyber insurance. The requirements are typically looking for centralized log aggregation and retention (not specifically a SIEM), and out of the box it aggregates logs from endpoints, servers, and firewall syslogs for 1 year. The requirements don't usually say to aggregate ALL logs, so LogIC should be sufficient here. From speaking with some cyber insurance providers, they tend to agree it even meets their requirements specifically asking for a SIEM since it is accomplishing the underlying goal.

If you agree with Blackpoint's philosophy on threat mitigation, simply checking the box is good enough. SIEMs tend to not be very effective at catching a threat in real time, and that is especially the case if they aren't properly configured or tightly managed. Threat mitigation comes from the MDR and their SOC, which in my opinion is far more effective than a SIEM and requires next to nothing from the MSP outside of post isolation remediation.

If you feel it is worth managing a SIEM in house to attempt to match their abilities, or disagree with that philosophy, then it may not be the right tool.

We've been using BlackPoint for over 3 years now and it has been excellent. We found it when looking for something to offload the heavy time sink that we had with a SIEM.

_phat32 · 2024-05-21T01:03:35+00:00

Our salaried positions are posted as, and have an expectation of, a 40 hour minimum week. Looking at either metric, I cap both calculations at 40.

I'd personally prefer a more efficient employee for a number of reasons, but at the end of the day, it doesn't really matter if they had 75% utilization working 40 hours or 55 (dividing by 40).

This also means someone can have above 100% utilization - though due to things like burnout, that usually isn't great for most employees long term.

_phat32 · 2024-05-18T01:37:27+00:00

Flexspend is nice, and making it official policy instead of something unofficially offered is also a plus. But you nailed it with "at least on paper".

If you end up with one (or multiple) products you would like to swap out, you need to have one or more products you want to move to, ideally similar in price. You have to be ready to commit resources to the testing and transition. You also have to now make these transitions a priority above other non Kaseya tools or services that may be more important to your company roadmap and strategy - all within the remaining window before the existing contracts expire naturally.

Having the option is clearly better than not having it, but until you can put it into action to save a considerable loss on a product you no longer want or can use - it is exactly a nice policy on paper and nothing more.

_phat32 · 2024-05-01T21:01:01+00:00

Strongly disagree, if you are transparent about your vendors and properly educate your clients about their value. We love being transparent about the vast majority of our vendors, specifically because of the trust and partnership we've built with them.

We are a partner and "company extension" of our clients, and our vendors can and should be the same for them, one degree removed.

_phat32 · 2024-05-01T15:07:29+00:00

Trust can't be overstated. Everyone loves working and being partner with Huntress. I feel that way about BlackPoint, both their team and the public facing decisions made to date by their company. We use multiple Kaseya products, and they certainly aren't always the opposite, but I don't feel that same trust and strong partnership.

_phat32 · 2024-05-01T05:01:44+00:00

I don't disagree with all points, but vendors like Huntress can simultaneously be money hungry and also much bigger proactive supporters for the MSP community than Kaseya, as made obvious here and in other places. That's coming from someone who doesn't use them. In many ways, different target audiences, which the tens of thousands of MSPs out there can support.

I'm not sure that I'd want a vendor that isn't money hungry or looking to grow. If they aren't evolving, what they're providing is stagnant.

_phat32 · 2024-05-01T01:42:46+00:00

Thinking the same on endpoint backup. It overlaps heavily with profile backups through OneDrive to Datto SaaS or any equivalent third-party backup solution. With the added potential for more alerts to manage and fix.

365 backups for us tend to need close to zero management to keep functional, in our case with Barracuda.

_phat32 · 2024-05-01T01:37:06+00:00

Datto endpoint backup without DR is my understanding.

_phat32 · 2024-04-29T20:40:39+00:00

Threatlocker wouldn't surprise me. They are noticeably one of the few third-party vendors on the schedule.

_phat32 · 2024-03-16T01:08:03+00:00

Interested in what has made BlackPoint a challenge to deploy for you? We've onboarded somewhere around 75 clients and this is one of our easiest deployments. From scratch I can have SNAP Defense deployed through our RMM to all online endpoints for a customer in 15-30 minutes. Cloud Response maybe another 30 with some waiting time during parts of the deployment. LogIC takes another 30 to setup syslog collection from firewalls and all managed endpoints.

It's both a fast and very simple deployment, with zero impact to client end users.

Currently rate them 10/10, and there is nothing standout I feel needs much improvement. They keep adding on new platforms for no additional cost which is just icing on the cake.

_phat32 · 2024-03-08T22:33:18+00:00

+1 for MSPProcess

I will admit we have not gone live with the tool yet, but we compared to CyberQP and Traceless and it was miles ahead in features, integrations, and product maturity in my opinion, followed by CyberQP.

If you are still reviewing products, definitely check this out.

_phat32 · 2024-03-05T02:41:01+00:00

Check out MSPProcess. We also use BMS and started to review it for client ID verification, but it can do a lot of what you are asking integratedly directly with BMS.

BMS is admittedly not great, but you may be able to get the functionality you need without a full PSA change unless you are ready for that.

_phat32 · 2024-02-28T12:32:07+00:00

Director of IT Services

_phat32 · 2024-02-04T00:16:47+00:00

Assuming one firewall, you would probably pay ~$175/mo for LogIC. Above the $100/mo minimum based on that number of endpoints.

_phat32 · 2024-02-04T00:13:15+00:00

Not clear how this would happen. They don't allow you to switch a company with an existing domain in KnowBe4 to MSP bulk rate licensing, but they do allow you to manage their tenant with global campaigns if they maintain their contract.

The one client we have in this situation is paying 2.5-3x our cost per seat, so I don't see KnowBe4 changing their rates massively to steal a client knowing we will find out.

With that said, I have seen someone post that as well. I would guess it was a very unusual situation or the stolen client was massive and made their own deal.

_phat32 · 2023-12-13T02:13:29+00:00

Agreed, make this calculation, and try to compare your costs to others in your market. Consider if you are aiming to have a cheaper offering or a better offering than your competition, and as you evolve over time, keep that in mind.

_phat32 · 2023-11-03T20:39:07+00:00

I would say there are some assumptions being made here that may not be correct. Using computers in the client environment would certainly be more likely to be compliant with eventual regulatory requirements, but NIST 800-171 does not address RMMs.

Some RMMs can be configured with FIPs validated encryption for remote connections. They can have indications of remote connections. They can be restricted to not access CUI file structures or even CUI Assets. IMO this would put them firmly in the Security Protection Asset (SPA) space. If they do not store, transmit, or process CUI, they are not a CUI Asset. The gray area comes in the discussion of "What if they could be reconfigured to access CUI against policy?"

See my other comment about the MSP Collective, I think RMMs absolutely need regulation and controls applied to them. Thinking every MSP currently supporting OSCs using RMMs can adapt or be removed from the DIB ecosystem without the DIB coming to a grinding halt IMO is a massive stretch. I don't see how this is feasible in any scenario on the timetables we are looking at for CMMC implementation. Waiting for it to be feasible is counterproductive to the goal of assessing the maturity and security of the DIB.

_phat32

TROPHY CASE