Skip to content
Office: (416) 621-6611
Emergency: (855) 561-4675
info@balanced.plus
Submit Support Ticket

Month: June 2026

How Are Co-Managed IT and Fully Managed IT Different?

Posted on by Andrei Fomitchev

You already have an IT person, maybe a small team. They keep the lights on, but they are buried: patching servers after hours, fielding password resets, and somehow also expected to plan next year’s cloud migration. The question is not whether you need outside help. It is how much.

This guide breaks down co-managed IT versus fully managed IT: what each model actually covers, and how to tell which one fits a business that already has internal IT.

Co-managed IT is a shared model where an external provider works alongside your in-house IT team, taking on specific functions (after-hours monitoring, cybersecurity, project work) while your staff keep day-to-day control. Fully managed IT hands the entire IT function to an external provider that owns strategy, support, and operations end to end. The difference comes down to who owns what: co-managed splits responsibility, fully managed transfers it.

If you have a capable internal IT team that is stretched thin, co-managed IT fills the gaps without replacing anyone. If you have no internal IT, or you want technology off your plate entirely, fully managed IT is the cleaner fit. Most of the decision is about how much control you want to keep, not about cost alone.

Co-Managed IT

Co-managed IT is a partnership model where an external managed service provider (MSP) shares responsibility for your technology with your internal IT staff. The provider covers agreed areas, such as monitoring, security, helpdesk overflow, or specialized projects, while your team retains ownership of the systems and decisions they handle best.

What is co-managed IT?

Co-managed IT splits the workload between your internal team and an external provider. Your staff keep the institutional knowledge and the relationships; the MSP adds capacity, tooling, and specialist skills your team does not have in-house. A common split: your internal team owns user support and business-specific applications, while the provider owns 24/7 monitoring, cybersecurity, patching, and backup.

In our work with GTA mid-market firms, the trigger for co-managed IT is almost never a broken IT team. It is a competent two-person team that cannot be on call at 2am and also deliver a Microsoft 365 migration on schedule. Co-managed IT support buys back that capacity without forcing you to hire a third or fourth full-time person for coverage you only need part of the time.

What is fully managed IT?

Fully managed IT means the provider owns your entire IT function. There is no internal IT staff to coordinate with; the MSP is your IT department, handling strategy, procurement, helpdesk, cybersecurity, and infrastructure. You get a single accountable partner and a predictable monthly cost, in exchange for handing over the operational driver’s seat.

This model suits businesses that have no internal IT, or whose leadership wants technology fully off their plate. It is also common when a generalist “IT person” has quietly become a single point of failure, and the business needs depth across security, cloud, and support that one hire cannot cover.

How are co-managed and fully managed IT different?

The core difference is ownership. Co-managed IT shares responsibility with your team and is designed to augment what you already have. Fully managed IT transfers responsibility entirely and replaces the need for internal IT. Here is how the two compare across the dimensions that matter most when you are choosing.

DimensionCo-Managed ITFully Managed IT
Who runs ITShared: your team plus the providerProvider owns it end to end
Best forBusinesses with stretched in-house ITBusinesses with little or no IT staff
Your internal teamStays, refocuses on strategic workNot required
Typical scopeGaps: security, after-hours, projectsEverything: support through strategy
Decision controlYou keep the final sayProvider drives, you approve direction
Ramp-upFaster: augments your existing setupFull onboarding and transition

When does co-managed IT make sense?

Co-managed IT makes sense when you have internal IT that is good but outnumbered by the work. You are not trying to replace your team; you are trying to extend its reach into hours, skills, or projects it cannot cover alone. The clearest signals:

  • You have one to three internal IT staff who are constantly reactive and never get to strategic work
  • You are missing a specific skill, usually cybersecurity or cloud architecture
  • You need 24/7 monitoring and after-hours coverage your team cannot sustain
  • A major project (migration, office move, security overhaul) is competing with daily support
  • Compliance frameworks (PIPEDA, PHIPA, SOC 2) demand expertise you do not have on staff
Warning:

The most common co-managed failure we see is undefined boundaries. When “who handles after-hours alerts” is left vague, tickets fall through the gap between your team and the provider. A clear responsibility matrix, written down before day one, is what separates a co-managed partnership that works from one that finger-points.

When is fully managed IT the better fit?

Fully managed IT is the better fit when there is no internal team to build around, or when leadership wants one partner accountable for everything. Hiring your way out of the problem is harder than it looks: the talent gap is real, and specialized security staff in particular are expensive and scarce in the GTA market. The signals that point to fully managed:

  • You have no internal IT, or one overwhelmed generalist doing everything
  • Leadership wants a single accountable partner, not a team to manage
  • You are scaling faster than you can hire and onboard IT staff
  • Technology issues keep pulling non-IT employees away from their actual jobs

4.8M

The global cybersecurity workforce gap in 2024, per the (ISC)2 Cybersecurity Workforce Study. Staffing security in-house is hard precisely because the talent is scarce, which is a major reason mid-market firms outsource it.

How do you choose between co-managed and fully managed IT?

Choosing comes down to an honest read of your current team and how much control you want to keep. Run these four steps before you talk to any provider, and the right model usually becomes obvious.

Audit your team’s real capacity: Not the org chart, the reality. How many hours a week does your IT staff spend firefighting versus planning? If the answer is “all of them,” you have a capacity problem co-managed IT solves directly.

List the gaps: Write down the skills, hours, and projects nobody currently owns. After-hours coverage, security monitoring, a cloud migration. These gaps define the scope of any provider relationship.

Decide what you want to keep control of: If retaining decision-making and institutional knowledge matters, lean co-managed. If you want to hand off the whole function and just approve direction, lean fully managed.

Match the model to the gap: Gaps in capacity and specialist skills point to co-managed. The absence of an internal function altogether points to fully managed. The size of the gap, not the size of your company, drives the choice.

The two models are not permanent. Several of our clients started fully managed while they were small, then shifted to co-managed once they hired an internal IT lead worth building a team around. Pick the model that fits where you are now, and treat it as something you revisit yearly, not a decision locked in for a decade.

Co-managed IT extends an existing team; fully managed IT replaces the need for one. Audit your capacity, name your gaps, and decide how much control you want to keep. The model follows from those answers, and you can change it as your business grows.

Not sure which side of the line your business falls on? That is the conversation we have with GTA companies every week. Our co-managed IT services are built to slot in alongside your existing team and cover exactly the gaps you name, nothing you do not need. If you are weighing the move, it helps to read how to evaluate an MSP before you sign and the signs your business is ready for managed IT.

Sources

How a Missing Database Index Turned a 50ms Query Into a 10-Second Problem

Posted on by Artemy

Performance problems do not always arrive with an alert or a failed deployment. Sometimes they show up quietly, during routine development, on a page that works perfectly but takes far longer to load than it should. That is exactly how this one surfaced: while testing a new feature, one page was noticeably slow. No errors, no failures, just a response time that did not match the size of the data being returned.

This post walks through how we diagnosed it, why SQL Server made the choice it did, and the index design that fixed it. The headline result: a single index took the query from roughly 10 seconds down to about 50 milliseconds, with no infrastructure changes and no application rewrite.

A slow query is usually a clue, not a verdict on your hardware. In this case SQL Server was running a full table scan because no index supported the query’s filter and sort. One well-designed composite index replaced the scan with an index seek and cut execution time from about 10 seconds to about 50 milliseconds, roughly a 200x improvement, without touching the server or the application code.

Database Index

A database index is a separate, ordered data structure that lets the database engine locate rows without reading the entire table. It works like the index at the back of a book: instead of scanning every page to find a topic, the engine jumps straight to the right location. A well-matched index turns a full table scan into a targeted seek, which is the difference between reading thousands of rows and reading a handful.

Step 1: Isolate Where the Time Actually Goes

Before touching the database, we confirmed where the time was being spent. The application server was not under load, CPU and memory looked normal, and there was no sign of an infrastructure bottleneck. Breaking the request down by stage made the problem obvious: almost all of the response time was spent waiting on a single database query to return. Everything else, application logic, serialization, and network, was negligible by comparison.

This step matters because a slow page is easy to misread as an underpowered server. Here, more hardware would have done nothing. The query itself was the bottleneck, so that is where the work belonged.

Step 2: Read the Execution Plan

The query was not complex. It filtered on a couple of columns, applied a sort, and returned a modest result set. To understand why it took 10 seconds, we looked at the SQL Server execution plan, which shows the strategy the optimizer chose for retrieving the data. The same query can be executed in many different ways, and SQL Server picks the plan it estimates to be cheapest based on the available indexes and its statistics.

The plan showed a clustered index scan, effectively a full table scan. Instead of jumping straight to the rows it needed, SQL Server was reading a large portion of the table and discarding everything that did not match. A few other signals lined up with that diagnosis:

  • A thick arrow leaving the scan operator, meaning a large number of rows were read into the pipeline before any filtering.
  • A Sort operator to satisfy the ordering, which is expensive and memory-hungry on large inputs.
  • A green missing-index recommendation at the top of the plan, SQL Server’s own hint that it had no efficient path to the data.
Good to know:

The query was not wrong. It returned correct results every time. The database simply had no efficient route to the rows, so it fell back to the only reliable option it had: read everything, then filter. That distinction matters, because the fix is an indexing decision, not a code bug.

Step 3: The Query and Why the Scan Happened

The query looked similar to this:

SQL slow-query.sql 
SELECT *
FROM CustomerOrders
WHERE TenantId = @TenantId
  AND Status = 'Active'
ORDER BY CreatedDate DESC;

At a glance it looks harmless: filter on two columns, sort the result. The problem was what the table offered to support that pattern, which was nothing useful. There was no index that led with TenantId and Status, so SQL Server could not seek directly to the matching rows. On a small table this is invisible. As the table grows, the cost of scanning every row on every execution grows with it, which is why this query performed fine early in the project and degraded over time as data accumulated.

Two more details made the scan worse than a simple filter. First, ORDER BY CreatedDate DESC forced a separate sort step, because the data was not retrieved in that order. Second, SELECT * pulled every column, which has consequences for the fix described below.

Step 4: Design the Right Index, Not Just an Index

It is tempting to read the missing-index hint, create exactly what it suggests, and move on. The hint is a starting point, not a finished design. Per Microsoft’s index design guidance, a good index for this query follows a clear order of columns:

Equality predicates first: TenantId and Status are matched with =, so they lead the key. This is what lets SQL Server perform an index seek straight to the relevant rows instead of scanning.

The sort column next: adding CreatedDate DESC to the key means rows come out of the index already in the requested order, which removes the expensive Sort operator entirely.

That gives us:

SQL index.sql 
CREATE INDEX IX_CustomerOrders_TenantId_Status_CreatedDate
ON CustomerOrders (TenantId, Status, CreatedDate DESC);

This is stronger than indexing only (TenantId, Status). That narrower index still helps SQL Server find the rows, but it leaves the ORDER BY unsupported, so the engine would still add a Sort. Including the sort column in key order avoids that work altogether.

Order your composite index keys as equality columns first, then the sort column, then range columns. Getting that sequence right is what lets a single index satisfy both the WHERE filter and the ORDER BY in one seek, with no separate sort step.

The SELECT * Problem and Covering Indexes

There is one more consideration. Because the query uses SELECT *, the index above still does not contain every column the query returns. SQL Server would seek the index to find matching rows, then perform a key lookup back to the clustered index for each row to fetch the remaining columns. On a large result set, thousands of key lookups can quietly undo much of the benefit. There are two clean ways to handle it:

  • Return only the columns you need instead of SELECT *, which is good practice regardless of indexing.
  • Add the required columns as included columns so the index can satisfy the whole query on its own, known as a covering index.
SQL covering-index.sql 
CREATE INDEX IX_CustomerOrders_TenantId_Status_CreatedDate
ON CustomerOrders (TenantId, Status, CreatedDate DESC)
INCLUDE (OrderTotal, CustomerName);  -- the columns the page actually displays

Included columns live at the leaf level of the index and are not part of the key, so they support the lookup without bloating the seek. The right choice depends on how many columns the page genuinely needs. The point is to make a deliberate decision rather than accept the default hint.

Step 5: Verify the Fix With Numbers, Not Vibes

After creating the index, we re-ran the query and re-examined the plan. The clustered index scan was replaced by an index seek, and the Sort operator was gone. To confirm it with hard numbers rather than wall-clock timing alone, we used the statistics output:

SQL verify.sql 
SET STATISTICS IO, TIME ON;
-- re-run the query, then compare logical reads before and after

Logical reads dropped dramatically, which is the real measure of how much work a query does and is far more stable than a stopwatch on a busy server. The end-to-end results:

MetricBefore (no index)After (composite index)
Query execution time~10 seconds~50 milliseconds
Data access methodClustered index scanIndex seek
Sort operatorPresentEliminated
Logical readsHighA small fraction
Page responseNoticeable delayNear-instant

~200x

Faster query execution after adding one index: from approximately 10 seconds to approximately 50 milliseconds, measured in a BALANCED+ engagement

And the change required none of the things teams usually reach for first: no infrastructure upgrades, no additional servers, no application rewrite, and no changes to business logic. A single, well-designed index delivered the entire improvement.

Why Indexing Is Worth Understanding, and Not Overdoing

Indexes are one of the most effective tools for database performance, but more indexes is not the goal. Every index carries a cost: it must be maintained on every insert, update, and delete, and it consumes storage. Over-indexing a write-heavy table can hurt as much as under-indexing a read-heavy one.

Warning:

Do not treat SQL Server’s missing-index recommendations as instructions. They identify candidates based on a single query in isolation, with no awareness of your write patterns or existing indexes. Blindly creating every suggested index leads to duplicate and overlapping indexes that slow down writes and bloat storage. Use them as input to a deliberate design, not a to-do list.

Effective indexing comes from understanding how the application actually queries the data: which columns are filtered with equality versus ranges, what ordering queries request, which columns are returned often enough to justify covering them, and how write-heavy the table is. Query patterns also drift over time as features get added, reporting requirements change, and data volumes climb. Indexes that were adequate at launch can quietly become liabilities at scale, which is exactly why periodic performance reviews belong alongside new feature work, not after something breaks.

The Business Impact of a 10-Second Query

A 10-second delay can look trivial in isolation. Multiplied across hundreds or thousands of requests a day, it is not. Slow pages interrupt workflows, reduce productivity, and erode user confidence in a system that feels unresponsive. Reducing this query from 10 seconds to 50 milliseconds changed the experience of the whole page without any architectural change. That is the kind of leverage well-targeted database work offers: small, surgical, and disproportionately impactful.

Lessons Learned

  • Measure before you optimize. Confirm where the time actually goes before assuming it is the server, the code, or the network.
  • Read the execution plan. It tells you exactly how SQL Server runs your query: scan versus seek, sorts, lookups, and where the cost lives.
  • Design indexes, do not just create them. Equality columns first, then sort columns, and decide deliberately about covering the query.
  • Data growth exposes problems that were invisible early on. What scaled fine at launch may not scale at volume.
  • Review performance proactively. The best time to find this is during a routine review, not during an outage.

Sometimes the most impactful optimization is simply helping the database find data it already has more efficiently. Here, one composite index reduced execution time from seconds to milliseconds and delivered a meaningfully better experience for everyone using the application, with zero infrastructure spend. That is the kind of improvement every development team likes to find.

Proactive performance reviews like this are part of how we keep mid-market systems healthy before slowdowns turn into outages. If your team is seeing pages that feel slower than the data warrants, our managed IT and application support practice can help diagnose and resolve it. Get in touch with BALANCED+ to talk through a performance review.

Frequently Asked Questions

What is the difference between an index seek and an index scan?

An index seek uses the index structure to navigate directly to the rows that match a query, reading only what it needs. An index scan reads through the entire index or table and filters afterward. Seeks are typically far cheaper on large tables, and moving from a scan to a seek is one of the most common high-impact query optimizations.

Why was the query slow if it returned correct results?

Correctness and performance are separate concerns. The query returned the right rows every time, but with no supporting index SQL Server had to scan a large portion of the table and sort the results on every execution. Correct results with poor performance almost always point to a missing or mismatched index rather than a logic error.

Should I just create every index SQL Server recommends?

No. Missing-index recommendations are generated from individual queries in isolation and ignore your write workload and existing indexes. Acting on all of them creates redundant indexes that slow down inserts, updates, and deletes. Treat the recommendations as candidates and design a focused set of indexes based on your actual access patterns.

How often should we review database performance?

Schedule reviews on a recurring cadence and after any significant change in data volume, feature scope, or reporting requirements. Indexes that were adequate at launch can degrade as tables grow, so a periodic check of slow queries and execution plans catches problems before users feel them. For most mid-market systems, a quarterly review plus checks after major releases is a reasonable baseline.

Sources

FortiBleed: Fortinet Credential Leak, What To Do Now

Posted on by Paul Thresher

If your business runs a FortiGate firewall or Fortinet SSL VPN, this week’s headlines deserve a measured response, not panic. A credential-harvesting campaign that researchers have nicknamed “FortiBleed” is circulating working login credentials for tens of thousands of internet-facing Fortinet devices worldwide. Here is the part the alarming name obscures: there is no new zero-day. The credentials were largely stolen in earlier Fortinet compromises and are now being fired back at organizations that never rotated them.

This post breaks down what FortiBleed actually is, what Fortinet has said about it, why it still poses real risk despite being “old” data, and the specific steps Canadian mid-market teams should take to close the exposure.

FortiBleed is not a new vulnerability or a fresh breach of Fortinet’s products. It is a large collection of credentials harvested in earlier incidents, now being reused against organizations that never rotated them. Fortinet has stated the activity is not related to any recent incident or advisory. The risk is real but the fix is hygiene: if you run internet-facing Fortinet devices and have not rotated credentials in years, assume exposure, rotate every credential, enforce MFA, and pull the management interface off the public internet.

What is FortiBleed?

FortiBleed

FortiBleed is the informal name given in June 2026 to a large dataset of administrator and SSL VPN credentials for internet-facing Fortinet devices, primarily FortiGate firewalls. Despite the dramatic name, it is not a vulnerability or a new product flaw. The credentials were largely gathered from device configuration files and weak password hashes exposed in earlier Fortinet compromises, and are now being reused and brute-forced against live devices across 194 countries.

The campaign came to light after security researcher Volodymyr “Bob” Diachenko found an attacker-controlled server left publicly accessible, exposing the operation’s stolen credentials, victim lists, and tooling. Threat intelligence firm SOCRadar independently analyzed the same infrastructure and rated the campaign critical. The scale is what makes it notable: depending on the dataset analyzed, researchers count between roughly 74,000 and 87,000 affected devices and tens of thousands of verified working credentials across more than 22,000 domains.

194 countries

Scope of the FortiBleed campaign, spanning 22,405 unique domains across telecom, government, healthcare, and finance (SOCRadar, 2026)

What has Fortinet said about FortiBleed?

Fortinet has stated it is aware of the credential-harvesting activity targeting FortiGate firewalls and VPN devices, but that the activity is based on data from previous incidents and is not related to any recent incident or advisory. In other words, attackers are reusing previously exposed credentials and applying brute-force techniques against devices, rather than exploiting a new flaw in current Fortinet products.

This matches what security researchers concluded after examining the dataset: there is no associated CVE or patch for “FortiBleed” itself because there is no new vulnerability. Much of the credential and configuration data traces back to older Fortinet compromises, including devices exploited through CVE-2022-40684, an authentication-bypass flaw from 2022. The data was collected years ago and is now being recirculated and tested at scale.

Important:

The takeaway is not “ignore it.” It is “this is a hygiene problem, not a patch problem.” Organizations most at risk are those that never rotated administrator or VPN credentials after the 2022-era Fortinet compromises. If that describes your environment, those old passwords may still work, and that is exactly what attackers are counting on.

Why is patching alone not enough?

Because the exposed credentials remain valid regardless of firmware version. Security researcher Kevin Beaumont noted that many of the affected devices were on fairly recent patches, and that the data appears to have come from exports of device configurations. A fully patched device still grants access to anyone holding a credential that was never rotated.

How older credentials were stored compounds the problem. Many devices still hold passwords hashed with salted SHA-256, which is feasible to crack offline with modern GPU hardware. Fortinet moved to the stronger PBKDF2 algorithm with randomized salt in early 2025, but devices upgraded without an administrator logging back in often keep the older, weaker hashes in place. In short: a device can be patched to the latest firmware and still be carrying crackable, never-rotated credentials.

Warning:

A current FortiOS version does not mean you are safe. If your administrators have not logged in to re-hash credentials after upgrading, your device may still store passwords using the older, crackable SHA-256 format that FortiBleed operators are exploiting.

How does the FortiBleed campaign work?

FortiBleed is built on industrialized automation rather than manual hacking. According to SOCRadar’s analysis of the exposed attacker server, the operation runs as a self-perpetuating cycle: scan, validate, harvest, repeat. The mechanics break down into three reinforcing techniques.

Credential stuffing and password spraying: Attackers test large volumes of credentials gathered from infostealer logs, dark-web archives, and prior breaches against FortiGate web panels and SSL VPN portals, recording every successful login.

Passive listening posts: Once a device is compromised, attackers use it to quietly capture additional credentials flowing through the network, feeding fresh logins back into their automated scanner.

Hash interception and offline cracking: Where password reuse fails, attackers intercept SSL VPN authentication hashes and crack them offline on a GPU cluster, recovering plaintext passwords that work on internal systems too.

The end goal is straightforward and dangerous: valid credentials let an attacker log in as a legitimate user, reach the firewall and the network behind it, change security controls, and create backdoor accounts. Researchers traced the cracked passwords being used to pivot into internal Active Directory environments, which turns a perimeter exposure into a full network compromise.

Who is affected, and does it reach Canadian businesses?

Yes. With devices in 194 countries and over 20 percent of entries tied to enterprises with $1B+ in revenue, the dataset is global and includes Canadian organizations. Named victims reported in coverage include major brands such as Samsung, Siemens, Foxconn, Oracle, Accenture, and DHL, alongside government agencies in critical-infrastructure sectors.

Telecom was the single most-targeted sector, followed by government, with healthcare and finance also heavily represented. For Canadian mid-market firms, the compliance stakes are real: a credential-driven breach can trigger mandatory breach reporting under PIPEDA, and regulated organizations in finance or healthcare face additional obligations under OSFI guidance and PHIPA. The Canadian Centre for Cyber Security has repeatedly flagged edge devices like VPN gateways as a priority target, and FortiBleed is a textbook example.

~80,000+

Working Fortinet credentials verified by attackers in the FortiBleed dataset, spanning admin and SSL VPN accounts (SOCRadar, 2026)

What should you do right now?

If your organization runs internet-facing Fortinet appliances and has not rotated credentials in the last few years, treat your existing credentials as potentially exposed until proven otherwise. The actions below are the same whether or not your specific device is in any dataset, because they close the reuse window that FortiBleed depends on. From a security operations standpoint, the response order matters: contain access first, then verify exposure, then harden.

Rotate every credential: Force a complete reset of all passwords tied to Fortinet VPN access and local administrative accounts. Assume current passwords are already in the attackers’ dataset.

Enforce MFA everywhere: Require multi-factor authentication on every administrator and remote-access session. Stolen passwords alone should never be enough to log in.

Pull the management interface off the internet: Restrict the FortiGate admin interface so it is not directly exposed to the public internet. Limit SSL VPN access to known sources where possible.

Upgrade FortiOS and re-hash credentials: Update to a supported FortiOS release (Fortinet guidance points to 7.2.11+, 7.4.8+, and 7.6.1+), then have every admin log in after the upgrade so passwords are re-stored using the stronger PBKDF2 algorithm.

Hunt for compromise: Review VPN and admin login histories for unfamiliar sources, check for unauthorized admin accounts or config changes, and watch for lateral movement into Active Directory. Engage incident response if anything looks off.

Do not just reset passwords and move on. Because compromised devices were used as passive listening posts, any credential that traversed that network, not only the firewall login, should be considered exposed. Rotate downstream service and domain accounts too, and monitor for replays over the following weeks.

Patching vs. credential hardening: where to focus

FortiBleed is a reminder that perimeter security is about identity as much as firmware. The table below maps the common assumption against the reality of this campaign, so you can prioritize the actions that actually reduce risk.

ActionStops a software exploit?Stops FortiBleed?
Apply latest FortiOS patchYesPartially (firmware alone leaves old hashes)
Rotate all VPN and admin credentialsNoYes, removes the stolen credentials
Enforce MFA on all accessNoYes, blocks reuse of stolen passwords
Remove admin interface from public internetPartiallyYes, shrinks the attack surface
Re-hash passwords to PBKDF2 after upgradeNoYes, defeats offline cracking
Good to know:

Track developing indicators of compromise and the latest outbreak guidance directly from Fortinet’s FortiGuard Labs outbreak alerts. Pair vendor advisories with active monitoring rather than relying on either alone.

The lesson of FortiBleed is that a patched device is not automatically a secure device. Credentials, MFA, exposed management interfaces, and password-hash hygiene are what separate the breached organizations from the protected ones. If you cannot quickly confirm all four are handled across your Fortinet estate, you have exposure to close.

If you are not certain whether your Fortinet devices store crackable hashes, expose their management interface, or enforce MFA on every session, that uncertainty is the gap attackers are counting on. As a managed security partner to Canadian mid-market firms, our team handles exactly this kind of rapid exposure review: credential rotation, MFA rollout, and locking down edge devices. Start with our managed Fortinet firewall services, harden access with a zero-trust MFA rollout, or get continuous detection through our MDR and XDR service. If you suspect you are already affected, our incident response and forensics team can help you scope and contain it.

Frequently asked questions

Is FortiBleed caused by a Fortinet vulnerability?

No. Fortinet has stated the activity is not related to any recent incident or advisory, and there is no CVE or patch for “FortiBleed” because it is not a new flaw. It is a collection of credentials harvested in earlier compromises, some tracing back to CVE-2022-40684 in 2022, now being reused and brute-forced against live devices. That is why patching alone does not resolve it: you have to rotate the old credentials and re-hash passwords with PBKDF2.

How do I know if my Fortinet device is affected?

Assume potential exposure if any FortiGate or Fortinet SSL VPN interface is reachable from the internet. Review VPN and admin login histories for unfamiliar source addresses, check for unauthorized admin accounts or configuration changes, and watch for unusual Active Directory activity. Threat-intel lookup tools released alongside the campaign can also indicate whether your domain appears in the dataset.

Does enabling MFA fix the problem?

MFA is essential but not sufficient on its own. It blocks attackers from reusing stolen passwords, which is critical, but you still need to rotate the exposed credentials, remove the management interface from public internet access, and re-hash stored passwords to PBKDF2. MFA is one layer of a four-part response, not a single fix.

What are the compliance implications for Canadian companies?

A credential-driven breach can trigger mandatory breach-of-security-safeguards reporting to the Office of the Privacy Commissioner under PIPEDA, with notification to affected individuals where there is a real risk of significant harm. Regulated organizations in finance or healthcare may have further obligations under OSFI guidance or provincial health-privacy laws such as PHIPA. Document your response and timeline carefully.

Sources

Why an IT Consulting Company Works Like the Cloud

Posted on by Andrei Fomitchev

You already trust the cloud to run a big part of your business. Servers, storage, email, line-of-business apps: you spin them up when you need them, scale them back when you don’t, and pay for what you actually use. No one buys a data centre anymore just to run payroll. So here is a question worth sitting with: if that model works so well for technology, why do so many companies still try to buy all their IT expertise the old way, as full-time, in-house headcount?

This post breaks down a comparison that reframes how mid-market leaders think about outside help: an IT consulting company behaves almost exactly like a cloud platform, except it delivers expertise instead of compute. We call it the “Human Cloud.”

The cloud delivers technology as a service. An IT consulting company delivers expertise as a service. Both give you on-demand access, the ability to scale up or down, and a pay-for-what-you-use model, so you get senior capability without carrying the full cost of owning it. Think of consulting as a “Human Cloud.”

IT Consulting Company

An IT consulting company is a firm that provides specialized technology expertise, strategy, and execution on demand, so a business can access senior skills without hiring them full-time. Like a cloud platform, it offers capability as a service: flexible, scalable, and billed for what you use rather than owned outright.

The “Human Cloud”: how IT consulting mirrors the cloud

The cloud succeeded because it turned fixed, capital-heavy infrastructure into a flexible service. The U.S. National Institute of Standards and Technology defines cloud computing by five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured (pay-per-use) service. Read that list again with people in mind instead of servers, and you have described exactly how a strong IT consulting partner operates. The match is not a loose metaphor. It holds point for point.

Cloud SystemIT Consulting Company
Provides computing power on demandProvides expertise on demand
Scale resources up or down as neededAdd or reduce consultants as projects evolve
Pay only for what you useEngage specialists only when required
Stores and manages valuable dataOrganizes and manages valuable business knowledge
Uses proven infrastructureUses proven methodologies and frameworks
Delivers reliability and supportDelivers guidance and problem-solving
Continuously evolves with new technologyContinuously develops new skills and industry expertise
Helps businesses move fasterHelps businesses make better decisions faster
Reduces the need for large in-house infrastructureReduces the need for large in-house specialist teams
Focuses on enabling growth and innovationFocuses on enabling growth and innovation

5

The number of essential characteristics that define cloud computing, per the NIST Definition of Cloud Computing: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service.

Expertise on demand: pay for what you use, not what you might need

The most expensive way to buy a skill is to hire it full-time before you know how often you will use it. Senior security architects, cloud engineers, and compliance specialists command six-figure salaries in the Greater Toronto Area, and that is before benefits, recruiting, training, and the risk of turnover. For a mid-market company that needs that depth a few weeks a quarter, full-time headcount is the equivalent of buying a server rack to run a workload that spikes twice a year.

Consulting flips the cost structure the same way the cloud did. You engage a specialist when a project, audit, migration, or incident calls for one, and you stop paying when the need passes. The expertise is there the moment you need it and off your books the moment you don’t.

$100K+

Typical annual base salary for a single senior IT or cybersecurity specialist in Ontario, before benefits and overhead, based on Government of Canada Job Bank wage data for the province.

Map your IT needs to a calendar before you map them to a payroll. Anything you need continuously (help desk, monitoring, patching) is a candidate to own or fully manage. Anything you need in bursts (a SOC 2 readiness push, a cloud migration, a security architecture review) is almost always cheaper and faster through the “Human Cloud.”

Scale up or down as the work changes

Rapid elasticity is the cloud feature people love most: resources expand for a busy season and contract when it ends, with no penalty for the swing. The same elasticity is what makes a consulting partner valuable during the moments that strain an in-house team.

When you acquire a company and need to merge two networks, you scale up. When a ransomware scare demands a forensic specialist this week, you scale up. When the project ships and operations settle, you scale back to a steady baseline. A fixed internal team cannot stretch and shrink like that without either burning out during peaks or sitting idle (and expensive) during troughs. A consulting relationship absorbs that variability for you.

Good to know:

Elasticity cuts both ways. The same partner who adds three specialists for a migration should be comfortable scaling back to one trusted advisor afterward. If a firm only ever wants to grow its footprint inside your business, that is a staffing agency, not a “Human Cloud.”

Proven methods, reliability, and skills that keep current

A cloud platform is valuable not just because it is on demand, but because it runs on proven, hardened infrastructure that one company could rarely build alone. A consulting partner brings the human version of that: proven methodologies, reference architectures, and playbooks refined across dozens of environments rather than learned the hard way inside yours.

It also handles the part most in-house teams struggle to keep up with: staying current. The cloud continuously rolls out new services; a good partner continuously develops new skills and industry expertise. From a security operations standpoint, that currency matters most when threats evolve faster than any single internal hire can track. You get the benefit of a team whose full-time job is to stay ahead, applied to your environment only when you need it.

Is an IT consulting company the same as managed IT services?

No, and the difference matters when you are deciding what to buy. Managed IT services are the steady, always-on layer: monitoring, help desk, patching, backups, and security operations delivered continuously for a predictable monthly fee. That is closer to infrastructure you run all the time. IT consulting is the on-demand, project-and-strategy layer: the specialist expertise you pull in for a specific decision, build, or problem.

Most mid-market companies need both, and the strongest partners deliver them together. The “Human Cloud” framing simply clarifies which need you are solving at any given moment: continuous operations versus on-demand expertise. In our work with GTA mid-market firms, the clients who get the most value treat their managed IT services as the always-on baseline and their consulting relationship as the elastic capacity layered on top.

When does the “Human Cloud” model make sense?

Use this quick framework to decide whether a need belongs in-house or in the “Human Cloud.”

Check the frequency: If you need the skill every day, owning or fully managing it usually wins. If you need it in bursts, consulting almost always costs less and delivers faster.

Check the depth: The more specialized the skill (security architecture, compliance, cloud migration), the harder and costlier it is to hire and retain, and the stronger the case for on-demand access.

Check the risk of staleness: If the skill must stay current with fast-moving technology or threats, a partner whose job is to stay ahead beats a single internal hire who can fall behind.

Check the cost of being wrong: For high-stakes decisions (a migration, an audit, an incident), proven outside methodology lowers the chance of an expensive mistake more than learning on the job does.

You would not buy a server room to run a workload that spikes twice a year. Apply the same logic to expertise. Own the capability you use every day, and pull the rest from the “Human Cloud” on demand. That is how mid-market companies stay agile, control cost, and focus on what they do best.

At BALANCED+, this is exactly how we work with mid-market businesses across Toronto and the GTA: a steady managed foundation plus senior expertise you can scale on demand, without the cost of carrying every specialist in-house. If you want to map which of your IT needs should be owned and which belong in the “Human Cloud,” book a conversation with our team and we will help you draw the line.

Frequently asked questions

What does an IT consulting company actually do?

An IT consulting company provides specialized technology expertise, strategy, and hands-on execution on demand. That ranges from planning a cloud migration or a cybersecurity program to guiding a compliance audit or solving a specific technical problem. The defining trait is that you access senior skills when you need them rather than employing them full-time.

Is IT consulting cheaper than hiring in-house?

For skills you need continuously, in-house can be more economical. For specialized or occasional needs, consulting is usually cheaper because you avoid a full salary, benefits, recruiting, and training for capability you only use part of the time. The smart approach is to own steady-state work and pull specialized expertise on demand.

What is the difference between IT consulting and managed IT services?

Managed IT services are continuous, always-on operations such as monitoring, help desk, patching, and security, delivered for a predictable monthly fee. IT consulting is on-demand, project-based expertise and strategy. Many mid-market companies use both: managed services as the operational baseline and consulting as elastic capacity for projects and decisions.

Why compare an IT consulting company to the cloud?

Because the economics are the same. The cloud delivers technology as a service: on demand, scalable, and pay-per-use. An IT consulting company delivers expertise on the same terms. Framing consulting as a “Human Cloud” helps leaders see that they can access senior capability flexibly instead of buying it all as fixed headcount.

Sources

FortiGate SSL VPN Is Going Away: Migrate to IPsec

Posted on by Maxim Kazachek

If your business runs remote access through a FortiGate firewall, the way your team connects from home is about to change, and the deadline is closer than most IT leaders realize. Fortinet is removing SSL VPN tunnel mode from FortiOS, the feature that powers the FortiClient remote access VPN that thousands of Canadian businesses rely on every day. On newer G-series FortiGate appliances, it is already gone.

This post breaks down exactly which FortiOS versions and FortiGate models are affected, the timeline you need to plan around, and how to migrate from SSL VPN to IPsec VPN without locking your remote workforce out.

SSL VPN tunnel mode is being phased out of FortiOS. FortiOS 7.6.2 is the last release to support it on most FortiGate models, and 7.6.3 removes it entirely. New G-series FortiGates do not support SSL VPN at all. If you use FortiClient remote access VPN, you must migrate to IPsec VPN before upgrading to 7.6.3 or moving to G-series hardware. Plan the switch now rather than discovering it during an upgrade.

SSL VPN Tunnel Mode

SSL VPN tunnel mode is the FortiGate remote access method that uses the FortiClient agent to create a full network tunnel over an encrypted HTTPS connection. It lets remote employees access internal company resources as if they were on the office network. Fortinet is deprecating this feature in favour of IPsec VPN, which uses a different, more standardized encryption protocol for the same job.

What Is Changing With FortiGate SSL VPN?

Fortinet is retiring SSL VPN tunnel mode across the FortiOS product line and steering all remote access toward IPsec VPN. This is not a security advisory or an emergency patch. It is a planned architectural change that arrives gradually through normal firmware upgrades, which is exactly why it catches teams off guard. You will not see it until the day you push a firmware update and your remote users can no longer connect.

According to Fortinet’s technical documentation on SSL VPN support across FortiGate models, the removal is happening on two tracks at once. The first track is hardware: the newer G-series FortiGate appliances ship without SSL VPN support, full stop. The second track is firmware: as you move up through the FortiOS 7.6 releases, SSL VPN tunnel mode is removed model by model until it disappears completely in 7.6.3.

Warning:

If you upgrade a FortiGate to FortiOS 7.6.3 or later without migrating first, SSL VPN tunnel mode will stop working and your remote employees will lose access. Confirm your VPN method before scheduling any firmware upgrade to 7.6.3.

FortiOS Version Timeline: When SSL VPN Goes Away

The single most useful thing you can do right now is map your current FortiOS version against the removal timeline. SSL VPN tunnel mode does not vanish in one release. It is pulled progressively, starting with low-memory and entry-level models and ending with a complete removal in FortiOS 7.6.3. Here is how the releases line up.

FortiOS VersionSSL VPN Tunnel Mode Status
7.4.xSupported, except some newer entry-level G-series models in later releases
7.6.0Removed only on certain low-memory (2 GB RAM) models; still available on most others
7.6.1Removed on additional desktop and entry-level models (40F, 60E/F, 80E, 90E, 90G, and similar)
7.6.2Last version with SSL VPN tunnel mode available where supported
7.6.3+SSL VPN tunnel mode removed on all FortiGate models; migrate to IPsec VPN

There is one more date that matters and it is easy to miss. FortiOS 7.4 is scheduled to reach end of support in 2027, which means staying on an older release to keep SSL VPN alive is not a long-term plan. You will run out of security updates on 7.4 around the same time you would otherwise be forced off SSL VPN by the 7.6 line. Either path leads to IPsec, so the practical question is simply when you do the work, not whether.

Good to know:

Not everything SSL-based is disappearing. SSL VPN web mode, the clientless browser portal, survives in a modified form and is renamed Agentless VPN in later FortiOS releases. It is the agent-based tunnel mode (FortiClient remote access) that is being removed.

Why Are G-Series FortiGates Affected First?

G-series FortiGate appliances do not support SSL VPN at all, which makes them the clearest signal of where Fortinet is heading. If you have recently purchased or are about to deploy a G-series firewall, IPsec VPN is your only built-in remote access tunnel option from day one. There is no SSL VPN tunnel mode to fall back on, regardless of which FortiOS version you run.

This matters most during hardware refreshes. A common scenario we see with GTA mid-market firms is a business replacing an aging FortiGate 60E or 90E with current G-series hardware, restoring the configuration, and assuming remote access will carry over. It will not. The SSL VPN configuration has nowhere to land on the new appliance. Any refresh onto G-series hardware needs an IPsec VPN migration baked into the project plan, not treated as a surprise after cutover.

Before approving any FortiGate hardware purchase, confirm whether the model is G-series and plan your remote access around IPsec VPN from the start. Building IPsec into the initial deployment is far cheaper than retrofitting it after users are already connecting through a method that is about to break.

How Do You Migrate From SSL VPN to IPsec VPN?

Migrating from SSL VPN to IPsec VPN is a planned project, not a single config toggle. The encryption protocol, client configuration, and authentication flow all change, and the safest approach is to run both methods in parallel during the transition so you can move users in controlled batches. Here is the sequence we follow.

Inventory your VPN footprint: Identify every FortiGate in your environment, its exact FortiOS version, its model, and how many users connect through SSL VPN tunnel mode today. This tells you who is affected and how urgent the timeline is for each site.

Build the IPsec VPN configuration: Configure dial-up IPsec VPN on the FortiGate with the right encryption proposals, authentication method, and split-tunnel or full-tunnel routing to match your security policy. Integrate it with your existing identity provider and multi-factor authentication.

Run SSL and IPsec in parallel: Keep SSL VPN active while you stand up IPsec alongside it. This gives you a rollback path and lets you migrate users in waves instead of a single high-risk cutover.

Pilot, then roll out in batches: Move a small test group to IPsec first, validate access to every critical resource, then expand. Update the FortiClient configuration and provide clear instructions so end users are not left guessing.

Decommission SSL VPN and upgrade firmware: Once everyone is on IPsec and stable, disable SSL VPN tunnel mode and proceed with your FortiOS upgrade to 7.6.3 or later, confident that remote access will not break.

FortiOS Upgrade Best Practices: Don’t Jump Too Far Ahead

The SSL VPN change is a reminder of a broader discipline: upgrade FortiOS deliberately, not aggressively. Fortinet designates specific releases as recommended, often called the “Gold” or mature release, and that is almost always where a production firewall should live. The newest available version is rarely the right place for a business-critical appliance, and the oldest supported version leaves you exposed. The sweet spot is the recommended release for your specific model.

  • Check Fortinet’s recommended release for your exact FortiGate model before every upgrade. The right version differs by hardware.
  • Follow the supported upgrade path. Jumping multiple major versions in one step can corrupt configurations or strip features like SSL VPN without warning.
  • Read the release notes for the target version, specifically the removed and deprecated features section, before you schedule the work.
  • Test in a maintenance window with a config backup and a rollback plan. Never upgrade a production firewall during business hours on a whim.
  • Start planning for FortiOS 8 now. Knowing what is coming lets you sequence hardware refreshes and feature migrations on your schedule instead of reacting to a forced change.
Important:

The most expensive FortiOS upgrades are the rushed ones. A planned migration with parallel VPN methods and a tested rollback costs a fraction of an emergency response after remote staff are locked out on a Monday morning.

SSL VPN tunnel mode is on its way out of FortiOS, and IPsec VPN is the path forward for every FortiGate remote access deployment. The businesses that handle this well are the ones that inventory their firewalls now, build IPsec alongside SSL VPN, and migrate users in controlled batches before a firmware upgrade forces the issue. The deadline is set by your own upgrade schedule and FortiOS 7.4’s end of support, so the time to plan is today.

At Balanced+, we manage and secure FortiGate environments for mid-market businesses across Toronto and the GTA, including firmware lifecycle planning and VPN migrations that keep remote teams connected through the transition. If you are not sure which FortiOS version your firewall runs or whether SSL VPN removal affects you, our team can audit your environment and build the migration plan for you. Learn more about our cybersecurity and managed firewall services.

Frequently Asked Questions

Is FortiGate SSL VPN being discontinued?

SSL VPN tunnel mode, the agent-based FortiClient remote access VPN, is being removed from FortiOS. FortiOS 7.6.2 is the last release that supports it on most models, and 7.6.3 removes it entirely. SSL VPN web mode survives in a renamed form called Agentless VPN, but the full tunnel feature most businesses use for remote access is being discontinued in favour of IPsec VPN.

Which FortiOS version removes SSL VPN?

FortiOS 7.6.3 removes SSL VPN tunnel mode on all FortiGate models. Removal begins earlier on certain low-memory and entry-level models in 7.6.0 and 7.6.1, but 7.6.2 is the last version where it remains available where supported. You must migrate to IPsec VPN before upgrading to 7.6.3 or later.

Do G-series FortiGate firewalls support SSL VPN?

No. G-series FortiGate appliances do not support SSL VPN tunnel mode at all, regardless of FortiOS version. If you deploy or refresh onto G-series hardware, IPsec VPN is your only built-in remote access tunnel option, so plan your remote access around IPsec from the start.

Is IPsec VPN better than SSL VPN on FortiGate?

For FortiGate remote access going forward, IPsec VPN is the supported and recommended method, which makes it the practical choice. IPsec uses a standardized encryption protocol and is built into current and future FortiGate hardware, including G-series models. SSL VPN tunnel mode is being removed, so even if your team prefers it today, IPsec is where remote access is heading.

Sources

How MCP’s Ensure your AI projects Succeed

Posted on by Artemy

Every week, another business announces an AI initiative. A pilot gets funded, a tool gets selected, and six months later, nothing has changed. No press release declaring success. Just a quiet budget reallocation and a team that has moved on to something else.

This pattern is predictable. And once you understand the structural cause, it becomes preventable.

Most enterprise AI projects do not fail because of the AI. They fail because the AI cannot reach the data it needs to be useful. Model Context Protocol (MCP) is the open standard that closes that gap by giving AI agents a secure, governed way to connect to business systems.

The Real Reason AI Pilots Stall

When organizations evaluate AI, the conversation almost always centers on model capabilities. How accurate is it? How fast does it respond? Can it handle our industry’s terminology?

Those are secondary questions. The primary question is: what can this AI actually see?

Most enterprise AI tools deploy into a vacuum. They can answer general questions, summarize content you paste into them, and generate responses from scratch. What they cannot do, without deliberate integration work, is reach your CRM, check your ticketing queue, read policies from SharePoint, or pull records from your ERP.

The result is an expensive tool that forces users to manually copy-paste context into a chat window. That is not AI-powered business. That is a smarter clipboard.

Employees quickly notice the gap. The AI is only as useful as what they remember to feed it, so they fall back to existing workflows. The pilot generates a handful of interesting demos, produces a slide deck for leadership, and gets quietly deprioritized.

The integration gap is not a technology problem you solve after the pilot. It is a scoping problem you address before the first tool gets selected. AI initiatives that skip integration planning almost always end up rebuilding from scratch.

What Enterprise Systems Are Actually Working With

Most mid-market businesses in Ontario have built their operations across a stack of platforms that were never designed to interoperate cleanly. A typical setup includes some combination of:

  • CRM: Salesforce, HubSpot, or Microsoft Dynamics
  • ERP: SAP, NetSuite, or Microsoft Business Central
  • Document management: SharePoint or Google Drive
  • Data warehouse: Snowflake, Azure Synapse, or AWS Redshift
  • Email and calendar: Microsoft 365 or Google Workspace
  • Ticketing and service desk: ServiceNow, Jira, or Zendesk

Each system holds a critical piece of the business. None of them were designed to feed an AI model. And without a standardized integration layer, connecting an AI agent to each one means building a custom connector, handling authentication separately, writing bespoke translation logic, and then maintaining all of it when systems change.

That work is expensive, slow, and fragile. Most organizations either skip it entirely (and get limited AI value) or build it piecemeal (and end up with technical debt they cannot maintain).

What Is MCP?

Model Context Protocol (MCP) is an open standard developed by Anthropic that defines how AI models and agents securely connect to external data sources and tools. MCP establishes a common interface between AI applications (clients) and business systems (servers), so any MCP-compatible AI can access any MCP-compatible system through a consistent, governed connection. Released in November 2024, MCP is not a proprietary product. It is a vendor-neutral specification designed to become the universal connector layer for enterprise AI.

The analogy that makes it concrete: before MCP, every AI integration was a custom job. Build a unique API bridge, manage credentials per system, write one-off parsing logic. It was the equivalent of wiring a new plug for every outlet in your building.

MCP standardizes the plug. One specification. One authentication model. One governance layer. Vendors build MCP-compatible interfaces for their products once. Any AI agent that supports the protocol can then connect to any compliant system without custom work.

In practice, an MCP server sits between the AI and the enterprise system. When an AI agent needs information, it calls the relevant MCP server. The server authenticates, retrieves the data, and returns it in a standardized format the model can use. The underlying system does not need to change.

MCP vs. Traditional AI Integration: What Changes

The gap between the old approach and MCP is significant across every dimension that matters to enterprise IT.

Dimension Traditional Integration With MCP
Integration approach Custom connector per system, built from scratch Standardized protocol; reuse across systems and AI tools
Access control Per-system, inconsistent policies Centralized; policy-driven at the protocol layer
Time to integrate Weeks to months per connection Days to weeks with available MCP servers
Vendor portability Locked to one AI platform Portable across any MCP-compatible AI
Audit trail Fragmented across individual systems Unified logging at the connection layer
Maintenance burden High (custom code breaks on system updates) Lower; vendor maintains the MCP server

Why Governance Is the Deciding Factor

For IT and security teams, the integration problem is fundamentally a governance problem. Custom API integrations are hard to audit, hard to update, and hard to revoke. When an employee changes roles or leaves, tracking down every access point they used is a manual, error-prone exercise. When a third-party vendor gets compromised, knowing exactly which systems were exposed requires digging through configuration files that were never documented centrally.

MCP changes the governance model because access is managed at the protocol layer. You define which agents can connect to which systems. You specify what operations they are permitted to perform and what data they are allowed to retrieve. That access is logged centrally. It can be revoked with a single policy change. It follows your existing security policies rather than creating parallel, informal access channels.

For organizations operating under PIPEDA, PHIPA, or SOC 2 requirements, this is the piece that makes enterprise AI viable rather than aspirational. Security and compliance teams need to be able to answer: who accessed what, when, and why. MCP makes that question answerable across every AI-to-system interaction.

When evaluating AI tools for enterprise use, ask vendors to document their integration architecture specifically. If the answer is “we handle that for you” without a clear explanation of where authentication happens, who controls access, and how connections are audited, that is a vendor lock-in and governance risk to flag before signing anything.

The Vendor Lock-In Problem MCP Solves

There is a second structural issue with enterprise AI adoption that MCP addresses directly: proprietary integration lock-in.

Most AI platforms want to own the integration layer. They build proprietary connectors, store data in their own pipelines, and make migration costly. If you build your AI capabilities on top of one vendor’s ecosystem and that vendor raises prices, changes terms, or gets acquired, you are effectively trapped.

MCP is an open standard maintained by a neutral specification body. That means the integration work you invest in today is portable. The MCP servers you build or license can work with a different AI model, a different platform, or a next-generation tool that does not exist yet. You are building infrastructure, not dependency.

Major technology companies have already signalled adoption. Block, Replit, Sourcegraph, and others began building MCP-compatible tooling within months of the specification’s release. The direction of travel is toward an ecosystem where MCP compatibility is a baseline expectation, not a differentiator.

What to Ask Before Your Next AI Initiative

If your organization has evaluated AI and found the results underwhelming, the integration gap is the most likely culprit. The tools were capable. They just could not see your business.

Before starting your next AI initiative, these are the questions that determine whether it delivers or stalls:

Define the data sources first: Which systems hold the data this AI will need to be useful? List them explicitly before evaluating any tools. If you cannot answer this question, the pilot scope is not defined.

Audit the integration architecture: Ask every vendor how their tool connects to your existing systems. Does it support MCP or another open standard? What does the authentication model look like? Where is access controlled and logged?

Assign ownership of the integration layer: Someone on your team needs to own the connection between AI and business systems. If that responsibility is undefined, integrations will be inconsistent, ungoverned, and unsupported.

Test governance before scale: Before expanding an AI initiative across teams or use cases, verify that access controls, audit logs, and revocation procedures are working as intended. Scaling ungoverned AI access multiplies risk, not just value.

AI does not fail because the technology is immature. It fails because the technology cannot reach the information it needs to do useful work. MCP addresses that at the infrastructure level: standardized connections, centralized governance, and portability across vendors. Getting the integration layer right is what separates an AI pilot from an AI capability.

At Balanced+, we help mid-market businesses in Toronto and the GTA build the IT infrastructure that makes AI adoption practical and secure. If your organization is working through an AI strategy or evaluating where to start, the integration architecture should be the first conversation. Learn more about our AI and machine learning services or book a consultation to talk through your specific environment.

Frequently Asked Questions

Why do most enterprise AI projects fail?

Most enterprise AI projects fail because the AI tool cannot access the business data it needs to be useful. Organizations deploy AI without solving the integration problem first, leaving the tool isolated from CRM records, ERP data, ticketing systems, and document repositories. Without access to live business context, AI adds limited practical value and adoption drops off.

What is Model Context Protocol (MCP)?

Model Context Protocol (MCP) is an open standard released by Anthropic in November 2024 that defines how AI models securely connect to external systems and data sources. It works like a universal adapter: AI agents connect to MCP servers, which handle authentication and data retrieval from enterprise systems like CRMs, ERPs, and ticketing platforms. Because MCP is vendor-neutral, integrations built on it are portable across AI providers.

How does MCP improve AI security and governance?

MCP centralizes access control at the protocol layer rather than managing permissions separately in each connected system. IT teams can define which AI agents are permitted to access which data, log every request, and revoke access centrally if needed. This makes it possible to audit AI behavior across all connected systems from a single control point, which is critical for organizations operating under PIPEDA, PHIPA, or SOC 2 requirements.

Does MCP prevent vendor lock-in?

Yes. Because MCP is an open, vendor-neutral specification, integration work built on the protocol is not tied to a single AI platform. Organizations can switch AI models or vendors without rebuilding their entire integration layer. This is a significant advantage over proprietary connector ecosystems, where migrating away from one vendor’s AI platform often means losing all the integration investment made on top of it.

Sources

Microsoft 365 Business Premium vs. Basic: What SMBs Need

Posted on by Artemy

You are pricing out Microsoft 365 for your team and the spreadsheet math is doing what it always does: Business Basic looks like the obvious win. It is roughly a third of the price of Business Premium, everyone gets email and Teams, and the apps run in the browser. Why pay more? Then someone on your team clicks a credential-harvesting link, the attacker logs in from an unmanaged laptop, and you discover the security controls you skipped were the actual product you were buying.

This post breaks down what genuinely separates Microsoft 365 Business Basic from Business Premium, what each plan costs in Canada, and how to decide which one your business actually needs without overpaying or underprotecting.

The price gap between Business Basic and Business Premium is not really about email or Office apps. It is about security and device management. Premium bundles enterprise-grade tools (Defender for Business, Entra ID P1, Intune, and data-loss prevention) that you would otherwise buy separately or live without. For most Canadian SMBs that handle client data, Premium is the floor, not the upgrade.

Microsoft 365 Business Premium is the top small-business tier of Microsoft 365. It includes everything in Business Standard (desktop and web Office apps, Exchange email, Teams, SharePoint, OneDrive) plus a bundled security and device-management stack: Microsoft Defender for Business, Microsoft Defender for Office 365 Plan 1, Microsoft Entra ID Plan 1, Microsoft Intune, and Azure Information Protection. It is capped at 300 users.

What is the actual difference between Business Basic and Business Premium?

The difference comes down to two things Basic does not include: desktop Office apps and a full security and management layer. Basic gives you the web and mobile versions of Word, Excel, and Outlook, hosted email, and Teams. Premium gives you the installed desktop apps plus the security tooling that protects identities, devices, and data. Business Standard sits in the middle: it adds desktop apps to Basic but stops short of the security stack.

Capability Business Basic Business Standard Business Premium
Web & mobile Office apps Yes Yes Yes
Desktop Office apps (Word, Excel, Outlook) No Yes Yes
Exchange email, Teams, SharePoint, 1 TB OneDrive Yes Yes Yes
Defender for Office 365 (Safe Links, Safe Attachments, anti-phishing) No No Yes
Defender for Business (endpoint detection & response) No No Yes
Entra ID P1 (Conditional Access, self-service password reset) No No Yes
Intune device management (MDM/MAM) No No Yes
Data-loss prevention & information protection No No Yes
Approx. price (CAD, annual, per user/month) ~$8 ~$17 ~$30

Pricing changes periodically and varies by commitment term, so confirm current figures on Microsoft’s Canadian plan comparison page before you budget. The ratios, however, stay roughly the same: Premium runs about three to four times the cost of Basic.

What does Business Basic actually give you (and what it leaves out)?

Business Basic is a complete cloud productivity suite for a team that lives in the browser. You get hosted Exchange email with a 50 GB mailbox, the web and mobile versions of the core Office apps, Microsoft Teams, SharePoint, and 1 TB of OneDrive storage per user. For a startup of five people running lean, or for frontline staff who only need email and a calendar, it is genuinely enough.

What it leaves out is the part that matters once you have employees, devices, and client data to protect. Basic has no endpoint protection, no managed device enrollment, no Conditional Access to enforce where and how people sign in, and no advanced email filtering beyond the standard built-in spam protection. According to Microsoft’s own Business Premium documentation, those security capabilities are precisely what define the Premium tier. With Basic, you are responsible for sourcing and funding all of it elsewhere.

A common misconception: people assume Basic is “Office without the desktop apps.” That is half true. The desktop apps are the smaller of the two gaps. The bigger gap is that Basic and Standard ship with no managed security layer at all, while Premium does.

What are you really paying for with Business Premium?

You are paying for a bundled enterprise security stack that would cost significantly more to assemble from standalone products. Business Premium folds five distinct tools into the per-user price, and each one closes a specific attack path that Basic leaves open.

  • Microsoft Entra ID P1 enables Conditional Access, the policy engine that blocks logins from risky locations or unmanaged devices and enforces MFA based on context rather than a blanket rule.
  • Microsoft Defender for Business adds endpoint detection and response (EDR) across Windows, Mac, iOS, and Android, the kind of behavioural threat detection that catches ransomware before it spreads.
  • Defender for Office 365 Plan 1 layers Safe Links, Safe Attachments, and advanced anti-phishing onto email, the channel attackers use most.
  • Microsoft Intune lets you enroll, configure, and remotely wipe company and personal devices, so a lost laptop is an inconvenience rather than a breach.
  • Azure Information Protection and DLP classify and protect sensitive documents, which matters for PIPEDA, PHIPA, and client-confidentiality obligations.

From a security operations standpoint, the value of Premium is not any single feature. It is that identity, email, endpoint, and data protection are integrated under one policy plane. When we onboard GTA mid-market clients, consolidating these controls into Business Premium often replaces a patchwork of point products that cost more in aggregate and never talked to each other.

Why “saving money” with Basic often costs more

Choosing Basic to save roughly $22 CAD per user each month is a real saving only if you never need the controls it omits. The moment you do (whether to satisfy a cyber-insurance application, pass a client security questionnaire, or simply recover from an incident) the gap shows up as a larger, unbudgeted cost.

Cyber-insurance underwriters increasingly require MFA, endpoint detection and response, and managed device controls before they will issue or renew a policy. On Business Basic you do not have native EDR or Conditional Access, which can mean higher premiums, coverage exclusions, or a declined application. The downgrade decision can quietly become an uninsurable-risk decision.

The math also runs the other way. The IBM Cost of a Data Breach Report 2024 put the global average breach cost at USD 4.88 million, and while a small business will not see that figure, even a contained incident routinely runs into tens of thousands of dollars in downtime, remediation, and lost trust. Against that, the Premium premium for a 25-person company is roughly $550 CAD a month. The security stack pays for itself the first time it prevents a single serious incident.

Which Microsoft 365 plan does your business actually need?

Match the plan to your risk and your workforce, not to the lowest line item. Use this decision sequence:

Do you handle client, financial, or health data? If yes, go to Premium. PIPEDA and PHIPA obligations effectively require the data protection, access controls, and audit capabilities that only Premium bundles natively.

Do you carry, or want, cyber insurance? If yes, go to Premium. Underwriters expect MFA, EDR, and managed devices, and Premium delivers all three out of the box.

Do staff need full desktop Office apps? If yes but you have no elevated security need, Business Standard is the honest middle. If no, Basic can cover browser-only users.

Are you browser-only, low-risk, and pre-revenue? Basic is defensible as a starting point, with a documented plan to move to Premium before you scale or take on sensitive data.

You do not have to standardize on one plan. Microsoft 365 lets you mix licences in the same tenant, so put frontline or browser-only staff on Basic and your knowledge workers and anyone handling sensitive data on Premium. Just make sure the Premium security policies (Conditional Access, Intune enrollment) are scoped to cover the accounts and devices that matter most.

Business Basic and Business Premium are not two sizes of the same thing. Basic is a productivity suite; Premium is a productivity suite with an integrated security platform attached. If your business has data worth protecting or insurance to qualify for, the question is not whether you can afford Premium. It is whether you can afford to skip it.

Picking the licence is the easy part. The value of Business Premium only shows up when the security stack is actually configured: Conditional Access policies written, Intune enrollment enforced, Defender tuned, and DLP rules mapped to your compliance obligations. That is where most SMBs leave the protection they paid for sitting switched off. We help GTA mid-market companies choose the right Microsoft 365 mix and stand up the security controls properly. If you want a second opinion on your current setup, our Microsoft 365 management team can walk through it with you.

Frequently asked questions

Is Microsoft 365 Business Premium worth it over Basic?

For any business that handles client data, carries cyber insurance, or runs company-managed devices, yes. Premium bundles endpoint detection, Conditional Access, device management, and advanced email security that Basic omits entirely. If you were going to buy those controls separately, Premium is almost always cheaper than the sum of the parts.

What is the main difference between Business Basic and Business Premium?

Two things: desktop apps and security. Basic gives you web and mobile Office apps with no security stack. Premium adds the installed desktop apps plus Microsoft Defender for Business, Defender for Office 365, Entra ID P1, Intune, and data-loss prevention. The security layer is the larger and more important difference.

Can I mix Business Basic and Business Premium licences?

Yes. Within a single Microsoft 365 tenant you can assign different plans to different users. Many businesses put browser-only or frontline staff on Basic and put knowledge workers and anyone handling sensitive data on Premium. Just confirm your security policies are scoped to cover the right accounts and devices.

Does Business Basic include any security features?

Basic includes standard built-in spam and malware filtering for Exchange Online and basic multi-factor authentication, but it does not include endpoint detection and response, Conditional Access, managed device controls, or advanced anti-phishing. Those require Business Premium or add-on licensing.

Sources