Posts on MN Risk & Cybersecurity Advisory

What 2026 CVEs Are Telling Us So Far: The Boring Stuff Is Still the Risk

Wed, 01 Jul 2026 00:00:00 +0000

We are halfway through 2026, and the vulnerability data is not pointing to one dramatic new category.

It is pointing to something more familiar.

Everyday software, operating systems, browsers, web applications, open source components, remote access tools, and network-edge systems continue to produce the risk that matters.

That may sound boring. It is also the point.

Most businesses do not get hurt because they missed a futuristic attack nobody could understand. They get hurt because ordinary software had an ordinary flaw, the system was exposed, the patch was delayed, or nobody had a clear owner for the risk.

This is a midpoint snapshot based on vulnerability data reviewed on July 1, 2026. CVE records change over time as vendors, researchers, and vulnerability databases enrich or correct them, so the exact counts may shift. The pattern is what matters.

What a CVE Means in Plain English

A CVE is a public tracking number for a known software vulnerability.

It is not the same as proof that attackers are using the issue. It is not a patch by itself. It is not always a perfect measure of risk.

A CVE is a starting point. It helps vendors, security teams, MSPs, auditors, and business leaders talk about the same weakness without guessing which issue they mean.

A practical vulnerability program needs more than CVE counts. It needs to know:

Is the affected software in our environment?
Is it exposed to the internet?
Is it used on critical systems?
Is there public exploit activity or exploit code?
Is it in CISA KEV?
Is the patch available?
Was the patch actually installed and verified?

That last question matters. Patch deployment and patch verification are not the same thing.

The Big 2026 Midpoint Numbers

As of July 1, the dataset showed:

Metric	Count
CVEs published so far in 2026	37,211
Critical CVEs	4,807
High CVEs	15,425
Medium CVEs	14,035
Low CVEs	943
Unknown severity	1,982
CVEs scored 9.0 or higher	5,333
CVEs scored 7.0 or higher	20,232
CVEs with exploit-reference signals	16,525
Published-in-2026 CVEs in CISA KEV	85
Total CISA KEV additions made in 2026	146

The first lesson is simple: volume is not slowing down.

The second lesson is more useful: raw volume is not a priority list.

If your business sees 37,211 CVEs and tries to treat them all the same, the program will fail. The point is not to chase every advisory with equal urgency. The point is to find the subset that intersects with your real environment, real exposure, and real business impact.

The Monthly Pattern

June was the highest full month so far.

Month	CVEs Published
January	5,143
February	4,798
March	6,229
April	5,913
May	7,036
June	7,508
July 1 partial	584

The July number is only a one-day partial count, so it should not be compared to a full month.

One other note: the modified-record count spiked hard in June in the local data. I would not use that as a public headline. That kind of spike can reflect enrichment, rescoring, or backfill activity rather than a clean signal that defenders should interpret as “June was uniquely dangerous.”

Published CVEs are a cleaner public signal for this kind of midpoint read.

The Boring Stuff Is Still the Risk

The strongest theme is that 2026 is still very much a web application and common software year.

Top weakness trends included:

Weakness	Count
Cross-site scripting	3,854
SQL injection	2,156
Missing authorization	1,879
Path traversal	1,309
Use-after-free	1,225
Improper access control	1,044
Out-of-bounds write	1,027
OS command injection	1,007
Code injection	952
Server-side request forgery	851

Grouped another way, the pattern is just as clear:

Weakness Group	Count
Auth and access control	4,984
Memory safety	4,945
Browser and web input issues	4,464
Code execution class bugs	2,375
SQL injection	2,157
Path traversal	1,386
Server-side request forgery	851
Deserialization	583

These are not exotic problems.

XSS, SQL injection, authorization flaws, path traversal, command injection, SSRF, use-after-free, and out-of-bounds writes are old classes. They keep showing up because modern systems are large, layered, fast-moving, and full of reused components.

For SMBs, the important lesson is not “learn every CWE.” The lesson is simpler:

If your business runs web apps, customer portals, vendor-hosted platforms, plugins, browser-based tools, APIs, or open source components, vulnerability management is not optional background noise. It is part of running the business.

Platform Risk Is Broad

The top vendor and product clusters also tell a useful story.

Vendor clusters included:

Linux: 2,940 CVEs
Microsoft: 2,075
Google: 1,491
Apple: 1,434
Oracle, Adobe, Apache, IBM, and Mozilla also showed strongly

Product clusters included:

Linux kernel
Windows
macOS
Chrome
Android
Firefox
iPhone and iPadOS
Thunderbird
GitLab
ImageMagick
Mattermost

This matters because many businesses still think of patching as a server task.

Servers matter, but they are not the whole picture.

Browsers matter. Phones matter. Email clients matter. Developer tools matter. SaaS and self-hosted collaboration platforms matter. Image processing libraries matter. Open source projects matter. Network-edge systems matter.

A patching program that only watches servers will miss a large part of the real attack surface.

Exploitability Is Not Rare

The dataset showed 16,525 published 2026 CVEs with exploit-reference signals.

That does not mean all 16,525 are being actively exploited in the wild. It does not mean every one of them should become an emergency.

It does mean defenders should stop treating CVEs as theoretical paperwork.

Public exploit references, proof-of-concept code, exploit discussions, scanner checks, and offensive tooling can turn a vulnerability from a line item into something much more urgent. Attackers do not need every vulnerability to be exploitable. They need one that works in your environment.

This is why vulnerability management should not stop at severity.

A CVSS 9.8 on software you do not run is not your immediate problem. A lower-scored vulnerability on an internet-facing system with exploit code and weak monitoring might be much more urgent.

KEV Is the Priority Filter, Not the Whole Universe

CISA’s Known Exploited Vulnerabilities catalog is one of the best places to start.

So far in 2026, 85 published-in-2026 CVEs were in KEV. There were also 146 total KEV additions during 2026, including older CVEs added this year.

That distinction matters.

Attackers do not care what year the CVE was published. If an older vulnerability still works, it is useful to them.

For defenders, KEV should be treated as a “drop everything and check this” list. It is not the only list that matters.

EPSS, the Exploit Prediction Scoring System, helps estimate how likely a vulnerability is to be exploited. It is not perfect, but it is useful when combined with exposure, asset importance, and whether exploit references exist.

A practical priority model should include:

CISA KEV
EPSS likelihood
Whether exploit references exist
Internet exposure
Asset criticality
Business impact
Whether compensating controls exist
Whether the patch has been verified

This gives a business a way to focus without pretending the vulnerability universe is small.

What SMBs Should Patch First

Most small and mid-sized businesses do not need a massive vulnerability management platform on day one. They need a clear order of operations.

Start here:

Patch anything in CISA KEV that exists in your environment.
Prioritize internet-facing systems, especially VPNs, firewalls, remote access tools, web servers, identity systems, and email systems.
Patch browsers, operating systems, and productivity software quickly.
Review high EPSS vulnerabilities and anything with public exploit references.
Fix exposed web application issues such as authentication bypass, SQL injection, XSS, SSRF, command injection, and path traversal.
Make sure unsupported software is removed or isolated.
Verify that patches actually installed.
Keep an inventory so you know what applies to you.

The inventory part is not glamorous, but it is where many programs break.

If nobody knows which systems exist, which software is installed, who owns it, and whether it is exposed, then patching becomes guesswork.

The SMB Takeaway

The 2026 vulnerability landscape is not saying “panic.”

It is saying something more practical:

Know what you run.
Watch KEV first.
Use EPSS and exploit references to sort the rest.
Patch exposed systems quickly.
Do not ignore browsers, endpoints, phones, developer tools, and open source components.
Treat web application security as a normal business issue.
Verify that fixes actually happened.

The boring stuff is still the risk.

That is not bad news. It means many of the right moves are understandable: inventory, prioritize, patch, verify, and repeat.

The businesses that do this consistently are in a much better position than the businesses waiting for a perfect tool, a perfect dashboard, or a perfect time to start.

Start a conversation about your security priorities

You Probably Don't Need Another Cybersecurity Product

Thu, 25 Jun 2026 00:00:00 +0000

If you run a small business and start looking at cybersecurity products, it does not take long to feel overwhelmed.

The industry has no shortage of acronyms:

CTEM
DSPM
SSPM
CNAPP
ITDR
XDR
AI-SPM
CAASM

Then there are the product categories that use full words but are not necessarily any clearer:

Attack Surface Management
Attack Path Management
Exposure Validation
Continuous Penetration Testing

Most of these products address a real problem. Some are very good at what they do.

You probably do not need them.

At least, not yet.

The Basics Still Matter

Security vendors are paid to explain why their product should be your next priority. What they usually cannot tell you is whether it is the right priority for your business.

That is an important difference.

A company can buy an impressive security platform and still leave its most likely path of attack wide open. It happens all the time. The new tool gets funded because it sounds advanced, while ordinary problems remain unresolved:

Employees can still sign in to email with only a password.
Former employees still have active accounts.
Backups exist, but nobody has tested a restore.
Remote access is exposed to the internet.
Critical software is months behind on updates.
Everyone has local administrator rights.
Alerts are generated, but nobody is responsible for reviewing them.
The company does not know which devices or cloud services it owns.

These are not exciting problems. They do not produce impressive product demonstrations. They are also the problems most likely to turn an ordinary incident into a very expensive one.

Security starts with blocking and tackling: know what you have, protect accounts, patch systems, limit access, secure email, maintain recoverable backups, and know what you will do when something goes wrong.

Until those basics are working, adding another dashboard may give you more information without making you much safer.

Expensive Tool, Wrong Problem

Consider a manufacturing company preparing to spend $100,000 on a CTEM platform—Continuous Threat Exposure Management. A product like that may help a mature security team identify and prioritize exposures across a complicated environment.

But if the company’s office workers do not use multi-factor authentication, the better investment is obvious.

An attacker does not care that the company has a sophisticated exposure-management dashboard. If a stolen Microsoft 365 password gets them into email, that is the door they will use.

Here are a few more examples:

A company does not need continuous penetration testing if its firewall and VPN appliances are not being patched.
A business does not need AI Security Posture Management when employees are using shared accounts and reused passwords.
A ten-person company probably does not need a CAASM platform to reconcile asset data from twenty security tools. It needs an accurate inventory of its laptops, servers, cloud services, and owners.
A small professional-services firm does not need a DSPM platform if it has not decided where customer files are allowed to be stored.
A business does not need an attack-path management product if every employee is a local administrator and the network is flat.
A company does not need XDR if nobody has the time or responsibility to investigate the alerts from the endpoint protection it already owns.
A retailer does not need a new identity-threat platform before it disables stale accounts and requires MFA for administrators.
A medical or dental practice does not need another compliance dashboard if its backups are connected to the same environment as everything else and have never been restored in a test.
A construction company does not need a cloud-native application protection platform if it does not develop or operate cloud-native applications.
A community bank may not need the same security stack as a national bank. It does need strong identity controls, vendor oversight, tested recovery procedures, useful logging, and a response plan people can actually follow.

This is not an argument against security technology. It is an argument for buying technology in the right order.

Start With the Business

The right security plan begins with the business, not a product category.

A machine shop, accounting firm, health clinic, bank, trucking company, and software developer do not face the same risks. They depend on different systems, hold different information, answer to different regulators, and suffer in different ways when technology stops working.

Before recommending a product, we need to understand things like:

What does the business do?
Which systems are necessary to keep operating?
What information would cause real harm if it were stolen?
How long can the business tolerate being offline?
How do employees and vendors access systems?
What technology and security services are already being paid for?
Who is responsible when an alert or incident occurs?
Are there customer, insurance, contractual, or regulatory requirements?

For a manufacturer, production downtime may be the largest risk. For an accounting firm, it may be stolen tax records and fraudulent email. For a bank, identity, transaction fraud, third-party access, and regulatory obligations all matter. For a small software company, source code, cloud access, and customer data may deserve more attention.

The controls should follow the risk.

Threats, Vulnerabilities, and Risk

Security language can make a fairly simple idea sound more complicated than it is.

A threat is something capable of causing harm. That could be a criminal group, a dishonest insider, a careless employee, a fire, failed equipment, or even a vendor mistake.

A vulnerability is a weakness that allows harm to occur. A missing patch is a vulnerability. So is a weak password, an exposed remote-access service, excessive permissions, or a backup that cannot be restored.

Risk is what those things mean to your business.

For example:

A criminal steals an employee’s password. That is the threat in action.
The account does not require MFA. That is the vulnerability.
The criminal uses the mailbox to redirect a payment, steal customer information, or launch ransomware. That is the business risk.

The goal is not to eliminate every possible weakness. No business has unlimited time or money, and no environment will ever be perfect.

The goal is to find the weaknesses most likely to cause meaningful harm and reduce those first.

Make Sure You Are Getting What You Already Pay For

Many small businesses already own more security capability than they realize.

Microsoft 365, Google Workspace, firewalls, endpoint-protection products, backup platforms, insurance services, and managed IT agreements often include controls that have never been fully enabled or configured.

Before adding another product, it is worth asking:

Is MFA enabled for every user, especially administrators?
Are risky sign-ins or suspicious forwarding rules being monitored?
Are endpoint-protection agents installed on every supported device?
Are alerts going to someone who will act on them?
Are old accounts, devices, and applications being removed?
Are backups protected from ordinary administrator accounts?
Has anyone successfully restored a file, server, or critical application?
Are security features included in current licenses actually turned on?
Does the managed service agreement clearly say who handles patching, monitoring, backup failures, and incident response?

Sometimes the fastest way to reduce risk is not to buy something. It is to properly use what is already on the invoice.

What a Small Business Is More Likely to Need

The answer depends on the business, but the early priorities are usually familiar:

Multi-factor authentication
Reliable, protected, and tested backups
Email security
Managed endpoint protection
Prompt operating system and application updates
Removal of unused accounts and unnecessary administrator access
An inventory of important devices, software, vendors, and data
Basic security awareness for employees
A written incident-response plan
Clear ownership between the business, its IT provider, and other vendors

None of these controls is glamorous. Done well, they stop common attacks, reduce downtime, and make recovery much more realistic.

After those controls are in place and working, more specialized products may make sense. A growing organization with several cloud platforms, a large security team, and thousands of assets may get real value from CTEM, DSPM, CAASM, XDR, or another specialized platform.

The key phrase is in place and working. Owning a control and operating it effectively are not the same thing.

Who Are These Advanced Products For?

There is a legitimate place for most of the products on the acronym list.

They are often built for organizations with complicated environments, specialized security teams, large quantities of data, many existing tools, and enough staff to respond to what the platform finds. Think of a national bank with a security budget in the millions and enough information-security employees to eat a stack of pizzas for lunch.

That description does not fit most small businesses. It does not fit many mid-sized businesses or small community banks, either.

A product designed to help a mature security program manage thousands of findings can become an expensive distraction in an organization that still needs to fix a dozen fundamental weaknesses.

There is also an ongoing cost beyond the purchase price. Someone has to configure the product, connect it to other systems, tune it, review its findings, investigate alerts, maintain it, and explain what the business should do next. If nobody has time for that work, the product may become one more blinking dashboard.

Buy Less. Reduce More Risk.

A sensible cybersecurity review should not begin with a shopping list.

It should begin by understanding the business, checking whether current spending is appropriate, identifying realistic threats, cataloging the weaknesses those threats could exploit, and finding the quickest practical path to reducing harm.

That path may include a new product. It may also mean enabling MFA, changing a configuration, testing a backup, removing access, updating a system, documenting a process, or making an existing provider accountable for work already covered by the contract.

The measure of a security program is not how many tools it owns or how advanced its acronyms sound.

The measure is whether the business is harder to disrupt, defraud, or hold for ransom—and whether it can recover when something still goes wrong.

Before buying the next security product, make sure the basics are doing their job.

Not Sure What You Actually Need?

An independent cybersecurity review can help separate useful investments from expensive distractions and turn a long list of concerns into a practical order of operations.

FBI Warns About Traffic Distribution Systems: What MSPs, Website Builders, and SMBs Should Know

Tue, 23 Jun 2026 00:00:00 +0000

On June 18, 2026, the FBI’s Internet Crime Complaint Center published a Public Service Announcement about criminal abuse of Traffic Distribution Systems.

The warning matters to small businesses because these attacks do not always begin with an obviously malicious website. A person may click a search result, online advertisement, email link, compromised website, or fake software download that looks normal. Behind the scenes, a Traffic Distribution System can inspect the visitor and decide what to show them.

One visitor may see an ordinary page. Another may be sent to a fake login screen, financial scam, malicious download, or ransomware delivery site.

That selective behavior makes the attack harder to reproduce, report, and block.

What is a Traffic Distribution System?

A Traffic Distribution System, commonly called a TDS, is technology that receives web traffic and routes each visitor to a destination based on rules.

The technology itself is not inherently malicious. Advertising platforms, affiliate networks, content delivery services, and website operators can use routing systems for legitimate purposes.

Criminals abuse the same concept to hide malicious activity.

According to the FBI advisory, a malicious TDS may collect information such as:

IP address
Approximate location
Operating system
Device type
Browser type and version

The system can then decide whether the visitor looks useful to the attacker.

For example, it might send security researchers, automated scanners, or visitors outside a target region to a harmless page. A person using a Windows computer from a business network in the desired location might receive a fake Microsoft 365 login page or a malicious script instead.

This is one reason traditional firewall rules may not be enough. The first website or redirect may not have a known malicious reputation, and the final destination can change based on the person, device, location, or time of day.

How a small MSP could fall victim

Imagine a technician at a small managed service provider searching for an installer, remote-support utility, printer driver, or troubleshooting tool.

The technician clicks a promoted search result that appears to point to a familiar vendor. The first page looks harmless, but it passes the browser through a TDS. The system recognizes a Windows device, a business IP address, and a browser profile that matches the attacker’s target.

The technician is then offered a convincing fake installer or update.

If that device has access to remote monitoring and management tools, password vaults, customer documentation, or privileged client accounts, one compromised workstation can create a much larger problem. The MSP’s trusted access may become the attacker’s path into multiple customer environments.

MSPs should treat software downloads, administrative browsing, and RMM access as high-risk activities. Separate administrative accounts, phishing-resistant multi-factor authentication, application controls, endpoint monitoring, and limited customer access can reduce the blast radius.

How a website builder could become part of the attack

A freelance website builder or small agency may manage dozens of WordPress sites, hosting accounts, plugins, themes, and domain records.

An attacker who steals one hosting credential or exploits an outdated plugin may insert redirect code into a client website. The malicious code can send selected visitors into a TDS while allowing the website owner and most automated scanners to see the normal site.

That creates an especially frustrating situation:

The client receives reports that visitors are being redirected.
The site appears normal when the developer checks it.
Only certain devices, locations, or referral sources trigger the attack.
The malicious destination may change between visits.

The website builder may unknowingly operate a distribution point for phishing or malware. Beyond the immediate cleanup, the incident can damage search rankings, advertising accounts, customer trust, and the agency’s reputation.

Website professionals should maintain an inventory of sites, themes, and plugins; remove abandoned components; require multi-factor authentication on hosting and CMS accounts; monitor file changes; and investigate unexpected JavaScript, PHP, .htaccess, administrator, and redirect changes.

How an ordinary SMB employee could be targeted

Consider an employee at a local manufacturer, accounting firm, clinic, or retailer who receives an email about an invoice or document.

The link does not immediately open a fake login page. It first sends the employee through a series of redirects. The TDS determines that the visitor is in the United States, is using a business Windows computer, and has a browser configuration the attacker knows how to target.

The employee may then see:

A fake Microsoft 365 or vendor login page
A fraudulent payment or shipping notice
A fake browser update
A malicious JavaScript or PowerShell-based download
A page designed to begin a remote-support scam

Stolen credentials can lead to mailbox access, payment fraud, customer impersonation, or a ransomware foothold. A business does not need to be specifically famous or wealthy to be useful to an attacker. It only needs to have money, data, insurance, trusted relationships, or access to other organizations.

Warning signs worth investigating

Traffic distribution attacks can be inconsistent by design, so reports that are difficult to reproduce should not be dismissed.

Watch for:

Customers reporting redirects that staff cannot reproduce
Website behavior that changes by device, browser, location, or referral source
Unexpected website administrator accounts
Recently modified JavaScript, PHP, theme, plugin, or .htaccess files
New scheduled tasks or unfamiliar startup items on endpoints
Unexpected use of wscript.exe, cscript.exe, or PowerShell
Users downloading or opening unexpected .js, .ps1, or .svg files
Browser history showing several unfamiliar domains before a phishing page
Endpoint or DNS alerts tied to advertising, redirect, or newly registered domains

The FBI specifically recommends monitoring suspicious scripting activity and considering safer default file associations so JavaScript files do not execute casually when opened.

Practical steps for small organizations

No single security product will solve this problem. The most effective defense is a set of controls that interrupt different parts of the attack.

Protect users and endpoints

Use endpoint detection and response tools that monitor script interpreters and suspicious child processes.
Restrict PowerShell and script execution where practical.
Use DNS and web filtering, while recognizing that newly created destinations may not yet be categorized.
Require multi-factor authentication, especially for email, remote access, hosting, and administrative tools.
Teach employees to obtain software from a known vendor address rather than an advertisement or search result.
Give users a quick, blame-free way to report strange redirects and downloads.

Protect websites and hosting accounts

Keep the CMS, themes, and plugins supported and patched.
Remove unused plugins, themes, accounts, API keys, and integrations.
Use unique administrator accounts and multi-factor authentication.
Review hosting control-panel and CMS login history.
Monitor important files for unauthorized changes.
Use a web application firewall as an additional layer, not as a substitute for maintenance.
Maintain tested backups that allow the site to be restored to a known-clean state.

Limit MSP and administrator exposure

Separate everyday accounts from privileged administrative accounts.
Do not use a highly privileged workstation for general web browsing or software searches.
Protect RMM, documentation, password vaults, and remote-access systems with strong authentication and conditional access.
Limit each technician and tool to the customers and systems they actually need.
Log administrative actions and review unusual access promptly.
Build an incident plan for disabling compromised technician accounts without losing control of customer environments.

Preserve the full URL, browser history, screenshots, downloaded files, timestamps, and the device used. The redirect chain may disappear or behave differently during a later investigation.

Disconnect a device if malware may have executed, but avoid destroying evidence. Reset exposed credentials from a known-clean system, revoke active sessions, and review email forwarding rules, hosting accounts, website files, remote-access tools, and administrative logs.

Organizations can report suspected cybercrime to the FBI through IC3.gov.

The larger lesson

The important part of the FBI warning is not a new acronym. It is the way criminals use selective routing to make malicious activity look inconsistent.

A website can appear clean to its owner and dangerous to a customer. A link can be harmless during testing and malicious when an employee opens it. A firewall can allow the first connection even though the person eventually lands on a credential theft or malware page.

Small MSPs, website builders, and SMBs should take reports of unexplained redirects seriously, protect the administrative tools that create outsized risk, and collect evidence before the trail changes.

Primary source: FBI Internet Crime Complaint Center, “Cyber Criminal Use of Traffic Distribution Systems (TDSs) to Facilitate Malicious Activity,” June 18, 2026.

Not-so-free Wifi

Mon, 22 Jun 2026 00:00:00 +0000

Free Wi-Fi Isn’t Always Free

I was at a restaurant the other night and the cellular signal inside the building was terrible. Like most people, my first instinct was to look for guest Wi-Fi so I could quickly look something up while waiting for my food.

I found a guest network, connected, and was immediately redirected to a login page. Instead of asking for a password, the service wanted me to sign in with one of my social media accounts. The platform was called SocialWiFi, and while I’m sure many people would have clicked through without a second thought, I closed the browser and put my phone away.

Whatever I wanted to look up could wait until I got home.

Maybe that makes me paranoid. After spending most of my career in cybersecurity, however, I’ve become increasingly selective about who I hand my information to and what I get in return. A few minutes of internet access simply wasn’t worth contributing another piece of information to a system designed to collect, analyze, and monetize personal data.

The Business of Knowing Everything

Most people understand that social media companies collect data. What many don’t realize is just how many organizations participate in the collection and exchange of information about consumers.

A restaurant offering free Wi-Fi may not care about your personal life. The company operating the Wi-Fi portal, however, likely cares about understanding customer behavior. Marketing firms care about understanding customer behavior. Data brokers care about understanding customer behavior. Advertisers care about understanding customer behavior.

Each organization may only possess a small piece of the puzzle, but modern technology allows those pieces to be combined in ways that would have been impossible twenty years ago.

Knowing that you visited a particular restaurant on a Tuesday evening isn’t especially valuable by itself. Knowing where you eat regularly, where you work during the day, where you live at night, which social media accounts you use, what websites you visit, and what products you buy begins to create a remarkably detailed profile. That’s where the value exists.

Nobody is making money from a single data point. They’re making money by collecting millions of them.

The Data Economy Most People Never See

We live in a world where information is bought, sold, enriched, and resold continuously. Data brokers maintain enormous databases containing information gathered from loyalty programs, marketing campaigns, public records, mobile applications, website tracking systems, social media platforms, and countless other sources.

Most consumers never directly interact with these companies. In many cases, they don’t even know they exist.

What starts as a rewards program at a grocery store may eventually become part of a marketing profile. A social media login for restaurant Wi-Fi becomes another data point. A mobile app that asks for more permissions than it needs contributes another piece of information.

None of these interactions feel significant at the time, which is exactly why they are so effective. The collection process is distributed across hundreds of seemingly harmless transactions that occur over many years.

By the time someone realizes how much information has been accumulated, the data has already been shared countless times.

Why This Matters to Business Owners

Many small business owners view privacy as a personal issue rather than a business concern. In reality, the line between personal privacy and business security has largely disappeared.

Attackers rarely begin by targeting firewalls or security software. They often start by researching people.

They look for social media profiles, personal interests, family members, employment history, locations, email addresses, and any other information that helps them build a profile of their target. The more information they can gather, the easier it becomes to craft convincing phishing emails, impersonate trusted individuals, or manipulate employees into taking actions they normally wouldn’t.

A criminal doesn’t necessarily need access to your business systems if they can convince someone that they are you.

We’ve seen countless examples of attackers impersonating executives, business owners, vendors, and trusted partners. In many cases, the attack succeeds not because the technology failed, but because the attacker knew enough about the target to appear legitimate.

Every piece of personal information available online makes that process easier.

Your Reputation Is Part of Your Security Program

One aspect of cybersecurity that doesn’t receive enough attention is brand protection. Business owners spend years building trust with customers, employees, and partners, yet much of that trust can be exploited by someone willing to impersonate them.

Imagine a criminal creating a convincing social media profile using publicly available information. Imagine customers receiving messages that appear to come from your business. Imagine vendors receiving fraudulent payment requests that seem legitimate because the attacker knows who they should contact and how your organization operates.

These scenarios happen every day.

The information used to make these attacks successful often comes from dozens of sources that seemed harmless when the data was originally collected.

When viewed individually, none of those data points appear dangerous. When combined, they can become surprisingly powerful.

The Negative You Can’t Measure

One of the reasons people struggle with privacy decisions is that the benefits are almost impossible to quantify.

I don’t participate in many loyalty programs. I rarely sign up for coupon clubs. I generally avoid handing out personal information unless there’s a clear reason to do so.

As a result, I almost certainly spend more money than someone who enthusiastically joins every rewards program available.

What I can’t calculate is what I’ve avoided.

How many robocalls never happened because my information wasn’t available?

How many spam emails never arrived?

How many phishing attempts failed because an attacker couldn’t gather enough information?

How many marketing databases don’t contain my information?

It’s impossible to measure a negative outcome. We can easily calculate the discounts we received, but we can’t calculate the problems that never occurred because we chose not to participate.

Convenience Always Has a Cost

The next time you’re presented with a social media login to access Wi-Fi, join a rewards program, or claim a discount, it’s worth taking a moment to ask a simple question:

If this service is free, how are they making money?

Sometimes the answer is harmless.

Sometimes it isn’t.

The point isn’t that every company collecting information is malicious. The point is that information has value, and many businesses are built around collecting, analyzing, and monetizing that value.

As consumers and business owners, we should understand that transaction before we agree to it.

Because once your information enters the data broker ecosystem, you lose control over where it goes next. And in a world increasingly driven by data, that information may eventually be used in ways you never anticipated.

Need an Independent Security Perspective?

At Minnesota Risk, we help organizations identify practical cybersecurity risks that affect both their business operations and their people. Whether you’re evaluating your security program, improving your defenses against social engineering, or looking for an independent assessment of your current security posture, we’re here to help.

Contact Minnesota Risk to learn how an independent cybersecurity partner can help protect your business, your customers, and your reputation.

The Game Theory of an Attacker

Tue, 16 Jun 2026 00:00:00 +0000

The Game Theory of an Attacker

You have an MSP.

You have tools.

You have alerts.

You may have email filtering, endpoint protection, MFA, backups, firewalls, remote monitoring, logging, and a ticketing system full of evidence that work is being done.

Those things matter. A good MSP and a good toolset can reduce a lot of risk.

But there is still an important question:

Who is thinking like an attacker and mapping out what happens when one of those controls does not work?

That is where many businesses have a gap.

Security is not only about whether a tool is installed. It is about what an attacker can do when something slips through.

Start With a Simple Phishing Email

Suppose your company has spam filtering in place.

That is good.

But no spam filter is perfect. None of them are. Sooner or later, a phishing message may land in an employee’s inbox.

Now the real questions begin:

What happens if the employee clicks the link?
What happens if they enter their Microsoft 365 password?
Does MFA stop the login, or can the attacker trick the user into approving it?
What systems does that employee have access to?
What customer information can they reach?
What files are stored locally on the laptop?
Are browser passwords saved?
Are there VPN profiles, mapped drives, or cached credentials?
Can that laptop talk to servers, file shares, printers, cameras, or accounting systems?
Can it make outbound connections to almost any destination on the internet?

This is the game theory of an attacker.

The attacker is not thinking, “Can I beat the whole company in one move?”

They are thinking, “If I get this one user, what can I reach next?”

The First Click Is Usually Not the Whole Attack

Many businesses think about phishing as a password problem.

That is part of it, but it is not the whole picture.

The first click may lead to a fake login page. It may lead to a malicious attachment. It may lead to a remote access tool. It may lead to a browser session hijack. It may lead to a conversation where the attacker slowly builds trust before asking for money, data, or access.

Once the attacker has a foothold, they start making decisions.

They may look for:

Email rules that hide replies or forward messages externally
Recent invoices, wire instructions, or vendor conversations
Shared mailboxes
OneDrive or SharePoint folders
Passwords in files, browsers, or notes
VPN access
Admin tools already installed on the machine
Remote desktop paths
File shares with broad permissions
Security tools they can disable or avoid

This is why “we have a spam filter” is not the end of the conversation.

It is the beginning of the risk conversation.

Tools Help, But Attackers Adapt

You might have ThreatLocker, endpoint detection, antivirus, application control, DNS filtering, or a managed detection and response service on the laptop.

Those controls can be valuable.

But attackers are good at adapting.

They may avoid dropping obvious malware. They may stay in memory. They may obfuscate their tools. They may use PowerShell, Windows Management Instrumentation, remote monitoring tools, scheduled tasks, browser sessions, OAuth tokens, legitimate cloud storage, or other tools that already exist in the environment.

This is often called “living off the land.”

In plain English, it means the attacker tries to use your normal tools against you.

That matters because some environments are built in a way that gives a compromised laptop too much freedom.

For example:

The user is a local administrator.
The workstation can reach internal servers it does not need.
Outbound firewall rules allow almost anything.
Sensitive data is stored locally without a clear reason.
Shared folders are open to broad groups.
Administrative tools are installed on normal user machines.
Logs exist, but nobody has tuned alerts around the most important behavior.
There is no clear playbook for isolating a device or revoking sessions.

None of those issues sound dramatic by themselves.

Together, they can give an attacker room to move.

The Question Is Blast Radius

One of the most useful security questions is:

If this one thing fails, how bad can it get?

If a user clicks a phishing link, is the damage limited to that user account, or does it open the door to finance, HR, customer files, cloud systems, and internal servers?

If a laptop is compromised, can it only access the internet and a few required business apps, or can it freely scan the internal network?

If an employee’s password is stolen, does MFA, conditional access, device compliance, and session monitoring reduce the impact, or can the attacker log in from anywhere?

If ransomware starts on one machine, can it reach every mapped drive?

If an attacker creates a mailbox rule, would anyone notice?

If a remote access tool appears on a workstation, would it be blocked, logged, or ignored?

This is where security starts to become practical.

You stop asking only, “Do we have a tool for that?”

You start asking, “What would actually happen here?”

Your MSP Is Important, But Security Risk Hides in the Corners

An MSP can do a lot of the work.

They can manage systems, deploy patches, configure firewalls, support users, maintain backups, monitor alerts, and respond to issues. A strong MSP is a major asset.

But security risk hides in the corners.

It hides in old firewall rules nobody remembers creating. It hides in local admin rights that were granted during an emergency and never removed. It hides in shared folders named “Archive” that contain years of customer data. It hides in a laptop used by a high-access employee who also has saved browser passwords and broad VPN access.

It hides in assumptions.

The MSP may know the tools. The business may know the operations. But someone has to connect the two and ask uncomfortable questions before an attacker does.

That is the role of an information security specialist or vCISO.

Not to replace the MSP.

Not to sell a pile of new tools.

The value is in helping the business understand the actual risk, prioritize the right fixes, and build a realistic plan.

Practical Improvements That Change the Game

Thinking like an attacker does not always lead to expensive recommendations.

Sometimes the best improvements are boring and effective.

For example:

Remove local administrator rights from standard users.
Segment the network so workstations cannot reach systems they do not need.
Tighten outbound firewall rules instead of allowing every port to the internet.
Limit VPN access by role and device.
Require MFA, but also review conditional access and session risk.
Reduce broad file share permissions.
Move sensitive data out of local storage when possible.
Block or tightly control remote access tools.
Alert on suspicious mailbox rules and forwarding.
Test whether endpoint controls stop common attack paths.
Build a simple incident playbook for isolating devices, disabling accounts, and revoking sessions.
Review which logs are collected and which alerts someone actually investigates.

None of these controls are magic.

But each one changes the attacker’s decision tree.

The goal is to make every next step harder, noisier, slower, or less useful.

That is how you reduce blast radius.

A Better Question for Leadership

Instead of asking, “Are we secure?” ask:

If an attacker gets one normal employee account or one normal laptop, what can they do next?

That question leads to better conversations.

It helps leadership understand risk in business terms. It helps the MSP understand which controls matter most. It helps prioritize security work based on likely impact instead of fear, vendor pressure, or whatever alert happened to be loudest this week.

It also makes cybersecurity feel less abstract.

You are not trying to solve every possible threat at once.

You are mapping the paths an attacker would take and closing the ones that matter most.

Get a Game Plan

Your MSP, tools, and alerts are all part of the picture.

But you still need someone in your corner who can think through the attack path, map the blast radius, and help decide which improvements make sense for your business.

MN Risk & Cybersecurity Advisory can help review your environment, identify the gaps that matter, and build a practical security roadmap.

If you want help getting a game plan together, contact MNRISK.

Is Your Business Tech Stack Helping, or Just Existing?

Wed, 10 Jun 2026 00:00:00 +0000

Most businesses do not build their technology environment all at once.

It usually grows over time. Email gets set up. File sharing gets added. A line-of-business application becomes critical. Someone buys a project management tool. Someone else signs up for a password manager, backup service, security tool, or cloud subscription. A few years later, nobody is entirely sure which tools are essential, which ones overlap, which ones are configured correctly, or which ones are still being paid for.

That is normal. It is also where risk and waste start to creep in.

A technology review gives business owners and leadership teams a clear view of what is actually in use, how it is set up, where the gaps are, and whether current spending matches the organization’s real needs.

The First Step Is Understanding What You Have

Before a business can mature its cybersecurity posture, it needs a practical inventory of the technology that supports daily operations.

That does not have to mean a massive enterprise architecture project. For many small businesses, the first step is simply answering questions like:

What systems do employees use every day?
Where does company data live?
Who has access to sensitive systems?
What tools protect email, endpoints, identities, and backups?
Which vendors or subscriptions are still active?
Which tools overlap or duplicate each other?
Which systems would cause serious disruption if they went down?

This kind of review is not about judging past decisions. It is about getting the lay of the land so future decisions are based on facts instead of assumptions.

Small Businesses Feel Waste More Quickly

Large organizations can sometimes absorb inefficient technology spending for longer than they should. Small businesses usually cannot.

When budgets are tighter and headcount is limited, every subscription, platform, and managed service agreement matters. Paying for duplicate tools can crowd out more important improvements. Buying an advanced product without the staff or process to operate it can create cost without meaningful protection. Ignoring basic gaps can leave the business exposed even while the technology budget keeps growing.

That is why a technology review can be especially valuable for small businesses. With fewer systems and a smaller environment, the review can often move quickly and produce practical findings:

tools that can be consolidated
licenses that may no longer be needed
systems that need stronger access controls
backups that need verification
security tools that are deployed but not fully configured
vendor responsibilities that are unclear
gaps between what leadership assumes is protected and what is actually protected

The goal is not to spend more for the sake of spending more. The goal is to spend where it reduces real operational or security risk.

Right-Sized Controls Matter

Most cybersecurity frameworks, standards, and regulations acknowledge some version of the same idea: controls should be appropriate for the organization.

That matters.

A ten-person business probably does not need the same technology stack as a multinational enterprise. It may not make sense to deploy a complex application allowlisting platform, a privileged access management suite, a full security operations center, and every tool a large regulated company might use.

But that does not mean a small business should do nothing.

Right-sizing means matching controls to the business context:

What data do you handle?
What legal, contractual, or insurance requirements apply?
How much downtime could you tolerate?
What systems are most critical?
Who supports the environment?
What budget and staffing are realistic?
Which risks would create the most harm if they were ignored?

For some businesses, the most important improvement might be stronger multi-factor authentication. For others, it might be backup resilience, endpoint protection, email security, vendor oversight, or reducing the number of unsanctioned tools employees use to get work done.

The answer depends on the business. That is exactly why a one-size-fits-all technology plan rarely works.

More Tools Do Not Automatically Mean Better Security

It is easy to assume that buying another tool will solve the problem.

Sometimes it will help. Often, the better first move is to understand whether the tools already in place are being used well.

A business might have a security product installed but not monitored. It might have a backup system that has never been tested. It might have multi-factor authentication enabled for some accounts but not the accounts that matter most. It might have three collaboration platforms, two file-sharing services, and no clear data ownership model.

In those cases, the issue is not always a lack of technology. The issue is a lack of visibility, ownership, configuration, or follow-through.

A technology review helps separate three very different problems:

Missing controls: something important is not in place.
Weak implementation: the tool exists, but it is not configured or managed effectively.
Unnecessary complexity: the environment has too many overlapping products, unclear ownership, or avoidable cost.

Those distinctions matter because they lead to different recommendations.

What a Quick Tech Stack Review Can Show

A practical technology review does not need to be dramatic or disruptive.

For many local businesses, a quick review can help identify:

overlapping tools that create unnecessary spend
subscriptions nobody clearly owns
security gaps that deserve attention
access risks across email, cloud storage, and business applications
whether existing vendors are covering the right responsibilities
simple improvements that would reduce risk without adding complexity

The output should be understandable. No fluff. No pressure. Just a clear picture of where the business stands and what the next few reasonable steps could be.

The Point Is Better Decisions

Technology should support the business. It should make work easier, protect important data, and help people operate with confidence.

If the tech stack is just existing, it may be quietly draining budget while leaving meaningful risk untouched.

A technology review gives leadership a way to pause, look at the whole picture, and make better decisions about what to keep, what to improve, what to retire, and where to invest next.

For small businesses, that clarity can be the difference between buying more technology and building a healthier, more intentional technology environment.

Want a Clearer View of Your Tech Stack?

MN Risk & Cybersecurity Advisory offers quick technology stack reviews for Minnesota businesses that want a practical look at overlapping tools, security risks, and sensible next steps.

Start the conversation

Your MSP Manages IT. Who Manages Cybersecurity?

Mon, 08 Jun 2026 00:00:00 +0000

Many small and midsized businesses have a trusted Managed Service Provider (MSP). They manage workstations, servers, Microsoft 365, backups, networking, and the day-to-day operation of your technology environment.

For most organizations, that’s exactly what they need.

But there is an important question that often goes unanswered:

Who is managing cybersecurity?

While IT and cybersecurity are closely related, they are not the same thing. Keeping systems running and managing business risk require different skill sets, different priorities, and different conversations.

The Problem

Most business owners and executives aren’t looking to become cybersecurity experts.

They don’t want to spend their day reviewing vulnerability reports, comparing security products, or trying to understand technical recommendations from vendors.

What they really want to know is:

Are we adequately protected?
What are our biggest risks?
What should we focus on next?
Are we meeting customer and regulatory expectations?
Are we spending money in the right places?

Without dedicated cybersecurity leadership, many organizations find themselves reacting instead of planning. Security improvements happen when a customer asks for them, an auditor requires them, or a cyber insurance renewal raises concerns.

That approach often leads to confusion, wasted spending, and increased risk.

Where a vCISO Fits In

A Virtual Chief Information Security Officer (vCISO) provides strategic cybersecurity leadership without the cost of hiring a full-time executive.

Rather than managing servers or resetting passwords, a vCISO focuses on the overall security program.

Responsibilities often include:

Identifying and prioritizing cybersecurity risks
Developing security roadmaps
Managing security policies and procedures
Supporting compliance initiatives
Reviewing security controls
Coordinating vulnerability management
Evaluating vendors and security tools
Assisting with cyber insurance requirements
Reporting security posture to leadership

Most importantly, a vCISO helps business leaders make informed decisions without requiring them to become technical experts.

Working With Your Existing MSP

One of the most common misconceptions is that a vCISO replaces an MSP.

In reality, the opposite is true.

The best security outcomes occur when the MSP and vCISO work together.

Your MSP may be responsible for implementing security controls, managing infrastructure, deploying updates, and maintaining systems. A vCISO provides strategic oversight and helps ensure those efforts align with business objectives and risk priorities.

Think of it this way:

The MSP handles the operational work.
The vCISO helps determine what work should be prioritized and why.
Leadership receives clear business-focused reporting instead of technical noise.

This creates accountability, improves communication, and helps ensure security investments are aligned with actual business risk.

Security Without the Noise

Many executives are overwhelmed by technical details.

A 50-page vulnerability report rarely helps a business owner decide where to invest resources.

A vCISO translates technical findings into business language by answering questions such as:

What is the risk?
How likely is it to affect us?
What should we do about it?
What happens if we choose not to act?

The goal isn’t to eliminate all risk. The goal is to understand risk and make informed decisions about it.

Focus on Growing the Business

Every hour spent worrying about cybersecurity is an hour not spent serving customers, growing revenue, or improving operations.

A mature cybersecurity program allows leadership to focus on the business while maintaining confidence that security risks are being actively managed.

That’s the value of a vCISO.

You gain executive-level cybersecurity leadership, strategic guidance, and an advocate who can work alongside your MSP and other technology partners without the cost of a full-time security executive.

Ready to Take Cybersecurity Off Your Plate?

If your business has an MSP but lacks dedicated cybersecurity leadership, it may be time to add a strategic security partner.

MN Risk & Cybersecurity Advisory helps organizations build practical, business-focused security programs, coordinate with existing MSPs, and provide executive-level cybersecurity guidance without unnecessary complexity.

Whether you need help understanding your risks, improving your security posture, preparing for compliance requirements, or simply making sense of cybersecurity decisions, we’re here to help.

Contact MN Risk & Cybersecurity Advisory today to schedule an introductory consultation and learn how a vCISO can help protect your business while allowing you to focus on what you do best.

HR Security Considerations: Hiring, Onboarding, and Protecting the Business Before Day One

Sat, 06 Jun 2026 00:00:00 +0000

Most companies think about cybersecurity after someone has already been hired.

That is too late.

By the time a new employee has a laptop, email account, payroll profile, VPN access, file shares, customer records, and a manager who is eager for them to “hit the ground running,” the business has already made a security decision. Maybe it was intentional. Maybe it was just the path of least resistance.

HR security is about making those decisions deliberately.

It does not mean treating every applicant like a criminal. It means recognizing that hiring, onboarding, access, training, contracts, and offboarding are all part of your security program. If an attacker can get hired, impersonate a candidate, intercept a laptop, or talk their way into admin access, they do not need to break in.

You invited them.

The Hiring Process Is a Security Control

The first question is simple:

Are applicants who they say they are?

For in-person hiring, that question is usually easier to answer. For remote roles, contract roles, IT roles, finance roles, and anyone with access to customer data, the risk is much higher.

Fake applicants are no longer just a theoretical problem. U.S. law enforcement has repeatedly warned that overseas IT workers have used stolen identities, fabricated resumes, fake websites, U.S.-based facilitators, and “laptop farms” to obtain remote jobs at American companies. In some cases, company-issued laptops were shipped to one location and then remotely accessed by someone in another country.

That should change how businesses think about remote hiring.

Good applicant validation includes:

Live video interviews with the same person across the process
A documented identity verification step before access is granted
Background checks appropriate to the role
Employment, education, license, or certification verification where relevant
Reference checks using independently verified contact information
Technical assessments that are hard to outsource in real time
A review of inconsistencies across resume, interview, location, payroll, tax, and shipping information
Extra scrutiny for roles with access to source code, finance systems, customer data, patient data, infrastructure, or intellectual property

Be careful here. Screening must be legal, consistent, and job-related. If you use a third-party background check company in the United States, the Fair Credit Reporting Act has specific disclosure, authorization, and adverse action requirements. Criminal history screening also needs to be handled carefully to avoid discriminatory impact.

The goal is not to create a hiring process based on suspicion. The goal is to create a hiring process that is consistent enough that scammers cannot simply talk their way through it.

Watch for Fake Applicant and Remote Worker Red Flags

No single red flag proves anything. People move, use nicknames, have weak internet, and make honest mistakes. But patterns matter.

Pay attention when:

The candidate refuses live video or repeatedly has camera problems
The person in the interview does not appear to match the identity documents or public professional history
Different people appear at different interview stages
The candidate’s resume, LinkedIn profile, GitHub profile, portfolio, or references appear recently created or unusually thin
References only respond through personal email accounts or cannot be independently tied to a real employer
The candidate pushes hard for remote access before identity or employment eligibility steps are complete
The shipping address is a freight forwarder, coworking space, mailbox store, unrelated residence, or otherwise inconsistent with the employee’s claimed location
Payroll, tax, IP geolocation, address, and identity information do not line up
The candidate asks to use personal devices for sensitive work when company equipment is required
They ask for unusual payment arrangements, crypto, third-party bank accounts, or payroll changes early in employment

These indicators should trigger review, not automatic rejection. Your process should give HR, legal, IT, and the hiring manager a way to pause and validate before the company ships equipment or grants access.

Secure Credential Transfer Before the First Day

One of the easiest ways to create unnecessary risk is to send credentials badly.

Do not email a password. Do not put a password in the laptop box. Do not text a permanent password. Do not ask the employee to reuse a personal password. Do not create a shared “new hire” account.

Use a controlled process:

Verify the employee’s identity before account activation.
Create the account in your identity provider, such as Microsoft Entra ID, Google Workspace, Okta, or another SSO platform.
Require MFA enrollment before the account can access business systems.
Use a temporary activation flow that expires quickly.
Deliver any temporary secret through a separate verified channel.
Force password reset at first login.
Require the first login from the managed device when possible.
Confirm successful login during a live onboarding call for remote employees.

If you use a password manager, invite the employee after identity verification and MFA setup. Shared credentials should be stored in the password manager with role-based access, not sent through chat or email.

For high-risk roles, consider delaying sensitive access until after the employee has completed live onboarding, security training, acceptable use acknowledgement, and device posture checks.

Shipping Laptops Without Feeding a Laptop Farm

Remote work changed the asset handoff problem.

Shipping a laptop is not just a logistics task. It is a security decision.

Before shipping:

Confirm the employee’s identity and start date
Confirm the shipping address through a documented process
Avoid shipping to mail drops, hotels, coworking spaces, freight forwarders, or unrelated third-party addresses unless there is a legitimate approved reason
Require direct signature where practical
Record serial number, tracking number, recipient, and delivery confirmation
Pre-enroll the device in MDM or endpoint management
Encrypt the device before shipment
Install EDR before shipment
Block local admin rights by default
Require MFA and device compliance before business app access
Disable remote desktop tools that are not explicitly approved

At first login:

Have the employee join a live onboarding session
Confirm the device serial number
Confirm that the user can sign in with their own account
Verify that endpoint protection, disk encryption, patching, and MDM check-in are working
Require security training before granting access to sensitive systems

The laptop should arrive as a controlled endpoint, not as a blank check.

Onboarding Should Be a Security Workflow

Most onboarding checklists are built around productivity:

payroll
benefits
equipment
email
team introductions

Those are necessary, but incomplete.

Security onboarding should include:

Acceptable use policy
MFA setup
Password manager setup
Phishing and social engineering awareness
Data classification basics
Customer data handling
Patient data handling, if applicable
Confidential information and trade secret expectations
Remote work expectations
How to report suspicious activity
How to report lost devices
How to request access
How to escalate security concerns without fear of embarrassment

Make this practical. New employees do not need a two-hour lecture full of acronyms. They need to know what data they can access, where it can be stored, what tools are approved, who to ask, and what to do if something feels wrong.

Start With Least Privilege

New employees should not receive broad access just because someone wants to avoid future tickets.

Access should be based on:

role
department
manager approval
business need
data sensitivity
system risk

Create standard access profiles for common roles. For example:

Sales development
Account management
Finance
HR
IT help desk
Developer
Executive assistant
Contractor

Each profile should define what the role gets on day one and what requires separate approval.

For sensitive access, use a second approval step. This includes:

financial systems
payroll
HRIS
production infrastructure
source code
domain administration
customer databases
electronic health records
security tools
backup systems

Admin access should be separate from daily user accounts. Privileged access should use MFA, logging, just-in-time approval where possible, and periodic review.

The goal is not to slow everyone down. The goal is to keep a new hire, compromised account, or bad actor from immediately doing business-ending damage.

You cannot protect trade secrets only with an NDA.

Contracts matter, but trade secrets also require actual protection. If every employee has access to everything, files can be downloaded without logging, and customer lists can be exported to personal email, the business may have a hard time proving it treated that information as secret.

Practical protections include:

Limiting access to confidential information based on role
Using data classification labels
Blocking personal email forwarding
Restricting personal cloud storage
Logging access to sensitive repositories and customer records
Monitoring unusual downloads or mass exports
Using DLP for email, cloud storage, and endpoints
Watermarking sensitive reports where appropriate
Requiring approval for exports of customer lists, source code, pricing models, or patient data
Reviewing access when employees change roles
Removing access immediately during offboarding

Be thoughtful with monitoring. Employees still have privacy rights, and overly aggressive surveillance can create legal and culture problems. Focus on business systems, business data, and clear policies that employees have acknowledged.

Contracts and Policies You Should Discuss With Counsel

This is where HR, legal, and security need to work together.

For employees who can access customer data, patient data, source code, financial data, trade secrets, sales pipelines, pricing, or internal systems, consider counsel-reviewed agreements and policies covering:

Confidentiality and nondisclosure
Trade secret protection
Intellectual property assignment
Acceptable use
Remote work
Bring-your-own-device restrictions
Security awareness and incident reporting
Conflicts of interest
Outside employment
Customer and employee data handling
HIPAA obligations, if applicable
PCI obligations, if applicable
Return of company property
Post-employment confidentiality
Non-solicitation, where lawful and appropriate
Invention assignment, where appropriate

Be especially careful with noncompetes. The federal FTC noncompete rule is not currently enforceable, and state law varies. Minnesota also restricts most new post-employment noncompete agreements entered into on or after July 1, 2023, with limited exceptions. That does not mean businesses have no protection. It means you should rely on properly drafted confidentiality, trade secret, IP, customer data, conflict-of-interest, and non-solicitation provisions where legally appropriate.

Do not download a generic agreement and assume it solves the problem. Employment contracts are one of those places where “cheap” can get expensive quickly.

Overemployment: Treat It as a Policy, Performance, and Conflict Issue

Overemployment means someone is trying to hold multiple full-time jobs at the same time, usually in remote roles, while hiding that fact from one or more employers.

The security concern is not that someone has a side project. Many employees do. The concern is when undisclosed outside work creates:

conflicts of interest
divided attention during business hours
use of company devices for another employer
exposure of confidential data
missed security responsibilities
access by another person in the home
work for a competitor
false time reporting
inability to respond during incidents

Handle this directly in policy.

A good outside employment or conflict-of-interest policy should explain:

whether full-time employees may hold other jobs
whether approval is required
what kinds of outside work are prohibited
expectations for availability during working hours
prohibition on using company devices, accounts, or data for outside work
confidentiality expectations
reporting obligations for conflicts

Then manage the employee based on measurable expectations. Missed meetings, unavailability, poor output, policy violations, suspicious device use, and conflicts of interest are actionable. Vague assumptions are not.

Do Not Forget Contractors, Agencies, and Vendors

Many companies apply more scrutiny to employees than contractors, even when contractors have the same or greater access.

That is backwards.

Contractors, fractional executives, outsourced developers, MSP technicians, recruiters, bookkeepers, marketing agencies, and consultants may touch sensitive systems or data. They need controls too.

At minimum:

Identify who the actual human users are
Prohibit shared vendor accounts
Require MFA
Require named accounts
Limit access by scope and time
Require contractual data protection obligations
Confirm whether subcontractors are allowed
Require notification before personnel changes
Remove access when the engagement ends
Review vendor access periodically

If a vendor manages your systems, they can become an attacker’s easiest path into your business.

A Practical HR Security Checklist

Use this as a starting point.

Before offer:

Define role risk level
Decide what screening is job-related
Use consistent interview and verification steps
Validate employment, licenses, or credentials where needed

After conditional offer:

Complete background screening legally
Complete identity and employment eligibility steps
Validate shipping address before sending equipment
Prepare contracts, policies, and acknowledgements

Before day one:

Create identity provider account
Require MFA
Enroll device in MDM
Install EDR
Assign only baseline role access
Prepare password manager invite
Schedule live security onboarding

During week one:

Confirm device posture
Complete security training
Review data handling expectations
Review acceptable use and remote work rules
Confirm access is sufficient, not excessive

Ongoing:

Review access after 30 to 60 days
Monitor unusual data movement
Review privileged access regularly
Reconfirm conflicts of interest when roles change
Test offboarding process

At termination or resignation:

Disable accounts promptly
Revoke tokens and sessions
Recover devices
Remove password manager access
Review recent sensitive data access
Preserve logs if there is a concern
Remind the employee of continuing confidentiality obligations

Useful Resources

Here are a few places to start:

USCIS Form I-9 and E-Verify guidance
FTC guidance on employment background checks
EEOC guidance on background checks
FTC noncompete rule status
U.S. Department of Justice reporting on North Korean remote IT worker schemes
Minnesota DEED small business note on noncompete changes
Your employment attorney
Your cyber insurance requirements
Your incident response plan
Your written information security program

Final Thought

HR security is not about making hiring hostile.

It is about making trust earned, documented, and appropriately limited.

A good process protects the business, protects customers, protects patients, protects employees, and protects honest applicants from being mixed in with preventable fraud. The best time to build that process is before the offer letter goes out.

Once the laptop ships and the account is active, the clock is already running.

If you are not sure whether your hiring, onboarding, access control, or offboarding process would catch these issues before they become expensive, it is worth taking a closer look.

MN Risk & Cybersecurity Advisory Cybersecurity guidance for small & mid-sized businesses Local. Independent. Vendor-neutral.

Breaking Into Cybersecurity: The Long Way Is Usually The Short Way

Fri, 05 Jun 2026 00:00:00 +0000

There is an entire industry built around the idea that you can break into cybersecurity in a few months.

Buy the bootcamp. Watch the videos. Build a home lab. Pass a certification. Update your LinkedIn headline. Congratulations, you are now a cybersecurity professional.

That story is attractive because it is simple. It is also incomplete.

Cybersecurity is not magic dust sprinkled on top of a resume. It is an applied discipline built on top of IT, networking, identity, operating systems, business processes, risk, and a thousand messy real-world details. If you skip all of that and jump straight to “security,” you may know some vocabulary, but you will struggle to understand what you are actually looking at.

That matters because security work usually starts with context.

Why did this login happen from that location? Is this DNS request normal? What does this firewall rule actually allow? Who owns this server? Is this vulnerability exploitable in this environment? Is this software still used by anyone? Is this an incident, a misconfiguration, or just the way the business works?

You cannot answer those questions from flashcards alone.

Start With IT

If you are starting from zero, the most realistic first step into cybersecurity is probably not a security job.

It is probably an IT help desk role.

There are many paths into security, and some people take less traditional routes. But for most people with no professional technical background, help desk is one of the best starting points because it gives you exposure to the systems security teams are later expected to defend.

On help desk, you learn how users actually use technology. You learn what breaks, what gets misconfigured, what gets ignored, and what people do when a process is inconvenient. You see passwords, MFA, email, endpoints, printers, VPNs, ticketing systems, account lockouts, permissions, software installs, onboarding, offboarding, and all the small operational habits that make up real IT.

That experience is not glamorous, but it is useful.

Security teams need people who understand how technology behaves in an organization. A SOC analyst who does not understand DNS, DHCP, Active Directory, email flow, endpoint management, or basic networking is going to have a hard time separating signal from noise.

A home lab can teach you how a tool works. A real IT job teaches you how technology, people, and business pressure collide.

Certifications Can Help, But Not In The Way People Sell Them

I still think the CompTIA “holy trinity” is a good place to start:

A+
Network+
Security+

Not because those certifications magically make you employable.

They do not.

They are useful because the study material exposes you to topics you may not even know are important yet. A+ gives you hardware, operating systems, troubleshooting, and support fundamentals. Network+ gives you the language of networking. Security+ introduces the basic security concepts you will keep seeing for years.

For someone starting from zero, that structure is valuable.

The mistake is thinking the certificate is the finish line. It is not. The certificate is a map of things you need to keep learning. Passing the exam is less important than building enough familiarity that the next technical conversation does not sound like a foreign language.

After that, you can start looking at more security-focused material. Pentest+ may be useful if you are leaning toward offensive security. Reading CISSP or CISM study material can help you understand governance, risk, and management language, even if you are nowhere near ready to sit for those exams. GIAC material is often excellent if you have access to it, although the price can be hard to justify early in your career.

The point is not to collect logos. The point is to expand your mental model.

Do Not Confuse A Lab With Experience

You will hear a lot of advice about building a home lab.

Some of that advice is fine. Labs are useful for curiosity. They help you break things safely. They let you install tools, test configurations, read logs, and understand concepts by touching them.

But a cheap home lab with non-enterprise gear is not the same thing as professional experience.

Hiring managers know this.

Running a few virtual machines at home is not the same as supporting production systems, working inside change control, responding to real tickets, dealing with real users, managing business constraints, or understanding why a company cannot simply rebuild everything the “right” way overnight.

That does not mean labs are worthless. It means you should be honest about what they are good for.

If you have access to tools at work, learn those first. Pay attention to how your organization actually deploys, configures, monitors, patches, backs up, and secures systems. If your company uses Microsoft 365, learn Microsoft 365. If it uses Intune, learn Intune. If it uses Active Directory, learn Active Directory. If it uses a ticketing system, RMM, EDR, SIEM, firewall, vulnerability scanner, identity provider, or backup platform, learn how those things work in that environment.

Then, when possible, recreate pieces of that environment in a lab. Not because the lab itself is impressive, but because it helps you understand the tools and decisions you are already seeing in the real world.

That is a much better use of your time than building a random stack of tools you saw in a video and never connecting them to business reality.

Learn Everything Around You

If you are in an IT role and want to move toward security, treat your job like a paid apprenticeship.

Learn the ticketing system. Learn the network. Learn identity and access management. Learn how onboarding and offboarding work. Learn how email security is configured. Learn why users get phished. Learn how backups are tested. Learn who approves firewall changes. Learn how devices are patched. Learn how vendors get access. Learn what happens when something breaks after hours.

Talk to people in adjacent departments. Network engineers, sysadmins, cloud engineers, security analysts, auditors, compliance people, managers, and business users all see different parts of the same machine.

Ask good questions:

How does this system fit into the business?
What breaks most often?
What scares you about this environment?
What logs do you actually look at?
What would make this easier to support?
What security controls create the most friction?
What do we do because it is right, and what do we do because insurance or compliance requires it?

The more you pay attention, the more you will realize how much you do not know.

That is not failure. That is the beginning of competence.

Start Speaking The Language

At some point, you need to spend more time around security thinking.

Listen to security podcasts. Watch conference talks. Follow incident writeups. Read vendor blogs with a skeptical eye. Pay attention to how security people talk about identity, logging, detection, risk, vulnerabilities, threat actors, controls, governance, and business impact.

You do not need to understand everything immediately.

At first, the goal is pattern recognition. You are building a vocabulary. You are learning what practitioners care about. You are noticing which topics keep coming up: MFA, phishing, endpoint detection, identity compromise, exposed services, unpatched systems, backups, logging gaps, privilege creep, vendor risk, cloud misconfigurations, and weak processes.

Then connect those topics back to your day job.

If you hear a discussion about MFA fatigue attacks, look at how MFA is configured where you work. If you read about ransomware, look at backup architecture and restore testing. If you watch a talk about Active Directory attacks, learn how your organization handles privileged accounts, service accounts, legacy protocols, and domain admin access.

Security becomes real when it attaches to systems you actually understand.

Go Where Security People Are

Local security meetings are underrated.

Go to meetups, BSides events, ISACA chapters, ISSA chapters, OWASP meetings, local conferences, and informal tech groups when you can. You do not need to be an expert to show up. You just need to be curious and respectful of people’s time.

These communities help in a few ways.

You hear what people are working on. You learn what roles actually exist. You meet people who can explain the difference between job titles that look identical from the outside. You find out which employers are good places to learn and which ones are constantly burning people out. You also start becoming a familiar face, which matters more than people like to admit.

Do not show up asking everyone for a job on day one.

Show up to learn. Ask thoughtful questions. Follow up. Volunteer if there are opportunities. Over time, people remember the person who kept showing up, kept learning, and did not pretend to know more than they did.

Secure The Technology You Already Touch

One of the best ways to prepare for a security role is to secure the technology already in front of you.

Pick a system you work with and go deeper.

Read the hardening guide. Review the admin documentation. Learn the logging options. Understand the default settings. Find the security baseline. Compare it to how your organization has it configured. Ask why the differences exist.

Do this with Windows, Linux, Microsoft 365, Google Workspace, firewalls, switches, VPNs, EDR tools, SaaS platforms, backup software, whatever you can responsibly access.

This is where the work starts to become practical.

You stop thinking of security as a separate universe and start seeing it as a property of every system. Secure configuration, least privilege, patching, monitoring, incident response, resilience, and documentation are all part of the same picture.

The Timeline Is Longer Than The Sales Pitch

Here is the tough-love version:

If you are starting from zero, it may take years before you are ready for your first real security role.

Maybe not five years exactly. Some people move faster. Some people get lucky. Some people find hybrid roles where they can grow into security responsibilities while still doing IT work. But “five years” is a much more honest planning number than “90 days.”

That is not meant to discourage you.

It is meant to set expectations correctly.

The long road is not wasted time. Help desk experience is not wasted time. Networking fundamentals are not wasted time. Troubleshooting printers, fixing account lockouts, cleaning up permissions, documenting weird software dependencies, and learning how users actually behave are not beneath you.

That is the ground floor of understanding how organizations really work.

Cybersecurity is full of people who want to skip the boring parts. The problem is that the boring parts are where a lot of the useful knowledge lives.

A Better Path From Zero

If I were giving someone a practical path from zero, it would look something like this:

Get basic IT fundamentals.
Earn A+, Network+, and Security+ if you need structure and early credibility.
Get an entry-level IT role, likely help desk.
Learn everything you can about the systems around you.
Take notes constantly.
Build small labs that reinforce what you see at work.
Study security concepts in parallel.
Attend local security and IT events.
Read hardening guides for technology you actually touch.
Look for chances to help with security-adjacent work: MFA rollouts, phishing reporting, patching, asset inventory, vulnerability remediation, access reviews, backups, logging, documentation, and incident response.

That path is slower than a bootcamp ad.

It is also much more likely to turn you into someone useful.

The goal is not to “break into cybersecurity” as quickly as possible. The goal is to become the kind of person a security team can trust with real systems, real incidents, real risk, and real business consequences.

That takes time.

But if you keep learning, keep asking better questions, and keep connecting security ideas to actual technology, you will be building something far more durable than a certificate collection.

Schedule a cybersecurity review

The Conflict of Interest in MSP Security Audits

Wed, 03 Jun 2026 00:00:00 +0000

The Conflict of Interest in MSP Security Audits

Managed service providers do a fantastic job for many businesses.

A good MSP keeps systems patched, answers urgent calls, manages backups, supports users, watches the network, and helps the company keep moving when technology gets messy. For small and mid-sized businesses, that relationship can be incredibly valuable.

But there is one area where businesses should be careful:

Letting the same company audit the work it performs.

That is a textbook conflict of interest.

It does not mean the MSP is dishonest. It does not mean they are doing poor work. In fact, a strong MSP should be checking its own work constantly. Internal reviews, monitoring, ticket reviews, vulnerability scans, backup checks, and security improvements are all signs of a provider that takes its role seriously.

The problem is independence.

Self-review is useful, but it is not independent

Every service provider should verify its own work.

If your MSP manages backups, they should be checking whether backups are running. If they manage endpoint protection, they should be watching alerts. If they manage Microsoft 365, they should be reviewing configuration changes, risky sign-ins, and security settings.

That type of operational review matters.

But self-review has limits.

When the same company designs the network, manages the tools, configures the security controls, and then grades the results, the business is missing an outside perspective.

Even the best teams can overlook their own assumptions. People naturally trust the systems they built. They know why decisions were made, what tradeoffs existed at the time, and where budget or operational constraints shaped the outcome.

That context is useful, but it can also make risks feel normal.

An outside reviewer sees the environment differently

An outside security provider has a different role.

Their job is not to defend past decisions or protect an existing support relationship. Their job is to ask whether the current setup actually reduces risk.

That independent review can help answer practical questions:

Are backups protected from ransomware?
Are administrator accounts controlled and monitored?
Is multi-factor authentication enforced where it matters?
Are old accounts, exposed services, or weak configurations still lingering?
Are security tools installed, configured correctly, and producing useful alerts?
Are policies and procedures realistic for how the business actually works?
Would insurance, compliance, or customer requirements stand up to scrutiny?

Those questions are not an attack on the MSP.

They are the kind of questions every business should be asking.

This should make the MSP relationship stronger

Independent review should not be about replacing the MSP.

In many cases, the best outcome is a better partnership between the business, the MSP, and an independent security reviewer.

The MSP keeps doing the day-to-day technology work. The outside security provider periodically validates the risk picture, identifies blind spots, and helps the business make informed decisions.

That separation matters because security is not only about effort.

It is about accountability.

Every business benefits when someone independent can say:

Here is what is working, here is what needs attention, and here is what should be prioritized next.

That kind of review keeps everyone honest without turning the relationship adversarial.

The business owns the decision

Your MSP can recommend improvements. Your MSP can implement tools. Your MSP can support users, manage systems, and help reduce technical risk.

But the business still owns the risk decision.

Leadership needs to know whether the current security program is appropriate for the business, not just whether a vendor says the environment looks fine.

That is why outside validation matters.

The MSP should welcome it. The business should expect it. And the security provider should approach it with respect for the work already being done.

Good providers check their own work.

Strong businesses also get a second set of eyes.

Need a second set of eyes?

If you want an independent review of your current security posture, MN Risk & Cybersecurity Advisory can help evaluate what is working, where gaps may exist, and what should be prioritized next.

This is not about replacing your MSP. It is about giving your business clear, independent validation.

40.6% of Hutchinson Area Businesses Are Not Using SPF Hardfail

Tue, 02 Jun 2026 00:00:00 +0000

40.6% of Hutchinson Area Businesses Are Not Using SPF Hardfail

Email fraud does not usually start with a dramatic breach. Often, it starts with a message that looks like it came from a trusted local business.

In a recent review of Hutchinson area customer domains, MNrisk found that 158 businesses, or 40.6% of the dataset, are using SPF softfail (~all) instead of SPF hardfail (-all).

That detail may look small, but it matters.

What SPF Softfail Means

SPF, or Sender Policy Framework, is a DNS record that tells receiving mail systems which servers are allowed to send email for a domain.

Many businesses have an SPF record that ends with:

~all

That ~all is called a softfail. It tells mail systems, in effect: “If this message comes from a server that is not listed here, treat it as suspicious, but do not necessarily reject it.”

A stronger SPF record ends with:

-all

That -all is called a hardfail. It tells mail systems: “If this message does not come from an approved sender, it should fail SPF.”

Why This Matters For Local Businesses

Attackers do not need to compromise your inbox to abuse your name. If your domain’s email authentication is loose, criminals may have an easier time sending messages that appear to come from your business.

That can create risk for:

Customers receiving fake invoices or payment-change requests
Employees receiving spoofed messages from ownership or managers
Vendors receiving fraudulent order or wiring instructions
The business reputation attached to your domain name

SPF hardfail is not a complete email security strategy by itself, but it is one important part of reducing spoofing risk.

Do Not Switch Blindly

There is an important caution here: a business should not change from ~all to -all until legitimate senders are validated.

Many organizations send email through several systems, including Microsoft 365, Google Workspace, website contact forms, accounting platforms, CRM tools, marketing platforms, ticketing systems, and industry-specific software.

If one of those systems is missing from the SPF record, moving straight to hardfail can cause legitimate messages to fail authentication.

The right process is:

Identify every service that sends email for your domain.
Confirm each service is represented correctly in your SPF record.
Remove old or unused senders.
Check DKIM and DMARC alignment at the same time.
Move from ~all to -all once the record is clean.

What The 40.6% Number Tells Us

The finding is not that these businesses are doing nothing. In fact, having SPF at all is a good starting point.

The issue is that many local domains appear to be sitting in a “partially configured” state. SPF was added at some point, but it may never have been tightened after the business confirmed who should be allowed to send email.

That is common. DNS records get created during a Microsoft 365 migration, a website launch, or an email provider change, then they are rarely revisited.

But email security is not a set-it-and-forget-it item. As businesses add new tools, retire vendors, or change IT providers, their email authentication records should be reviewed too.

A Practical Next Step

If your business uses a custom domain for email, ask your IT provider or security partner to review your SPF, DKIM, and DMARC records.

At minimum, you want to know:

Who is authorized to send email for your domain?
Are any old vendors still listed?
Is your SPF record still using ~all?
Can your domain safely move to -all?
Is DMARC configured to monitor or enforce suspicious mail?

For many small businesses, this is a quick review. For businesses with multiple software platforms sending email, it may take a little more discovery. Either way, it is easier to fix before a spoofed invoice or fake payment request creates confusion.

Bottom Line

In MNrisk’s customer data, 40.6% of Hutchinson area businesses reviewed are using SPF softfail instead of hardfail.

That means there is a clear opportunity for local businesses to strengthen email authentication without buying another tool or adding complexity. Validate legitimate senders first, then consider moving SPF from ~all to -all as part of a broader SPF, DKIM, and DMARC review.

Small DNS details can carry real business risk. This is one worth checking.

Need Help Reviewing Your Email Security?

MN Risk & Cybersecurity Advisory helps businesses review SPF, DKIM, DMARC, DNS records, and the systems that send email on behalf of their domain.

If you are not sure whether your domain can safely move from ~all to -all, we can help identify legitimate senders, clean up old records, and build a practical path toward stronger email authentication.

Feel free to reach out if you would like help reviewing your email security posture.

CAA Records: 97.7% of Hutchinson Domains Are Missing Them

Sat, 30 May 2026 00:00:00 +0000

Why CAA DNS Records Matter

Recently, I tested domains associated with businesses and organizations in the Hutchinson area. One statistic stood out:

97.7% of the domains tested did not have a CAA DNS record configured.

That does not mean those websites are insecure. It does suggest that many organizations are missing a simple, free security control that helps protect one of the most important trust systems on the Internet: SSL/TLS certificates.

What Is a CAA Record?

CAA stands for Certification Authority Authorization.

A CAA record tells certificate authorities which organizations are allowed to issue SSL/TLS certificates for your domain.

Without a CAA record, any trusted public certificate authority can issue a certificate for your domain if they successfully complete the required validation checks.

With a CAA record, you can explicitly define which certificate authorities are permitted to issue certificates for your domain.

For example, this authorizes Let’s Encrypt:

example.com. IN CAA 0 issue "letsencrypt.org"

Why Does This Matter?

SSL certificates are the foundation of HTTPS. They help ensure visitors are communicating with the legitimate website and not an impostor.

Certificate authorities generally do a good job validating certificate requests, but no process is perfect. Misissued certificates have happened before.

A CAA record adds another layer of control. It tells certificate authorities, “Only these approved providers may issue certificates for this domain.”

That matters because certificates are trust objects. If a certificate is issued incorrectly, it can create opportunities for impersonation, phishing, or interception in certain attack scenarios.

A Simple Example

Imagine your company uses Let’s Encrypt for all website certificates.

Without a CAA record:

Any trusted certificate authority could potentially issue a certificate after completing validation.
You have less control over the certificate issuance process.
You rely entirely on external validation controls.

With a CAA record:

Only Let’s Encrypt is authorized to issue certificates.
Other certificate authorities must reject issuance requests.
Unauthorized issuance attempts can be reported to you.

This reduces risk and improves visibility into certificate activity.

Why So Few Organizations Use CAA Records

Most organizations are familiar with DNS records such as:

A
AAAA
MX
SPF
DKIM
DMARC

CAA records rarely receive the same attention.

Unlike SPF, DKIM, and DMARC, CAA records do not usually solve a visible day-to-day business problem. Websites continue to work normally without them, so they are easy to overlook.

Many hosting providers and website platforms also do not create them automatically.

As a result, they are often missing from otherwise well-managed DNS environments.

Are CAA Records Required?

No.

Your website will work without one.

However, cybersecurity is about layers. Not every control needs to be expensive, complicated, or disruptive.

CAA records are:

Free
Easy to deploy
Widely supported
Low maintenance
Helpful for reducing certificate issuance risk

For most organizations, adding one takes only a few minutes.

Common CAA Configurations

Allow Let’s Encrypt:

example.com. IN CAA 0 issue "letsencrypt.org"

Allow DigiCert:

example.com. IN CAA 0 issue "digicert.com"

Allow multiple certificate authorities:

example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issue "digicert.com"

Receive notifications about certificate issuance events:

example.com. IN CAA 0 iodef "mailto:security@example.com"

How to Check Your Domain

You can check whether a domain has a CAA record configured with:

dig example.com CAA

Or:

nslookup -type=CAA example.com

If no records are returned, your domain likely does not have a CAA policy configured.

The Bigger Picture

When nearly 98% of local domains are missing a security control, it is usually not because organizations have consciously decided against it.

More often, it simply means the control is not widely known.

That is exactly where CAA records sit today.

They are not flashy. They will not stop every attack. They are not a substitute for proper certificate management.

But they are another layer of defense that helps ensure only approved certificate authorities can issue certificates for your domain.

For a control that is free, easy to implement, and requires very little ongoing maintenance, that is a worthwhile improvement.

Need Help Reviewing Your DNS Security?

MN Risk & Cybersecurity Advisory helps organizations assess DNS security, email security, certificate management, and overall cybersecurity risk.

Whether you are looking at SPF, DKIM, DMARC, CAA, DNSSEC, or broader cybersecurity concerns, we can help you understand your options and reduce risk.

Feel free to reach out if you would like help reviewing your DNS security posture.

Why Businesses Benefit From an Independent Cybersecurity Partner

Wed, 27 May 2026 00:00:00 +0000

Why Businesses Benefit From an Independent Cybersecurity Partner

Managed Service Providers (MSPs) do a tremendous amount of good work for businesses every day. They keep systems running, manage infrastructure, support users, maintain backups, deploy tooling, and solve countless operational problems behind the scenes.

For many small and mid-sized businesses, their MSP is one of their most valuable technology partners.

But cybersecurity and IT operations are not always the same thing.

That is where an independent cybersecurity advisor or vCISO relationship can provide enormous value, not just for the business, but for the MSP and ultimately the customers being protected.

Security Oversight Should Be Independent

In almost every mature industry, oversight and implementation are separated.

Financial audits are performed independently
Insurance inspections are performed independently
Building inspections are performed independently
Legal reviews are performed independently

Cybersecurity is no different.

An MSP may deploy and manage technology, but an independent cybersecurity partner provides a second set of eyes focused entirely on risk, governance, exposure, and business impact.

That separation creates accountability, transparency, and better decision-making.

This is not about distrust. It is about reducing blind spots.

MSPs Are Often Wearing Too Many Hats

Most MSPs are expected to handle:

Helpdesk support
Networking
Microsoft 365 administration
Endpoint management
Backups
Vendor management
Procurement
Cloud migrations
Firewalls
Compliance requests
Security tooling
Incident response

That is an enormous amount of responsibility.

Even highly capable MSPs can struggle to dedicate enough time to strategic cybersecurity planning because the operational workload never stops.

An independent cybersecurity advisor helps fill that gap by focusing on:

Risk management
Security program maturity
Policy and governance
Compliance alignment
Executive reporting
Vendor risk
Business continuity
Incident preparedness
Security architecture reviews
Third-party validation

This allows the MSP to continue doing what they do best while security strategy receives dedicated attention.

A Dedicated Security Partner Protects The MSP Too

Good MSPs should welcome independent review.

Why?

Because cybersecurity risk increasingly lands on everyone involved after an incident.

When a ransomware event occurs or sensitive data is exposed, businesses often ask questions like:

Was MFA enabled everywhere?
Were backups tested?
Was logging configured correctly?
Were systems patched appropriately?
Were risky exposures documented?
Was leadership informed of the risks?

Independent security reviews help create clarity around these decisions.

That protects the business, but it also protects the MSP by demonstrating that risks were discussed, evaluated, prioritized, and documented appropriately.

A strong cybersecurity advisor should never operate adversarially toward the MSP. The relationship works best when both sides collaborate.

Businesses Need Strategy, Not Just Technology

Buying security products is not the same thing as having a security strategy.

Many organizations today have excellent tools but lack:

Defined risk ownership
Security policies
Incident response planning
Vendor review processes
Data classification guidance
AI usage governance
Security awareness planning
Executive reporting
Long-term security roadmaps

Technology alone does not answer business questions like:

What risks matter most to us?
What should we prioritize first?
Are we overspending in some areas and underinvesting in others?
What happens if a vendor is breached?
How do we measure improvement over time?
Are we prepared for customer security questionnaires?
Could we survive a ransomware incident operationally?

These are business risk discussions, not just IT discussions.

Every organization develops assumptions over time.

That is normal.

An outside cybersecurity advisor can help identify:

Legacy configurations everyone forgot about
Overly permissive access
Compliance drift
Tool overlap and waste
Internet exposures
Weak vendor controls
Missing documentation
Unclear ownership responsibilities
Gaps between leadership expectations and operational reality

Fresh perspective matters.

Sometimes the most valuable outcome is simply validating that things are already being done correctly.

Security Is Becoming A Business Requirement

Customers, insurers, regulators, and partners increasingly expect businesses to demonstrate cybersecurity maturity.

Organizations are routinely asked about:

MFA adoption
Endpoint protection
Vulnerability management
Incident response
Backup testing
Security awareness training
Vendor risk management
Logging and monitoring
Cyber insurance controls
AI governance and data handling

An independent cybersecurity partner helps organizations answer these questions confidently and consistently.

That support can make a major difference during:

Cyber insurance renewals
Customer onboarding
Vendor questionnaires
Compliance audits
Contract negotiations
Security reviews from larger clients

The Goal Is Partnership, Not Replacement

A cybersecurity advisor should not replace your MSP.

The best outcomes happen when:

The MSP handles implementation and operations
Leadership owns business decisions
An independent cybersecurity advisor provides strategy, oversight, and risk guidance

Those roles complement each other.

Businesses benefit from clearer accountability. MSPs benefit from strategic alignment and shared visibility. Customers benefit from stronger security outcomes.

That is a win for everyone.

Final Thoughts

Cybersecurity has evolved far beyond antivirus and firewalls.

Today, it is a business risk management function that touches operations, legal exposure, insurance, compliance, customer trust, and executive decision-making.

MSPs remain incredibly important partners in that equation.

But independent cybersecurity oversight adds an additional layer of protection and clarity that many organizations are currently missing.

The goal is not to create friction.

The goal is to help businesses make better-informed security decisions before a crisis forces them to.

Need An Independent Security Perspective?

Whether you already work with an MSP, internal IT team, or outside vendors, an independent cybersecurity review can help identify gaps, validate assumptions, and build a clearer long-term security strategy.

The goal is not to replace your existing partners. The goal is to strengthen the overall security posture of the business while improving communication between leadership, IT, and security stakeholders.

If your organization would benefit from:

A dedicated cybersecurity advisor
Risk and security program guidance
Security roadmap development
Vendor and tool review
Compliance readiness support
Executive-level security reporting
Independent security assessments

MN Risk & Cybersecurity Advisory can help.

Reach out today for a conversation about your current environment, risks, and long-term security goals.

free to reach out

Not every datacenter is an existential threat

Tue, 26 May 2026 00:00:00 +0000

Not Every Datacenter Is an Existential Threat

There was a recent post from the Hutchinson Economic Development Authority addressing rumors surrounding a proposed datacenter project in Hutchinson. The post clarified that no formal paperwork had been filed yet.

That is an important detail. At this point, there are still unknowns.

We do not know the final design, the power requirements, the water usage, the ownership structure, the tax arrangement, or the long-term economic impact. Those are all fair questions for the community to ask.

But we should also be careful not to assume every project with the word “datacenter” attached to it is the same thing.

A lot of the online reaction seems to treat this proposed Hutchinson project like it is one of the massive AI datacenter campuses making national headlines. Based on the publicly discussed size, that does not appear to be the case.

The proposed site is reportedly around 80,000 square feet on the east side of town in the industrial area.

That may sound large, but in the world of datacenters, that is a relatively modest footprint. Once you account for setbacks, parking, loading areas, utility access, cooling equipment, and general site layout, this appears much closer to a small regional colocation or enterprise-style facility than a hyperscale AI campus.

That distinction matters.

Scale Changes the Conversation

Here is a quick visual comparison between a typical hyperscale datacenter campus and the size of what appears to be proposed in Hutchinson:

An 80,000 square foot site is about 1.8 acres.

By comparison, many hyperscale datacenter campuses are 100 acres or more. Some are several hundred acres when fully built out.

To put that into perspective:

80,000 square feet is roughly the size of a medium-sized industrial building or small warehouse site
100 acres is about 4.3 million square feet
A 100-acre campus is more than 50 times larger than an 80,000 square foot site

Those are very different projects.

The concerns people have about massive AI datacenter campuses are not imaginary. Large hyperscale projects can consume enormous amounts of electricity, require major utility upgrades, use significant water depending on cooling design, and sometimes receive large public subsidy packages while creating fewer long-term jobs than people expect.

Those are real issues.

But applying those concerns directly to every smaller datacenter proposal can lead to a distorted conversation.

What We Should Be Asking

None of this means Hutchinson should approve anything blindly.

A datacenter, even a smaller one, is still infrastructure. The city and community should ask practical questions before any project moves forward.

Some of the right questions include:

How much electricity would the facility require?
Would it require utility upgrades?
Would it use water for cooling?
How much water would it use?
Would there be backup generators on site?
What noise controls would be in place?
How many permanent jobs would it create?
Would the city offer tax abatements, TIF, or other incentives?
What would the net tax benefit be after incentives?
What happens if the facility changes ownership or use later?

Those are reasonable questions.

The point is not that every datacenter is automatically good. The point is that every datacenter is not automatically bad either.

Not All Datacenters Are the Same

The word “datacenter” covers a lot of very different things.

It can mean:

A small regional facility hosting local business servers
A colocation facility where companies rent secure rack space
A carrier hotel where internet and telecom providers interconnect
A private enterprise datacenter for a hospital, manufacturer, or financial institution
A cloud facility supporting regional workloads
A massive hyperscale AI training campus with hundreds of thousands of GPUs

Those are not interchangeable.

A small regional colocation facility and a multi-hundred-acre AI training campus have about as much in common as a local airport and a major international cargo hub. They are related categories, but the scale, purpose, and impact are completely different.

Small Regional Datacenters

Smaller regional datacenters are often used for:

Colocation
Backup and disaster recovery
Managed hosting
Business continuity
Local or regional connectivity
Low-latency services

These facilities can provide real upside when they are sized appropriately and when the public deal makes sense.

Potential benefits include:

Better regional internet infrastructure
More fiber investment
Improved redundancy for local businesses
Technical jobs
Support for MSPs, telecom providers, and technology companies
More options for businesses that need secure local infrastructure

For communities trying to attract technology, healthcare, manufacturing, professional services, or remote work opportunities, better infrastructure can matter.

Carrier Hotels and Interconnection Facilities

A carrier hotel is a type of datacenter where network providers, telecom companies, cloud providers, and enterprises physically connect to one another.

These facilities can be especially valuable because they improve connectivity.

Benefits can include:

Lower latency
Better internet resiliency
More provider competition
More routing options
Stronger regional technology infrastructure

Not every datacenter is a carrier hotel, but this is a good example of why the category is more nuanced than people often assume.

Some datacenters are not just buildings full of servers. They are connectivity hubs.

Enterprise Datacenters

Some datacenters are built for a single organization.

Examples might include:

Hospitals
Universities
Manufacturers
Financial institutions
Government agencies

Even with the growth of cloud computing, there are still reasons an organization may want local or regional infrastructure. These can include regulatory requirements, latency-sensitive systems, manufacturing operations, business continuity, or operational control.

Again, this is very different from a hyperscale AI campus.

Hyperscale AI Datacenters

Hyperscale AI datacenters are the facilities getting most of the national attention right now.

These are enormous campuses built by or for major cloud and AI companies. They are often designed for:

AI model training
GPU compute clusters
Large-scale cloud workloads
Massive storage systems
AI inference at scale

These projects can be hundreds of acres. They can require hundreds of megawatts of power. Some future proposals are even larger.

This is where many of the serious concerns come from.

The Real Concerns With Hyperscale AI Facilities

The criticism of hyperscale AI datacenters is not baseless.

Large projects can create real community tradeoffs.

Power Consumption

Large AI datacenters can require enormous amounts of electricity.

That can create concerns around:

Grid capacity
Utility upgrades
Energy pricing
New generation requirements
Infrastructure costs passed on to ratepayers

A smaller regional facility may barely register compared to a massive AI campus. Scale matters.

Water Usage

Some datacenter cooling designs use significant water.

That makes it important to ask:

What cooling method will be used?
How much water will be required?
Where will the water come from?
Is the usage sustainable?
What happens during drought or peak demand?

Not every datacenter uses the same cooling model, so this should be evaluated based on the actual project.

Limited Long-Term Employment

Large datacenter projects can create significant temporary construction work, but long-term staffing is often more modest than people expect.

That does not mean the jobs are worthless. Many are skilled, technical, and well-paying.

But communities should be realistic about the permanent employment numbers, especially if large incentives are being discussed.

Tax Incentives and TIF

This may be the most important local issue.

A datacenter can be a good project, a bad project, or somewhere in between depending on the public deal.

Cities should be cautious with:

Tax abatements
TIF districts
Sales tax exemptions
Utility discounts
Public infrastructure subsidies

There is a big difference between a project that pays its way and strengthens the tax base, and a project where the public gives away too much of the upside.

The details matter.

The Bottom Line

Hutchinson should ask questions. That is how local government is supposed to work.

But the conversation should be grounded in the actual scale of what is being discussed.

Based on the publicly discussed size, this does not appear to be a massive AI datacenter campus. It appears much closer to a small regional colocation or enterprise-style facility.

That does not automatically make it good.

It also does not automatically make it bad.

The right approach is to evaluate the actual proposal when details are available:

What is the size?
What is the use?
What are the power and water requirements?
What infrastructure is needed?
What incentives are being requested?
What is the net benefit to the community?
What protections are included for residents and taxpayers?

“Datacenter” is a broad term. Some are massive resource-intensive AI campuses. Some are modest infrastructure facilities that can strengthen local connectivity and support business growth.

Those should not be treated as the same thing.

A rational conversation starts with scale, facts, and a clear-eyed look at the tradeoffs.

Source: Tom’s Hardware: Pizza Hut’s AI delivery system cooks up $100 million franchisee lawsuit

AI Disinvestment: When the Hype Cycle Starts Sending Invoices

Sun, 24 May 2026 00:00:00 +0000

AI Disinvestment: When the Hype Cycle Starts Sending Invoices

It feels like the wheels are starting to come off the AI bus.

Do not get me wrong. AI is useful. It can help summarize documents, draft content, analyze data, support developers, speed up research, and reduce repetitive work. Used well, it can be a real force multiplier.

But that is very different from the story many companies were sold.

The pitch was not just, “AI can help your team work faster.” The pitch was closer to, “AI will transform everything, replace huge parts of your workforce, and create massive returns almost immediately.”

That version of the story is starting to look shaky.

Are We In An AI Bubble?

Maybe.

There is no doubt that AI will keep improving. The tools are already impressive, and the next few years will almost certainly bring better models, better integrations, and more practical business use cases.

But the current AI landscape often feels less like a refined business transformation and more like a brute-force effort.

More GPUs. Bigger data centers. Larger models. Higher token spend. More automation. More agents. More promises.

At some point, businesses have to ask a boring but important question:

Is this actually producing value?

That question is where the AI disinvestment conversation starts.

AI disinvestment does not mean abandoning AI. It means pulling back from wasteful, poorly planned, or low-value AI projects and redirecting money toward initiatives that actually support the business.

The Pilot Problem

A widely discussed MIT report found that 95% of enterprise generative AI pilots were failing to produce meaningful results. The key issue was not necessarily that the models were bad. The bigger problem was that companies struggled to integrate AI into real workflows in a way that changed productivity, revenue, or operations.

Source: Fortune: MIT report says 95% of generative AI pilots are failing

That should sound familiar.

A lot of AI projects start like this:

An executive hears that competitors are “doing AI.”
A team is told to find a use case.
A pilot is launched.
People use it for a few demos.
The tool never becomes part of the actual business process.
Everyone quietly moves on.

That is not transformation. That is experimentation without a strategy.

There is nothing wrong with experimenting. The problem is pretending every experiment is a business case.

The Productivity Paradox Is Back

Fortune also reported that thousands of CEOs said AI had no measurable impact on employment or productivity, raising comparisons to the old productivity paradox from the computer era.

Source: Fortune: CEOs say AI has had no impact on employment or productivity

That does not mean AI is useless.

It means productivity gains are not automatic.

Giving employees access to AI tools does not magically redesign business processes. It does not clean up messy data. It does not fix unclear ownership. It does not replace governance. It does not solve bad strategy.

AI can accelerate a good process.

It can also accelerate a bad one.

Replacing People With AI Is Not A Strategy

One of the most expensive mistakes companies can make is assuming AI is a direct headcount replacement.

Forbes reported that some companies that cut workers because of AI are now bringing people back.

Source: Forbes: Companies Fired Workers For AI. Now They Want Them Back

That should not be surprising.

People do more than complete tasks. They understand context. They notice when something feels wrong. They deal with exceptions. They understand customers, vendors, politics, process gaps, and institutional knowledge.

AI may reduce some repetitive work, but replacing experienced employees before the system is proven is a risky bet.

The better strategy is usually human amplification:

Help existing teams move faster
Reduce repetitive administrative work
Improve first drafts and analysis
Support decision-making
Keep humans accountable for judgment, risk, and outcomes

The goal should not be “how many people can we replace?”

The better question is:

How do we make our best people more effective?

Operational Reality Still Matters

The difference between an AI demo and a working business system is massive.

Starbucks reportedly scrapped an AI inventory tool across North America after the system struggled with inaccurate counts and product identification issues.

Source: Reuters: Starbucks scraps AI inventory tool across North America

Pizza Hut is also facing a $100 million lawsuit from a major franchisee over an AI-powered delivery management system. The franchisee alleges that delivery times worsened, customer satisfaction dropped, and sales declined after the system changed how delivery coordination worked.

These are not abstract problems.

They are real-world examples of AI systems colliding with messy operations.

The AI may work in the lab. The workflow may look good in a slide deck. The vendor demo may be impressive.

But then the system hits real stores, real drivers, real customers, real inventory, real incentives, and real edge cases.

That is where many AI projects fail.

The Cost Problem Is Getting Harder To Ignore

AI is not free.

Advanced models can be expensive to run, especially when companies start using agentic workflows that make multiple calls, process large context windows, or run continuously in the background.

The cost problem is not limited to software subscriptions. It also shows up in infrastructure.

xAI’s Colossus project describes itself as a massive AI training supercomputer.

Source: xAI: Colossus

At the same time, Wccftech reported that xAI was using only about 11% of its GPU capacity, citing reporting from The Information.

Source: Wccftech: xAI using just 11 percent of GPUs

That may be a temporary utilization issue, and AI infrastructure is complicated. But it highlights an important business lesson:

Buying a massive amount of capacity is not the same thing as turning it into productive value.

The same is true for small and mid-sized businesses.

Buying AI tools is easy.

Getting measurable value from them is harder.

AI Disinvestment Is Not Anti-AI

This is the part that gets lost in the hype cycle.

Being skeptical of AI spending does not mean being against AI.

It means being against waste.

It means asking normal business questions:

What problem are we solving?
Who owns the outcome?
What process is changing?
What data does the system need?
What happens when the AI is wrong?
What does this cost at full usage?
What security and privacy risks are being introduced?
How will we measure success?
When do we shut it down if it does not work?

That last question is important.

Every AI initiative should have an exit ramp.

If the project does not reduce cost, improve quality, reduce risk, increase revenue, or meaningfully improve speed, then it should be reviewed. If it still cannot justify itself, it should be retired.

That is not failure. That is responsible governance.

The Security And Risk Side Cannot Be An Afterthought

AI projects often create new risks faster than companies can manage them.

Common issues include:

Sensitive data being pasted into public tools
Employees connecting AI tools to local files without oversight
Shadow AI subscriptions outside IT visibility
Unclear data retention and training policies
Weak access controls around AI agents
Unreviewed plugins, connectors, and MCP servers
AI-generated code entering production without proper review
Vendors making broad AI claims without clear security documentation

This is where business strategy, cybersecurity, legal, compliance, and operations need to work together.

AI should not be treated as just another software purchase. In many cases, it changes how data moves, how decisions are made, and who or what has access to sensitive business information.

That requires governance.

Not bureaucracy. Governance.

There is a difference.

A Better AI Strategy

A practical AI strategy should start small and stay tied to business outcomes.

A good approach looks more like this:

Pick a real business problem
Do not start with “we need AI.” Start with a pain point.
Use AI to support people, not blindly replace them
Look for ways to make existing teams faster and more consistent.
Measure the outcome
Track time saved, error reduction, customer impact, revenue impact, or risk reduction.
Control the data
Know what information users can upload, where it goes, and how it is stored.
Define acceptable use
Employees need clear guidance on what they can and cannot do with AI tools.
Review vendors carefully
Understand their security posture, data handling, retention, access controls, and contractual terms.
Watch the spend
Token usage, premium subscriptions, and agentic workflows can get expensive quickly.
Shut down what does not work
A failed pilot should not become a permanent line item.

The Real Opportunity

AI is not going away.

But the easy money phase may be ending. The companies that win with AI will probably not be the ones that bought the most tools, launched the most pilots, or replaced people the fastest.

The winners will be the companies that slow down long enough to ask better questions.

Where can AI help our people?

Where can it reduce friction?

Where can it improve quality?

Where does it create unacceptable risk?

Where is the ROI real, and where are we just chasing the hype cycle?

AI can absolutely be valuable.

But value does not come from plugging in a chatbot and hoping magic falls out.

It comes from strategy, governance, process design, security, and clear business ownership.

That may not be as exciting as the sales pitch.

But it is a lot more likely to work.

Need Help Reviewing Your AI Strategy?

If your business is using AI, considering AI tools, or trying to figure out whether the investment is actually worth it, now is the time to step back and review the strategy.

MN Risk can help evaluate AI use cases, security risks, vendor claims, governance gaps, and whether your AI projects are aligned with real business outcomes.

AI should make your business stronger.

It should not become another expensive tool nobody can explain.

AI Security Is Not Just an Acceptable Use Policy

Tue, 19 May 2026 00:00:00 +0000

AI Security Is Not Just an Acceptable Use Policy

Artificial intelligence tools are showing up everywhere.

Employees are using AI to write emails, summarize documents, analyze spreadsheets, generate code, review contracts, search internal knowledge, and automate repetitive work. In many cases, that is a good thing. AI can help people move faster, improve quality, and reduce manual effort.

But there is a growing security problem that many businesses have not fully addressed yet:

Who gets to decide which AI tools can connect to your business systems?

That question matters a lot.

It is one thing for an employee to ask an AI tool to rewrite a public marketing paragraph. It is very different for an employee to connect a personal AI account to company email, file storage, chat, customer records, source code, ticketing systems, or other internal applications.

That is where the risk changes.

The Real AI Security Gap

A lot of businesses already have an AI policy.

It might say things like:

Do not paste confidential information into public AI tools.
Do not upload client files into unapproved AI systems.
Do not use personal AI accounts for company work.
Only use approved AI tools for sensitive business data.

That is a good start.

But a policy alone does not stop anything.

The real problem is that employees may still be able to connect unapproved AI tools to business applications using their normal work account. In many environments, users can approve third-party apps, browser extensions, automation platforms, AI assistants, or other integrations without much oversight.

From the employee’s point of view, they are just trying to get work done.

From the business’s point of view, a personal or unmanaged AI tool may now have access to sensitive company data.

That can include:

Client information
Internal chat messages
Email content
Documents
Spreadsheets
Source code
Meeting notes
Financial records
Customer records
Support tickets
Strategic plans

This is not just a theoretical risk. AI tools can act as a force multiplier. A bad copy-and-paste decision is one thing. An AI tool with access to an entire file library, mailbox, or chat history is something else entirely.

The Problem With Personal AI Accounts

One of the biggest risks is personal account usage.

Many AI platforms offer both personal and business versions. The business version may include better security terms, administrative controls, logging, retention settings, privacy commitments, and data protection options.

The personal version may not.

That creates a major governance issue.

An employee may sign into an AI tool with a personal account and then connect it to a business system. The company may not have visibility into that account. It may not be able to review activity, manage retention, disable access, enforce data protection settings, or confirm whether business data is being handled appropriately.

That is a problem.

The issue is not simply “AI is bad” or “AI tools train on everything.” That is too simplistic. Many enterprise AI services offer stronger protections than consumer versions.

The real issue is this:

Confidential business data should not flow into unmanaged tools, personal accounts, or systems the business cannot monitor, govern, or control.

AI Governance Needs More Than Trust

Security awareness training is important. Policies are important. Signed acknowledgments are important.

But they are not enough.

If the only thing preventing confidential data from being shared with an unapproved AI tool is employee memory, the business does not have a control. It has a hope.

A stronger AI governance program should answer questions like:

Which AI tools are approved for business use?
Which AI tools are allowed only for public information?
Which AI tools are blocked?
Can employees approve new integrations on their own?
Can personal AI accounts connect to business systems?
Can sensitive data be pasted into AI tools?
Can company files be uploaded to AI platforms?
Can AI browser extensions read internal web applications?
Can the business detect risky AI usage?
Can access be revoked quickly if needed?

These are practical control questions.

Start With the Access Problem

The first thing businesses should look at is application access.

Many modern business tools allow third-party integrations. That is useful, but it also creates risk. If users can approve any app that asks for access, then a business may accidentally allow unreviewed AI tools into sensitive systems.

A good first step is to require approval before third-party apps can connect to business platforms.

This does not mean every request needs to become a giant security project. But there should be a review process, especially when an app requests access to sensitive data.

Higher-risk access includes:

Email
Files
Chat messages
Calendars
Customer records
Source code
Financial systems
HR systems
Ticketing systems
Administrative permissions

If an AI tool wants access to those systems, the business should know about it before access is granted.

Require Managed Access to Sensitive Systems

Another important control is device access.

If employees can access sensitive business systems from unmanaged personal devices, it becomes much harder to control data movement. An employee may use a personal laptop, unmanaged browser, personal AI account, or unauthorized browser extension to move data somewhere it should not go.

Businesses should consider requiring managed or compliant devices for sensitive applications.

That might include:

Company-managed laptops
Approved mobile apps
Managed browsers
Device compliance checks
Mobile application management
Restrictions on copying data between managed and unmanaged apps

This is not always easy, especially for businesses that allow bring-your-own-device access. But the principle is simple:

The more sensitive the system, the more controlled the access path should be.

Create an Approved AI Tool List

Employees are going to use AI.

If the business does not provide an approved path, people will often find their own path.

That is why businesses should create a simple AI tool classification model.

Approved for Confidential Data

These are tools the business has reviewed and approved for sensitive work.

They should have appropriate business terms, access controls, administrative settings, logging, and data protection commitments.

Examples may include enterprise AI assistants, approved productivity tools, approved coding assistants, or internally managed AI systems.

Approved for Public Data Only

These tools may be acceptable for general productivity, but not for confidential data.

For example:

Rewriting public marketing content
Brainstorming blog ideas
Summarizing public information
Creating generic templates
Drafting non-sensitive content

Employees should understand that “approved for public data” does not mean “approved for everything.”

Not Approved

Some tools should not be used for business data at all.

This may include tools with unclear privacy terms, no enterprise controls, risky browser extensions, unknown vendors, or tools that require personal accounts to process business data.

The goal is not to make AI impossible to use. The goal is to make the safe path obvious.

Watch for AI Integrations, Not Just AI Websites

Many businesses focus on blocking AI websites. That can help, but it is not enough.

AI risk often shows up through integrations.

Examples include:

AI meeting note tools connected to calendars
AI assistants connected to chat platforms
AI coding tools connected to repositories
AI automation platforms connected to file storage
Browser extensions that can read page content
Personal productivity tools connected to business email
AI search tools connected to internal knowledge bases

A business should regularly review connected apps and integrations, not just web browsing history.

Useful questions include:

What third-party apps currently have access to company data?
Which users approved them?
What permissions were granted?
Are any of those apps AI-related?
Are any using personal accounts?
Are any no longer needed?
Are any requesting more access than necessary?

This review should happen on a recurring basis.

Data Loss Prevention Still Matters

AI security is really data security.

The question is not just, “Which AI app is being used?”

The better question is:

What data can leave the business, and where can it go?

Businesses should consider controls that reduce risky data movement.

That may include:

Blocking sensitive file uploads to unapproved tools
Warning users before they paste sensitive information into AI tools
Preventing copy and paste from managed apps into unmanaged apps
Restricting downloads from sensitive systems
Monitoring for client data, regulated data, credentials, or source code in AI prompts
Limiting browser extensions
Restricting access from unmanaged devices

These controls are not perfect, but they help turn AI policy into something measurable and enforceable.

Do Not Forget Browser Extensions

Browser extensions are an underrated risk.

Some extensions can read or modify the content of web pages. That may include internal systems, customer portals, ticketing tools, financial platforms, or administrative consoles.

An AI-powered browser extension may seem harmless, but if it can read page content, it may be able to access sensitive business data.

Businesses should have a browser extension policy, especially for employees who access sensitive systems.

At minimum:

Block unapproved extensions
Allow only reviewed extensions
Monitor installed extensions
Remove extensions that are no longer needed
Treat AI browser extensions as higher-risk until reviewed

Give Employees a Safe Option

One of the best ways to reduce risky AI usage is to provide approved tools.

If employees see AI as useful but the business only says “no,” people may work around the rules.

A better approach is:

Provide approved AI tools
Explain what they can be used for
Explain what they cannot be used for
Make access easy
Train employees on practical examples
Review usage periodically

The message should not be:

“Do not use AI.”

The message should be:

“Use AI in ways that protect our clients, our data, and our business.”

Suggested AI Security Controls

A practical AI security program does not need to start with a giant project.

Start with the basics.

1. Require Approval for New App Integrations

Do not allow users to approve risky third-party apps without review.

Focus especially on apps requesting access to:

Email
Files
Chat
Source code
Customer records
Financial data
Administrative permissions

2. Review Existing App Access

Look for apps that already have access to business systems.

Remove apps that are:

Unused
Unapproved
Over-permissioned
Connected to personal accounts
No longer needed
Owned by unknown vendors

3. Classify AI Tools

Create simple categories:

Approved for confidential data
Approved for public data only
Not approved

Keep the list easy to understand.

4. Require Managed Devices for Sensitive Apps

Where possible, require managed or compliant devices to access sensitive business systems.

This helps reduce the risk of personal devices, unmanaged browsers, and unapproved tools being used to move business data.

5. Monitor AI Usage

Use available security tools to identify AI applications in use.

Look for:

New AI apps
Unusual data access
Risky integrations
Sensitive data uploads
Personal account usage
Unapproved browser extensions

6. Implement Data Loss Prevention

Use data protection controls where possible.

Focus on preventing sensitive information from being uploaded, pasted, copied, or synced into unapproved tools.

7. Create an Exception Process

There will always be legitimate business needs.

Create a simple process for requesting approval of new AI tools.

The request should answer:

What tool is being requested?
What business problem does it solve?
What data will it access?
Will it use confidential or client data?
Does it support business accounts?
Who will manage access?
How will data be retained or deleted?
What happens when the employee leaves?

Keep the process lightweight, but real.

8. Review Regularly

AI tools change quickly.

A one-time review is not enough.

At least quarterly, review:

Approved AI tools
Blocked AI tools
New AI usage
Connected apps
Browser extensions
Data loss events
Exceptions
User access

A Simple Leadership Message

For business leaders, the message should be straightforward:

AI is not just another website employees visit. AI tools can connect to business systems, retrieve data, summarize information, automate actions, and move sensitive content outside approved environments.

That does not mean businesses should avoid AI.

It means businesses need to govern AI like any other system that touches confidential data.

AI security should focus on:

Who can connect tools to business systems
Which tools are approved
What data those tools can access
Whether personal accounts are allowed
How sensitive data is protected
How risky usage is detected
How access is removed when needed

The Bottom Line

Businesses do not need to solve every AI risk overnight.

But they should stop relying on policy alone.

A strong AI security approach should combine:

Clear rules
Approved tools
Managed access
App approval workflows
Data protection
Monitoring
Regular review

The goal is not to block innovation.

The goal is to make sure AI adoption does not quietly create a new, unmanaged path to sensitive business data.

AI can be useful. AI can help employees move faster. AI can improve productivity.

But if an AI tool can access company data, it needs governance.

Because once confidential data leaves your control, it may be very difficult to get it back.

Need Help Getting AI Usage Under Control?

AI can be useful, but it needs guardrails.

If you are not sure which AI tools your employees are using, what apps they can connect to, or whether sensitive business data is being exposed, now is a good time to take a closer look.

How to Protect Your Business from npm Supply Chain Attacks

Sun, 17 May 2026 00:00:00 +0000

Does your website use Node.js or JavaScript?

There is a good chance that under the hood, you are using npm packages to make everything work.

You may be exposed to the recent glut of npm supply chain attacks.

The good news: you do not need to panic. Start with the basics:

Use lockfiles.
Review dependency changes.
Keep secrets out of build jobs.
Enable MFA.
Scan for exposed credentials.
Have a plan to rotate keys fast.

npm risk is not just a developer problem. It is a business risk.

Practical npm Supply Chain Protections

npm supply chain issues have been getting a lot of attention lately, and for good reason.

A lot of modern applications depend on hundreds or even thousands of open source packages. That is not automatically bad. Open source software powers a huge portion of the internet. But it does mean businesses need to understand one important thing:

A dependency is code you are choosing to trust.

When an npm package is compromised, the risk is not limited to the application itself. A malicious package may run during installation, look for secrets, steal GitHub tokens, access cloud credentials, modify build scripts, or tamper with your deployment pipeline.

That makes npm supply chain risk more than a software development issue.

It is a credential risk.

It is a CI/CD risk.

It is a business risk.

The good news is that there are practical steps you can take to reduce the risk.

Start With the Right Mindset

You probably cannot prevent every bad package from entering the npm ecosystem. That is not a realistic goal for most businesses.

The better goal is this:

Make sure a bad package cannot do much damage if it does get pulled into your environment.

That means limiting access, protecting secrets, reviewing dependency changes, and making your build process more predictable.

Use Lockfiles and `npm ci`

One of the simplest things you can do is make sure your builds are repeatable.

Use npm ci in your CI/CD pipeline instead of npm install.

npm ci

The difference matters.

npm ci installs dependencies based on your package-lock.json file. That helps prevent unexpected dependency changes from sneaking into your build.

You should also commit your lockfile to source control:

git add package-lock.json
git commit -m "Lock npm dependencies"

This does not eliminate supply chain risk, but it reduces surprise changes. When every build pulls whatever version happens to match a version range, you are accepting more risk than you may realize.

Avoid Automatically Installing Brand-New Package Releases

Many malicious packages are discovered fairly quickly after they are published.

That means a short waiting period can help.

Instead of automatically upgrading dependencies the moment a new version is released, consider using a cooling-off period. For many businesses, waiting 24 to 72 hours before adopting a new npm package version is reasonable. For higher-risk applications, waiting longer may make sense.

Tools like Dependabot or Renovate can help manage this process, but dependency updates should still be reviewed like any other code change.

A reasonable approach might look like this:

Patch updates: review before merging
Minor updates: review before merging
Major updates: planned and tested change
Brand-new dependencies: extra scrutiny required

Dependency updates are not just maintenance tasks. They are new code entering your environment.

Disable Install Scripts Where Practical

Many npm attacks abuse install scripts.

Packages can include scripts such as:

preinstall
install
postinstall

These scripts may run automatically when the package is installed. That can be useful for legitimate packages, but it is also attractive to attackers.

Where possible, consider running:

npm ci --ignore-scripts

This prevents install scripts from running automatically.

This may not work for every project. Some packages, especially native modules, may require install scripts to function correctly. But where you can disable scripts, it is a strong control.

At minimum, you should know which packages require install scripts and why.

Keep Secrets Away From Dependency Installation

This is one of the most important controls.

A malicious package running during installation should not have access to production secrets.

A risky CI/CD flow looks like this:

Install dependencies
Build application
Deploy to production

All in one job, with sensitive credentials available the entire time.

A safer flow looks like this:

Job 1: Install dependencies with no production secrets
Job 2: Build and test with minimal access
Job 3: Deploy with production credentials available only when needed

The install step should not have access to:

GitHub tokens
npm publishing tokens
AWS, Azure, or GCP credentials
SSH keys
Slack or Teams webhooks
Production database credentials
Deployment secrets

If a malicious package runs during npm ci, it should land in a low-privilege environment with nothing valuable to steal.

That is the real goal.

Use Short-Lived Credentials

Long-lived credentials create long-lived risk.

Where possible, avoid static cloud keys and long-lived tokens in CI/CD environments.

Instead, use short-lived credentials through OIDC or your cloud provider’s native identity features.

This is especially important for credentials like:

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AZURE_CLIENT_SECRET
GCP_SERVICE_ACCOUNT_KEY
GitHub personal access tokens
npm tokens

If a token is stolen, you want the damage window to be short.

Short-lived credentials are not magic, but they dramatically reduce the blast radius of a compromise.

Turn On Secret Scanning

Assume attackers are looking for secrets.

At minimum, businesses using GitHub should look at:

GitHub secret scanning
GitHub push protection
CI/CD audit logging
Cloud provider alerts
npm token monitoring

Secret scanning helps identify credentials that have accidentally been committed to repositories or exposed in other ways.

Push protection can stop some secrets from being committed in the first place.

These controls are not exciting, but they are extremely practical.

Review Dependency Changes Like Code Changes

A dependency update is code entering your application.

Treat it that way.

When reviewing dependency changes, ask questions like:

Is this a new direct dependency?
Why do we need it?
How widely used is the package?
Was the package recently created?
Did the maintainer change?
Did the package add new install scripts?
Did it add a large dependency tree?
Does the package access the network, filesystem, or environment variables?
Is the package name similar to another popular package?

Be especially careful with dependencies that touch:

Authentication
Authorization
Build systems
Deployment tooling
Cloud SDKs
Logging
Security controls
Cryptography
CI/CD workflows

The more sensitive the role of the package, the more scrutiny it deserves.

Use `npm audit`, But Do Not Stop There

npm audit is useful, and you should use it.

npm audit

For production dependencies, you can also run:

npm audit --production

But it is important to understand what npm audit does and does not do.

It is better at identifying known vulnerable packages than identifying brand-new malicious packages.

That means npm audit is a good baseline, but it should not be your only control.

Supply chain attacks often happen before traditional vulnerability databases catch up.

Consider a Private Package Proxy or Cache

For businesses with multiple developers or production applications, a private npm proxy or cache can be a valuable control.

Examples include:

GitHub Packages
JFrog Artifactory
Sonatype Nexus
Cloudsmith
Verdaccio

The idea is to avoid having every developer machine and CI/CD runner pull directly from the public npm registry.

Instead, the flow becomes:

Developer or CI/CD system
        ↓
Approved package cache
        ↓
Public npm registry

This gives you a place to:

Cache known-good versions
Block known-bad versions
Review new packages
Prevent dependency confusion
Create an approval process
Improve visibility into package usage

For smaller teams, this may feel like overkill. For businesses that depend heavily on software delivery, it can be a very reasonable investment.

Watch for Dependency Confusion

Dependency confusion happens when a build system accidentally pulls a public package instead of an internal private package.

This can happen when internal package names are not properly scoped or registry configuration is loose.

To reduce this risk:

Use scoped internal packages
Configure your registry carefully
Avoid unscoped internal package names
Route private scopes only to your private registry

For example:

@yourcompany:registry=https://npm.pkg.github.com/
//npm.pkg.github.com/:_authToken=${NODE_AUTH_TOKEN}

The goal is to make sure internal packages come from internal sources, not from the public internet.

Protect Your npm and GitHub Accounts

Supply chain attacks are not always about tricking someone into installing a bad package. Sometimes attackers compromise legitimate maintainers, repositories, or publishing workflows.

That means account security matters.

For developers and maintainers:

Use MFA or passkeys
Do not share npm accounts
Use least-privilege tokens
Remove old tokens
Protect release branches
Require pull request reviews
Review GitHub Actions workflows
Prefer trusted publishing where available

If your company publishes npm packages, this becomes even more important.

A compromised publishing account can turn your legitimate package into someone else’s attack path.

Have an Incident Playbook

When a compromised package is reported, you do not want to make up the response as you go.

Have a simple playbook.

Start with:

1. Search package-lock.json files for the affected package and version.
2. Check whether the package is direct or transitive.
3. Identify where it was installed.
4. Check developer machines, CI/CD runners, and build containers.
5. Remove or pin away from the affected version.
6. Rebuild from a clean environment.
7. Rotate exposed credentials.
8. Review GitHub, npm, cloud, and CI/CD audit logs.
9. Look for suspicious commits, workflows, tokens, releases, or deployments.

The key step is credential rotation.

Do not just remove the bad package and move on.

If a malicious package ran in an environment that had access to secrets, assume those secrets may have been exposed.

A Practical Policy for Small Businesses

You do not need a hundred-page policy to get started.

A simple npm dependency policy could say:

We use lockfiles and npm ci for repeatable builds.
Dependency updates are reviewed before merging.
New dependencies require extra review.
CI/CD install jobs do not receive production secrets.
Install scripts are disabled where practical.
Secrets are short-lived where possible.
GitHub and npm accounts require MFA.
Known compromised dependencies trigger credential rotation.

That is not flashy, but it is practical.

And practical is the point.

The Bottom Line

npm supply chain risk is not just a developer problem.

It is not just an open source problem.

It is a business risk tied directly to credentials, build systems, release pipelines, and production access.

The goal is not perfection. The goal is to make smart, practical improvements that reduce the blast radius when something goes wrong.

Use lockfiles. Review dependency changes. Limit secrets in CI/CD. Disable install scripts where practical. Protect developer accounts. Have a plan for when a package is compromised.

The basics still do a lot of heavy lifting when they are implemented well.

If you are not sure how exposed your business is to software supply chain risk, start with a practical review of your repositories, CI/CD pipelines, developer access, and secrets management.

MN Risk & Cybersecurity Advisory can help identify where the real risks are and build a plan that fits how your business actually operates.

Your IT Vendor Cannot Own Your Business Risk

Wed, 13 May 2026 00:00:00 +0000

Your IT Vendor Cannot Own Your Business Risk

A good IT provider can be one of the most valuable partners your business has.

They keep systems running. They support users. They manage devices, networks, backups, cloud services, email, and security tools. In many small and mid-sized businesses, the MSP is the team that keeps the lights on.

But there is a line that often gets blurry:

Your IT vendor can help manage technology risk, but they cannot own your business risk.

That responsibility still belongs to the business.

You cannot outsource accountability

It is tempting to think that hiring an MSP means cybersecurity is “handled.”

That sounds simple:

“We pay an IT company. They take care of all of that.”

The problem is that cybersecurity is not just an IT task. It is a business risk issue.

Your IT provider can recommend controls, configure tools, monitor systems, apply patches, set up backups, and respond to technical problems. But they cannot decide what level of risk your business is willing to accept.

They cannot decide:

How much downtime your business can tolerate
Which systems are most critical to revenue
What customer data matters most
Whether a risk should be accepted, reduced, transferred, or avoided
How much the business is willing to spend to lower risk
What legal, contractual, or regulatory obligations apply to your company
Whether leadership is comfortable with the current exposure

Those decisions require business context.

And that context has to come from the business.

Your MSP does not run your company

Your MSP may know your systems very well. They may know your firewall, Microsoft 365 tenant, backups, endpoint protection, and network better than anyone inside your company.

But that does not mean they know your business strategy.

They may not know which customers are most important. They may not know which contracts have security requirements. They may not know which operational processes absolutely cannot go down. They may not know what your insurance carrier expects. They may not know what promises your sales team has made to customers.

Most importantly, they are not the ones who have to answer for the business consequences of a bad decision.

If a system goes down, data is lost, a customer contract is violated, or a regulator asks questions, the business cannot simply point to the MSP and say:

“We thought they were handling it.”

That may be part of the story, but it is not a complete risk management strategy.

Risk decisions belong to leadership

Every business accepts risk. Sometimes knowingly, sometimes accidentally.

Maybe you know a system is old, but replacing it would be expensive. Maybe you know MFA is not enabled everywhere, but rolling it out will cause friction. Maybe you know backups need improvement, but budget is tight. Maybe you know a vendor has security gaps, but they are critical to operations.

Those may or may not be reasonable decisions.

The issue is not that risk exists. Risk always exists.

The issue is whether the business understands the risk and makes a conscious decision about what to do with it.

There are only a few basic ways to treat risk:

Accept it because the business is comfortable with the exposure
Reduce it by adding controls or changing processes
Transfer it through insurance, contracts, or vendor agreements
Avoid it by stopping the risky activity altogether

Your MSP can provide input. They can explain technical options. They can help implement the chosen path.

But the decision itself should come from business leadership.

The gap between the business and the MSP

This is where many businesses get stuck.

The MSP is focused on keeping technology running. The business is focused on serving customers, making payroll, growing revenue, and managing operations. Both sides are important, but they are often speaking different languages.

The MSP may say:

“You need better endpoint protection, better backup retention, conditional access policies, and vulnerability management.”

The business may hear:

“We need to buy more tools.”

The business may say:

“We cannot afford downtime during our busy season.”

The MSP may hear:

“Do not make changes unless something is broken.”

Neither side is wrong. They are just looking at the problem from different angles.

That gap is where cybersecurity strategy often falls apart.

A business needs someone who can translate technical risk into business impact, then turn business priorities back into a realistic security roadmap.

That is where a vCISO can help.

What a vCISO adds

A virtual Chief Information Security Officer, or vCISO, helps the business make better security and risk decisions without needing to hire a full-time security executive.

A vCISO does not replace your MSP.

A good vCISO should make your MSP more effective.

The MSP usually owns execution and operations. The vCISO helps with strategy, prioritization, risk management, governance, and communication with leadership.

In practical terms, a vCISO can help:

Identify and prioritize the most important cyber risks
Build a security roadmap that fits the business
Translate technical findings into business language
Help leadership decide whether to accept, reduce, transfer, or avoid risk
Review MSP recommendations through a risk management lens
Help define security requirements for vendors and internal systems
Support cyber insurance, compliance, and customer security questionnaires
Create policies and standards that are realistic for the business
Facilitate conversations between leadership, IT, legal, finance, and vendors
Track risk decisions so they are documented and understood

This gives the business a security strategy function without asking the MSP to also be the board advisor, risk officer, compliance interpreter, and business decision-maker.

“Do everything” is not a strategy

Many businesses want one vendor to “do everything.”

That makes sense on the surface. One provider. One invoice. One support number. Less complexity.

But cybersecurity does not work well when it is treated as a pile of tasks with no strategy behind it.

Someone still needs to ask:

What are we protecting?
Why does it matter?
What would hurt the business the most?
What risks are we currently accepting?
Are we spending money in the right places?
Are our controls aligned with our actual threats?
Are we meeting our contractual and regulatory obligations?
How do we explain our security posture to customers, insurers, auditors, or the board?

Those are not help desk questions.

Those are business risk questions.

Your MSP may be excellent at operations, but that does not automatically make them your risk advisor, compliance lead, board-level security translator, and business strategy partner.

Some MSPs can provide parts of that service. Some have mature security practices. Some have strong advisory teams. But even then, the business still has to participate in the decisions.

A vCISO helps organize those decisions, document them, and turn them into a practical roadmap your MSP can execute.

Security tools do not make risk decisions

Another common mistake is assuming tools equal strategy.

Endpoint protection is not a strategy.

A firewall is not a strategy.

Backups are not a strategy.

MFA is not a strategy.

EDR, MDR, SIEM, vulnerability scanning, email filtering, and security awareness training are all useful. Some may be essential. But tools are only valuable when they support a business objective.

For example, “we have backups” is not the same as knowing:

What is backed up
How often backups run
How long restores take
Whether backups are protected from ransomware
Whether restore tests are performed
Which systems must come back first
How much data loss the business can tolerate

That last part matters.

If the business can only tolerate four hours of downtime, but the backup process takes two days to restore critical systems, that is not just a technical issue. That is a business continuity problem.

The MSP can help fix it.

But leadership has to define what “good enough” means.

A vCISO can help leadership define those requirements in plain language, then work with the MSP to determine whether the current environment supports them.

Liability does not disappear because you hired a vendor

Hiring a vendor does not erase your responsibility.

Contracts, insurance policies, customer agreements, privacy laws, regulatory requirements, and basic business obligations still apply to the company. A vendor may have some contractual responsibilities, but the business is still the one operating the company, collecting the data, serving the customers, and making the decisions.

This is why risk ownership matters.

If a breach happens, the business may need to notify customers. The business may need to work with legal counsel. The business may need to answer to regulators, insurers, partners, or customers. The business may lose revenue, reputation, or operational capacity.

Even if a vendor made a mistake, the impact lands on the business.

That does not mean MSPs are off the hook for doing poor work. Vendors should absolutely be held accountable to their agreements, service levels, and professional responsibilities.

But accountability for business risk cannot be fully transferred to an IT provider.

A vCISO can help make sure responsibilities are clearer before something goes wrong. That includes helping the business understand vendor scope, service gaps, security obligations, incident response roles, and which decisions need formal leadership approval.

Your MSP should be part of the strategy, not a replacement for it

None of this means your MSP is bad.

In fact, a good MSP should be involved in the conversation. They often have valuable insight into where the technical problems are. They know where systems are fragile. They know which users struggle with security controls. They know which tools are working and which ones are shelfware.

The best outcomes happen when the business, MSP, and security advisor are aligned.

The business provides direction.

The MSP operationalizes and supports the environment.

A vCISO helps translate between technical issues and business decisions.

That creates a healthier model:

Leadership understands the risk
The MSP knows what priorities matter most
Security spending is tied to business impact
Technical work supports a broader roadmap
Risk decisions are documented
Everyone has a clearer role

That is much better than assuming one vendor can magically own every business, technology, security, legal, and risk decision.

The business has to be involved

Cybersecurity does not need to be overwhelming, but it does require business input.

Leadership does not need to know every technical detail. They do not need to configure firewalls or read every vulnerability report.

But they do need to understand the big picture:

What are our biggest risks?
What are we doing about them?
What are we choosing not to do?
What would happen if a key system went down?
Are we meeting our obligations?
Are we comfortable with the current level of risk?
Who is responsible for making decisions?

That is the part that cannot be outsourced.

A vCISO can make this process easier by bringing structure to the conversation. Instead of dumping technical findings on leadership, they can frame risk in terms of business impact, likelihood, cost, and priority.

That helps leadership make informed decisions instead of reacting to the loudest alert, newest tool, or latest scary headline.

A better way to work with your MSP

Instead of asking your MSP to “handle security,” ask better questions:

What risks are you seeing in our environment?
Which issues should leadership understand?
Where are we underinvested?
What security tasks are you performing today?
What security tasks are outside your scope?
Are our backups tested?
Are our critical systems covered by MFA?
Are we relying on any unsupported systems?
What would you recommend we prioritize over the next 90 days?
What decisions do you need from us?

These questions create clarity.

They also help separate operational tasks from business risk decisions.

Your MSP should not have to guess what the business cares about most. The business should provide that direction.

A vCISO can help facilitate those conversations, challenge assumptions, and turn the answers into a clear action plan.

Final thought

Your MSP can be a critical part of your cybersecurity program.

They can implement controls, manage systems, respond to issues, and help keep the business running. A strong MSP is an asset.

But they are not a substitute for business leadership making informed risk decisions.

At the end of the day, your business owns its risk.

Not because your MSP is doing something wrong.

Because it is your business.

Your customers, your contracts, your operations, your reputation, and your decisions.

The goal is not to replace your MSP. The goal is to give them better direction, better priorities, and a clearer strategy so everyone is working toward the same outcome.

That is where a vCISO can help bridge the gap between business leadership and technical execution.

Moving DMARC from p=none to p=reject

Fri, 08 May 2026 00:00:00 +0000

DMARC is one of those security controls that sounds simple until you actually try to enforce it.

At a high level, DMARC helps prevent people from spoofing your email domain. It tells receiving mail servers what to do when a message claims to come from your domain but does not properly authenticate using SPF or DKIM.

The problem is that a lot of organizations stop at this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

That is better than nothing, but p=none is monitoring mode. It does not tell anyone to block or quarantine spoofed messages. It only asks receiving mail servers to send you reports.

That means if someone is pretending to be your company in an email campaign, your DMARC record may be observing the problem, but it is not doing much to stop it.

The goal should usually be to move toward this:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

But you should not jump straight from p=none to p=reject without understanding what is sending email on behalf of your domain.

This is a process.

What DMARC Actually Does

DMARC works with SPF and DKIM.

SPF helps define which mail servers are allowed to send email for your domain.

DKIM uses a cryptographic signature to prove that an email was authorized by your domain and was not modified in transit.

DMARC checks whether SPF or DKIM passes and whether the passing result aligns with the domain shown in the visible From: address.

That alignment piece matters. A message can technically pass SPF or DKIM but still fail DMARC if the authenticated domain does not line up with the domain the recipient sees.

DMARC then tells the receiving mail server what to do when a message fails.

The three common policies are:

Policy	What It Means
`p=none`	Monitor only. Do not ask receivers to take enforcement action.
`p=quarantine`	Ask receivers to treat failing messages as suspicious, often sending them to spam or quarantine.
`p=reject`	Ask receivers to reject failing messages outright.

The key word is “ask.” Receiving mail systems make their own final decisions, but major providers generally honor DMARC policy when it is configured correctly.

Why You Should Not Start with `p=reject`

It can be tempting to go straight to enforcement.

After all, if the goal is to stop spoofing, why not just publish p=reject and be done?

Because you may break legitimate email.

Most businesses have more systems sending email than they realize. It is not just Microsoft 365 or Google Workspace. It may also include:

CRM platforms
Marketing tools
Billing systems
Ticketing systems
Website contact forms
HR platforms
Payroll systems
Cloud applications
Managed service providers
Printers or scanners
Legacy applications
Third-party vendors

Some of these systems may be sending as your domain without properly configured SPF or DKIM.

If you publish p=reject before identifying those systems, legitimate emails may start getting rejected.

That is why the safe path is:

p=none → p=quarantine → p=reject

Step 1: Set Up DMARC Reporting First

Before you enforce anything, you need visibility.

DMARC aggregate reports show who is sending email using your domain and whether those messages are passing SPF, DKIM, and DMARC alignment checks.

A basic DMARC record might look like this:

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

The rua tag is where aggregate reports are sent.

Technically, you can send these reports to a regular mailbox, but I do not recommend it. DMARC reports are XML files, and they are not fun to read manually. Use a DMARC reporting service or a tool that parses the reports into something usable.

At this stage, your goal is not enforcement.

Your goal is discovery.

You want to answer questions like:

Who is sending email as my domain?
Are my main email platforms passing SPF and DKIM?
Are third-party tools properly authenticated?
Are there unknown sources sending mail?
Are messages failing because of SPF, DKIM, or alignment issues?
Are subdomains being used?
Are there obvious spoofing attempts?

Do not skip this step. Without reporting, you are guessing.

Step 2: Start with `p=none`

If you already have DMARC at p=none, that is fine. You are in monitoring mode.

A starter record may look something like this:

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"

The adkim and aspf tags control DKIM and SPF alignment strictness.

For many organizations, relaxed alignment is more forgiving and may be easier at first:

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r"

Strict alignment is stronger, but it can also break more things if your sending sources are not configured cleanly.

The right answer depends on your environment.

For most small and mid-sized businesses, the first priority is to get reporting working and understand the current state.

Step 3: Review Reports for a Few Weeks

Once reporting is enabled, let it run.

You want enough time to see normal business activity. A few days usually is not enough. A couple of weeks is better. A month is better yet, especially if you have newsletters, invoices, monthly statements, or recurring system emails.

Look for your known senders first.

Examples might include:

Microsoft 365
Google Workspace
Mailchimp
HubSpot
Salesforce
Zendesk
QuickBooks
Shopify
WordPress
Website form plugins
Security awareness platforms
Ticketing systems

For each one, confirm whether it is passing DMARC.

If it is failing, figure out why.

Common issues include:

SPF does not include the sending service
DKIM is not enabled for the sending service
DKIM is enabled but using the wrong domain
A vendor is sending through its own domain instead of yours
A website form is spoofing your domain instead of sending from a valid address
SPF has too many DNS lookups
Multiple SPF records exist
A subdomain is being used without a clear policy

At this point, you are cleaning up your email ecosystem.

This is where most of the work happens.

Step 4: Fix SPF and DKIM Problems

Before moving to enforcement, make sure legitimate senders pass DMARC.

That usually means fixing SPF, DKIM, or both.

SPF Fixes

Your SPF record tells the world which systems are allowed to send email for your domain.

A simple SPF record might look like this:

example.com TXT "v=spf1 include:spf.protection.outlook.com -all"

But many organizations add includes over time:

example.com TXT "v=spf1 include:spf.protection.outlook.com include:sendgrid.net include:mailgun.org -all"

That can be fine, but SPF has a DNS lookup limit. If your record gets too large or includes too many third parties, it may fail.

Common SPF cleanup tasks include:

Removing old vendors
Consolidating services
Avoiding duplicate includes
Making sure there is only one SPF record
Staying under the DNS lookup limit
Using -all once you are confident

Be careful with overly broad SPF records. Adding huge IP ranges or unnecessary vendors creates risk.

DKIM Fixes

DKIM is often the better long-term control because it survives forwarding better than SPF.

For each legitimate third-party email platform, check whether it supports DKIM signing using your domain. Most reputable services do.

You may need to add one or more DNS records provided by the vendor.

These often look like CNAME records:

selector1._domainkey.example.com CNAME selector1-example-com._domainkey.vendor.example
selector2._domainkey.example.com CNAME selector2-example-com._domainkey.vendor.example

Or TXT records:

selector._domainkey.example.com TXT "v=DKIM1; k=rsa; p=..."

Once DKIM is enabled, check your DMARC reports again to confirm the messages are passing and aligned.

Step 5: Move to `p=quarantine`

Once your reports look clean, move from monitoring to partial enforcement.

Your DMARC record might become:

_dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

This tells receiving mail servers that messages failing DMARC should be treated as suspicious.

Some systems may send them to spam. Some may quarantine them. Some may apply their own filtering logic.

This is a good middle step because it lets you start enforcing without immediately rejecting everything that fails.

You can also use the pct tag to apply the policy gradually:

_dmarc.example.com TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com"

That means the quarantine policy should apply to 25% of failing messages.

Then you can increase it over time:

pct=50
pct=75
pct=100

Not every organization needs to use pct, but it can be helpful if you have a large or complicated email environment.

Step 6: Watch Reports for a Couple Months

After moving to p=quarantine, keep watching your DMARC reports.

This is where patience matters.

Let the policy run for a couple months if you can. That gives you time to see less frequent email sources, seasonal campaigns, billing cycles, customer communications, automated systems, and vendor workflows.

During this phase, pay attention to:

Legitimate senders that are now being quarantined
Business units using unauthorized tools
Vendors sending email without proper authentication
Website or application email failures
Forwarding-related issues
Subdomain abuse
Spoofing attempts

You may discover systems that nobody remembered existed.

That is normal.

The goal is not just to “turn on DMARC.” The goal is to understand and control who can send email using your domain.

Step 7: Move to `p=reject`

Once you are comfortable that legitimate email is passing DMARC, move to reject.

Your final record may look like this:

_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

This tells receiving mail servers to reject messages that fail DMARC.

This is the strongest common DMARC policy and where most organizations should eventually end up.

At this point, you have moved from visibility to enforcement.

You are no longer just watching spoofed messages. You are asking receiving mail systems to reject them.

Do Not Forget Subdomains

Subdomains matter.

By default, your main DMARC policy may apply to subdomains, but you can also explicitly define a subdomain policy with the sp tag.

For example:

_dmarc.example.com TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@example.com"

This tells receivers to reject DMARC failures for both the root domain and subdomains.

That matters because attackers may try to use subdomains such as:

billing.example.com
mail.example.com
secure.example.com
support.example.com

If your organization sends mail from subdomains, make sure those are included in your review before enforcing a strict subdomain policy.

A Practical DMARC Rollout Plan

Here is a simple rollout plan.

Phase	Policy	Duration	Goal
1	`p=none`	2 to 4 weeks	Collect reports and identify senders
2	`p=none`	As needed	Fix SPF, DKIM, and alignment problems
3	`p=quarantine`	1 to 2 months	Begin enforcement and monitor impact
4	`p=reject`	Ongoing	Reject unauthorized email

The exact timeline depends on the size and complexity of your environment.

A small business with Microsoft 365 and one marketing platform may be able to move quickly.

A larger organization with dozens of vendors, multiple brands, and legacy systems may need more time.

Common Mistakes

Publishing DMARC Without Reporting

A DMARC record without reporting is not very useful during rollout.

You need the reports to understand what is happening.

Jumping Straight to `p=reject`

This can work in very simple environments, but it is risky if you do not know all legitimate senders.

Forgetting Third-Party Vendors

Marketing, invoicing, ticketing, HR, and CRM platforms are common sources of DMARC failures.

Ignoring DKIM

SPF is helpful, but DKIM is usually more reliable, especially when email is forwarded.

Letting SPF Get Messy

SPF records tend to accumulate old vendors. Review and clean them up.

Forgetting About Subdomains

Attackers may spoof subdomains if your policy does not cover them.

Treating DMARC as a One-Time Project

DMARC needs ongoing review. Every time a new email vendor is added, someone should ask how SPF, DKIM, and DMARC will be handled.

DMARC Is Not Just a DNS Record

DMARC enforcement is not just a technical checkbox.

It is really about email governance.

Who is allowed to send email for your business?

Who approves new email platforms?

Who owns DNS changes?

Who reviews authentication failures?

Who gets notified when a vendor breaks email authentication?

If nobody owns those questions, your DMARC posture will slowly drift over time.

Final Thought

Moving from p=none to p=reject is not hard, but it does require a process.

Start with reporting. Watch the data. Identify legitimate senders. Fix SPF and DKIM. Move to quarantine. Keep watching. Then move to reject when you are confident.

The mistake is thinking DMARC enforcement is just changing one DNS record.

It is not.

That DNS record is the final step. The real work is understanding who is sending email as your domain and making sure only authorized systems are allowed to do it.

Weak Encryption Is Usually a Process Problem

Thu, 07 May 2026 00:00:00 +0000

A recent article from The Register reported that Kaspersky researchers found 60% of MD5 password hashes could be cracked in under an hour using a single high-end GPU.

That should make people uncomfortable.

Not because MD5 is new. It is not.

Not because weak passwords are new. They are not.

The uncomfortable part is that a lot of organizations still have old cryptography, old VPN settings, old password storage methods, and old assumptions quietly sitting in production.

And in many cases, nobody has checked them in years.

Encryption Does Not Age Gracefully

Encryption and hashing choices are not “set it and forget it” decisions.

Something that was acceptable years ago may be completely inappropriate today. Hardware gets faster. Cloud compute gets cheaper. Attack tools get better. Leaked password datasets get larger. What used to require time, money, and specialized equipment may now be practical for a motivated attacker with rented GPU time.

That is why weak encryption is often less about one bad technical decision and more about process failure.

Someone built an application.

Someone configured a VPN.

Someone set up a database.

Someone picked a hashing method.

Then the business moved on.

Years later, the company may still be relying on that original decision without realizing the risk has changed.

SHA-256 Is Not the Whole Answer

One common question is whether applications are using newer hashing algorithms like SHA-256 instead of MD5 or SHA-1.

That is a good question, but it needs a little nuance.

SHA-256 is a modern cryptographic hash function, but by itself, it is not the right answer for password storage.

Passwords should not be stored using fast general-purpose hashes like:

MD5
SHA-1
Plain SHA-256
Plain SHA-512

Those algorithms are fast by design. Fast is good for file integrity and digital signatures. Fast is bad for password storage because attackers can test guesses extremely quickly.

For passwords, applications should use password hashing or key derivation functions designed to be slow and resistant to brute force attacks, such as:

Argon2id
bcrypt
scrypt
PBKDF2 with appropriate parameters

The important part is not just the algorithm name. It is also how it is configured.

A good password storage review should ask:

What algorithm is being used?
Is each password uniquely salted?
Is there an appropriate work factor, cost, iteration count, or memory setting?
Can the parameters be increased over time?
Are old hashes upgraded after successful login?
Are passwords ever encrypted reversibly instead of hashed?
Are service accounts, API keys, and shared secrets handled differently than user passwords?

If your application team cannot answer those questions, that does not automatically mean something is wrong. It does mean someone should take a closer look.

Key Management Is Usually Where Things Fall Apart

Encryption is only as strong as the way keys are managed.

A strong algorithm with poor key management is still a weak system.

Common problems include:

Encryption keys stored in source code
Secrets committed to GitHub
Keys reused across environments
Production and development sharing the same secrets
No documented key rotation process
No clear owner for encryption keys
Old API keys that never expire
Shared administrator credentials
Backup encryption keys stored next to the backups
No inventory of certificates, keys, tokens, and secrets

A key management review does not have to be overly complicated. Start with a simple inventory.

For each important system, identify:

What data is encrypted
Where the keys live
Who can access the keys
How keys are rotated
What happens if a key is exposed
Whether keys are backed up securely
Whether old keys still work
Whether access to keys is logged and reviewed

If nobody owns this process, the business is probably relying on luck.

VPNs Deserve a Fresh Look

VPNs are another area where old configurations tend to linger.

Over the last several years, SSL VPN products and edge appliances have had a steady stream of serious security issues. These systems are attractive targets because they are exposed to the internet and often provide direct access into the internal network.

That does not mean every VPN is bad.

It does mean VPNs need to be reviewed like high-risk internet-facing infrastructure.

If your company still has an SSL VPN exposed to the internet, ask:

Do we still need this?
Is it fully patched?
Is it monitored?
Is MFA required for every user?
Are inactive users removed?
Are vendors and contractors reviewed?
Are logs being sent somewhere useful?
Has the appliance been checked for indicators of compromise?
Is there a safer access model available?

Many organizations deployed SSL VPNs because they were convenient. Convenience is not a security strategy.

IPsec VPNs Need Review Too

IPsec VPNs are common for site-to-site connections, vendor tunnels, cloud connectivity, and branch offices.

They can be very secure when configured well. They can also be weak if they are running old settings nobody has touched in years.

A practical IPsec VPN review should check for:

IKEv2 instead of IKEv1 where possible
AES-256 or another approved strong encryption option
SHA-2 instead of SHA-1 or MD5
Strong Diffie-Hellman groups
No aggressive mode
No weak pre-shared keys
No shared keys reused across multiple tunnels
No obsolete encryption like DES or 3DES
Documented tunnel ownership
Documented business purpose
Regular review of whether the tunnel is still needed

Aggressive mode is especially worth checking. It has historically made certain VPN configurations easier to attack, especially when combined with weak pre-shared keys. If it is enabled, there should be a very good reason.

Most of the time, there is not.

MFA Should Be Non-Negotiable

Anything exposed to the internet should have MFA enabled.

That includes:

VPNs
Email
Remote access tools
Cloud consoles
Admin portals
Firewalls
SaaS applications
Identity providers
Code repositories
Backup platforms
Financial systems

MFA is not perfect, but lack of MFA is still one of the easiest ways to turn a stolen password into a real incident.

For higher-risk systems, organizations should also look at stronger MFA options, conditional access, device posture, phishing-resistant authentication, and admin separation.

But the first question is simple:

Is MFA enabled everywhere it should be?

If the answer is “mostly,” the next question is “where is it not enabled?”

That list matters.

The Real Problem Is Drift

Most weak encryption problems do not start as negligence.

They start as drift.

A setting was acceptable when it was deployed.

A vendor recommended something years ago.

An application was inherited from another team.

A VPN tunnel was created during an emergency.

A developer used a default library example.

A certificate was renewed manually.

A key was copied somewhere for troubleshooting.

Then time passed.

The business changed. The threat landscape changed. The technology changed. But the configuration stayed the same.

That is how organizations end up with weak hashing, exposed VPNs, old ciphers, forgotten tunnels, and unmanaged keys.

What Businesses Should Do Next

This does not need to become a massive project right away. Start with a focused review.

1. Review password storage

Identify applications that store user passwords and confirm how those passwords are protected. Pay close attention to custom applications, older portals, customer-facing systems, and internally developed tools.

2. Inventory encryption keys and secrets

Find out where important keys, tokens, certificates, and secrets live. Determine who owns them and how they are rotated.

3. Review internet-facing remote access

Look closely at VPNs, remote access portals, firewalls, and administrative interfaces. Confirm they are patched, monitored, and protected with MFA.

4. Validate IPsec VPN settings

Check tunnel configurations for weak encryption, old IKE versions, aggressive mode, weak pre-shared keys, and outdated business purpose.

5. Remove what you no longer need

The best VPN tunnel, admin portal, or exposed service is the one you no longer have to expose at all.

6. Make this a recurring review

Encryption and remote access settings should be reviewed on a schedule. Not once. Not only after an incident. Not only when a vendor asks.

Final Thought

Weak encryption is not always dramatic. It is not always visible. It does not always show up as a flashing red alert.

Sometimes it is just an old setting that nobody has looked at in five years.

That is the risk.

Modern security is not just about buying better tools. It is about making sure the tools, applications, VPNs, keys, and authentication systems you already have are still configured for the world we live in now.

Because attackers are not testing your environment against what was reasonable ten years ago.

They are testing it against what works today.

References

Slow Down the Hype Cycle: Strategy Comes Before New Technology

Wed, 06 May 2026 00:00:00 +0000

Slow Down the Hype Cycle: Strategy Comes Before New Technology

Every few years, a new technology comes along that everyone feels like they need to adopt immediately.

Right now, that technology is AI.

A business owner, executive, or department leader sees what tools like ChatGPT, Claude, Microsoft Copilot, or other AI platforms can do, and the natural reaction is:

“We should be using this.”

That reaction is not wrong. These tools can be incredibly useful. They can help people write, summarize, research, brainstorm, analyze, code, document, and move faster.

But there is a difference between adopting useful technology and rushing into a tool because everyone else is doing it.

Before you buy the enterprise subscription, roll it out to employees, and tell everyone to start using it, it is worth slowing down and asking a few important questions.

Buying the Tool Is Not the Strategy

One of the most common mistakes businesses make with new technology is assuming that buying the product is the strategy.

It is not.

Buying Claude Enterprise, Microsoft Copilot, ChatGPT Enterprise, or any other AI platform is just one part of the decision. The bigger question is how that tool fits into your business.

For example:

Who should have access?
What should they use it for?
What should they not use it for?
What kind of company data is allowed?
What kind of customer data is prohibited?
Who owns the policy?
Who monitors usage?
How do you control cost?
What happens when the budget runs out?
How do you know whether it is actually helping?

Those questions matter because AI tools are not just another software subscription. They can touch sensitive business data, customer information, intellectual property, internal processes, source code, contracts, financial details, and employee workflows.

That does not mean you should avoid them. It means you should treat them like a real business technology decision.

The Hype Cycle Creates Pressure

The hype cycle creates pressure to move fast.

Nobody wants to feel like they are falling behind. Nobody wants to be the company that ignored the next major shift in technology. Nobody wants to hear that a competitor is using AI to move faster while they are still debating whether to approve a pilot.

That pressure is real.

But speed without direction can create waste, confusion, and risk.

A rushed rollout often leads to things like:

Employees using personal accounts for business work
Sensitive data being copied into tools without guidance
Multiple teams buying overlapping subscriptions
No clear ownership of cost or access
No visibility into what is being used
No agreement on acceptable use
No plan for measuring success
No answer when leadership asks, “What are we getting for this?”

At that point, the business may technically be “using AI,” but it may not be getting much value from it.

Worse, it may be creating new risks that nobody fully understands yet.

Start With Use Cases

A better approach is to start with use cases.

Do not start with the tool. Start with the business problem.

For example, maybe your business wants to use AI to:

Help sales teams draft follow-up emails
Summarize long customer conversations
Assist with policy and procedure documentation
Help developers review or explain code
Speed up security questionnaires
Analyze support tickets for trends
Generate first drafts of marketing content
Help leadership summarize reports
Support internal knowledge searches

Each of those use cases has a different risk profile.

Using AI to rewrite a public marketing post is very different from using AI to analyze customer contracts, source code, financial data, or security incidents.

The use case should drive the decision. Not the other way around.

Define Who Gets Access

Not everyone needs the same level of access.

Some users may need full access to an enterprise AI platform. Others may only need limited access through approved business applications. Some teams may not need access at all, at least not right away.

This is where planning matters.

You may want to define user groups such as:

User Group	Example Use	Risk Level	Access Consideration
Executives	Summaries, planning, communication	Medium	May handle sensitive business information
Sales and Marketing	Drafting, campaigns, follow-ups	Low to Medium	Needs brand and data guidance
Engineering	Code assistance, troubleshooting	Medium to High	Source code and IP concerns
HR	Job descriptions, internal communication	High	Employee and applicant data concerns
Finance	Forecasting, analysis, reporting	High	Financial and confidential business data
Security and IT	Triage, documentation, scripting	Medium to High	Sensitive technical details

This does not mean these teams cannot use AI. It means access should be intentional.

Policy Needs to Come Early

Policy does not need to be a 40-page document that nobody reads.

In fact, it probably should not be.

But employees do need clear guidance.

A basic AI acceptable use policy should answer questions like:

What tools are approved?
Are personal AI accounts allowed for business work?
What data is not allowed to be entered?
Can customer data be used?
Can source code be used?
Can financial data be used?
Are outputs allowed to be copied directly into customer-facing materials?
Does AI-generated work require human review?
Who do employees ask when they are unsure?

Most employees are not trying to do the wrong thing. They just need boundaries.

Without a policy, every employee is left to make their own judgment. That usually leads to inconsistent decisions across the business.

Budget and Token Spend Matter

AI costs can be more complicated than a simple per-user software license.

Some tools are priced per user. Others may involve usage-based costs, token consumption, API calls, add-ons, storage, connectors, observability tooling, or premium model access.

That means the financial planning needs to go beyond:

“How much is the subscription?”

You also need to think about:

What is the monthly or annual budget?
Is usage capped?
Who gets charged internally?
Do different departments have separate budgets?
What happens if usage spikes?
What happens when the budget runs out?
Are users downgraded?
Are features disabled?
Is approval required for more spend?
Who reviews the usage reports?

This matters because a successful AI rollout can actually create more demand. If employees find the tools useful, usage may increase quickly.

That is a good problem to have, but it still needs to be managed.

Observability Is Part of the Plan

For many businesses, AI adoption introduces a visibility problem.

You may need to understand:

Who is using the tool
How often they are using it
Which departments are using it
What features are being used
Whether sensitive data is being exposed
Whether usage aligns with approved use cases
Whether costs are trending up
Whether the tool is delivering value

Depending on the platform, this may require admin dashboards, logging, data loss prevention controls, CASB/SSE integrations, identity provider logs, endpoint visibility, API monitoring, or third-party AI observability tools.

The right answer depends on the size of the business, the sensitivity of the data, and the level of risk.

The important point is this: visibility should not be an afterthought.

If leadership is going to approve a new technology, someone should be able to explain how the business will monitor adoption, risk, and cost.

Security and Privacy Cannot Be Bolted On Later

Security and privacy need to be part of the decision from the beginning.

Before rolling out a new AI platform, businesses should understand:

How the vendor handles customer data
Whether prompts and outputs are used for training
What retention controls are available
Whether data can be deleted
Whether logs are exportable
Whether admin controls are available
Whether SSO and MFA are supported
Whether role-based access is available
Whether the vendor has relevant compliance reports
Whether the tool integrates with existing security controls

These are not just technical questions. They are business risk questions.

If a tool is going to process sensitive information, the business should understand what happens to that information.

Shadow AI Is Already Happening

One of the reasons businesses should address AI intentionally is because employees may already be using it.

If the company does not provide approved tools or guidance, employees may find their own path. That often means personal accounts, browser extensions, unapproved apps, free tools, or random services that have not been reviewed.

This is sometimes called “shadow AI.”

The goal should not be to scare everyone or ban everything. That usually does not work.

A better approach is to provide a safe, approved path. Give employees useful tools, explain the rules, and make it easy to ask questions.

Most people will follow the approved process if the approved process is practical.

A Pilot Is Better Than a Panic Rollout

For many businesses, a pilot is the right first step.

A good pilot should have:

A defined group of users
Clear use cases
A known budget
Approved tools
Basic policy guidance
Security and privacy review
Success criteria
A feedback process
A decision point at the end

The decision point is important.

At the end of the pilot, leadership should be able to decide whether to expand, adjust, pause, or stop.

That decision should be based on actual business value, not just excitement.

The Questions to Ask Before You Buy

Before adopting any major new technology, especially AI, ask:

What business problem are we trying to solve?
Who needs access?
What data will the tool process?
What data is off limits?
What policies need to exist first?
How will employees be trained?
How will usage be monitored?
How will cost be controlled?
What security controls are required?
What does success look like?
Who owns the platform internally?
What happens if the tool creates risk, cost, or operational issues?

These questions are not meant to slow innovation down forever.

They are meant to make sure the innovation actually works.

Strategy Helps You Move Faster

It may sound counterintuitive, but slowing down at the beginning can help a business move faster later.

When the strategy is clear, decisions get easier.

People know what tools are approved. Employees know what data they can use. Finance knows what budget to expect. IT knows what needs to be supported. Security knows what needs to be monitored. Leadership knows what value they are looking for.

That is much better than buying a tool first and trying to build the plan after the fact.

Final Thought

New technology can create real value, but only when it is connected to a real strategy.

AI is a great example. The opportunity is real. The benefits can be real. But the risks, costs, and operational questions are real too.

The goal is not to say “no” to new technology.

The goal is to say:

“Yes, but let’s do it the right way.”

That means understanding the use cases, defining access, setting policy, planning for cost, monitoring usage, and making sure the business knows what success looks like.

Hype gets attention.

Strategy creates value.

Why the U.S. Router Ban Makes Sense from a Cybersecurity Perspective

Sat, 02 May 2026 00:00:00 +0000

Why the U.S. Router Ban Makes Sense from a Cybersecurity Perspective

The U.S. government has taken a stronger position against foreign-made consumer routers, and from a cybersecurity perspective, I understand why.

According to Reuters, the FCC announced in March 2026 that it was banning the import of new foreign-made consumer routers, citing national security and cybersecurity concerns. The FCC’s public notice added routers produced in foreign countries to the FCC Covered List unless a specific router or class of routers receives conditional approval from the Department of War or the Department of Homeland Security. The FCC notice says the concern is that compromised routers can enable espionage, network disruption, intellectual property theft, and attacks against critical infrastructure. :contentReference[oaicite:0]{index=0}

That may sound extreme at first, but routers are not normal consumer gadgets. They sit at the edge of homes, businesses, schools, clinics, farms, local governments, and critical infrastructure. They see traffic. They route traffic. They often provide Wi-Fi, DNS, firewalling, VPN access, port forwarding, and remote administration.

When those devices are poorly secured, unsupported, or controlled through opaque supply chains, they become more than a household inconvenience. They become infrastructure.

This is not just about one brand

A lot of the public conversation focuses on China, and there are real reasons for that. Reuters reported that China is estimated to control at least 60% of the U.S. home router market. The FCC also cited foreign-made routers being implicated in major cyber campaigns, including Volt Typhoon and Salt Typhoon. :contentReference[oaicite:1]{index=1}

But the broader issue is not simply “foreign-made equals bad.”

The real issue is this:

Who designs the firmware?
Who controls the software update process?
Where is the hardware manufactured?
Who can influence the vendor?
How long does the vendor support the device?
Does the device ship securely by default?
Can the device be patched quickly when a critical vulnerability is found?
Is there a realistic way for customers to know when the device is no longer safe?

For most consumers and small businesses, the answer is usually: “I have no idea.”

That is the problem.

Routers are perfect targets

Attackers love routers for a few reasons.

First, they are usually always on. Second, they often sit directly on the internet. Third, many people never update them. Fourth, older devices may continue running for years after the vendor stops supporting them. Fifth, compromised routers are useful because they let attackers hide inside normal residential and business internet traffic.

That last point matters. If an attacker uses a compromised router in a normal neighborhood or small business, the traffic may look less suspicious than traffic coming from a known malicious server overseas. This makes compromised routers useful for proxy networks, botnets, reconnaissance, credential attacks, spam, denial-of-service attacks, and espionage.

This is where I personally agree with the U.S. stance. Over time, we could unintentionally build a giant sleeper network of vulnerable devices. They may look harmless while sitting in homes and small offices, but if enough of them are compromised or designed with weak controls, they could become a “waiting on a signal” network that can be used for large-scale internet attacks.

That is not science fiction. We have already seen botnets made out of cameras, routers, DVRs, and other IoT devices.

Security issues seen across common IoT and network devices

The concern is not theoretical. There is a long history of severe vulnerabilities in routers, cameras, DVRs, NVRs, NAS devices, and other internet-connected equipment.

Here are some of the major vendors and device categories I would watch closely.

Vendor	Country / Region	Device types	Example security issue	Why it matters
Hikvision	China	IP cameras, NVRs, DVRs	CVE-2021-36260, a command injection vulnerability in Hikvision products	Cameras and recorders are often placed on trusted networks and may be reachable remotely.
Dahua	China	IP cameras, DVRs, NVRs, intercoms	CVE-2021-33044 and CVE-2021-33045, authentication bypass flaws added to CISA’s Known Exploited Vulnerabilities catalog	Authentication bypass on cameras can allow attackers to access devices without valid credentials.
TP-Link	China / global operations	Consumer routers, Wi-Fi devices, mesh systems	CVE-2023-1389 in the TP-Link Archer AX21 allowed unauthenticated command injection as root. Fortinet reported botnets exploiting this vulnerability for wide-scale spread.	Cheap, widely deployed routers create a large attack surface.
D-Link	Taiwan	Routers, cameras, NAS devices	Multiple D-Link router flaws have been added to CISA’s Known Exploited Vulnerabilities catalog, including command injection issues.	Older home and small-business routers often remain online after support ends.
QNAP	Taiwan	NAS devices	CVE-2022-27593 affected QNAP Photo Station on internet-exposed NAS devices and was tied to DeadBolt ransomware activity.	NAS devices often contain backups and sensitive business data.
Zyxel	Taiwan	Routers, firewalls, gateways, access points	Zyxel has had router and firewall vulnerabilities appear in exploitation tracking over time, including CISA KEV-listed issues.	Edge firewalls and gateways are high-value because compromise gives attackers a network foothold.
ASUS	Taiwan	Routers and network gear	ASUS routers and update mechanisms have had serious security issues over time.	Consumer routers often blend home and business use, especially in very small businesses.
Unknown white-label brands	Various	Cameras, smart plugs, bulbs, doorbells, baby monitors, DVRs	Weak default passwords, poor update support, hardcoded credentials, exposed services, and unclear firmware origins	Cheap IoT devices can be difficult to assess, patch, or trust.

This does not mean every device from these vendors is compromised. It also does not mean U.S.-based vendors are automatically secure. Country of origin is not a replacement for security testing.

But country of origin, supply chain control, vendor transparency, update practices, and legal jurisdiction all matter when the device sits at the edge of the network.

The real risk is concentration

One vulnerable router is a problem for one household or one business.

Millions of vulnerable routers are a national security problem.

That is the part that often gets missed. The concern is not just that a single small business might get hacked. The concern is that entire product lines can become mass-exploitation targets. If a vendor has a huge share of the market and the devices are difficult to patch, attackers can scale very quickly.

This is how a consumer device becomes a national infrastructure issue.

Routers connect everything behind them. If they are compromised, they can potentially be used to:

spy on traffic patterns
redirect users to malicious sites
intercept DNS requests
attack other targets
participate in botnets
hide attacker traffic
create persistence inside homes and businesses
disrupt connectivity during a crisis

When these devices are foreign-produced and the supply chain is not trusted, the risk is not only vulnerability management. It becomes a strategic risk.

What small businesses should take from this

Most small businesses are not going to do firmware reverse engineering. They are not going to review supply chains. They are not going to analyze bootloaders or validate the integrity of embedded operating systems.

That is fine. They do not need to.

But they should have basic purchasing and lifecycle rules for network-connected devices.

For example:

Do not buy the cheapest router, camera, DVR, or smart device just because it works.
Avoid unsupported or end-of-life devices.
Do not expose router, camera, NAS, or DVR management interfaces directly to the internet.
Replace devices that no longer receive firmware updates.
Put IoT devices on a separate network whenever possible.
Require unique passwords and disable default accounts.
Turn off UPnP unless there is a specific business need.
Keep a simple inventory of routers, cameras, access points, NAS devices, and firewalls.
Check whether critical vulnerabilities exist before buying or deploying a device.
Prefer vendors with clear security advisories, update history, and vulnerability disclosure processes.

The goal is not perfection. The goal is to stop casually adding unknown, unmanaged, internet-connected hardware to business networks.

This is bigger than home Wi-Fi

For a home user, a bad router may mean poor privacy, malware risk, or participation in a botnet.

For a business, it can be worse. A compromised router or IoT device can become the first step toward ransomware, data theft, credential harvesting, or business email compromise. It can also create liability if the business unknowingly becomes part of attacks against others.

This matters even more for organizations that handle regulated data, provide critical services, or support local infrastructure.

A router is not just a box with blinking lights. It is a trust boundary.

My view

I support the U.S. taking a harder stance on foreign-made routers where there is a credible national security concern.

Not because every foreign-made device is malicious. Not because domestic devices are magically secure. But because routers are too important to treat like disposable electronics.

If we keep filling homes, businesses, and critical infrastructure with cheap devices that have poor patching, unclear ownership, weak firmware security, and questionable supply chains, we are building risk at scale.

That risk may sit quietly for years.

Then, during a conflict, crisis, or major cyber campaign, those devices can become useful to an adversary. That is the “sleeper network” concern. A large population of vulnerable routers and IoT devices does not need to be activated all at once to cause damage. It only needs to be available, distributed, and hard to clean up.

That should concern everyone.

Practical policy language for businesses

If you are a small business, school, city, clinic, manufacturer, or nonprofit, you do not need a complicated policy to start improving this area.

Here is a simple version:

Network-connected devices, including routers, firewalls, cameras, DVRs, NVRs, NAS devices, wireless access points, and IoT equipment, must be purchased from vendors with a documented security update process, supported firmware, unique credentials, and a clear vulnerability disclosure process. Unsupported devices, devices with known exploited vulnerabilities, and devices with internet-exposed management interfaces must be replaced, isolated, or remediated.

That one paragraph is better than having no standard at all.

Final Thought

Cybersecurity is not just about laptops, antivirus, and passwords. It is also about the devices we forget are even there.

Routers, cameras, DVRs, smart devices, and other IoT equipment are often treated as low-risk purchases. They are not. They are network infrastructure.

The U.S. router restriction is a reminder that supply chain security is no longer just an enterprise or government issue. It affects homes, small businesses, and the basic trust we place in the devices that connect us to the internet.

I understand the concerns raised by groups like the Electronic Frontier Foundation. A broad restriction on foreign-made routers will likely create short-term challenges, especially since the United States does not currently manufacture these devices at the scale consumers and businesses rely on.

But from a national security perspective, I think the concern is valid. If the choice is between short-term market disruption and continuing to build a massive population of vulnerable, foreign-controlled, or poorly supported edge devices, I think the long-term security benefit is worth taking seriously.

This does not mean every foreign-made device is malicious. It means routers are too important to treat like disposable consumer electronics. They are part of the trust layer of the internet, and we should be much more careful about who builds them, who updates them, and who can influence them.

PPS

Anyone remember the Bloomberg story about Supermicro? That one still keeps me up at night.

Physical Security Assessments

Tue, 21 Apr 2026 00:00:00 +0000

Physical Security Frameworks for Data Centers: ISO 27001 vs TIA-942 vs BICSI 002

When people talk about cybersecurity frameworks, they usually mean things like NIST CSF or ISO 27001. But when you start getting into physical security—especially in data centers—you quickly realize there are multiple standards, and they don’t all do the same thing.

If you’re deploying cameras, access controls, or evaluating a facility, the question becomes:

Which framework should I actually use?

This post breaks down three of the most relevant standards:

And more importantly:

What they’re for
When to use them
How they differ in practice

The Short Version

If you only remember one thing, it’s this:

ISO 27001 → Governance and risk (the why)
TIA-942 → Data center tiering and resilience (the what level)
BICSI 002 → Detailed design and implementation (the how)

They are complementary, not competing.

What Each Framework Is Actually Trying to Do

ISO/IEC 27001 — Risk-Based Security Management

:contentReference[oaicite:3]{index=3} is not a physical security standard. It’s an information security management system (ISMS) framework.

Physical security shows up under Annex A.7 (Physical and Environmental Security).

What it does:

Requires you to identify physical risks
Requires you to implement controls
Requires you to prove those controls are effective

What it does not do:

Tell you how many cameras you need
Tell you to build a mantrap
Tell you how to design a secure facility

ISO 27001 is about accountability and auditability, not engineering.

TIA-942 — Data Center Infrastructure & Tiering

:contentReference[oaicite:4]{index=4} is focused specifically on data center design and availability.

Its most well-known concept is Tier I–IV classification, which maps to uptime and redundancy.

What it does:

Defines levels of resilience
Covers:
- Power
- Cooling
- Telecommunications
- Physical security (at a higher level)
Helps organizations align infrastructure to business uptime requirements

What it does not do:

Go deep into exact implementation details (e.g., exact camera placement)
Serve as a full audit framework like ISO 27001

TIA-942 answers:
“How robust should this data center be?”

ANSI/BICSI 002 — Practical Design & Build Guidance

:contentReference[oaicite:5]{index=5} is where things get real.

This is the most hands-on, engineering-focused of the three.

What it does:

Provides detailed guidance on:
- Security zoning
- Mantraps
- CCTV coverage
- Rack layout and cages
- Cabling pathways
Includes best practices you can actually implement directly

What it does not do:

Provide a governance or audit framework
Define business-level risk acceptance

BICSI 002 answers:
“How do I actually build this correctly?”

Side-by-Side Comparison

Here’s a practical control mapping across the three:

Control Area	ISO/IEC 27001 (A.7)	TIA-942	ANSI/BICSI 002
Perimeter Security	Requires defined secure boundaries and protection from unauthorized access	Specifies site selection, perimeter barriers, standoff distances, fencing	Detailed campus/site security: fencing, vehicle barriers, CPTED principles
Facility Location & Risk	Risk-based consideration of environmental threats	Explicit guidance on site risks (flood plains, seismic zones, proximity threats)	Very detailed site selection and risk modeling (natural + human threats)
Physical Entry Controls	Access controls (badges, biometrics), visitor management	Multi-layered access (perimeter → building → white space)	Strong guidance on layered security zones, mantraps, guard presence
Access Control Zones	Secure areas defined logically	Tier-based zoning (public, restricted, critical spaces)	Formal zone model (Level 1–4 spaces, increasing restriction)
Mantraps / Controlled Entry	Not explicitly required, but implied via risk-based controls	Recommended for higher tier facilities	Often expected for high-availability / mission-critical designs
Visitor Management	Logging, escorting, authorization	Defined visitor procedures tied to security zones	Formal processes including badging, escorts, audit trails
Monitoring (CCTV)	Monitoring required, but no specifics	Recommends CCTV coverage for entrances and critical areas	Prescriptive guidance on camera placement, retention, monitoring
Intrusion Detection	Required as part of monitoring controls	IDS for perimeter and facility intrusion recommended	Detailed intrusion detection systems (motion, door sensors, alarms)
Security Staffing	Not specified	May include guards depending on tier	Explicit guidance on guard presence and roles
Environmental Protections	Protection against fire, flood, power issues	Defines fire suppression, power redundancy, environmental controls	Very detailed: fire zones, suppression types, environmental sensors
Fire Suppression	Required (risk-based)	Specifies system types (e.g., pre-action, clean agent)	Detailed engineering requirements and best practices
Power & Utilities Protection	Covered under equipment/environmental controls	Redundancy tiers (N, N+1, 2N)	Detailed power architecture and resilience planning
Equipment Security	Protect equipment from theft/damage	Physical separation and protection of critical systems	Rack-level security, cage design, locking mechanisms
Cabling Security	Protect from interception/damage	Routing requirements, separation of paths	Detailed pathways, segregation, and protection methods
Media Handling & Disposal	Secure disposal required	Referenced but not deeply prescriptive	More operational guidance on handling and destruction
Secure Work Practices	Clean desk, restricted activities	Not a primary focus	Limited (more facility-focused than behavioral)
Logging & Audit Trails	Required (access logs, monitoring logs)	Expected for compliance and operations	Strong emphasis on logging physical access events
Resilience / Redundancy	Risk-based requirement	Core concept (Tier I–IV classification)	Strong focus on uptime, redundancy, and fault tolerance
Testing & Maintenance	Control effectiveness must be reviewed	Requires testing of systems (power, fire, etc.)	Detailed maintenance and operational procedures
Documentation	Policies and procedures required	Design and operational documentation required	Extensive documentation expectations (design + ops)

When to Use Each Framework

Use ISO 27001 when:

You need an audit-ready security program
You’re aligning to compliance or certification
You want to demonstrate risk management maturity

This is what executives, auditors, and customers care about.

Use TIA-942 when:

You’re designing or evaluating a data center
You need to define uptime expectations
You want to align infrastructure to business impact

This is what architects and leadership use to justify investment.

Use BICSI 002 when:

You’re actually building or assessing a facility
You need specific implementation guidance
You want to avoid “hand-wavy” security designs

This is what engineers and assessors use on the ground.

How They Work Together (Real World)

In practice, mature organizations don’t pick one—they use all three:

ISO 27001 defines what must exist
TIA-942 defines how robust it should be
BICSI 002 defines how to implement it

If you’re doing a physical security assessment:

Use ISO 27001 to frame controls and reporting
Use BICSI 002 to identify gaps and make recommendations
Use TIA-942 to contextualize risk and resilience

Final Thought

A lot of physical security assessments fail because they lean too far in one direction:

Too ISO → vague, checkbox-driven
Too BICSI → overly technical, no business context
Too TIA → focused on uptime, missing control depth

The sweet spot is combining all three.

That’s where you move from:

“We have cameras”

to:

“We have a defensible, risk-aligned physical security program”

5 Common Security Mistakes Small Businesses Make (And How to Fix Them)

Fri, 10 Apr 2026 00:00:00 +0000

Most small and mid-sized businesses aren’t ignoring cybersecurity—they’re just trying to balance it with everything else.

The problem is, a few common gaps show up over and over again. Not because people don’t care, but because no one has clearly explained what actually matters.

Here are the five most common mistakes I see—and what to do about them.

1. Assuming “We’re Too Small to Be Targeted”

This is the most common—and most dangerous—assumption.

Most attacks today aren’t targeted. They’re automated. Attackers scan the internet looking for:

weak passwords
exposed services
outdated systems

If your business shows up in that scan, you’re a target.

What to do instead

Focus on basic protections:

strong passwords + MFA
patching systems
limiting exposure to the internet

You don’t need to be perfect—you just need to not be easy.

2. Relying Soley on an IT Provider for Security

Your IT provider (MSP) is critical, but their primary job is to keep systems running.

Security is different. It’s about:

identifying risk
making decisions about what matters
preparing for worst-case scenarios

Most MSPs handle operational security, not strategic security.

What to do instead

Make sure someone is responsible for:

understanding your risk
prioritizing improvements
guiding decisions at a business level

3. Not Understanding Cyber Insurance Requirements

Many businesses have cyber insurance—but don’t realize:

Coverage depends on having specific controls in place.

If something happens and those controls aren’t there:

claims can be reduced
or denied entirely

What to do instead

Before renewal, make sure you can confidently answer:

Do we actually meet the requirements?
Are controls documented and consistent?

This is one of the easiest ways to reduce risk quickly.

4. No Plan for “What Happens If Something Goes Wrong”

When an incident happens, most teams are figuring things out in real time.

That leads to:

delays
mistakes
lost evidence
increased impact

Even a simple event can escalate quickly without a plan.

What to do instead

Have a basic incident response plan:

who to call
what to isolate
what NOT to do
how to document

You don’t need a 100-page binder—just a clear starting point.

5. Trying to Do Everything Instead of What Matters

There’s a lot of noise in cybersecurity:

tools
checklists
frameworks

It’s easy to feel like you’re always behind.

The reality is:

Not all risks are equal.

Trying to fix everything at once leads to:

wasted effort
frustration
no real progress

What to do instead

Focus on:

your biggest risks first
the systems that matter most
practical improvements

Progress beats perfection.

Final Thought

Most businesses don’t have a cybersecurity problem, they have a clarity problem.

Once you understand:

where your real risks are
what actually matters

Do you have a plan for when things go wrong?

Everything gets simpler.

If you’re not sure where you stand, a quick review can usually identify the biggest gaps in under an hour.

MN Risk & Cybersecurity Advisory Cybersecurity guidance for small & mid-sized businesses Local. Independent. Vendor-neutral.

When April Fools Becomes a Security Risk

Mon, 06 Apr 2026 00:00:00 +0000

Every year on April 1st, the internet fills up with jokes, fake announcements, and pranks. Most of it is harmless.

But in cybersecurity, April Fools creates a very real problem:

It becomes harder to tell what’s real—and what’s not.

And that hesitation can be costly.

Real Incidents, Bad Timing

In 2026, multiple legitimate cybersecurity events happened right on April 1st.

A major crypto platform was hacked, losing hundreds of millions of dollars
A large company disclosed a real cyber incident affecting its systems

In both cases, early reactions were mixed:

“Is this real?”
“Is this just a stunt?”
“Is this part of April Fools?”

That uncertainty matters.

Because in cybersecurity, speed matters.

Why April 1 Is Different

Most security incidents rely on one thing to succeed:

Delay

Attackers don’t need hours—they need minutes.

If a suspicious message, login prompt, or alert gets ignored—even briefly—that’s often enough.

April 1 introduces a dangerous variable:

People second-guess what they’re seeing
Teams hesitate before responding
Alerts don’t get the same urgency

In other words:

The signal-to-noise ratio drops at exactly the wrong time.

A New Type of Risk: “Looks Like a Joke”

Traditionally, cybersecurity advice focuses on:

Spotting fake emails
Avoiding malicious links
Using strong authentication

But now there’s a different problem:

Real threats that look like jokes

For example:

A strange login request
An unusual email from a vendor
A “weird” system alert

On any other day, you might investigate immediately.

On April 1?

You might ignore it.

Why This Hits Small Businesses Harder

Large organizations have:

Security teams
Monitoring tools
Formal incident response processes

Most small and mid-sized businesses don’t.

Instead, they rely on:

Gut instinct
Experience
“Does this feel real?”

That works most of the time.

But April Fools disrupts that instinct.

And that creates an opening.

What to Do Instead

You don’t need a complex security program to handle this.

Just a simple rule:

Treat April 1 like any other day when it comes to security.

Specifically:

Don’t dismiss unusual login prompts
Don’t ignore unexpected emails—even if they seem odd
Verify before assuming something is a joke
When in doubt, take a second look

It’s better to investigate something harmless than to ignore something real.

The Bigger Shift

Cybersecurity is changing.

It’s no longer just about:

Preventing break-ins
Blocking malware
Stopping obvious phishing

More and more, it’s about:

Understanding how attackers use normal behavior against you

April Fools is a perfect example.

It’s not a vulnerability in software.

It’s a vulnerability in how people respond.

Final Thought

The worst day to ignore a security alert is April 1.

If something looks unusual, treat it seriously—no matter what day it is.

If you’d like help understanding your organization’s real-world exposure—from email security to DNS and web vulnerabilities—feel free to reach out.

No pressure, just a conversation.

Is My MSP/MSSP enough?

Thu, 26 Mar 2026 00:00:00 +0000

Do I Need a vCISO or Is My MSP Enough?

If you’re a small or mid-sized business, you’ve probably asked a version of this question:

“We already have an IT provider… aren’t they handling security?”

It’s a fair question—and the answer is:

Your MSP is essential. But they’re not designed to own your security strategy.

What Your MSP Does Well

Managed Service Providers (MSPs) and Managed Security Service Providers (MSSPs) are critical partners. They:

Keep systems running
Deploy and manage security tools
Respond to alerts and incidents
Handle day-to-day IT operations

In other words:

They operate your technology and security environment.

And most businesses absolutely need that.

Where the Gap Starts

The challenge isn’t execution—it’s direction.

Most MSPs are not responsible for:

Defining your overall security strategy
Prioritizing risks based on business impact
Planning for upcoming projects (cloud migrations, new systems, etc.)
Measuring whether your current security tools are actually effective

That’s not a knock on MSPs—it’s just not what they’re built for.

They are optimized for:

Efficiency
Standardization
Keeping environments stable

Not for:

Business-level risk decisions
Long-term security planning

What a vCISO Actually Does

A vCISO (virtual Chief Information Security Officer) fills that gap.

Instead of focusing on tools, a vCISO focuses on:

Risk — What actually matters to your business
Prioritization — What should be fixed first (and what can wait)
Strategy — Where your security program is going over time
Alignment — Making sure IT, security, and business goals match

Think of it this way:

Your MSP runs the engine.
A vCISO helps decide where the car should go—and whether it’s safe to get there.

Why This Matters for Small Businesses

Most small and mid-sized businesses don’t need a full-time CISO.

But they do need:

Someone asking the right questions
Someone validating decisions
Someone making sure money is being spent in the right places

Without that, it’s easy to end up with:

Too many tools
Gaps in critical areas
A false sense of security

The Best Approach: Work Together

The strongest model isn’t MSP or vCISO.

It’s both.

Your MSP handles execution and operations
A vCISO provides strategy and oversight

And importantly:

A good vCISO should make your MSP more effective—not replace them.

Where to Start

If you’re not sure whether your current setup is covering both strategy and execution, the first step is simple:

Take a step back
Look at your risks
Evaluate whether your current approach aligns with your business

That’s exactly what a cybersecurity review is designed to do.

Bottom Line

Your MSP is a critical partner—but strategy doesn’t happen by accident.

If no one owns it, it’s probably not being done.

Not sure where to start?

Need a Second Perspective?

If you’re not sure where your current setup falls—or whether your business has gaps between IT operations and security—it’s worth taking a closer look.

Why engage a vCISO?

Wed, 25 Mar 2026 00:00:00 +0000

Why Small and Mid-Sized Businesses Should Consider a vCISO

If you run a small or mid-sized business, you’ve probably asked yourself a version of this question:

“Do we really need a CISO?”

The honest answer is:
You need what a CISO does—not necessarily the full-time salary that comes with one.

That’s where a vCISO (virtual Chief Information Security Officer) comes in.

Security Is About Maturity, Not Magic

Let’s start with a reality check.

Cybersecurity isn’t about buying the right tool or hiring a “rockstar engineer.”
It’s about process maturity and risk reduction over time.

Good security programs:

Reduce risk in measurable ways
Protect your brand and reputation
Keep operations running smoothly
Enable the business—not slow it down

And most importantly:

You don’t have to outrun the bear. You just have to outrun the slowest person.

Attackers are opportunistic. They’re looking for:

Weak controls
Unpatched systems
Poor visibility
Easy wins

If your organization is just a little harder to compromise than the next one, you’ve already shifted the odds in your favor.

The “Middle Market Security Gap” Is Real

A recent industry report highlighted something many of us have seen firsthand:

Midmarket companies are too big to ignore, but too small to be served properly.

These organizations:

Have real revenue and valuable data
Operate complex environments (cloud, SaaS, remote workforce)
Face the same threats as enterprises

But they lack:

Dedicated security leadership
Mature processes
Integrated tooling
Board-level engagement

The result?

High confidence… but low visibility
Too many tools… but not enough clarity
Security stuck in IT… instead of being a business conversation

Why a Full-Time CISO Often Doesn’t Make Sense

Let’s talk economics.

A seasoned CISO will cost:

$250K–$350K base salary
Plus bonuses, equity, benefits
Realistically $400K–$500K+ total cost

That’s before you even fund:

Staff
Tools
Consulting
Compliance efforts

For most SMBs, that’s simply not practical.

But the risks?
They’re very real.

What a vCISO Actually Brings to the Table

A good vCISO isn’t just a “part-time advisor.”
They bring structure, clarity, and momentum.

1. Turning Chaos Into a Program

Most SMBs have security activities—but not a security program.

A vCISO helps you:

Build a risk register
Define policies and standards
Establish ownership and accountability
Create repeatable processes

2. Translating Cyber Risk Into Business Risk

Security often dies in technical language.

A vCISO connects the dots between:

Vulnerabilities → financial risk
Incidents → operational impact
Controls → business outcomes

This is how cybersecurity finally makes it into:

Executive conversations
Budget discussions
Board-level awareness

3. Reducing Tool Sprawl and Noise

Many SMBs are drowning in tools:

Too many alerts
No prioritization
No unified view of risk

A vCISO helps you:

Rationalize your stack
Focus on what actually matters
Get value out of what you already own

4. Prioritizing What Actually Reduces Risk

Not all security work is equal.

A vCISO focuses on:

High-impact, low-effort improvements
Real risk reduction—not checkbox compliance
Incremental progress over time

Because here’s the truth:

Small, consistent improvements will transform your security posture.

5. Preparing for the Inevitable

It’s not if—it’s when.

A vCISO ensures you’re ready:

Incident response planning
Tabletop exercises
Defined roles and communication paths

So when something happens, you’re not improvising.

6. Acting as a Force Multiplier

A vCISO doesn’t replace your MSP or IT team.

They:

Augment your existing providers
Provide strategic direction
Help operational teams execute effectively

Think of it as:

Strategy + oversight + alignment = better outcomes from the same resources

You Don’t Need to Beat Nation-States

Let’s be clear about something.

There are adversaries with:

Unlimited time
Unlimited money
Advanced capabilities

You are not going to out-defend them.

And you don’t need to.

Your goal is to:

Reduce your attack surface
Eliminate easy wins
Detect and respond quickly
Make yourself a less attractive target

That’s achievable.

The ROI of a vCISO

Instead of spending $500K/year on a full-time executive, you can:

Engage a vCISO for a fraction of the cost
Start building a real security program
Reduce meaningful risk within months
Avoid costly breaches, downtime, and reputational damage

And perhaps most importantly:

You start making intentional, measurable progress instead of reacting to the latest fire.

Final Thought

Most SMBs don’t have a technology problem.
They have a prioritization and maturity problem.

A vCISO helps you:

Focus
Simplify
Execute

Cybersecurity isn’t about perfection.

It’s about being:

Slightly better
Slightly faster
Slightly harder to attack

Day after day.

And over time, that’s what turns your organization from a target…
into one that attackers decide just isn’t worth the effort.

Not sure where to start?

Need a Second Perspective?

If you’re not sure where your current setup falls—or whether your business has gaps between IT operations and security—it’s worth taking a closer look.

How Do I Recover From Ransomware?

Sun, 22 Mar 2026 00:00:00 +0000

Why Modern Backup Strategy Matters (3-2-1-1)

A friend of mine works in IT consulting, mostly on the operational side of things. He was recently called in by a potential client who had started seeing some concerning messages on their computer—clear warning signs that something wasn’t right.

He advised the client to slow down, investigate, and address the issue properly.

The client chose a different path.

They prioritized getting the business back up and running as quickly as possible.

A week later, they were hit with ransomware.

The First Recovery… and the Missed Gap

To his credit, my friend did a lot right during the initial recovery. He took time to ensure the business had a backup strategy in place. For its time, it was solid—aligned with what was considered best practice.

Back then, the gold standard was the 3-2-1 backup rule:

3 copies of your data
2 different storage media
1 copy stored off-site

On paper, that sounds like a strong strategy—and for years, it was.

But there was a critical gap.

What Changed: Attackers Got Smarter

Modern ransomware operators don’t just encrypt your data.

They:

Gain access to your environment
Move laterally
Identify backup systems
Delete or corrupt backups before deploying ransomware

Why?

Because if you can restore your data, you don’t need to pay.

The Evolution to 3-2-1-1

That’s why today’s best practice has evolved into 3-2-1-1:

3 copies of your data
2 different storage types
1 off-site copy
1 offline or immutable copy

That last “1” is the difference-maker.

Offline vs. Immutable Backups

To survive modern ransomware, at least one copy of your data must be:

🔒 Offline

Not connected to your network at all

Example: tape backups, disconnected storage

🧊 Immutable

Stored in a way that prevents modification or deletion

Example: object storage with immutability / retention locks

If an attacker can reach your backups, they can delete your backups.

The Case for “Old” Technology

I’ve always been a fan of tape backups.

That opinion tends to get some eye rolls from other technology folks—but here’s the reality:

Tape, when used correctly, is offline by default.

No network access. No API. No remote deletion.

That makes it inherently resilient to ransomware.

Now, to be fair:

Tape libraries (robotic systems) can reduce that isolation
Management practices matter

But the core idea holds: offline is powerful.

Why This Matters

On the worst day your business will ever have—when ransomware hits—your backups determine your future.

You are either:

Restoring operations and moving forward

Rebuilding your business from scratch

There is no middle ground.

The Real Question

When everything else fails, it comes down to one simple question:

Do you still have a clean, recoverable copy of your data?

If the answer is no, then the only remaining copy may be in the hands of the attacker.

Final Thought

Backup strategy isn’t just about redundancy anymore—it’s about resilience against an active adversary.

If your backups can be deleted, they are not a reliable safety net.

Make sure your strategy includes that final layer.

Because when you need it, it’s already too late to fix it.

Not sure where to start?

Need a Second Perspective?

If you’re not sure where your current setup falls—or whether your business has gaps between IT operations and security—it’s worth taking a closer look.

Where Should a Small Business Start With Cybersecurity?

Mon, 09 Mar 2026 00:00:00 +0000

If you’re a small or medium-sized business owner, cybersecurity can feel overwhelming.

You hear about things like NIST frameworks, ISO certifications, SOC 2 audits, and the OWASP Top 10, and it quickly starts to sound like something only giant corporations can afford to worry about.

The truth is much simpler.

You don’t need to start with a 400-page framework or hire a team of security engineers. Most small businesses can dramatically improve their security posture by focusing on a handful of practical controls.

Before worrying about compliance frameworks or certifications, start with the fundamentals.

Step 1: Focus on the Biggest Risks First

Most cyber attacks against small businesses are not sophisticated nation-state attacks. They are usually one of the following:

Phishing emails that steal passwords
Stolen credentials reused across services
Ransomware delivered through compromised accounts
Unpatched systems exposed to the internet

Attackers go after the easiest path, not the most impressive one.

The good news is that the biggest risks also tend to have the simplest fixes.

Step 2: Implement the Security Basics

If a small business does nothing else, these controls will stop a huge percentage of real-world attacks.

Use Multi-Factor Authentication Everywhere

Passwords alone are no longer enough.

Multi-factor authentication (MFA) requires users to confirm their login with something they have, like a phone or authenticator app.

At a minimum, MFA should be enabled for:

Email accounts
Microsoft 365 or Google Workspace
VPN access
Administrative accounts
Financial systems

Compromised email accounts are one of the most common starting points for fraud and ransomware.

Keep Systems Automatically Updated

Many attacks exploit vulnerabilities that already have patches available.

Make sure the following systems update automatically:

Windows and macOS systems
Servers
Firewalls and network equipment
Business applications
Cloud services

Delaying updates is one of the easiest ways to leave the door open to attackers.

Use a Password Manager

People naturally reuse passwords across multiple sites.

That becomes a major problem when one of those sites gets breached.

Password managers allow employees to generate unique, strong passwords for every system without needing to remember them.

Limit Administrative Access

Not every employee needs full control of systems.

The principle of least privilege means users should only have the access they need to do their jobs.

Reducing administrative access dramatically limits the damage if an account is compromised.

Back Up Critical Data

Ransomware attacks often succeed because organizations have no reliable backup.

Backups should be:

Automated
Stored separately from production systems
Tested periodically to ensure recovery works

If you can restore your systems from backup, ransomware becomes far less threatening.

Step 3: Use a Simple Security Framework

Once the basics are in place, it helps to organize security around a simple framework.

One widely used model is the NIST Cybersecurity Framework, which breaks cybersecurity into five core functions:

Identify – Understand your systems and risks
Protect – Implement controls to reduce risk
Detect – Monitor for suspicious activity
Respond – Know how to react to incidents
Recover – Restore operations after an attack

You don’t need to implement hundreds of controls to benefit from this model. Even a lightweight version can help structure your security efforts.

Step 4: Document What You Have

Many small businesses already have security controls in place — they just aren’t documented.

Start by writing down:

What systems you run
Who administers them
What backups exist
What security tools are deployed
Who to contact during an incident

This simple inventory becomes the foundation for improving your security posture over time.

Step 5: Improve Gradually

Cybersecurity isn’t a project you complete once and forget.

It’s a process of continuous improvement.

A practical roadmap for many small businesses might look like this:

Year 1

Implement MFA
Establish reliable backups
Inventory systems
Deploy endpoint protection

Year 2

Centralize logging
Implement vulnerability scanning
Formalize basic security policies

Year 3

Conduct tabletop incident response exercises
Evaluate compliance frameworks if required by customers

You don’t have to solve everything at once.

Final Thoughts

Cybersecurity often looks intimidating because the industry uses a lot of jargon and complex frameworks.

But at its core, protecting a business comes down to a few practical steps:

Protect identities
Patch systems
Limit access
Back up data
Monitor activity

For most small and mid-sized organizations, doing these things consistently will prevent the majority of real-world attacks.

Start simple, improve steadily, and focus on the controls that reduce real risk.

Not sure where to start?

Need a Second Perspective?

If you’re not sure where your current setup falls—or whether your business has gaps between IT operations and security—it’s worth taking a closer look.

NIST CSF for Small Businesses: A Practical Guide

Sat, 07 Mar 2026 00:00:00 +0000

If you start researching cybersecurity for your business, you will eventually encounter the NIST Cybersecurity Framework (CSF).

At first glance, it can feel intimidating. It includes dozens of categories, references hundreds of controls, and is widely used by government agencies and large enterprises.

But the core idea behind the framework is actually very simple.

The NIST Cybersecurity Framework organizes cybersecurity into six major functions that describe the lifecycle of managing cyber risk.

These functions help answer fundamental questions like:

Do we understand our risks?
Are we protecting our systems?
Can we detect an attack?
Do we know what to do if something goes wrong?

For small and medium-sized businesses, the framework provides a structured way to think about cybersecurity without needing to become a security expert.

The Six Core Functions

The CSF is built around six core functions:

Identifier	Function	Purpose
GV	Govern	Establish cybersecurity strategy and oversight
ID	Identify	Understand systems, assets, and risks
PR	Protect	Implement safeguards to reduce risk
DE	Detect	Identify cybersecurity events
RS	Respond	Contain and manage incidents
RC	Recover	Restore operations after an incident

Think of these functions as the lifecycle of cybersecurity risk management.

GOVERN (GV)

Definition:
The organization’s cybersecurity risk management strategy, expectations, and policy are established, communicated, and monitored.

What This Means in Practice

Governance answers questions like:

Who is responsible for cybersecurity?
What risks are acceptable?
What policies guide how technology is used?
How are vendors evaluated?

Many small businesses assume cybersecurity is purely a technical issue, but it is actually a business risk management issue.

Just like financial oversight or legal compliance, cybersecurity requires leadership and accountability.

Why This Matters for SMBs

Without governance:

Security decisions become reactive
Employees don’t know expectations
Vendors may introduce risk
Security spending becomes random

Common Pitfalls

Small businesses often:

Have no written security policies
Assume their IT provider is responsible for everything
Never evaluate vendor security risk
Lack executive ownership of cybersecurity

Where a vCISO Helps

A virtual Chief Information Security Officer (vCISO) helps translate cybersecurity into business terms.

They help leadership:

Define risk tolerance
Establish policies
Align security with business goals
Ensure accountability exists

IDENTIFY (ID)

Definition:
The organization’s current cybersecurity risks are understood.

What This Means in Practice

Before protecting your business, you must understand:

What systems exist
What data you store
What vendors you rely on
What risks could impact operations

Many businesses discover they cannot answer basic questions like:

Where is our customer data stored?
What systems are internet-facing?
What software do employees use?

Why This Matters for SMBs

You cannot protect what you do not know exists.

If systems, cloud services, or vendors are unknown, they become blind spots attackers can exploit.

Common Pitfalls

Small businesses often:

Have no inventory of systems
Forget about shadow IT and SaaS tools
Lack visibility into third-party vendors
Skip formal risk assessments

Where a vCISO Helps

A vCISO typically begins with a security baseline assessment:

Inventory systems and assets
Identify critical data
Evaluate existing controls
Map risks to business impact

This creates the foundation for the rest of the security program.

PROTECT (PR)

Definition:
Safeguards to manage the organization’s cybersecurity risks are used.

What This Means in Practice

This is the function most people think of when they hear “cybersecurity”.

It includes controls such as:

Multi-factor authentication
Endpoint protection
Encryption
Access controls
Employee security training

These safeguards reduce the likelihood that attackers can compromise systems.

Why This Matters for SMBs

Most cyber attacks against small businesses rely on very basic weaknesses, such as:

weak passwords
phishing attacks
unpatched systems
excessive user privileges

Implementing even basic protections dramatically reduces risk.

Common Pitfalls

Businesses often:

Rely entirely on antivirus
Skip security awareness training
Give employees excessive privileges
Delay system updates

Where a vCISO Helps

A vCISO helps prioritize protections based on real risk, not marketing hype.

Instead of buying random security tools, they help ensure:

identity security is implemented properly
employees receive training
access controls are enforced
protections align with the risk profile

DETECT (DE)

Definition:
Possible cybersecurity attacks and compromises are found and analyzed.

What This Means in Practice

Even the best protections cannot stop every attack.

Detection focuses on answering:

Are we currently under attack?
Has an account been compromised?
Is someone accessing data they shouldn’t?

Examples include:

monitoring login behavior
analyzing suspicious activity
reviewing security alerts

Why This Matters for SMBs

Many small businesses discover breaches months after they happen.

Without monitoring, attackers can quietly:

steal data
deploy ransomware
move through systems

Early detection dramatically reduces damage.

Common Pitfalls

Small businesses often:

Do not review security logs
Ignore security alerts
Lack centralized monitoring
Assume their firewall will detect everything

Where a vCISO Helps

A vCISO helps implement practical detection capabilities such as:

centralized logging
alert monitoring
security dashboards
escalation procedures

RESPOND (RS)

Definition:
Actions regarding a detected cybersecurity incident are taken.

What This Means in Practice

If an incident occurs, the organization must know:

who investigates
who communicates internally
whether law enforcement is contacted
whether customers must be notified

A documented response plan dramatically improves outcomes during an incident.

Why This Matters for SMBs

During an attack, panic and confusion can cause more damage than the attack itself.

Without a plan:

systems may be shut down unnecessarily
legal obligations may be missed
evidence may be destroyed
recovery may take longer

Common Pitfalls

Businesses frequently:

have no incident response plan
rely on ad-hoc decisions during a crisis
fail to define communication procedures

Where a vCISO Helps

A vCISO helps create and test:

incident response plans
escalation procedures
tabletop exercises
communication protocols

RECOVER (RC)

Definition:
Assets and operations affected by a cybersecurity incident are restored.

What This Means in Practice

After an incident, organizations must:

restore systems from backup
validate integrity of systems
communicate with stakeholders
improve defenses

Recovery ensures the business can resume operations quickly and safely.

Why This Matters for SMBs

Many small businesses fail after a major cyber incident because they cannot restore operations quickly.

Reliable recovery capabilities mean:

downtime is minimized
customer trust is preserved
financial losses are reduced

Common Pitfalls

Organizations often:

assume backups work without testing them
store backups in the same environment as production
lack documented recovery procedures

Where a vCISO Helps

A vCISO ensures recovery plans are realistic by helping organizations:

design resilient backup strategies
test disaster recovery procedures
improve resilience after incidents

Why the NIST CSF Is Useful for Small Businesses

The NIST Cybersecurity Framework does not require a specific technology or vendor.

Instead, it provides a structured way to manage cybersecurity risk.

For small and medium-sized businesses, this is valuable because it helps answer questions like:

What should we prioritize?
What controls are missing?
What risks should leadership understand?

Rather than chasing individual security tools, the framework focuses on building a complete security program.

Why Many Businesses Work With a vCISO

Most small businesses do not have a dedicated cybersecurity executive.

A vCISO (Virtual Chief Information Security Officer) or vCXO provides strategic security leadership without the cost of a full-time executive.

They help organizations:

assess current security maturity
align with frameworks like NIST CSF
prioritize investments
coordinate security initiatives
communicate risk to leadership

For many organizations, a vCISO acts as the bridge between business leadership and technical teams.

Final Thoughts

Cybersecurity does not have to be overwhelming.

Frameworks like the NIST Cybersecurity Framework provide a clear roadmap built around six simple ideas:

Govern cybersecurity risk
Identify what needs protection
Protect systems and data
Detect suspicious activity
Respond to incidents effectively
Recover operations when something goes wrong

Even a simplified implementation of these functions can significantly improve a small business’s security posture.

The key is starting with a structured approach and improving over time.

Not sure where to start?

Need a Second Perspective?

If you’re not sure where your current setup falls—or whether your business has gaps between IT operations and security—it’s worth taking a closer look.

What Happens During a Cybersecurity Review?

Fri, 06 Mar 2026 00:00:00 +0000

Cybersecurity can feel overwhelming. There are thousands of tools, vendors, and security products, and it is not always clear where organizations should focus their efforts.

A cybersecurity review helps organizations step back and evaluate whether their current security posture is addressing the most important risks.

Understanding Risk Exposure

The review begins with understanding the organization’s risk profile.

Important questions include:

What types of data does the organization store?
What systems are critical to operations?
What would the impact of downtime or data loss be?

Security priorities should be driven by business risk.

Reviewing Current Security Controls

A cybersecurity review typically evaluates areas such as:

multi-factor authentication
identity and access management
endpoint protection
backup and recovery capabilities
email security
network segmentation
monitoring and logging

The goal is to understand what protections already exist and how effectively they are implemented.

Identifying Priority Security Risks

Not every security gap represents the same level of risk.

The review focuses on identifying the most important vulnerabilities or weaknesses, such as:

lack of multi-factor authentication
insufficient backup protections
exposed remote access services
lack of monitoring or alerting

Addressing these higher-impact risks first often produces the greatest improvement in security posture.

Creating a Security Improvement Plan

Rather than recommending dozens of new tools, the goal is to create a clear and realistic plan for strengthening security over time.

This might include:

prioritizing specific security improvements
better configuring existing tools
aligning controls with frameworks such as CIS Critical Security Controls or NIST

Supporting Existing MSPs and Security Providers

A cybersecurity review is designed to work alongside existing MSPs and MSSPs.

Operational providers manage day-to-day systems and security operations. An independent review helps ensure those efforts are aligned with the organization’s most important risks and priorities.

Cybersecurity Reviews for Hutchinson Businesses

Thu, 05 Mar 2026 00:00:00 +0000

Many organizations today rely on Managed Service Providers (MSPs) and Managed Security Service Providers (MSSPs) to operate their technology and security environments. These providers are essential partners, and they play a critical role in keeping systems running and protecting businesses from threats.

However, many companies still struggle with an important question:

Are we investing in the right technology and security priorities?

That’s where an independent technology and cybersecurity review can help.

I work with organizations primarily in Hutchinson, Minnesota and the surrounding communities, helping small and mid-sized businesses step back and evaluate whether their technology and cybersecurity investments are aligned with their actual risks and business goals.

An Independent Strategic Perspective

My role is not to replace your MSP or MSSP.

In fact, the opposite.

I work alongside existing technology providers to help organizations evaluate their technology and cybersecurity posture from a strategic perspective.

This includes reviewing things such as:

Current cybersecurity controls
Security tooling and architecture
Technology investments and priorities
Risk exposure and mitigation strategies
Alignment with frameworks such as CIS Critical Security Controls or NIST

The goal is to ensure organizations are focusing on the right risks and the right investments.

Maximizing Technology and Security Spend

Many companies invest significant money into IT and cybersecurity tools but still feel uncertain about whether they are getting the most value from those investments.

A strategic review can help answer questions like:

Are we spending money on tools we don’t actually need?
Are we missing critical protections while investing elsewhere?
Are our tools configured and integrated effectively?
Are we prioritizing the most important security risks?

By focusing on strategy and prioritization, organizations can often improve their security posture without necessarily increasing spending.

Working Alongside MSPs and MSSPs

Operational providers such as MSPs and MSSPs are incredibly important.

They manage systems, deploy solutions, monitor alerts, and handle day-to-day operations.

My role is different.

I focus on:

Strategy
Architecture
Prioritization
Independent review

Rather than displacing an MSP or MSSP, I aim to augment their work by helping ensure the organization is pursuing the right long-term direction.

Think of it as adding an independent technology and cybersecurity advisor to your team.

Technology Agnostic Guidance

One important principle of my work is that I am technology agnostic.

I do not sell software, hardware, or security products.

That means recommendations are based on what is best for the organization — not tied to a particular vendor or platform.

This allows businesses to make more informed decisions about:

Security platforms
Infrastructure investments
Cloud architecture
Risk management strategies

A Practical Approach to Cybersecurity

Cybersecurity can feel overwhelming. There are thousands of tools, vendors, and frameworks, and it can be difficult to know where to start.

The focus of these reviews is simple:

Identify the most important risks
Ensure the organization is investing in the right protections
Align security efforts with business priorities

The end result is a clearer roadmap for improving security while making the most of existing technology investments.

If your organization is located in Hutchinson, Minnesota or the surrounding area and would benefit from an independent perspective on technology or cybersecurity strategy, a review can provide valuable insight and help ensure you are focusing on what matters most.

I work with businesses throughout Hutchinson and nearby communities, including areas such as Glencoe, Waconia, Buffalo, Litchfield, and other parts of central Minnesota. Many organizations in our region rely heavily on MSPs and trusted technology partners, and my goal is simply to help ensure those investments are aligned with the right strategy and priorities.

Not sure where to start?

Need a Second Perspective?

If you’re not sure where your current setup falls—or whether your business has gaps between IT operations and security—it’s worth taking a closer look.

How Email Security Actually Works: API vs SEG vs Inline Solutions

Sun, 01 Feb 2026 00:00:00 +0000

Email is still the #1 attack vector for most businesses.

But when you start looking at email security products, it gets confusing fast:

API-based tools
Inline / journaling solutions
Secure Email Gateways (SEG)

They all “protect email”… but they work very differently.

Understanding that difference is more important than the product you choose.

The Three Main Types of Email Security

There are three primary architectures:

API-based email security
Inline / journaling (hybrid API)
Secure Email Gateways (SEG / MX-based)

Let’s break them down.

1. API-Based Email Security

Examples:

How it works

API-based tools connect directly into Microsoft 365 or Google Workspace.

They do NOT sit in the mail flow.

Instead, they:

analyze emails inside the mailbox
monitor user behavior and communication patterns
detect attacks like BEC, phishing, and account takeover

This gives them access to signals traditional tools don’t see (like internal emails and identity behavior) :contentReference[oaicite:2]{index=2}

Pros

No MX changes required
Fast deployment (minutes)
Works well with Microsoft 365 native protection
Can detect advanced/social engineering attacks
Can remediate emails after delivery

Cons

Email is already delivered before action (in some cases)
Less control over mail flow
Not always ideal for strict compliance environments

Key takeaway

API-based security is great for modern cloud email and advanced threats

2. Inline / Journaling-Based (Hybrid API)

Examples:

Check Point Harmony Email (Avanan)

(Some vendors blur the lines here—Avanan is API-first but can act inline)

How it works

These solutions:

integrate via API
AND can inspect messages inline or via journaling

They effectively sit logically in the flow, without always requiring MX changes.

They can:

block before delivery
analyze internal traffic
extend into Teams, OneDrive, etc. :contentReference[oaicite:4]{index=4}

Pros

Better pre-delivery blocking than pure API
Still cloud-native
Broader coverage (email + collaboration tools)
Good balance of visibility + control

Cons

More complex than pure API
Can overlap with existing tools
Still not as “authoritative” as a gateway for mail flow

Key takeaway

Hybrid approaches try to give you the best of both worlds

3. Secure Email Gateways (SEG)

Examples:

How it works

SEGs sit in front of your email system.

You change your MX record so mail flows like this:

Internet → SEG → Microsoft 365

They inspect email before it ever reaches your environment.

Pros

Full control of inbound mail flow
Blocks threats before delivery
Strong for:
- spam filtering
- malware
- compliance / DLP
Mature and well understood

Cons

You are altering your mail flow
MX records point to a third party (visible externally)
Can introduce:
- latency
- delivery issues
Limited visibility into internal email activity
Often weaker against modern BEC/social engineering attacks

Also worth noting:

SEGs were originally designed for on-prem email
Modern attacks increasingly bypass perimeter-only controls :contentReference[oaicite:8]{index=8}

Key takeaway

SEGs are great at controlling the perimeter, but struggle with modern identity-based attacks

Important: These Categories Overlap

This is where people get confused.

Some vendors can do multiple things.

For example:

Barracuda Email Protection supports gateway + API deployment models
Avanan is API-based but can act inline
Mimecast is primarily SEG, but has integrations/APIs

Do You Even Need a SEG?

If you’re running Microsoft 365:

You may NOT need a traditional SEG

Why:

Microsoft already provides baseline filtering
API-based tools can layer on top
You avoid changing mail flow entirely

In many cases:

Microsoft 365 + API-based security = simpler, modern architecture

The Tradeoff (This Matters)

SEG approach:

Strong control
More complexity
Visible externally (MX records)
Legacy-friendly

API approach:

Simpler
Better for modern attacks
Less intrusive
Relies on cloud-native architecture

The Real Problem Most Businesses Have

It’s not “which tool is best.”

It’s:

overlapping tools
unclear architecture
gaps between layers

You’ll often see:

SEG + M365 Defender + API tool
all doing similar things
but no one knows what’s actually working

Final Thought

Email security isn’t about buying more tools.

It’s about understanding:

where your protection sits
what it can see
what it can’t

Once you understand that, the right solution becomes obvious.

Need Help Figuring It Out?

If you’re not sure whether your current email security setup actually makes sense—or if you’re paying for overlapping tools—it’s worth taking a closer look.

What’s the Difference Between Antivirus, Malwarebytes, EDR, and XDR?

Thu, 01 Jan 2026 00:00:00 +0000

If you’ve looked into cybersecurity tools recently, you’ve probably seen terms like antivirus (AV), Malwarebytes, EDR, and XDR.

They all “protect your systems”… but they’re not the same thing.

Here’s a simple way to understand the differences—and how they fit together.

Antivirus (AV): The Basics

Antivirus is the traditional security tool most people are familiar with.

It focuses on:

detecting known malware
blocking viruses and basic threats
scanning files and downloads

Examples:

Microsoft Defender Antivirus (built into Windows)
Bitdefender
Norton
McAfee

Think of antivirus as your baseline protection.

Malwarebytes: Enhanced Malware Cleanup

Tools like Malwarebytes go a step beyond traditional antivirus.

They focus on:

removing stubborn infections
catching potentially unwanted programs (PUPs)
cleaning up systems that AV might miss

Examples:

Malwarebytes (business and consumer versions)
HitmanPro (similar category)

Many businesses use these as a secondary layer or cleanup tool when something slips through.

EDR (Endpoint Detection and Response): Visibility + Response

EDR tools are designed for modern threats.

Instead of just blocking known malware, they:

monitor behavior on systems
detect suspicious activity (not just known signatures)
provide visibility into what’s happening on endpoints
allow response actions (isolate a device, stop processes, etc.)

Examples:

Microsoft Defender for Endpoint
CrowdStrike Falcon
SentinelOne
Sophos Intercept X

Important:

EDR solutions almost always include antivirus capabilities.

That means:

you don’t typically run a separate AV alongside EDR
EDR replaces traditional antivirus while adding visibility and response

Think of EDR as:

Antivirus + behavioral detection + response capabilities

XDR (Extended Detection and Response): The Bigger Picture

XDR builds on EDR by expanding visibility beyond just endpoints.

It typically includes:

endpoint protection (like EDR, including antivirus)
network activity
email security signals
cloud/application logs

Examples:

Microsoft Defender XDR
Palo Alto Cortex XDR
Trend Micro Vision One

Important:

XDR includes EDR, which already includes antivirus.

So the stack becomes:

AV → included in EDR
EDR → included in XDR

Think of XDR as:

“What’s happening across my entire environment—not just one machine?”

So Which One Do You Need?

Most small and mid-sized businesses fall into one of these:

Basic setup → Antivirus only
Slightly better → AV + Malwarebytes
Modern security → EDR (replaces AV)
More mature → XDR (adds full visibility across systems)

The key point:

You don’t stack all of these—you choose the right level.

The Real Takeaway

Security tools don’t replace strategy.

It’s very common to see businesses with:

overlapping tools
gaps in visibility
no clear understanding of what’s actually protecting them

That’s where risk builds up.

Need Help Sorting It Out?

If you’re not sure whether your current setup actually protects your business—or if you’re paying for overlapping tools—it’s worth taking a closer look.

What Does Cyber Insurance Actually Cover?

Mon, 01 Dec 2025 00:00:00 +0000

Cyber insurance is becoming more common for small and mid-sized businesses.

But most business owners don’t really understand:

what it covers
what it doesn’t
and what it requires from them

That can become a problem when you actually need to use it.

What Cyber Insurance Typically Covers

Most cyber insurance policies are designed to help after a security incident.

That can include:

Incident response (forensics, investigation)
Legal costs
Notification requirements (if customer data is involved)
Business interruption (lost revenue during downtime)
Ransomware payments (in some cases)

In short:

Cyber insurance helps reduce the financial impact of an incident.

What It Usually Does NOT Cover

This is where things get misunderstood.

Cyber insurance typically does NOT cover:

Poor security practices
Known vulnerabilities that were not fixed
Misconfigured systems
Lack of basic controls (like MFA)

If your environment is clearly insecure, the insurer may:

deny the claim
reduce the payout
or challenge coverage

Why Claims Get Denied

This is the part most businesses don’t realize.

When you apply for cyber insurance, you are usually asked questions like:

Do you use multi-factor authentication (MFA)?
Are systems regularly patched?
Do you have endpoint protection?
Do you have backups?

If those answers are inaccurate—or not maintained over time—you may have a problem later.

The policy assumes your answers are true and remain true.

What Insurance Companies Expect

Most insurers now expect a baseline level of security, including:

MFA on email and remote access
Endpoint protection (EDR or similar)
Regular patching
Secure backups (protected from ransomware)
Email security controls

This is not “advanced security”—it’s becoming the minimum.

The Biggest Misconception

Cyber insurance is not a security solution.

It does not:

prevent attacks
detect threats
or respond in real time

It only helps after something goes wrong.

Insurance transfers risk—it does not reduce it.

Where Businesses Get Into Trouble

A common situation looks like this:

The business buys cyber insurance
Assumes they are “covered”
Does not verify their actual security posture
Has an incident
Then discovers gaps during the claim process

That’s when things get complicated.

The Real Takeaway

Cyber insurance is important.

But it only works well when:

your environment matches what you reported
your security controls are actually in place
and you understand what’s covered

Without that, you may be paying for something that doesn’t fully protect you.

Need a Second Look?

If you’re not sure whether your current security controls meet insurance expectations—or if your policy aligns with your actual environment—it’s worth taking a closer look.

Common Cybersecurity Threats Small Businesses Face

Sat, 01 Nov 2025 00:00:00 +0000

When people think about cybersecurity threats, they often picture large companies being targeted by sophisticated attackers.

In reality, small and mid-sized businesses are often easier targets.

Not because they’re more valuable—but because they’re easier to break into.

Here are some of the most common threats SMBs face today.

1. Phishing Emails

Phishing is still the most common way attackers get in.

These emails are designed to:

trick users into clicking a link
steal login credentials
install malware

They often look like:

Microsoft 365 login alerts
invoices from vendors
messages from executives

It only takes one click.

2. Business Email Compromise (BEC)

This is where an attacker gains access to an email account—usually through phishing.

From there, they:

impersonate employees or executives
request wire transfers
change payment instructions

These attacks are highly effective because:

they look legitimate
they happen inside trusted conversations

3. Ransomware

Ransomware encrypts your data and demands payment to restore it.

It often starts with:

a phishing email
a compromised account
or an unpatched system

The real impact isn’t just the ransom—it’s:

downtime
lost productivity
potential data loss

4. Weak Passwords and No MFA

Many breaches happen because of:

reused passwords
simple passwords
no multi-factor authentication (MFA)

If an attacker gets valid credentials, they often don’t need to “hack” anything else.

They just log in.

5. Unpatched Systems

Software vulnerabilities are discovered all the time.

If systems aren’t updated:

attackers can exploit known weaknesses
access systems remotely
move deeper into the network

Patching is one of the simplest—and most overlooked—security controls.

6. Poor Backup Practices

Backups are often assumed to be “working”… until they’re needed.

Common issues include:

backups not running
backups not tested
backups accessible to ransomware

Without reliable backups, recovery becomes much harder.

7. Misconfigured Cloud Services

Tools like Microsoft 365, Google Workspace, and file-sharing platforms are powerful—but easy to misconfigure.

Common risks:

overly broad access permissions
public file sharing
lack of monitoring

Cloud doesn’t mean secure by default.

The Real Risk

Most successful attacks don’t rely on advanced techniques.

They rely on:

gaps in basic controls
lack of visibility
and assumptions that “someone is handling it”

The Takeaway

You don’t need to defend against everything.

But you do need to:

understand where your risks are
know what protections are in place
and make sure the basics are covered

Small improvements over time can significantly reduce your risk.

Not sure where to start?

Not Sure Where You Stand?

If you’re not sure how your business would hold up against these types of threats, it’s worth taking a closer look.

How to Spot a Phishing Email

Wed, 01 Oct 2025 00:00:00 +0000

Phishing emails are one of the most common ways attackers get into a business.

They don’t rely on hacking systems—they rely on tricking people.

The good news is most phishing emails have warning signs.

You just need to know what to look for.

What Is a Phishing Email?

A phishing email is designed to:

trick you into clicking a link
get you to enter your password
or convince you to take an action (like sending money)

They often pretend to be:

Microsoft or Google login alerts
invoices or payment requests
messages from coworkers or executives

Common Signs of a Phishing Email

1. Urgency or Pressure

Phishing emails often try to rush you.

Examples:

“Your account will be locked in 1 hour”
“Immediate action required”
“Payment overdue”

Attackers want you to act before you think.

2. Unexpected Requests

If something feels out of place, it probably is.

Examples:

a vendor suddenly changing payment instructions
a coworker asking for gift cards
a login alert you weren’t expecting

3. Suspicious Links

Always be cautious with links.

Before clicking:

hover over the link (on a computer)
check where it actually goes

Red flags:

misspelled domains (micros0ft.com)
strange URLs
shortened links

4. Requests for Credentials

Legitimate companies:

do NOT ask for passwords via email
do NOT send login forms in attachments

If an email asks you to log in: go directly to the website instead of clicking the link

5. Slightly “Off” Email Addresses

The display name may look correct—but the email address isn’t.

Examples:

microsoft-support@randomdomain.com
ceo@company.co instead of company.com

Always check the actual sender address.

6. Poor Grammar or Formatting

Not always—but often:

spelling mistakes
awkward phrasing
inconsistent formatting

Many phishing emails are generated quickly or translated.

7. Attachments You Weren’t Expecting

Be cautious with:

PDFs
Word documents
ZIP files

Especially if:

you didn’t ask for them
they come from an unknown sender

What To Do If You’re Not Sure

If something feels off:

Don’t click anything
Don’t reply
Verify another way (call the person, go to the website directly)

When in doubt, slow down.

Why This Matters

Most security tools help—but they don’t catch everything.

Phishing attacks are designed to:

look legitimate
blend into normal business activity

That’s why user awareness is still critical.

The Real Takeaway

You don’t need to be a security expert.

You just need to:

pause before clicking
question unusual requests
and verify when something doesn’t feel right

That alone stops a large percentage of attacks.

Not sure where to start?

Need Help Reducing Risk?

If you’re not sure how well your business is protected against phishing—or whether your current tools are actually effective—it’s worth taking a closer look.

How Attackers Bypass MFA (and How to Stop Them)

Sat, 13 Sep 2025 00:00:00 +0000

Multi-factor authentication (MFA) is one of the best protections you can put in place.

But it’s not perfect.

Attackers know this—and they’ve adapted.

Understanding how MFA gets bypassed is key to making sure it actually protects your business.

Wait… I Thought MFA Was Secure?

It is.

MFA stops a huge percentage of basic attacks.

But attackers don’t try to “break” MFA directly.

Instead, they:

trick users
steal sessions
or exploit weak configurations

Most MFA bypasses are not technical—they’re behavioral.

1. MFA Fatigue (Push Bombing)

This is one of the most common attacks today.

How it works:

An attacker gets a user’s password
They repeatedly try to log in
The user receives multiple MFA push notifications
Eventually, the user clicks “Approve” just to stop the prompts

Why it works

Users get annoyed
They assume it’s a glitch
They just want it to stop

How to prevent it

Use number matching (instead of simple approve/deny)
Train users: never approve unexpected prompts
Limit repeated login attempts
Monitor for repeated MFA requests

2. Phishing + Real-Time Credential Capture

This is more advanced—and very effective.

How it works:

User clicks a phishing link
They land on a fake login page
They enter username + password
They complete MFA

Meanwhile:

The attacker is relaying that login in real time
They capture the session and gain access

MFA worked—but the attacker logged in at the same time.

How to prevent it

Use phishing-resistant MFA (hardware keys, passkeys)
Implement strong email security
Train users to verify login pages
Use conditional access policies

3. Session Hijacking

In this case, MFA is never challenged again.

How it works:

A user logs in successfully (with MFA)
A session token is created
The attacker steals that token (via malware or browser compromise)
The attacker reuses the session

Why it works

The system thinks the user is already authenticated
MFA is not triggered again

How to prevent it

Use device compliance policies
Limit session duration
Monitor for unusual session behavior
Use endpoint detection (EDR)

4. Weak MFA Methods (SMS)

Not all MFA methods are equally secure.

SMS-based MFA can be bypassed through:

SIM swapping
social engineering with mobile carriers
interception attacks

How to prevent it

Prefer authenticator apps or hardware keys
Avoid SMS where possible
Use stronger authentication methods for admin accounts

5. Misconfigured or Partial MFA

Sometimes MFA is “enabled”… but not everywhere.

Common gaps:

Admin accounts without MFA
legacy protocols bypassing MFA
certain apps excluded from enforcement

Why it matters

Attackers look for the weakest path in.

If MFA isn’t applied consistently, they’ll find a way around it.

How to prevent it

Enforce MFA for all users
Block legacy authentication
Review conditional access policies
Regularly audit your configuration

The Real Takeaway

MFA is still one of the best defenses you have.

But:

MFA reduces risk—it doesn’t eliminate it.

To be effective, it needs to be:

configured correctly
enforced consistently
paired with other controls

Where Businesses Get Caught Off Guard

A common situation:

MFA is enabled
Everyone assumes they’re protected
No one checks how it’s configured
An attacker bypasses it anyway

That’s not a failure of MFA.

It’s a failure of understanding how it’s being used.

Need a Second Look?

If you’re not sure whether your MFA setup actually protects your business—or where gaps might exist—it’s worth taking a closer look.

What Is MFA and Why Does Your Business Need It?

Mon, 01 Sep 2025 00:00:00 +0000

Multi-factor authentication (MFA) is one of the simplest and most effective ways to protect your business.

But it’s also one of the most misunderstood.

Most people know they “should have it,” but don’t fully understand what it does—or why it matters.

What Is MFA?

MFA stands for multi-factor authentication.

It means you need more than just a password to log in.

Instead of only entering a password, you also need something else, such as:

A code from an authenticator app (TOTP)
A push notification on your phone
A text message with a verification code
A physical security key (yubikey or smartcard)
A fingerprint
A faceID scan
A retinal scan

In simple terms:

MFA = something you know (your password) + something you have (your phone or device) or something you ARE (biometric data like a fingerprint, faceID, retinal scan)

Any combination of two or more different factor types is considered MFA.

Why Passwords Alone Aren’t Enough

Passwords are often:

reused across multiple sites
easy to guess
exposed in data breaches

Once a password is compromised, an attacker can often log in without triggering any alarms.

From there, they can:

access email
reset other passwords
impersonate users
launch further attacks

How MFA Protects You

MFA adds a second layer of protection.

Even if an attacker has your password, they still need access to your second factor (usually your phone).

That makes it much harder to break in.

MFA stops a large percentage of common attacks.

Common MFA Methods

Not all MFA is the same.

Authenticator Apps (Recommended)

Apps like Microsoft Authenticator or Google Authenticator
Generate time-based codes
More secure than text messages

Push Notifications

Approve or deny a login attempt on your phone
Convenient and widely used

Be aware of “MFA fatigue” attacks, where users receive repeated push requests until they accidentally approve one.

Text Messages (SMS)

Sends a code via text
Better than nothing, but less secure than apps
Deprecated officially by NIST in 2016, this is better than single-factor authentication, but should be a last resort.

Hardware Keys

Physical devices (like a USB key)
Very secure, but less common in SMBs

Biometric Data

FaceID (face scan like on an iPhone)
Fingerprint (common in datacenters, mobile devices, etc)
Retinal scan (rare outside of high-security environments)

Where MFA Matters Most

If you do nothing else, enable MFA on:

Email (Microsoft 365 / Google Workspace)
Remote access (VPN, remote desktop)
Admin accounts
Financial systems

Email is especially critical.

If someone gets into your email, they can often access everything else.

The Biggest Mistakes with MFA

Even when MFA is enabled, there are common gaps:

Not enforcing MFA for all users
Allowing exceptions or bypasses
Using weak methods (SMS only)
Not protecting admin accounts
Using two of the same factor and calling it MFA (for example, password + security questions)

MFA only works if it’s applied consistently.

The Real Takeaway

MFA is not complicated.

It’s one of the easiest ways to reduce risk across your business.

But it has to be:

enabled everywhere it matters
configured properly
and enforced consistently

Not sure where to start?

Need Help Getting It Right?

Most businesses think they have MFA “enabled”—but haven’t validated where it actually applies.

If you’re not sure whether MFA is fully protecting your business—or where gaps might exist—it’s worth taking a closer look.

Cybersecurity vs IT Support — What’s the Difference?

Fri, 01 Aug 2025 00:00:00 +0000

Many small and mid-sized businesses rely on an IT provider to keep things running.

And for the most part, that works well.

But when it comes to cybersecurity, there’s often confusion about where IT support ends—and where security actually begins.

Understanding that difference is important.

What Is IT Support?

IT support (often provided by an MSP) focuses on keeping systems working.

That typically includes:

Setting up computers and servers
Managing networks and WiFi
Installing and maintaining software
Help desk support (fixing issues when things break)
Managing backups and updates

In simple terms:

IT support keeps your business running.

What Is Cybersecurity?

Cybersecurity is focused on protecting your business from threats.

That includes:

Identifying risks
Implementing security controls
Monitoring for suspicious activity
Responding to incidents
Planning for future threats

It’s less about fixing problems—and more about preventing them.

Cybersecurity reduces risk to your business.

Where Things Get Blurry

Most IT providers today offer some level of security.

They might:

install antivirus or EDR
set up firewalls
enable MFA
deploy email security tools

These are all important.

But tools alone are not a complete security strategy.

The Key Difference

The difference comes down to focus.

IT Support:

Reactive
Focused on uptime and usability
Fixes issues when they occur

Cybersecurity:

Proactive
Focused on risk and protection
Looks for gaps before they become problems

A Simple Example

An IT provider might:

install antivirus
make sure updates are running
fix a computer when it breaks

A cybersecurity-focused approach asks:

Is antivirus enough for this business?
Are we monitoring for threats?
What happens if something gets through?
Where are the biggest risks right now?

Why This Matters

Many businesses assume:

“We have IT support, so we’re covered.”

But in reality:

tools may be in place
systems may be running
but risks may not be fully understood

That’s where gaps start to form.

It’s Not One or the Other

This isn’t about replacing your IT provider.

In most cases:

IT support handles day-to-day operations
cybersecurity adds strategy, visibility, and risk management

They should work together.

The Real Takeaway

IT support and cybersecurity are both important—but they serve different roles.

One keeps things running.

The other helps ensure a problem doesn’t turn into a business-impacting event.

Understanding that difference is the first step toward making better decisions.

Need a Second Perspective?

If you’re not sure where your current setup falls—or whether your business has gaps between IT operations and security—it’s worth taking a closer look.