Skip to content
Office: (416) 621-6611
Emergency: (855) 561-4675
Start Screen Share Submit Support Ticket

Author: Artemy

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

Microsoft 365 DLP Policy Setup: What IT Teams Get Wrong

Posted on by Artemy

You built the DLP policy. The compliance checkbox is checked. Three months later, sensitive data walks out the door anyway. This is not a hypothetical: it is the most common outcome for Microsoft 365 DLP deployments that were done right on paper but wrong in practice.

This post covers the five mistakes that consistently undermine Microsoft Purview DLP deployments in mid-market organizations, what the enforcement limits actually look like, and what a properly structured DLP policy set should include.

Microsoft Purview DLP is not one system; it is four separate enforcement engines that do not share policy scope. Most IT teams configure one engine and assume they are covered. The result is a policy that looks complete in the portal and does nothing for Teams chats, endpoint devices, or SharePoint files uploaded in bulk.

DLP Policy (Microsoft Purview)

A DLP policy in Microsoft Purview is a rule set that detects and acts on sensitive information across Microsoft 365 services. Each policy defines which services to monitor (Exchange, SharePoint, OneDrive, Teams, or endpoint devices), which sensitive information types to detect, and what action to take when a match occurs: audit, warn, block, or notify. Policies are configured in the Microsoft Purview compliance portal and enforced separately by each service’s native engine.

Mistake 1: Treating Microsoft Purview DLP as a Single System

The most damaging architectural misunderstanding in DLP deployments is treating “Microsoft Purview DLP” as a unified enforcement layer. It is not. When you create a policy in the Purview compliance portal, you are writing instructions that will be interpreted separately by up to four different enforcement engines: Exchange Online, SharePoint and OneDrive, Microsoft Teams, and Windows endpoint devices.

Each engine has its own enforcement model, its own latency, and its own limitations. A policy scoped to Exchange will not protect Teams messages, even if the content is identical. A policy covering SharePoint document libraries will not catch a file being copied to a USB drive. These are not bugs; they are the architecture. The problem is that the Purview portal makes it easy to scope a policy to “all locations” with a single toggle, but what that actually enforces in each context requires reading the DLP policy reference documentation carefully.

Warning:

Selecting “All locations” when creating a DLP policy does not mean all enforcement engines are active. Endpoint DLP requires devices to be onboarded to Microsoft Purview separately. If your Windows endpoints are not onboarded, endpoint rules in your policy are silently ignored with no error or alert.

In our work with mid-market GTA organizations, this is the single most common gap we find when reviewing existing DLP configurations: a well-written Exchange policy that was never extended to Teams or SharePoint, because the team assumed one policy covered everything.

Mistake 2: Not Knowing Your Licensing Ceiling Before You Design

Microsoft Purview DLP capabilities are split across licence tiers in ways that are not obvious until you try to enable a feature. Teams message DLP, endpoint DLP, and Adaptive Protection (which dynamically tightens controls based on insider risk signals) all require licences beyond what most mid-market organizations already have.

FeatureM365 Business PremiumM365 E3M365 E5 / E5 Compliance
Exchange DLPYesYesYes
SharePoint / OneDrive DLPYesYesYes
Teams message DLPNoNoYes
Endpoint DLP (Windows)NoNoYes
Endpoint DLP (macOS)NoNoYes (limited activities)
Adaptive ProtectionNoNoYes
Exact Data Match (EDM)NoNoYes

If your organization is on M365 Business Premium or E3, Teams DLP and endpoint DLP are not available without adding the Microsoft 365 E5 Compliance add-on. Knowing this before you build your DLP program means you can scope policies realistically, communicate gaps to leadership, and budget for the correct licence tier if Teams or endpoint coverage is required.

Good to know:

The M365 E5 Compliance add-on can be purchased on top of Business Premium or E3 for specific users who need endpoint or Teams DLP coverage, rather than upgrading your entire tenant. For mid-market organizations with 50 to 200 seats, this is often the most cost-effective path to full coverage.

Mistake 3: Ignoring Policy Priority Order and Conflict Resolution

When multiple DLP policies match the same event, Microsoft Purview applies the most restrictive action from the highest-priority policy. Priority is determined by the order policies appear in the Purview compliance portal: lower number equals higher priority. Most organizations never configure this deliberately. The result is that whichever policy was created first gets the highest priority by default, which is almost never the right outcome.

The practical consequence: if you have a broad informational policy set to audit-only that was created early in your deployment, and a stricter block policy created later, the audit policy will win for any content matching both. Your block rule never fires. This is not visible in normal portal views; you need to check Activity Explorer to see which policy matched and what action was taken.

Use a naming convention that reflects intent and scope from the start: for example, “01-PCI-Block-Exchange,” “02-SIN-Warn-SharePoint,” “03-Confidential-Audit-All.” The numbered prefix makes priority order visible in the portal list without clicking into each policy. Document the intended priority order in a DLP runbook and review it whenever a new policy is added.

Mistake 4: Treating False Positive Management as a Launch Task

Every Purview DLP deployment generates false positives. The volume depends on how broadly your sensitive information types are scoped and how much your organization’s legitimate work involves content that resembles sensitive data. Financial services, legal, and healthcare firms are especially prone to high false positive rates because credit card numbers, Social Insurance Numbers, and health identifiers appear regularly in day-to-day documents.

The mistake is treating false positive resolution as something you do at launch and then move on from. In practice, the alert queue grows continuously. Without a defined review workflow, it becomes a backlog that no one looks at. When the alert queue is ignored, legitimate violations get buried alongside noise, which defeats the purpose of the system entirely.

A workable false positive workflow has three components: a defined owner for the DLP alert queue (usually the IT security lead or a shared security operations function), a weekly triage cadence during the first 90 days of any new policy, and a documented threshold for when a false positive rate triggers a policy tune-up. The DLP Alerts dashboard allows you to classify each alert as a true positive, false positive, or benign — use that classification consistently so you can track your false positive rate over time and demonstrate to leadership that the policy is being actively managed.

Mistake 5: Assuming SharePoint DLP Coverage Is Real-Time

DLP enforcement on SharePoint and OneDrive operates on the search crawler index, not on the file upload event itself. When a file lands in SharePoint, it is not immediately scanned for sensitive content. It is evaluated when the search crawler processes it, which can take anywhere from minutes to several hours depending on crawl queue depth and file volume.

This matters most during bulk data migrations or large file imports. If your organization migrates a file share to SharePoint, thousands of files enter the environment before DLP has had a chance to evaluate any of them. For organizations subject to PIPEDA breach notification obligations, this is a real compliance exposure window, not a theoretical one.

Warning:

If you are planning a SharePoint migration, notify your DLP policy owner before the migration begins. Consider restricting broad access permissions on the destination library during the crawl period and applying sensitivity labels to known-sensitive files before migration to add a secondary control layer while DLP catches up.

What Microsoft Purview DLP Cannot Protect Against

Understanding where enforcement ends is as important as knowing what it covers. These are the gaps no Purview DLP policy can close on its own:

  • Images and screenshots: Purview DLP does not inspect image files or screen captures for sensitive content. A Social Insurance Number or credit card number in a scanned PDF or screenshot is invisible to the policy engine.
  • ZIP and compressed archives: Files inside a ZIP archive are not inspected. Sensitive content inside a compressed file bypasses detection entirely.
  • BYOD and unmanaged personal devices: Endpoint DLP requires Intune management or Purview device onboarding. Personal devices used for work are not covered unless enrolled in device management.
  • Third-party SaaS applications: Purview DLP does not extend to Slack, Google Drive, Salesforce, or any non-Microsoft SaaS tool. Data moving to or from those platforms is outside scope.
  • Camera and verbal disclosure: Someone photographing a screen or reading sensitive data aloud cannot be detected by any DLP system. These insider risk scenarios require procedural controls, not technical ones.

These gaps are not reasons to avoid Purview DLP; they are reasons to layer it with complementary controls including managed detection and response, Purview Insider Risk Management, and Conditional Access policies that restrict where sensitive data can be accessed from.

A Minimum Viable DLP Policy Set for Mid-Market Canadian Organizations

Based on deployments across GTA mid-market clients, this is the minimum policy set that provides meaningful coverage across M365 for organizations on E3 or Business Premium. Organizations on E5 should extend each policy to include endpoint and Teams locations where applicable.

Policy 1: Payment Card Data (PCI): Detect credit card numbers across Exchange, SharePoint, and OneDrive. Action: block external sharing, notify sender and compliance team. Run in audit mode for two weeks before enforcing to assess false positive volume.

Policy 2: Social Insurance Numbers (PII): Detect Canadian Social Insurance Numbers across Exchange, SharePoint, and OneDrive. Action: warn on external send, block bulk sharing above five instances. Include a policy tip that explains acceptable handling procedures.

Policy 3: Health Information (PHIPA): For organizations in or serving healthcare, detect health information types across Exchange and SharePoint. Action: block external sharing, alert the privacy officer. Coordinate with your PHIPA compliance lead before going live.

Policy 4: Confidential Label Enforcement: Block or warn on external sharing of any document carrying a “Confidential” or “Highly Confidential” sensitivity label. This requires Microsoft Purview Information Protection labels to be deployed and adopted first. Without label adoption by users, this policy does nothing.

Policy 5: Endpoint DLP (E5 or Compliance Add-On Required): Restrict copy-to-USB, print-to-unmanaged-printer, and browser upload of files containing sensitive information types from Purview-onboarded Windows devices. Deploy in audit mode first; endpoint DLP generates high false positive volume on initial deployment, especially in environments with legacy document workflows.

48%

Of all data breaches involved ransomware or extortion in 2025, according to the Verizon 2026 Data Breach Investigations Report. Uncontrolled data access and exfiltration paths are a primary enabler — which is exactly what a properly configured DLP program is designed to close.

Run each new policy in audit mode for a minimum of two weeks before enforcing it. Use the Activity Explorer in the Purview compliance portal to review which rules are matching, which users are triggering alerts most often, and whether the match is legitimate or a false positive. A policy that generates hundreds of false positive alerts per week will create alert fatigue and lose stakeholder trust before it ever blocks a real violation.

Microsoft Purview DLP is a powerful control, but it requires deliberate architecture decisions. Know which engines you are actually configuring. Know your licensing ceiling before you design. Set policy priority intentionally. Build a false positive workflow before you go live. Document the enforcement gaps so the business understands what DLP does and does not cover. A policy that looks complete in the portal but was never tested end-to-end provides false confidence, and false confidence in a security control is worse than no control at all.

If you are reviewing your M365 DLP configuration or starting from scratch, the team at Balanced+ works with mid-market GTA organizations on managed cybersecurity services that include Purview DLP design, deployment, and ongoing alert management. A configuration review is often enough to surface the most critical gaps before they become incidents.

Frequently Asked Questions

What is a DLP policy in Microsoft 365?

A DLP policy in Microsoft 365 is a rule set configured in the Microsoft Purview compliance portal that detects sensitive information (such as credit card numbers, Social Insurance Numbers, or health data) across M365 services and takes automated action when a match is found. Actions can include auditing the event, displaying a policy tip to the user, blocking the action, or alerting a compliance administrator. Each policy applies separately to the enforcement engine of each selected service location.

Does one DLP policy cover Exchange, Teams, and SharePoint at the same time?

A policy can be scoped to multiple locations, but each location is enforced by a separate engine with its own behaviour and limitations. Teams DLP requires an E5 or E5 Compliance licence; without it, Teams is not covered even if selected in the policy scope. SharePoint enforcement is based on the search crawler index rather than real-time file events. Exchange enforcement is near-real-time. Each location should be verified independently to confirm enforcement is actually active.

How long does it take for a new DLP policy to take effect?

According to Microsoft’s DLP documentation, policies generally take effect about an hour after being turned on. SharePoint and OneDrive enforcement depends on the search crawler, which may add additional lag. Do not test enforcement immediately after creating a policy; allow at least an hour before concluding that a rule is not working.

What is the difference between audit mode and enforce mode in Purview DLP?

In audit mode, Purview DLP logs all policy matches and generates alerts but does not take any action on the content or notify users. This is the recommended starting point for any new policy, as it lets you assess match volume, identify false positives, and tune rules before any user-facing disruption occurs. Enforce mode takes the configured action (such as blocking a send or displaying a policy tip). Moving from audit to enforce should happen only after at least two weeks of alert review and active tuning.

Sources

How AI Agents Automate Business Operations

Posted on by Artemy

Your operations team spent 12 hours last week copying data between spreadsheets. Your IT staff manually checked 40 web pages for uptime. Someone on your marketing team filled out the same test form six times to verify it worked after a plugin update. None of this required human judgment. It just required a human’s time.

That’s changing. AI agents (not chatbots, not basic automations) are now capable of navigating websites, filling out forms, extracting data, and completing multi-step workflows without human intervention. And for mid-market businesses running lean teams, this isn’t a future trend. It’s a competitive advantage available right now.

AI agents aren’t chatbots that answer questions. They’re autonomous tools that take action. They navigate websites, interact with applications, extract data, and complete multi-step business workflows. The difference between a chatbot and an AI agent is the difference between someone who gives you directions and someone who drives you there.

What Are AI Agents (And Why Should You Care Now?)

The term “AI” gets thrown around loosely, so let’s be specific about what we mean when we talk about AI agents in a business context.

AI Agent

A software system powered by a large language model (LLM) that can autonomously plan and execute multi-step tasks. Unlike a chatbot, which only responds to prompts, an AI agent can browse websites, interact with applications, make decisions based on what it finds, and complete workflows from start to finish without human input at each step.

The key word is autonomously. A chatbot waits for your question. An AI agent takes your goal (“check our website for broken links every morning” or “fill out this vendor application form with our company details”) and figures out how to accomplish it.

What makes this possible today is a new category of capability that lets AI agents interact with the real world:

Model Context Protocol (MCP)

An open standard developed by Anthropic that lets AI agents connect to external tools and data sources through a universal interface. MCP servers act as bridges between the AI and real-world systems like web browsers, databases, APIs, file systems, and business applications. Think of MCP as a USB port for AI: instead of building a custom integration for every tool, any MCP-compatible agent can plug into any MCP server and immediately gain new capabilities.

This is the architecture that makes AI agents practical for business. Rather than needing a developer to build custom integrations for every workflow, your team can connect pre-built MCP servers that handle web browsing, database queries, file management, and more. The agent handles the reasoning. The MCP servers handle the doing.

The Tools Behind It: Playwright and Claude Code

Every screenshot in this article was captured by an AI agent browsing a live website in real time. The tool that makes this possible is Playwright, an open-source browser automation framework built by Microsoft. Playwright can control Chromium, Firefox, and WebKit browsers programmatically, navigating pages, clicking buttons, filling forms, and taking screenshots just like a human user would.

What makes Playwright especially powerful for AI agents is the Playwright MCP server. This server wraps Playwright’s capabilities into the Model Context Protocol, so any MCP-compatible AI agent (like Anthropic’s Claude) can control a web browser through natural language instructions. The agent says “navigate to this URL and fill out the contact form,” and the Playwright MCP server translates that into real browser actions.

If you’re using Claude Code (Anthropic’s command-line AI development tool), you can add the Playwright MCP server in under a minute:

That single command gives Claude the ability to open a browser, navigate to any URL, read page content, interact with elements, fill out forms, and capture screenshots. No additional configuration required. Once installed, you can ask Claude to do things like “go to our website and check if the contact form works” and it will open a real browser, run through the workflow, and report back with screenshots of what it found.

This is the same setup we used to generate every demonstration in this article. The form-filling screenshots, the site monitoring captures, the page analysis examples: all produced by Claude controlling a Playwright browser through MCP, running against a live production website.

Playwright MCP is just one of hundreds of available MCP servers. Others connect AI agents to Google Drive, Slack, databases, GitHub, CRM platforms, and more. The MCP ecosystem is growing fast, and each new server expands what your AI agent can do without any custom development.

5 Ways AI Agents Save Your Team Time Every Week

Here’s where this gets practical. These aren’t hypothetical use cases. They’re workflows that businesses are automating with AI agents today.

1. Automated Website Monitoring

An AI agent can navigate your entire website on a schedule, checking that pages load correctly, forms function, SSL certificates are valid, and content hasn’t been tampered with. Unlike basic uptime monitors that only check if a server responds, an AI agent actually sees the page the way a visitor would.

Screenshot of an AI agent automatically monitoring the BALANCED+ homepage for uptime and content changes
An AI agent navigating to a business website to verify the homepage loads correctly, checking navigation elements, hero content, and page structure, all without human intervention.

If something is wrong (a broken image, a missing phone number, a form that throws an error) the agent flags it immediately. No more finding out about broken pages from a customer complaint.

2. Competitive Intelligence on Autopilot

Want to know when a competitor updates their pricing page, launches a new service, or publishes a blog post targeting your keywords? An AI agent can monitor competitor websites daily, extract the relevant changes, and deliver a summary to your inbox every morning.

Screenshot of an AI agent automatically scanning a company blog page to gather competitive intelligence and content insights
An AI agent scanning a blog index page. It can read headlines, categorize content topics, and track publishing frequency across multiple competitor sites automatically.

This used to require a junior analyst spending hours clicking through competitor sites. Now it runs in the background while your team focuses on acting on the insights instead of gathering them.

3. Automated Form Testing

Every time you update a WordPress plugin, change a form field, or modify your contact page, there’s a risk that something breaks. AI agents can automatically test your forms by navigating to the page, filling in every field with realistic test data, submitting, and verifying the confirmation message appears.

Screenshot showing an AI agent that has automatically filled in all fields of a contact form including name, email, company, service type, and message
A real demonstration: an AI agent navigated to a contact form, identified all input fields, selected the appropriate service category from a dropdown, and composed a realistic message, in seconds.

Run this after every deployment and you’ll catch broken forms before your prospects do. That’s leads you’d otherwise lose without ever knowing it.

15-25 hrs/week

Time mid-market teams typically spend on manual web tasks that AI agents can automate, including monitoring, data collection, form testing, and report generation. (Internal benchmarks across 50+ managed accounts)

4. Data Collection and Reporting

Need to pull pricing data from vendor portals every week? Aggregate job postings across multiple boards? Collect product specifications from supplier websites? AI agents handle repetitive data collection tasks that would otherwise eat hours of your team’s week.

The agent navigates to each source, extracts the data you’ve specified, normalizes it into a consistent format, and delivers it to a spreadsheet, database, or dashboard. When a source changes its layout (something that would break a traditional scraper) the AI agent adapts because it understands the page structure, not just the HTML.

5. Employee Onboarding Workflows

Onboarding a new employee involves creating accounts across multiple platforms: email, project management, HR systems, security training, VPN access. An AI agent can work through an onboarding checklist, navigating to each platform, creating accounts with the correct permissions, and logging what was completed.

This reduces onboarding from a half-day IT task to a supervised 30-minute process, with a complete audit trail of exactly what was provisioned and when.

Start with one workflow. Pick the most repetitive, lowest-risk task your team does every week (website monitoring or form testing are great candidates) and automate that first. Once you see the time savings and reliability improvements, you’ll quickly identify the next five workflows to hand off to an AI agent.

What This Looks Like in Practice

To make this concrete, here’s exactly what happens when an AI agent automates a form testing workflow, one of the most common use cases we see with our managed IT clients.

Step 1: The agent receives its instructions. You define the task once: “Navigate to our contact page, fill out the form with test data, submit it, and verify the confirmation message appears. Run this every morning at 7 AM and alert me if anything fails.” The agent stores these instructions and executes them on schedule.

Step 2: The agent navigates to the page. Using the Playwright MCP server, the agent opens a real Chromium browser, navigates to your contact page, and waits for it to fully load, just like a real visitor would.

Step 3: The agent reads the page and identifies the form. Rather than relying on hardcoded selectors that break when your page changes, the AI agent understands the page structure. It identifies the form fields by their labels (First Name, Last Name, Email, Message) and knows what type of data each expects.

Step 4: The agent fills and submits the form. Each field gets populated with realistic test data. Dropdowns are selected, text areas are filled with appropriate content, and the submit button is clicked. The agent then waits for the page response.

Step 5: The agent verifies the result and reports back. Did a confirmation message appear? Did the page throw an error? Did the form redirect to a thank-you page? The agent checks for the expected outcome and sends a pass/fail report. If something broke, you know about it before your first prospect of the day hits that form.

Here’s what the agent actually sees at each stage. These are real screenshots captured by an AI agent during a live demonstration:

Screenshot of an AI agent navigating to the BALANCED+ contact page to begin automated form testing
Step 2 in action: the AI agent has navigated to the contact page and is ready to identify and interact with the form fields.
Screenshot of an AI agent navigating and analyzing a Managed IT Services webpage for content and structure
The same agent can navigate to any page on the site. Here it’s analyzing a services page, reading the content structure, checking for missing elements, and verifying that all links resolve correctly.

How AI Agents Compare to Traditional Automation

If you’ve used scripts, macros, or tools like Zapier before, you might be wondering what’s different here. The short answer: AI agents handle complexity and change in ways that traditional automation can’t.

Scripts & MacrosAI Agents
SetupRequires a developer to write and test custom codeDescribe what you want in plain language
MaintenanceBreaks when the target website or application changes its layoutAdapts automatically by understanding page structure, not just HTML selectors
FlexibilityDoes exactly one thing; any variation requires new codeHandles variations and edge cases by reasoning about the task
CostLow per-script, but developer time for each new automation adds upHigher per-task compute cost, but dramatically lower setup and maintenance time
Learning curveRequires programming knowledge (Python, JavaScript, etc.)Natural language instructions allow your operations team to define workflows
Error handlingFails silently or crashes when encountering unexpected statesRecognizes errors, attempts recovery, and reports what went wrong in plain language

Traditional automation still has its place. For high-volume, unchanging tasks, a well-written script is faster and cheaper per execution. But for the kind of varied, web-based workflows that mid-market operations teams deal with daily, AI agents are a step change in what’s possible without a dedicated development team.

What to Consider Before You Start

Warning:

AI agents are powerful, but they need guardrails. Before deploying any AI automation in your business, make sure you have these fundamentals in place: Start small and automate one low-risk workflow first, then validate the results before scaling. Define clear boundaries by specifying exactly what the agent should and shouldn’t do, especially around sensitive data and customer-facing interactions. Maintain human oversight because AI agents should report to humans, not replace human judgment on decisions that matter. Ensure security controls so that any tool interacting with your systems has proper access controls, credential management, and audit logging.

The biggest mistake businesses make with AI automation is trying to automate everything at once. The teams that get the most value start with a focused pilot, measure the results, and expand methodically.

You should also consider data privacy. AI agents that browse the web and interact with applications are processing data. Make sure your implementation complies with your organization’s data handling policies and any applicable regulations (PIPEDA in Canada, GDPR for European clients, etc.).

The Bottom Line

AI agents represent a genuine shift in what small and mid-market teams can accomplish without growing headcount. The manual web tasks that eat 15 to 25 hours of your team’s week (monitoring, testing, data collection, reporting) can run autonomously with better accuracy and complete audit trails. The technology is here now, the ROI is measurable, and the barrier to entry is lower than most businesses expect. The question isn’t whether AI agents will change how your team works. It’s whether you’ll be the one setting the pace or playing catch-up.

Ready to explore how AI-powered automation could work for your business? Our team helps mid-market companies identify the right workflows to automate and implement the tools to make it happen, securely and strategically.

Book a consultation to discuss your automation opportunities, or learn more about our managed IT services that keep the foundation running while you innovate.

FortiOS 8.0 Is Here: Everything Announced at Fortinet Accelerate 2026

Posted on by Artemy

The BALANCED+ team is on the ground at Fortinet Accelerate 2026 in Las Vegas this week, and the headline announcement is a big one: FortiOS 8.0 is here. This is the most significant platform update Fortinet has shipped in years, and it changes how organizations should think about network security, AI-driven threat protection, and quantum readiness.

Here’s what matters for mid-market IT leaders and security teams.

FortiOS 8.0: One Platform, Not Twelve Tools

The core message behind FortiOS 8.0 is consolidation. Fortinet has rebuilt the operating system to bridge advanced networking with AI-driven security natively, no bolt-on integrations, no stitching together separate products.

FortiOS 8.0

Fortinet’s natively integrated operating system that unifies networking and security into a single platform. It consolidates endpoint protection, zero-trust access, threat detection, and network management under one OS, replacing fragmented legacy tool stacks.

The consolidation breaks down into three pillars:

One Unified Agent (FortiClient): Integrates endpoint protection (EPP), zero-trust network access (ZTNA), and endpoint detection and response (EDR) into a single agent. It now supports post-quantum cryptography for VPNs, adaptive ZTNA posture visibility, and AI application control.

One Management Tool (FortiManager): Centralized control across campus, branch, and cloud environments. FortiAI-Assist is now built in, using generative AI to simplify network management and reduce human error.

One Data Lake (FortiAnalyzer): Upgraded with a unified XDR dashboard for instant risk assessment across network, endpoint, and identity domains. SOC monitoring moves to machine-speed response.

AI Built Into the Core, Not Layered on Top

Fortinet has embedded what they call “Native AI” directly inline within FortiOS 8.0. This isn’t a chatbot slapped onto a dashboard, it’s machine learning running inside the inspection engine to stop zero-day and AI-powered attacks at wire speed without adding latency.

Good to know:

FortiOS 8.0 introduces three distinct AI engines: FortiAI-SecureAI for securing AI workloads, FortiAI-Protect for inline threat prevention, and FortiAI-Assist for guided configuration and troubleshooting, each purpose-built for a different security function.

The practical impact for security teams:

  • AI-powered IPS for DNS, catches malicious DNS queries that signature-based systems miss
  • Application-to-application (A2A) detection, visibility into machine-to-machine API traffic
  • GenAI usage controls, deep visibility and governance over how employees use tools like ChatGPT, Copilot, and other AI services
  • FortiAI-Assist for FortiGate, AI-driven tooltips, guided suggestions, and debugging assistance that help close the security skills gap

The GenAI governance capabilities in FortiOS 8.0 are a direct answer to one of the biggest shadow IT risks in 2026. If your organization hasn’t established policies for AI tool usage, this update gives you enforcement at the network level, not just a written policy that nobody follows.

Post-Quantum Cryptography: Preparing for Tomorrow’s Threats Today

This is the part that should get every CISO’s attention. Fortinet is building post-quantum cryptography (PQC) and Quantum Key Distribution (QKD) directly into FortiOS 8.0, not as an add-on license or future roadmap item.

Warning:

The “harvest-now, decrypt-later” threat is real. Adversaries are already capturing encrypted traffic today with the expectation that quantum computers will crack it within the next decade. If your VPN tunnels or data transfers carry sensitive information, the window to act is now, not when quantum computing matures.

What FortiOS 8.0 delivers on the quantum front:

  • Support for NIST-approved PQC algorithms (FIPS 204 and FIPS 205)
  • Full SSL/TLS deep inspection with quantum-safe encryption
  • Quantum-resilient management access and agentless VPNs
  • Minimal performance impact, critical for production environments

FIPS 204 & 205

NIST-approved post-quantum cryptography standards now supported natively in FortiOS 8.0

Next-Gen Security Operations: FortiSOC Gets Agentic AI

Fortinet’s SOC platform, spanning SIEM, SOAR, and XDR, now leverages what they call “Agentic AI.” These are embedded AI agents within FortiAnalyzer that autonomously handle alert triage, root-cause investigation, and response orchestration.

Agentic AI

AI systems that operate autonomously to complete multi-step tasks without constant human direction. In the context of FortiSOC, agentic AI conducts initial alert triage, investigates root causes, and recommends or executes response actions, reducing the volume of work that requires a human analyst.

For organizations already running SOC operations (in-house or outsourced), this translates to:

  • Faster mean time to detect (MTTD) and mean time to respond (MTTR)
  • Reduced analyst fatigue from alert noise
  • Identity-driven detections that catch credential-based attacks earlier in the kill chain

Unified SASE and the All-in-One Bundle

Fortinet continues to push the convergence of networking and security with some significant packaging and architecture changes:

All-in-One Services Bundle: Consolidates 5 SKUs and premium care into a single SKU. Organizations can extend SD-WAN to full SASE at roughly 40% of the FortiGate model cost, a significant reduction in licensing complexity.

Sovereign SASE: Rolling out in 2025–2026, this gives organizations the flexibility to run SASE with data sovereignty controls, critical for Canadian organizations subject to PIPEDA and provincial privacy regulations.

FortiASIC SP5: Fortinet’s proprietary ASICs now support up to 14 different applications simultaneously, including 5G, VXLAN, OT, and Zero Trust workloads, delivering hardware-accelerated performance where software alone can’t keep up.

40%

Cost reduction when extending SD-WAN to full SASE using the new All-in-One Services Bundle vs. individual FortiGate licensing

Data Loss Prevention Gets Serious Upgrades

Data governance is no longer a nice-to-have. FortiOS 8.0 significantly expands its DLP and content inspection capabilities:

  • OCR-powered inspection via FortiGuard DLP, catches sensitive data embedded in images and scanned documents
  • Image classification through URL filtering, blocks visual content that text-based filters miss
  • FortiData Labels aligned with Microsoft Information Protection (MIP), consistent data classification across apps and environments

The MIP alignment is particularly relevant for organizations running Microsoft 365. If you’ve already invested in Microsoft’s data classification labels, FortiOS 8.0 can now enforce those same labels at the network perimeter, creating a unified governance model from endpoint to firewall.

OT Security Extends to the Industrial Edge

For organizations with operational technology environments, manufacturing floors, utilities, critical infrastructure, FortiOS 8.0 extends advanced security controls directly to the industrial edge:

  • Virtual IP (VIP) support for encrypted communications to OT servers
  • Strong segmentation between IT and OT networks
  • Enhanced IPsec connectivity for remote OT sites
  • Compliance and audit readiness for NERC CIP and IEC 62443 standards

What This Means for Your Organization

FortiOS 8.0 isn’t an incremental update, it’s a platform shift. The consolidation of endpoint, network, and cloud security under one OS eliminates the integration tax that mid-market businesses have been paying for years. The native AI capabilities move threat detection from human-speed to machine-speed. And the post-quantum readiness gives organizations a concrete path to protect data against future decryption threats.

As an authorized Fortinet partner, the BALANCED+ team is at Accelerate 2026 getting hands-on with FortiOS 8.0 and evaluating how these capabilities translate to real-world deployments for our clients. If you’re running Fortinet infrastructure, or considering it, this is the right time to have a conversation about your upgrade path.

Talk to BALANCED+ about your FortiOS 8.0 upgrade path →

.NET EF Identity Resolution, the Hard Way

Posted on by Artemy

Why do two seemingly identical database queries return different values? That’s the question that kicked off an hours-long debugging session, one that revealed a subtle but dangerous interaction between .NET Entity Framework’s Identity Resolution and improper DbContext management.

Entity Framework Core tracks every entity it loads by primary key. If a helper class creates its own DbContext instead of sharing one through Dependency Injection, the two contexts maintain separate identity caches. Changes made in one are invisible to the other, leading to silent data resets that are incredibly hard to trace.

The Problem

The scenario was straightforward on the surface. An API endpoint increments and saves a “Counter” property on a Parts entity mid-execution. The database reflects the correct value after the save. But by the time the endpoint finishes, the Counter resets to its original value, as if the increment never happened.

The culprit line? A completely unrelated save operation on the same entity, updating different fields. Somehow, saving unrelated properties was overwriting the Counter with a stale value. The Counter wasn’t being touched anywhere else in the code, so where was the old value coming from?

C# PartService.cs 
// These two lines return DIFFERENT Counter values
// even though they query the same row at the same time:

var counter1 = dbContext.Parts.Find(partId).Counter;
// Returns: 5 (stale, from identity cache)

var counter2 = dbContext.Parts
    .AsNoTracking()
    .First(p => p.Id == partId).Counter;
// Returns: 6 (correct, fresh from database)

The Debugging Journey

Tracking this down required a methodical approach. Each step peeled back another layer of the problem, and each result added to the confusion before the full picture emerged.

Pinpoint the Reset

By commenting out lines one at a time, the exact statement that resets the Counter was identified: an SaveChanges() call that updates completely unrelated fields on the same entity. The Counter value in the database is correct before this line runs, and wrong after.

Inspect the In-Memory Object

Logging the part instance’s Counter value showed it was already stale, holding the original value, not the incremented one. But the increment and save had already succeeded. Where was this stale copy coming from?

Query a Fresh Copy

Selecting another copy of the same row from the database using a standard LINQ query also returned the wrong Counter value, even though the database showed the correct value at that exact moment. Two queries, same row, both stale.

Bypass the Cache

As a final test, querying the Counter value with AsNoTracking(), which skips EF’s caching layer entirely, returned the correct value. This confirmed the problem wasn’t in the database. It was in EF’s own tracking system.

The Root Cause

The answer comes down to two concepts colliding: Entity Framework’s Identity Resolution and the way the DbContext was being managed in this codebase.

Identity Resolution (EF Core)

When Entity Framework returns an entity from the database, it tracks that instance by its primary key. Any subsequent query for the same entity returns the already-tracked instance from memory rather than hitting the database again. This improves performance and reduces memory usage, but it means in-memory values can drift from what’s actually in the database.

Identity Resolution on its own isn’t enough to cause this bug. The real issue was how the codebase managed its DbContext instances.

Warning:

The API endpoint’s logic was split between a parent controller and a helper class. Instead of receiving the DbContext through Dependency Injection (or even as a constructor argument), the helper class instantiated its own new AppDbContext(). This created two completely separate tracking contexts, each with its own Identity Resolution cache, oblivious to changes made by the other.

Here’s what happened step by step: The parent controller incremented the Counter and saved it through its DbContext, the database now holds the correct value. Then the helper class, using its own separate DbContext, queried the same entity. Its Identity Resolution cache still held the original, pre-increment value. When the helper saved its unrelated changes, it overwrote the Counter with the stale cached value.

2

separate DbContext instances were active in the same API request, each maintaining its own identity cache, silently fighting over the same data.

The Fix

Always use Dependency Injection for your DbContext. Never instantiate new DbContext() inside helper classes, services, or utility methods. One HTTP request should use one DbContext instance, giving every component the same source of truth and the same Identity Resolution cache.

The fix was simple once the root cause was clear. Instead of the helper class creating its own DbContext, the existing context is passed through the constructor:

C# PartHelper.cs 
// BEFORE: helper creates its own context (broken)
public class PartHelper
{
    private readonly AppDbContext _db = new AppDbContext();
    // This context has NO knowledge of changes
    // made by the parent controller's context
}

// AFTER: context is injected (correct)
public class PartHelper
{
    private readonly AppDbContext _db;
    public PartHelper(AppDbContext db) => _db = db;
    // Now shares the same tracking cache as the parent
}

With a single shared DbContext, both the parent controller and the helper class read from and write to the same Identity Resolution cache. The Counter increment is visible everywhere, and no save operation can silently overwrite it with a stale value.

The Takeaway

Going back to the original mystery, those two “identical” queries that returned different values, the explanation is now clear. The first query (Find()) consults the Identity Resolution cache and returns the tracked instance with its stale Counter value. The second query (AsNoTracking()) bypasses the cache entirely and fetches the real, current value from the database.

This kind of bug is particularly dangerous because it’s silent. No exceptions are thrown. No logs indicate a problem. The data just quietly reverts, and everything looks normal until someone notices the numbers don’t add up.

Tip:

Quick reference: dbContext.Entity.Find(id) returns the tracked, potentially stale instance from the Identity Resolution cache. dbContext.Entity.AsNoTracking().First(...) always fetches fresh data from the database. When debugging unexpected values, AsNoTracking() is your fastest way to check if Identity Resolution is the culprit.

The process to find the solution was far more complex than the solution itself, but that’s often how it goes with framework-level bugs. Understanding Identity Resolution isn’t just useful for debugging; it’s essential knowledge for building reliable .NET applications that don’t silently corrupt their own data.

What Is SAMI? And How Does it Benefit Your Business?

Posted on by Artemy

You’ve invested in a firewall. You’ve got endpoint protection. Maybe you’ve even run a penetration test in the last year or two. On paper, it looks like you’re covered.

But here’s the question most business owners and IT managers don’t ask often enough: how much of your security is based on what already happened versus what’s happening right now?

Most cybersecurity tools are designed to detect and respond. Something triggers an alert, someone investigates, and the team reacts. That model worked when threats moved slowly and attackers followed predictable patterns. That’s not the world we’re operating in anymore. Attacks are faster, more automated, and increasingly targeting the gaps between your tools rather than the tools themselves.

The businesses that are getting ahead of this aren’t necessarily spending more. They’re shifting from a reactive model to a continuous one. That’s where Continuous Threat Exposure Management comes in, and it’s why platforms like SAMI are gaining serious traction.

Why Reactive Cybersecurity Isn’t Enough Anymore

The traditional approach to cybersecurity follows a familiar cycle. You deploy tools, configure them, and wait. When something goes wrong, you respond. Between incidents, you might run a quarterly vulnerability scan or an annual penetration test to check for gaps.

The problem is what happens in between those checkpoints.

Threat actors aren’t waiting for your next scheduled audit. They’re probing your environment continuously, looking for misconfigurations, unpatched systems, exposed credentials, and gaps between your security layers. A vulnerability that didn’t exist on Monday can be actively exploited by Wednesday.

For businesses without a dedicated 24/7 security operations center or a large internal security team, that window between discovery and response is where the real damage happens. Ransomware doesn’t wait for your IT person to get back from lunch. A compromised credential doesn’t pause while your security vendor schedules a review.

The reactive model creates a dangerous illusion. You feel protected because you have tools in place. But those tools are only as effective as the moment they were last validated. And for most businesses, that moment was weeks or months ago.

What Is Continuous Threat Exposure Management (CTEM)?

Continuous Threat Exposure Management is a fundamentally different approach to cybersecurity. Instead of periodic assessments and reactive alerting, CTEM continuously identifies, prioritizes, and remediates security risks based on their actual business impact.

Think of it this way. A traditional security model is like getting a physical once a year. CTEM is like wearing a monitor that tracks your vitals in real time and alerts you the moment something needs attention.

With CTEM, your security posture isn’t a snapshot. It’s a live feed. Vulnerabilities are identified as they emerge. Risks are ranked not just by technical severity but by how much damage they could cause to your specific business. Remediation is guided and prioritized so your team isn’t chasing low-impact alerts while critical exposures sit unaddressed.

This matters especially for organizations navigating compliance requirements like SOC2, ISO 27001, or PIPEDA. Auditors increasingly want to see that security isn’t just a point-in-time exercise but a continuous, demonstrable practice. CTEM gives you that evidence.

It also addresses a frustration many business leaders share: spending money on security without ever feeling confident it’s actually working. CTEM closes that gap by providing measurable, ongoing validation rather than assumptions.

What Is SAMI?

SAMI, which stands for Security Assisted by Machine Intelligence, is Autnhive’s cloud-based, AI-driven CTEM platform. It’s designed to help organizations move from reactive security to continuous, proactive threat management across IT, OT, and AI environments.

At a high level, SAMI continuously scans, tests, and validates your security environment. Rather than relying on a single annual pen test or periodic vulnerability scan, SAMI automates and runs these assessments on an ongoing basis, identifying exposures as they appear and prioritizing them based on real business risk.

Key capabilities include:

  • Automated penetration testing and attack simulations that run continuously rather than once a year
  • CIS Benchmarking and endpoint assessments to validate configurations against industry standards
  • Third-party application and risk assessments covering mobile, desktop, and cloud-native environments
  • AI security features including firewall protection for AI systems, assessment of large language models (LLMs), and monitoring of agentic workflows
  • Real-time SOC monitoring with live, firewall-based detection and enforcement

SAMI was developed in Canada and is built to integrate directly into existing security operations and SOC workflows. It’s not a rip-and-replace platform. It layers into what you already have and fills the gaps that periodic tools leave behind.

How SAMI Benefits Your Business

For business owners and IT leaders managing competing priorities with limited resources, the practical benefits of SAMI come down to a few key areas.

Real-time visibility instead of blind spots. Most businesses have gaps between their security tools that they don’t even know about. SAMI provides continuous visibility across your entire environment, so risks don’t sit undetected for weeks or months.

Risk prioritization based on business impact. Not every vulnerability is equal. SAMI ranks exposures based on how much damage they could actually cause to your operations, so your team focuses on what matters most rather than drowning in low-priority alerts.

Compliance and governance support. Whether you’re working toward SOC2, ISO 27001, or navigating PIPEDA requirements, SAMI provides the continuous validation and documentation that auditors and regulators want to see. It also aligns with emerging AI regulations and governance frameworks.

Protection that scales without adding headcount. You don’t need to build an internal SOC or hire a team of security analysts to benefit from CTEM. SAMI automates the testing, monitoring, and prioritization that would otherwise require significant staff investment.

SOC-ready outcomes. SAMI doesn’t just generate reports. It delivers actionable, SOC-integrated results that fit directly into security workflows, reducing the time between identification and remediation.

AI environment protection. As businesses adopt AI tools, LLMs, and automated workflows, SAMI extends security coverage into these environments. This is an area where most traditional security tools have no visibility at all.

Why BALANCED+ Is Bringing SAMI to Canadian Businesses

BALANCED+ has been named a Premier Channel Partner and Value-Added Reseller of the SAMI platform in Canada. This partnership means Canadian businesses get more than just access to the platform. They get the advisory, deployment, and operational expertise to make it work within their existing environment.

BALANCED+ delivers SAMI with hands-on support, helping organizations integrate CTEM into their security operations from day one. That includes deployment planning, configuration, SOC workflow integration, and ongoing operational guidance.

“SAMI delivers exactly what enterprise security leaders are asking for, continuous validation, real-time protection, and SOC-ready outcomes across both infrastructure and AI,” said Kevin Milloy, Director of Sales at BALANCED+. “We’re proud to bring this Canadian-developed platform to customers across Canada.”

For businesses that have been investing in cybersecurity tools but still feel uncertain about their actual level of protection, this partnership is designed to close that gap.

Moving from Reactive to Continuous

The cybersecurity landscape has shifted. Threats are continuous, automated, and increasingly sophisticated. The tools and approaches that worked five years ago were built for a different environment.

Continuous Threat Exposure Management represents the next evolution, not just in technology, but in how businesses think about security. It’s the difference between hoping your defenses hold and knowing, in real time, where you stand.

If you’re evaluating your cybersecurity strategy and wondering whether your current approach gives you the visibility and confidence you need, understanding CTEM is a strong place to start.

Learn More About Continuous Threat Exposure Management Want to explore how CTEM and the SAMI platform could fit into your security strategy? Connect with the BALANCED+ team to learn more about proactive cybersecurity for Canadian businesses.

BALANCED+ Named Premier Channel Partner of Autnhive

Posted on by Artemy

FOR IMMEDIATE RELEASE

Toronto, ON BALANCED+ is pleased to announce that it has been named a Premier Channel Partner and Value-Added Reseller (VAR) of Autnhive’s SAMI platform, a cloud-based, AI-driven Continuous Threat Exposure Management (CTEM) solution, in Canada.

Through this partnership, BALANCED+ will deliver SAMI to enterprise customers seeking to proactively secure their IT, OT, and AI infrastructure with real-time visibility, detection, and enforcement. BALANCED+ will provide customers with access to SAMI alongside advisory, deployment, and operational expertise, helping organizations integrate the platform directly into existing security operations and SOC workflows.

“SAMI delivers exactly what enterprise security leaders are asking for, continuous validation, real-time protection, and SOC-ready outcomes across both infrastructure and AI,” said Kevin Milloy, Director of Sales, BALANCED+. “We’re proud to bring this Canadian-developed platform to customers across Canada as the trusted national leader in cybersecurity solutions.”

As part of this partnership, BALANCED+ will deliver SAMI deployments with IT, OT, and AI cybersecurity modules, continuous threat exposure management, real-time attack prevention through live firewall-based SOC monitoring for AI, and governance and compliance support aligned to security policies and emerging AI regulations.

SAMI (Security Assisted by Machine Intelligence) enables organizations to identify, prioritize, and remediate security risks based on business impact. Its capabilities include CIS Benchmarking, endpoint assessments, automated penetration testing, automated attack simulations, firewall protection for AI systems, and assessment of large language models, agentic workflows, and cloud-native infrastructure.

BALANCED+ is dedicated to helping organizations modernize infrastructure, reduce risk, and adopt emerging technologies with confidence. This partnership reinforces that commitment by expanding the company’s ability to deliver proactive, measurable cybersecurity outcomes at scale.

For more information about BALANCED+ and its cybersecurity services, click here.

Contact Artemy Kirnichansky Phone: +1 (416) 621-6611 Email: Artemy.Kirnichansky@balanced.plus

Protecting Corporate Data on Unmanaged Devices with Intune App Protection

Posted on by Artemy

Your sales rep checks customer emails from her personal iPhone while waiting at the airport. Your contractor downloads project files to his home laptop. Your office manager reviews invoices on her tablet during lunch.

None of these devices belong to you. You didn’t configure them. You don’t manage them. You have no idea what other apps are installed, whether the operating system is current, or if basic security practices are followed. But your customer data, financial records, and confidential business information are sitting on those devices right now.

This is the reality of modern work: remote teams, hybrid schedules, contractors, and the simple expectation that people can work from anywhere. The flexibility is real. So are the risks. The good news is that you can protect corporate data on those devices without taking control of the devices themselves, and the tool most Canadian businesses already own to do it is Microsoft Intune.

The short version: Intune App Protection Policies (also called Mobile Application Management, or MAM) secure corporate data inside individual apps like Outlook, Teams, and OneDrive, without enrolling or managing the whole device. You control the data, not the phone. That is what makes it the right fit for BYOD, personal devices, and contractor access.

Intune App Protection Policies (MAM)

Intune App Protection Policies are rules that protect corporate data inside approved business apps rather than managing the entire device. Also known as Mobile Application Management (MAM), they let you enforce security controls (encryption, PIN, copy/paste limits, selective wipe) on personal or unmanaged devices that are never enrolled in device management.

The problem with devices you don’t control

When employees and contractors access corporate resources from personal devices, you lose visibility into what happens to that data. An employee might copy customer contact lists into a personal note-taking app. Project files could be saved to a personal cloud storage account. Sensitive emails might be forwarded to personal addresses for “convenience.” None of this requires malicious intent. People just work the way that feels natural, and the technology doesn’t enforce any boundaries.

The risks compound quickly:

  • Corporate data gets copied to personal apps and cloud storage you can’t see or control
  • Sensitive information remains on devices long after employees or contractors leave
  • Lost or stolen phones and laptops expose business data to unknown parties
  • IT has no visibility into how corporate information is accessed, shared, or stored

Traditional device management (MDM) doesn’t solve this in personal-device scenarios. You can’t reasonably demand full control over someone’s personal phone. Employees and contractors won’t accept it, and it raises legitimate privacy concerns. Requiring full enrollment usually means people work around the policy instead of complying with it. The answer isn’t managing devices. It’s managing data.

What are Intune App Protection Policies?

Intune App Protection Policies protect corporate data within applications rather than requiring control of the entire device. They apply directly to approved business apps such as Outlook, Microsoft Teams, OneDrive, and the Microsoft 365 apps. Think of it as a secure container inside those apps: when someone opens Outlook on their personal device, corporate data stays inside the protected application, and the security controls apply to the business app, not the whole phone or laptop.

Crucially, App Protection Policies work independent of device enrollment. The device never has to be enrolled in Intune management for the policy to take effect, which is exactly what makes personal and BYOD devices workable. Business data stays in business apps, personal data stays personal, and the device owner’s privacy is respected because you are not touching their photos, personal email, or other apps.

What can Intune App Protection actually control?

When implemented properly, App Protection Policies address the specific risks that personal-device access creates. There are four capability areas that matter most.

1. Data leakage prevention

The foundation is keeping corporate data from leaving approved apps. You can block copy and paste of corporate content into personal apps, restrict “Save As” to approved corporate locations only, and prevent sharing through unmanaged applications. The data simply can’t leave the secure container through normal use.

Tip:

Pair App Protection with Microsoft Purview DLP for defense in depth. Purview adds centralized data classification and sensitivity labels, so you can enforce consistent, sensitivity-based rules across apps, users, and locations, not just inside the app container.

2. App-level security and authentication

App Protection enforces security at the application level, so corporate data stays protected even if the device itself is unlocked or shared. You can require an app-specific PIN or biometric to open business apps, automatically lock apps after a period of inactivity, and block access from rooted or jailbroken devices. Someone who picks up an unlocked phone still can’t get into Outlook or Teams without meeting the app’s own requirements.

3. Identity-based access and Conditional Access

Combined with Microsoft Entra ID, App Protection Policies get stronger through Conditional Access. Access decisions are based on user identity, authentication strength, and sign-in risk, not device ownership alone. You can require multi-factor authentication, allow corporate data to open only in protected apps, and block high-risk or suspicious sign-in attempts. This layered model aligns directly with Zero Trust principles: verify explicitly, and never assume a device is trusted just because it connected.

4. Selective wipe of corporate data

When access should end, you can remove only the corporate data from the protected apps. A selective wipe clears business data from managed apps while leaving personal data, photos, and apps completely untouched. If a contractor’s engagement concludes, an employee leaves, or a device goes missing, you pull the company data and nothing else. This is the single most valuable capability for BYOD and contractor scenarios, because it lets you offboard cleanly without ever owning the device.

Confirm licensing: App Protection Policies are included with Microsoft Intune (part of Microsoft 365 E3/E5 and Business Premium). Most mid-market businesses already own this.

Create the policy: In the Microsoft Intune admin center, go to Apps > App protection policies, then create a policy per platform (iOS/iPadOS, Android, Windows).

Choose the protected apps: Target the Microsoft 365 apps your team actually uses (Outlook, Teams, OneDrive, Word, Excel), where corporate data lives.

Set data-protection and access rules: Block copy/paste and save-to-personal, require a PIN or biometric, set an inactivity timeout, and block jailbroken/rooted devices. Microsoft’s data protection framework offers baseline, enhanced, and high-security presets to start from.

Layer on Conditional Access: Require MFA and app-based Conditional Access so corporate data only opens in protected apps on compliant sign-ins.

Assign, test, and monitor: Assign the policy to user groups, test on a real BYOD device, then track it under Apps > Monitor to confirm it is applying.

MAM vs full device management: which do you need?

App Protection (MAM) and full device management (MDM) are not competitors; they solve different problems. Use MDM for company-owned devices you can fully control. Use MAM App Protection for personal and unmanaged devices where you only need to protect the data.

ConsiderationFull device management (MDM)App Protection (MAM)
Device enrollment requiredYesNo
Best forCompany-owned devicesPersonal / BYOD / contractor devices
Scope of controlEntire deviceCorporate data inside approved apps
User privacyIT sees the whole devicePersonal apps and data stay private
OffboardingFull device wipe or retireSelective wipe of corporate data only
User frictionHigher (often resisted on personal devices)Lower (no enrollment)

Why App Protection is ideal for BYOD and contractors

The personal-device challenge becomes especially acute with contractors, consultants, and temporary workers. They need access to corporate systems to do their jobs, but full device management is rarely practical or appropriate. Contractors often work for multiple clients at once, so enrolling their device in your management system creates conflicts. Temporary workers may only need access for weeks. The overhead of enrollment, and the complications of removing it later, simply don’t make sense.

App Protection Policies provide the middle path. Contractors get the access they need through protected apps, your corporate data stays secured, and when the engagement ends you remove the business data without touching anything else on their device. It also simplifies compliance: when your agreements require protecting client data, you can demonstrate that controls exist regardless of who owns the hardware. The protection travels with the data, not the device.

You will not control the device, and for personal devices that trade-off is the right one. Intune App Protection gives you meaningful, enforceable data security (leak prevention, app authentication, Conditional Access, and selective wipe) while respecting the boundaries of device ownership. Employees use the devices they prefer, contractors work without enrolling personal equipment, and corporate data stays protected throughout.

Getting App Protection right

App Protection Policies are powerful, but the details decide whether they actually protect you. Policies that are too loose leave gaps; policies that are too aggressive frustrate users until they find workarounds. In practice, a handful of misconfigurations show up again and again:

  • Data transfer left open to “All apps” instead of “Policy managed apps,” so corporate data can still flow into personal apps despite the policy being “on.”
  • App Protection deployed without app-based Conditional Access. This is the big one. The policy protects data inside the managed app, but nothing forces users into that app in the first place, so they reach corporate data through the mobile browser or an unmanaged mail client and bypass the whole thing.
  • Browser access left unrestricted. Data opened in Safari or Chrome sits outside the app container. Unless you route it through a managed browser like Edge, mobile web is a common blind spot.
  • Copy and paste left at “Any app” rather than restricted to managed apps, which quietly reopens the leak the policy was meant to close.
  • PIN and timeout settings tuned so aggressively that users hunt for workarounds. Over-tightening undermines a policy as surely as leaving it loose.

Treat App Protection and Conditional Access as a pair, not two separate projects. An App Protection Policy on its own secures data inside the managed app; a Conditional Access rule that requires app protection is what actually forces users into those apps and blocks the unmanaged paths around them. Deploy one without the other and you have a policy that looks complete in the console but leaks in the real world.

The right configuration balances real protection against day-to-day usability, and it should be reviewed as Microsoft adds settings and as your workforce changes.

At BALANCED+ we design and manage these policies as part of our managed cybersecurity and Microsoft 365 management services, tuning App Protection, Conditional Access, and Purview together so corporate data stays secure on every device without slowing your team down. If personal and contractor devices are touching your business data today, that is worth a conversation. Get in touch and we will review your current setup.

Sources

Documentation That Writes Itself: How to Automate Your Technical Knowledge

Posted on by Artemy

Every development team says documentation matters. Few actually keep it current.

Somewhere between sprint planning and production releases, “update the docs” falls to the bottom of the priority list. Again. The result is predictable: tribal knowledge that lives in people’s heads, outdated instructions that mislead more than they help, and hours wasted rediscovering how things work.

The problem isn’t effort or intention. Developers want good documentation. Manual processes just can’t keep pace with modern development cycles.

The solution is treating documentation as an automated output of your engineering process, not a separate task that depends on someone remembering to do it.

The Real Cost of Stale Documentation

Outdated documentation isn’t just annoying. It’s expensive.

Teams lose time onboarding new engineers who follow instructions that no longer apply. Debugging sessions stretch longer because workflow documentation doesn’t match current reality. Architectural decisions get relitigated because nobody documented the reasoning behind them.

Over time, this creates knowledge debt. Institutional understanding that exists only in specific people’s heads. When those people leave, change teams, or go on vacation, the knowledge becomes inaccessible.

You’ve probably seen this pattern: a senior engineer gives notice, and suddenly everyone scrambles to capture what they know before they’re gone. Two weeks isn’t enough to transfer years of accumulated context. Critical information walks out the door.

Living documentation solves this by making documentation a natural byproduct of development, not an afterthought that requires separate effort.

What Living Documentation Actually Means

Living documentation connects directly to your codebase and build pipeline. Instead of existing as a separate artifact that people remember to update (or don’t), it’s generated from the same source as your software.

When your code changes, your documentation updates automatically. API references reflect current endpoints. Configuration guides match actual settings. Dependency information stays accurate.

This approach typically combines three elements:

Code-driven docs generate technical documentation straight from code comments. Tools like PDoc (Python), TypeDoc (TypeScript), and JSDoc (JavaScript) parse your docstrings and produce formatted reference material automatically.

Static site generators transform Markdown files and auto-generated content into searchable, navigable documentation websites. Frameworks like MkDocs and Docusaurus handle the presentation layer.

CI/CD integration ties documentation builds to your deployment pipeline. Every merge to main triggers a documentation rebuild and deploy. No manual steps required.

The result is documentation that can’t fall behind, because it’s part of your development workflow rather than a separate responsibility.

Setting Up Automated Documentation: A Practical Walkthrough

Let’s build a working example using MkDocs, PDoc, and GitHub Actions. This setup transforms code comments and Markdown files into an automatically updating documentation site.

Step 1: Write Meaningful Code Comments

Automated documentation is only as good as the comments it pulls from. The goal isn’t just listing parameters. It’s capturing intent, context, and expected behavior.

Write structured docstrings for functions and API endpoints that explain what the code does and why it matters.

Example (Python):

python

# services/reporting.py

def generate_monthly_summary(customer_id, start_date, end_date):
    """
    Generate and email a monthly financial summary.

    Parameters:
        customer_id (UUID): Identifier for the customer account.
        start_date (Date): Beginning of reporting period.
        end_date (Date): End of reporting period.

    Returns:
        ReportMetadata: Object containing report status, location, and timestamp.

    Raises:
        ReportException: If generation or delivery fails.
    """
    ...

Good docstrings describe what success looks like, what can go wrong, and any non-obvious behavior. They’re useful for humans reading the code directly and become even more valuable when transformed into searchable documentation.

Step 2: Create the Documentation Generation Script

A short automation script ties everything together. This converts structured code comments into HTML or Markdown pages and adds contextual metadata like branch information and build timestamps.

Example (generate_docs.py):

python

# generate_docs.py

import pdoc
import os

# Generate API documentation directly from code
pdoc.pdoc(
    "services",                      # root package
    output_directory="docs/api"      # where to write docs
)

# Optional: auto-create project metadata
with open("docs/environment.md", "w") as f:
    f.write("# Environment Overview\n\n")
    f.write(f"- Deployed branch: {os.getenv('BRANCH', 'main')}\n")
    f.write(f"- Last build: {os.getenv('BUILD_TIME', 'unknown')}\n")

This script generates API documentation from your code comments and creates an environment overview page with deployment context. Customize it based on what information your team needs.

Step 3: Configure MkDocs

MkDocs turns your Markdown files and generated content into a polished documentation site. The configuration file defines your site structure and appearance.

Example (mkdocs.yml):

yaml

# mkdocs.yml

site_name: Enterprise Reporting Platform Docs
nav:
  - Overview: index.md
  - Environment: environment.md
  - API Reference:
    - Reporting Service: api/services/reporting.md
theme:
  name: material

The Material theme provides a clean, searchable interface out of the box. Your navigation structure can be as simple or detailed as your project requires.

Running python generate_docs.py followed by mkdocs serve builds a live documentation site reflecting your current codebase. You can preview changes locally before deploying.

Step 4: Integrate with CI/CD

The final step connects documentation generation to your deployment pipeline. Every push to main automatically rebuilds and deploys your documentation site.

Example (GitHub Actions workflow):

yaml

# .github/workflows/docs.yml

name: Build and Deploy Documentation
on:
  push:
    branches: [ main ]

jobs:
  docs:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.x'
      - run: pip install mkdocs mkdocs-material pdoc
      - run: python generate_docs.py
      - run: mkdocs gh-deploy --force

This workflow installs dependencies, generates documentation from your current code, and deploys to GitHub Pages. Similar configurations work with Azure DevOps, GitLab CI, or any other CI/CD platform.

Once this is in place, documentation updates happen automatically. No reminders, no manual steps, no drift between code and docs.

Why This Matters for Development Teams

For developers, automated documentation means less manual work. Your comments, commit messages, and configuration files become inputs to the documentation pipeline. When you change code, documentation reflects those changes without extra effort.

More importantly, teams can trust that documentation is accurate because it’s built from the same source of truth as the code itself. No more wondering if the docs reflect reality or some historical version that nobody updated.

For engineering managers and technical leaders, automated documentation delivers measurable operational value:

  • Faster onboarding. New engineers learn from current, searchable documentation instead of outdated wikis or constant questions to senior team members.
  • Consistent standards. Every project follows the same documentation pipeline, creating predictable structure across your codebase.
  • Knowledge retention. Information doesn’t disappear when people change teams or leave the company. It’s captured in the system.
  • Audit capability. Documentation becomes versioned and reviewable like any other part of your codebase. You can see what changed and when.

Documentation transforms from a liability that requires constant maintenance into an asset that compounds in value as your codebase grows.

Other Tools Worth Considering

MkDocs with PDoc works well for Python projects, but the same principles apply across different technology stacks.

Docusaurus is ideal for React-based projects or product documentation. It integrates tightly with Markdown, supports versioning out of the box, and handles both technical and user-facing documentation well.

Sphinx excels for large Python projects, especially those requiring sophisticated cross-referencing or API documentation generated directly from code. It’s more complex to configure but offers extensive customization.

DocFX fits .NET projects with deep code-to-documentation integration. If your stack is primarily Microsoft technologies, it’s worth evaluating.

TypeDoc and JSDoc serve JavaScript and TypeScript projects the same way PDoc serves Python, generating API documentation from code comments.

The specific tools matter less than the principle: connect your documentation to your code and automate the publishing pipeline. Whatever stack you’re using, there’s probably a toolchain that supports this approach.

Making Documentation Sustainable

The goal isn’t perfect documentation. It’s sustainable documentation.

Manual processes fail because they require ongoing effort that competes with other priorities. When deadlines pressure, documentation loses. Every time.

Automated documentation succeeds because it removes that competition. The effort happens once, when you set up the pipeline. After that, keeping docs current requires no additional work. It just happens as part of your normal development workflow.

This shift matters more than the specific tools you choose. Whether you use MkDocs or Docusaurus, GitHub Actions or GitLab CI, the important thing is building a system where documentation maintains itself.

When knowledge lives inside your CI pipeline, it can’t get lost. When documentation generates from code, it can’t go stale. When publishing happens automatically, it can’t be forgotten.

The best documentation isn’t written once and maintained forever. It’s rebuilt automatically, every day, from the source of truth that matters most: your actual code.

Need Help Setting This Up?

Implementing automated documentation requires some initial configuration, but the long-term payoff is significant. If you’d like guidance on building a documentation pipeline for your development team, we can help you design a sustainable system that fits your technology stack and workflow.

A 3-Second Query, 20 Open Connections, and the Design Pattern That Fixed It

Posted on by Artemy

A simple database query that normally runs in under 0.1 seconds was suddenly taking 3 seconds. No schema changes. No new joins. No suspicious filters. Just a plain, boring query that had decided to become slow.

So we started digging.

Finding the Real Problem

One of the first things we checked was the number of active connections to the database. That’s when we saw it. One of our applications had more than 20 active connections open at the same time. Just for that single app.

Out of curiosity, we terminated the application and reran the exact same query. It completed in less than a tenth of a second.

The query was never slow. The Oracle database was under unnecessary pressure because of how our application was managing its connections. Or rather, mismanaging them.

The Culprit: One Connection Per Object

Looking into the code, we found the issue. Every time a certain part of the application needed to talk to the database, it created its own connection object.

Different parts of the code were doing:

  • new Database() here
  • new Database() there
  • Then holding on to those connections longer than necessary

None of this looked horrible at a glance. But in practice, the database was juggling dozens of concurrent connections from a single application that didn’t need them.

The Fix: A Simple Singleton

The solution was textbook. We changed the database access logic so the application used a singleton object for its connection.

That meant:

  • The application maintained only one active connection
  • All code that needed the database shared the same instance
  • We stopped flooding Oracle with unnecessary connections

After that change, query times went back to normal and stayed there.

What the Code Looked Like

Before: Creating New Connections Everywhere

Every time the constructor runs, a new Oracle connection opens:

java

public class BadOracleDatabase {
    private Connection connection;

    public BadOracleDatabase() throws SQLException {
        // New connection every time this is called
        this.connection = DriverManager.getConnection(
            "jdbc:oracle:thin:@//db.mycompany.com:1521/ORCLEDB",
            "<app_user>",
            "<secret>"
        );
    }

    public Connection getConnection() {
        return connection;
    }
}

When different classes keep calling new BadOracleDatabase(), you end up with dozens of open connections. That’s when the database starts choking.

After: One Shared Instance

The Singleton version ensures the application shares a single connection:

java

public class OracleDatabase {
    private static OracleDatabase instance;
    private Connection connection;

    private OracleDatabase() throws SQLException {
        this.connection = DriverManager.getConnection(
            "jdbc:oracle:thin:@//db.mycompany.com:1521/ORCLEDB",
            "<app_user>",
            "<secret>"
        );
    }

    public static synchronized OracleDatabase getInstance() throws SQLException {
        if (instance == null || instance.getConnection() == null || 
            instance.getConnection().isClosed()) {
            instance = new OracleDatabase();
        }
        return instance;
    }

    public Connection getConnection() {
        return connection;
    }
}

Now all database-using code goes through OracleDatabase.getInstance() instead of creating new objects. One shared instance. One active connection. Problem solved.

Why This Matters Beyond the Code

This wasn’t a fancy microservice refactor or a massive infrastructure overhaul. It was a basic design pattern that most developers learn early and then forget to apply.

But that small change:

  • Improved query performance by orders of magnitude
  • Reduced database load significantly
  • Made the system more predictable under normal operations
  • Saved hours of debugging and tuning
  • Avoided unnecessary scaling costs

The broader lesson is simple. You don’t always need something exotic to solve real problems. Sometimes, recognizing that something should be a shared object instead of N separate ones is enough.

Design patterns aren’t academic exercises. They’re practical tools that save time, money, and headaches. This one certainly did for us.