DEV Community: rnits

Copilot Didn't Leak Your Files — It Made the Ones You Overshared Easy to Find

rnits — Wed, 16 Sep 2026 10:02:27 +0000

The office manager at a 30-person accounting firm in Nashua asked Copilot a reasonable question during their rollout: "Summarize our staff compensation structure."

It did. In a tidy paragraph, with names and numbers, pulled from a spreadsheet a bookkeeper had saved to a SharePoint site back in 2021 and shared with "Everyone" so a colleague could open it once. Nobody had looked at that file in years. Nobody remembered it existed. It took Copilot about four seconds to find it and read it back.

Here is the part that matters: Copilot did nothing wrong. The office manager already had permission to open that file. She could have found it herself by browsing SharePoint — if she had known it was there, which she did not, because nobody browses SharePoint. Copilot did not break a rule, bypass a control, or leak anything. It simply answered a question using files the user was already allowed to see.

That is the whole Copilot oversharing problem in one sentence. It is not a security hole in Copilot. It is a spotlight on the permissions mess you have been quietly accumulating for a decade.

What Copilot actually does with your files

Microsoft 365 Copilot works by reading the data a user already has access to. When you ask it something, it searches across your SharePoint sites, OneDrive, Teams chats, and Exchange mailbox, finds relevant content, and uses it to build an answer. That access is scoped to the individual — Copilot cannot see anything the person asking could not already open on their own.

This is a good security design, and worth saying plainly before we criticize anything: Copilot respects existing permissions. It does not create a shared pool of company data that everyone can query. If a user has no rights to the finance site, Copilot will not surface finance files for them.

The trouble is the phrase "already has access to." In most small businesses, that set is enormous, and nobody has ever measured it.

For fifteen years, the way people shared a file in Microsoft 365 was to make it easy. A partner needed a document, so someone clicked Share and picked "Anyone" or "Everyone in the organization" because it was faster than typing an email address. A department stood up a Teams channel and dumped every file it touched into the connected SharePoint site with default-open permissions. An intern got added to a security group in 2019 and never got removed. A folder got shared to a client's personal Gmail for one project that ended two years ago.

None of that caused a problem, because finding a file required knowing it existed and where it lived. Discovery was hard, so oversharing was invisible. The access was always there — the friction of navigating to it was the only thing keeping it quiet.

Copilot removes the friction. A natural-language question against your entire tenant surfaces the one payroll file, the one board deck, the one HR investigation, that a user technically could reach but never would have found. The exposure did not increase. Its discoverability went from near-zero to instant.

Why small businesses are more exposed than enterprises here

Large companies have been fighting oversharing for years with governance tooling, records management, and staff whose job is data classification. They still get it wrong — Microsoft published an entire "oversharing blueprint" because their biggest customers kept turning on Copilot and immediately surfacing HR files. But at least someone owns the problem.

Small businesses have the same mess with none of the controls, and a few conditions that make it worse:

The tenant grew organically with no plan. Nobody designed the SharePoint structure. It accreted, one Team and one "quick share" at a time, across multiple IT providers who each did things their own way. There is no map of who can see what because there was never an architect.
"Everyone" and "Anyone" links are everywhere. The default sharing behavior in older tenants was permissive, and the people clicking Share were not thinking about a future AI reading everything. Every one of those links is a standing grant.
Guests never leave. External users — clients, contractors, the accountant's outside bookkeeper, a former vendor — get added to a site or a file and stay there indefinitely. Copilot honors those grants too, though the guest sees results through their own access, not the employee's.
Old files never die. The 2021 comp spreadsheet, the 2019 layoff plan, the merger discussion that fell through. Small businesses almost never retire old data. It sits in SharePoint at whatever permission it was born with, waiting for a question that matches it.
There is no data classification. Nothing is labeled "confidential." Copilot cannot treat sensitive files differently because nothing tells it which files are sensitive.

The result is that the average 20-to-50-person business we assess has thousands of files reachable by people who have no business reason to see them — and until Copilot arrives, everyone assumes those files are effectively private because nobody ever stumbles into them.

The failure modes we actually see

When a small business turns on Copilot without doing the prep, the same handful of things surface in the first week. These are not hypotheticals — they are what shows up.

Compensation and HR data. The single most common one. Payroll spreadsheets, offer letters, performance reviews, and disciplinary records that were shared too broadly years ago. Someone asks Copilot a payroll or headcount question and it cheerfully assembles an answer from files that HR believed were locked down.

Mergers, sales, and financials. Board decks, cap tables, buyer discussions, tax returns. A business owner's most sensitive documents, often stored in a personal OneDrive and shared to an accountant or attorney with a link that later got forwarded internally.

Client and patient data crossing internal walls. In a professional-services firm, matter files or client records shared to the wrong internal group. For a healthcare or legal practice, that is not just embarrassing — it is a potential HIPAA or confidentiality problem, because internal access controls are part of what those regulations require you to maintain.

Old projects with external guests still attached. Copilot surfaces content from a site where a former contractor's account is still a member. The employee did not know the guest was there; the guest may not even remember they still have access.

One documented Copilot bug, for completeness. In May 2026, Microsoft patched CVE-2026-26129, an information-disclosure flaw in Copilot Business Chat. It is worth knowing it existed, and it is worth keeping Copilot patched like anything else. But it is a footnote. The oversharing problem is not a bug that gets patched — it is your own permissions, and no update from Microsoft will fix those for you.

The honest part: this is not a reason to avoid Copilot

Plenty of vendors are using Copilot oversharing to sell fear, and a certain kind of MSP will happily quote you a stack of new monitoring tools to "make Copilot safe." That is the wrong frame.

Copilot is a legitimately useful tool, and the oversharing it exposes is a problem you already had. The files were overshared yesterday, before Copilot. A curious or disgruntled employee could have found them with enough browsing. A departing staffer could have already walked out with them. Copilot did not create the risk — it made it measurable, which is actually a gift, because now you can see it and fix it.

The right response is not to cancel the rollout. It is to run a cleanup first, then turn Copilot on with confidence. The cleanup is worth doing even if you never deploy Copilot, because everything it fixes is a real exposure regardless of whether an AI is the thing that finds it.

The pre-Copilot cleanup, in order of leverage

This is a few hours of focused work for a typical small tenant, not a six-month governance project. Do it in this order — each step removes the most risk for the least effort at that stage.

1. Find and kill the broad sharing links

The "Everyone," "Everyone except external users," and "Anyone with the link" grants are where the worst surprises live. The Microsoft 365 admin center and SharePoint admin center can report on sites and files shared organization-wide. Pull that list, and for each one ask a simple question: does this genuinely need to be open to the whole company? Almost none of them do. Replace broad grants with access scoped to the specific people or group that actually needs the file.

This one step removes the majority of the "Copilot found the payroll file" scenarios, because those files were almost always reachable through a broad link, not a deliberate share.

2. Review your guest and external access

List every external guest in the tenant and every externally shared site or file. For each guest, confirm there is a current reason they should still have access. The former contractor, the vendor from a finished project, the client whose engagement ended — remove them. Set an expiration policy on new external sharing links so this stops accumulating again on its own.

3. Clean up the security groups behind your SharePoint sites

Oversharing often hides one layer down, in the groups that grant site access. A "Finance" group with a former marketing hire still in it. A catch-all "All Staff" group used to grant access to a site that should have been department-only. Walk the membership of the groups that gate your most sensitive sites and remove anyone who does not belong. This is also where you catch the intern from 2019.

4. Deal with the genuinely sensitive stuff directly

Some data should never be in a broadly reachable location at all — active HR investigations, compensation planning, M&A discussions, anything under legal hold. Move it to a properly restricted site with a named, minimal access list, or apply a sensitivity label that restricts it. Do not rely on obscurity. Once Copilot is on, obscurity is gone.

5. Turn on the controls you are already paying for

Most of what you need to keep the tenant clean going forward is already in your Microsoft 365 licensing, unused. Sensitivity labels let you classify and automatically restrict confidential content. Data loss prevention policies can flag or block sensitive data patterns. Copilot itself can be told to exclude labeled content from its responses. The tooling exists; in nearly every tenant we assess, it has never been switched on. Our Microsoft 365 managed services work is frequently where these controls finally get configured, because someone has to own the setup and nobody ever had.

6. Roll Copilot out to a small group first

Do not flip it on for all 40 people at once. Enable it for a handful of trusted users, ask them to run the kinds of questions that would surface trouble — payroll, headcount, anything about a specific person or a sensitive project — and watch what comes back. If something appears that should not, you have found another overshared file to fix before it reaches the whole company. Expand once the pilot group stops finding surprises.

The governance layer that keeps it clean

The cleanup fixes today's mess. Keeping it clean is a governance question, and it is the same answer as every other AI problem: a policy and an owner, not a pile of tools.

An AI governance framework for Copilot answers the questions that determine whether the tenant stays clean six months from now. Who is allowed to share files organization-wide, and how? What gets labeled confidential, and by whom? How often does someone review external guests and broad grants? What is Copilot allowed to touch, and what is walled off from it? These are decisions, not products, and they belong in a short written policy your staff can actually follow. We build these as part of our AI governance service — the deliverable is a workable policy and a clear owner, not a binder designed to impress an auditor.

The deployment side matters too. Turning Copilot on properly means configuring the sensitivity labels and exclusions, setting up the DLP rules, running the pilot, and training staff on what Copilot can and cannot see — so the office manager in Nashua understands that "Copilot can read it" means "I already could read it," and knows to report anything that looks like it should not be there. That technical rollout is what our AI enterprise deployment service handles, and it is the difference between a Copilot launch that surfaces your HR files and one that does not.

Five questions to ask whoever manages your Microsoft 365

If you outsource IT and you are considering Copilot — or worse, if someone already turned it on — these questions will tell you where you stand. Ask them by email so you have the answers in writing.

Before we enable Copilot, will you run an oversharing report on our tenant? A provider who has never heard of this is not ready to deploy Copilot for you.
How many files and sites in our tenant are shared with "Everyone" or "Anyone with the link"? If the answer is "we'd have to check," that number has never been managed.
Who are all the external guests in our tenant, and why does each one still have access? A stale guest list is a standing exposure with or without Copilot.
Are sensitivity labels and DLP configured, and will Copilot respect them? These are included in most business licensing. "Not turned on" is the common — and fixable — answer.
What is the rollout plan — everyone at once, or a monitored pilot first? "Everyone at once" is how the HR files get found.

If the answers are vague, that is not a reason to panic. It is a reason to do the cleanup before the launch rather than after.

The short version

Copilot oversharing is not a flaw in Copilot. It is your own permissions, built up over years of clicking Share to make life easier, suddenly made searchable by a tool that is very good at finding things. The files were exposed the whole time. Copilot is just the first thing to go looking.

That reframing should be reassuring, not alarming. A problem you can see is a problem you can fix, and the fix is a few hours of permissions cleanup plus a policy to keep it clean — not a canceled rollout and not six new line items on your IT bill. Do the cleanup, turn Copilot on to a pilot group, expand when the surprises stop. That is the entire playbook.

If you want an honest read on what your tenant would surface the moment Copilot goes live — how many broad shares, how many stale guests, what is sitting in SharePoint at the wrong permission — that is included in our free cyber security audit. You keep the findings whether or not you ever hire us, and if your setup is already clean, we will tell you that too. Serving small businesses across New Hampshire and Massachusetts, we would rather you turn Copilot on the right way than learn what it can see the hard way. Or just get in touch and ask.

Related services from RNITS

Written by The RNITS Company. For more information, visit www.rnits.com.

'Your AI Scribe Is Recording. Did Anyone Ask the Patient?'

rnits — Tue, 11 Aug 2026 12:08:03 +0000

Most small practices did not decide to adopt AI. It showed up.

The EHR vendor pushed an update, and now there is an ambient AI scribe in the visit screen with a microphone button. Microsoft turned on Copilot inside a license the practice already paid for. The billing service added an AI claim-review step and mentioned it in a release note nobody read. Somewhere in there, a front-desk employee started using ChatGPT to rewrite letters, because it was faster.

Nobody bought an AI strategy. Each of those tools is now a HIPAA question. Nine months later the practice is running four AI systems that touch patient information, and if a patient asked which ones had heard their medical history, no one in the building could answer.

That is the actual compliance problem, and it is not primarily a HIPAA problem. HIPAA is the part everyone worries about. The part that has generated actual lawsuits this year is state recording law, and in our service area it works differently on either side of the border.

The rule nobody localized

Ambient AI scribes are genuinely good technology. A clinician who used to spend two hours a night finishing notes gets that time back. We are not going to tell you not to use one. But understand what the tool does mechanically: it records the audio of a conversation between two people, sends it somewhere to be processed, and produces text.

HIPAA governs what happens to the protected health information in that recording. It has almost nothing to say about whether you were allowed to make the recording in the first place. That question belongs to state wiretap law, and it carries criminal penalties that HIPAA does not.

Here is where the generic advice you will find online falls down. Most articles about AI scribes lump Massachusetts and New Hampshire together as "all-party consent states" and move on. That is wrong about one of them, and the difference matters operationally.

Massachusetts prohibits secret recording, not unconsented recording

The Massachusetts wiretap statute, M.G.L. c. 272, § 99, defines an unlawful interception as the act of using a device "to secretly hear, secretly record, or aid another to secretly hear or secretly record the contents of any wire or oral communication."

The operative word is secretly. In Commonwealth v. Jackson, 370 Mass. 502 (1976), the Supreme Judicial Court held that a party's actual knowledge that the recording is happening is enough to defeat the secrecy element. Express permission is not the legal test in Massachusetts. Notice is.

The penalties are not trivial. Unlawful interception carries up to five years in state prison, or up to two and a half years in a house of correction, or a fine up to $10,000, and the statute also supports civil suits by the person recorded.

New Hampshire actually does require consent

Cross into Nashua and the standard changes. Under RSA 570-A:2, it is unlawful to record an in-person or telephone conversation without the consent of all parties. Not notice. Consent.

The penalty splits based on whether the recorder was part of the conversation. A participant who records without everyone's consent commits a misdemeanor, punishable by up to a year and a $2,000 fine. Someone who was not a party and intercepts the conversation commits a felony, facing up to seven years and a $4,000 fine.

So New Hampshire is the stricter of the two, which is the opposite of what most practices assume, because Massachusetts has the louder reputation.

The practical answer is to build one workflow to the stricter standard. If your practice has offices in Lowell and Nashua, or clinicians who cover both, you do not want two consent procedures. Announce the recording, get an affirmative verbal acknowledgment from the patient, and document that you got it. That satisfies New Hampshire's consent requirement and clears Massachusetts' secrecy bar with room to spare.

One caveat, stated flatly: this is a summary of statutes and one case, not legal advice about your practice. Before you deploy a scribe, have your counsel look at your specific consent language. It is a short conversation and a cheap one.

The lawsuit that made this concrete

If this felt theoretical until now, it stopped being theoretical in April.

On April 8, 2026, patients filed a class action in the U.S. District Court for the Northern District of California against Sutter Health and MemorialCare over their use of Abridge's ambient AI scribe. The core allegation is that clinical conversations were recorded, transmitted to outside systems for processing, and turned into documentation without meaningful patient consent. The claims include the California Invasion of Privacy Act, the Confidentiality of Medical Information Act, state unfair competition law, common-law invasion of privacy, and the federal Wiretap Act. Plaintiffs are seeking a nationwide class covering two years.

Two details are worth sitting with.

First, Abridge is not a defendant. The health systems are. The vendor sold a tool; the provider chose to point it at patients. When this goes wrong, it goes wrong for the covered entity, and a reassuring sentence in a vendor's marketing does not transfer the liability.

Second, notice which body of law is doing the work. These are privacy and wiretap claims brought by patients, not a HIPAA enforcement action brought by the government. HIPAA has no private right of action. State recording and privacy statutes frequently do. A practice can be entirely defensible under HIPAA and still be the defendant in this kind of case.

Why "we have a BAA" does not reach this

The reflex answer, when any of this comes up, is that the vendor signed a Business Associate Agreement.

A BAA is necessary and it is not sufficient. It is a contract about how a business associate handles PHI. It does not grant you permission to record a person, and it does not create patient consent. The part that surprises people most: it usually does not cover every feature of the product it is attached to. Coverage tends to be scoped to specific service tiers and specific surfaces, with the integration and connector features carved out by name.

We wrote that up in detail already, including which AI vendor tiers can get a BAA at all and which features sit outside the covered surface even when one is signed. If you have not worked through your own tools at that level, start there. It determines everything below.

So what does compliance actually look like

Six things. None of them requires new software. All of them are configuration, writing, and one uncomfortable inventory.

1. A risk analysis that names your AI systems

This is the boring one that generates the fines.

The Security Rule has required an accurate, thorough risk analysis since it took effect, at 45 CFR § 164.308(a)(1)(ii)(A). Incomplete or missing risk analysis remains the single most frequently cited deficiency in OCR investigations. In 2025 OCR closed 21 settlements and civil monetary penalties, its second-highest annual total on record, collecting just over $8.3 million.

Nearly every risk analysis we read at a small practice was written before ambient AI existed and has not been touched since. It inventories the server, the workstations, the EHR, and the backup. It does not mention the scribe, Copilot, the AI feature in the billing portal, or the browser extension somebody installed.

An AI system that touches PHI is in scope. If it is not in the document, the document is not accurate, and "we did a risk analysis in 2023" is not a defense that survives contact with an investigator.

2. Minimum necessary, applied to the prompt

Here is the requirement almost nobody applies to AI, and it applies even when the BAA is perfect.

Under 45 CFR § 164.502(b), you disclose the minimum PHI necessary to accomplish the purpose. A signed BAA does not suspend that rule. So when a staff member pastes an entire twelve-page chart into an AI tool to get one lab value interpreted, that is a minimum-necessary problem regardless of what contract sits behind the tool.

This is a training issue with a concrete rule attached: ask the narrow question with the narrow data. It is also, usefully, the same habit that produces better output.

3. Audit controls that can answer "what went in"

45 CFR § 164.312(b) requires mechanisms that record and examine activity in systems containing PHI.

The test is simple and most practices fail it: if a patient asks what AI tools processed their information and what those tools received, can you produce an answer? For the scribe, that means knowing which encounters were recorded, where the audio went, how long it is retained, and whether it was used for anything besides your note. For general-purpose assistants, logging varies enormously by vendor and tier, and for some tools the honest answer is that the log does not contain the content at all.

Find out now, in writing, per tool. Discovering the gap during a patient complaint is the expensive version.

4. A consent moment that actually happens

A policy that says patients are informed is not the control. The control is the sentence a clinician says out loud at the start of the visit, every time.

Make it short enough to be said naturally, and make it ask for an answer rather than announce a fact:

"I use an AI assistant that listens and drafts my notes so I can focus on you instead of the keyboard. It records our conversation. Is that all right with you?"

Then three operational requirements behind it. Someone records the answer in the chart. Declining is genuinely available and costs the patient nothing. And staff know what to do when a patient says no, which means the workflow has a functioning manual path, not a shrug and a recording anyway. A signed general notice at the front desk does not substitute for this, and a patient who never heard the microphone mentioned is exactly the plaintiff in the April complaint.

5. The vendor chain past the first vendor

Your scribe vendor is a business associate. The cloud it runs on is a subcontractor. The speech model it calls might be a fourth party.

Under 45 CFR §§ 164.308(b) and 164.502(e), those obligations flow down, and you are entitled to know the chain. Three questions get you most of the way: Who are your subprocessors for audio and text? Is our data used to train or improve any model, and if so, is that opt-out or opt-in? What is the retention period for the raw audio, and can we set it to zero?

Ask in email. Keep the reply. A vendor that cannot answer plainly has told you something.

6. A written breach-determination path

This is the one that saves a practice in a bad week.

PHI lands somewhere it should not. Pasted into a consumer AI tool, say, or captured by a scribe for a patient who declined. The question is whether that is a reportable breach. HIPAA does not treat every impermissible disclosure as one. Under 45 CFR § 164.402 you run a four-factor risk assessment: the nature and extent of the PHI, who received or used it, whether it was actually acquired or viewed, and how well the risk has been mitigated. If you cannot demonstrate a low probability of compromise, it is a breach and notification obligations start.

Write down who runs that analysis, what evidence they gather, and where the determination is filed, before you need it. Doing this for the first time under a deadline is how practices either over-report or, worse, quietly decide it was nothing.

The 2026 mandate that is not actually law

You are going to get sold on this one, so it is worth being direct.

Vendors and consultants are marketing hard on the "new 2026 HIPAA Security Rule requirements": mandatory asset inventories, network mapping, the end of "addressable" controls. The Notice of Proposed Rulemaking is real. It published January 6, 2025, and the comment period closed that March.

It is not law. In the Fall 2026 Unified Agenda, HHS moved those amendments to its Long-Term Actions list, with anticipated final action in July 2027. That is a delay of more than a year from the previously floated timeline, and proposed rules change materially between proposal and final.

Two honest conclusions from that, and they point in opposite directions.

Do not buy anything today on the premise that a 2026 federal deadline is coming, because it is not. And do the asset inventory anyway, not because the NPRM might require it, but because you already need it for the risk analysis you are already obligated to have, and because you cannot answer a single question in this article without knowing which AI systems are running in your practice.

Anyone selling you urgency on a rule that is 11 months from a proposed final action is telling you how they sell. That is the pattern our whole HIPAA compliance work is built to push back on.

What penalties look like now

The numbers moved this year, so if you are working from an older figure, update it.

Effective January 28, 2026, HHS applied its annual inflation adjustment. The four tiers now run: $145 to $73,011 per violation where the practice did not know and could not reasonably have known; $1,461 to $73,011 for reasonable cause; $14,602 to $73,011 for willful neglect corrected within 30 days; and $73,011 to $2,190,294 for willful neglect left uncorrected. The annual cap per violation category is $2,190,294.

The important structural detail is that tier depends on knowledge and correction, not on the size of the incident. A practice that finds a problem, documents it, and fixes it is in a different tier than one that was told and did nothing. Documentation is not paperwork here. It is the evidence that determines which row you land in.

What to do this month

In the order we would tackle it:

Inventory what is actually running. Not a survey. Go look. Check the EHR's feature settings for ambient documentation, the Microsoft 365 admin center for Copilot license assignments, the credit card statement for AI subscriptions, and browser extensions on the front-desk machines.
For each one, answer three questions in writing. Does it touch PHI? Is there an executed BAA that covers the tier and features you use? Does it record audio?
Fix the consent moment first if anything records. It is the fastest change and the one with criminal exposure attached.
Add the AI systems to your risk analysis. If the document predates them, it is out of date by definition.
Send the subprocessor and retention questions to every AI vendor touching PHI. Keep the answers.
Write the breach-determination page. One page, named roles, four factors.
Train once, specifically. Twenty minutes on minimum necessary in prompts and what to do when a patient declines recording. Generic security awareness training does not cover either.

None of that is a project. It is a couple of afternoons, and every item is cheaper before you need it than during.

Where we come in

The hard part of this work is not technical. It is that it sits between IT, clinical workflow, and law, and at a fifteen-person practice it lands on the office manager, who already has a full job.

That is the gap our virtual CISO service fills. A person who reads the vendor appendix, checks whether the control operates the way the policy claims, and tells you straight when the honest answer is "not yet." When AI governance needs to become actual written policy your staff will follow, that is AI governance work, and it is usually one page shorter than you expect. Neither one requires a platform.

We are also not going to tell you to rip out the scribe. Clinician burnout is a real operational risk, and ambient documentation is one of the few tools that measurably helps. The goal is to run it in a way that survives a patient question, an OCR inquiry, and a plaintiff's lawyer, which mostly means announcing it, scoping it, logging it, and writing down what you decided.

RNITS is an IT and cybersecurity company in Tyngsboro, Massachusetts, working with small medical, dental, and behavioral health practices across New Hampshire and Massachusetts. Onsite within about 150 miles, remote nationally.

If AI has already arrived in your practice and nobody has mapped it, get in touch and we will go through the actual systems, tiers, and consent language with you.

The Rnits Company. The un-MSP. (978) 226-8931.

Related services from RNITS

Written by The RNITS Company. For more information, visit www.rnits.com.

'Your Biggest Client Wants to Know What AI You Use'

rnits — Fri, 07 Aug 2026 14:40:21 +0000

A client of ours got the annual vendor security questionnaire from their largest customer last month. Same customer, same packet, third year in a row. This time it was four pages longer, and the new pages were about AI.

Not "do you use AI, yes or no." Which models. Trained on whose data. Which of your subprocessors can see ours. What happens when the output is wrong and somebody acts on it. Who reviewed it before it reached us.

The owner's first instinct was to answer "we don't use AI." That would have been false, and he knew it while he was thinking it. His office manager had been drafting proposals in ChatGPT since March, and his bookkeeper was using Copilot inside Excel because it showed up in a license they already paid for. His second instinct was "yes, we use AI responsibly," which is worse than the false answer, because vague answers generate a follow-up call from someone in procurement who does this all day.

There is a real answer available. It takes four specific things being true, plus understanding one thing about AI vendor contracts that almost nobody gets right.

What the AI section actually asks

If your customer is large enough to have a procurement department, the questionnaire they send you is probably not homegrown. The most common one in circulation is the Shared Assessments SIG. The 2026 edition added coverage across the whole AI lifecycle: how data gets collected, how models get trained, how systems get deployed, how bias gets monitored. SIG Lite runs 128 questions. SIG Core runs 627.

Nobody sends a 15-person firm the 627-question version. But the AI questions that make it into the trimmed-down versions tend to cluster around the same five subjects:

Model provenance. Which AI systems do you use, from which vendors, on which service tier.
Training-data rights. Can the vendor train on what you put in? Have you turned that off? Can you prove it?
Hallucination controls. When the model is confidently wrong, what stops that from reaching the customer as fact?
AI subprocessor transparency. Your AI vendor is now a subprocessor of your customer's data. Is it on the list you already gave them?
Framework alignment. Increasingly they ask whether you map to ISO 42001 or the NIST AI Risk Management Framework.

The framework question is the one worth being honest about. If a 20-person company answers "yes, we are aligned to ISO 42001," the next question is "show us." You are better off writing "we have not adopted a formal AI management standard; here are the controls we do operate," and then listing them. Reviewers are not scoring you against a Fortune 500. They are checking whether anyone at your company has thought about this at all. A short, specific, verifiable answer beats an impressive one you can't back up.

The part everyone gets wrong: "we have a BAA"

This is the section to read twice. It is the most common wrong answer we see, and it comes from people acting in good faith.

A medical practice handling protected health information knows the drill: any vendor touching PHI needs a Business Associate Agreement. So the reasoning goes, we bought the enterprise AI plan, the enterprise plan comes with a BAA, therefore PHI in that tool is covered.

It is not that simple, and Anthropic's own published privacy documentation is unusually clear about why. Take it as the example because they spell it out in writing, and the pattern holds across the industry.

Which tiers can get a BAA at all. Anthropic will sign a HIPAA BAA, but only for Claude Enterprise (which is sales-assisted, not self-serve) and the first-party Claude API. Free, Pro, and Max have no BAA option. None. If your practice manager is on a $20 Pro subscription, no contract exists that makes that compliant, regardless of what the privacy page says about training.

Even on the eligible tier, it is not automatic. For Claude Enterprise, the organization's Primary Owner has to go into organization settings, open "Data and privacy," activate HIPAA compliance, and accept the BAA. A standard Enterprise plan where nobody clicked that is not covered. We have watched a business assume they were covered for a year on the strength of the invoice.

And here is the part that changes the whole answer. Once HIPAA mode is on, coverage applies to some surfaces and not others. Covered: Chat, Projects, Artifacts, Voice, Web Search, Research, Skills. Explicitly excluded from BAA coverage: Batch API, Files API, Skills API, Code Execution, Computer Use, Web Fetch, Cowork, Claude for Office (the Excel, PowerPoint, and Docs integrations), Claude Design, Workbench, Claude Console, and, in Anthropic's own words, "features involving third-party data flows (MCPs/Connectors, Enterprise Search, Claude in Chrome)."

Read that exclusion list again and notice what it is. It is the connector surface. The integrations. The parts that make the tool genuinely useful to a small business instead of a fancy text box. The moment you wire the assistant into your file store, your CRM, your ticketing system, or your browser, you have left the covered surface.

So "we use Claude Enterprise and we have a BAA" is not an answer to the questionnaire. Which surfaces you have enabled is the answer. A practice using Chat and Projects with HIPAA mode activated is in a defensible position. The same practice with a connector pointed at the folder holding scanned intake forms is not, and the contract they are relying on says so in plain language.

OpenAI's shape is the same, with different labels. BAAs are available on the API for zero-data-retention-eligible endpoints and on the sales-managed ChatGPT Enterprise and Edu plans. Not on the self-serve ChatGPT Business plan. Across the frontier vendors the pattern is consistent: nothing on free or self-serve tiers, BAAs available on managed enterprise tiers, and feature-level exclusions layered on top of the ones that qualify.

The practical takeaway is unglamorous. Privacy features listed on a pricing page are marketing. A BAA is a signed contract with an appendix telling you which buttons you are allowed to press, and somebody at your company should have read that appendix. If nobody has, that is a two-hour job. Our HIPAA compliance work starts there, because it determines everything downstream.

The four things you need in place before you answer

None of this requires buying anything new. All four of these are configuration and writing.

1. Scope what the connectors can reach

A connector is not a feature you turn on. It is a set of permissions you grant, and the default grant is almost always broader than the job requires.

When somebody connects an AI assistant to SharePoint so it can summarize project notes, the usual result is an assistant that can read every file that person can read. For a bookkeeper or an office manager, that is often the entire business: payroll, HR files, client contracts, the scanned insurance paperwork. Nothing malicious is happening. The assistant is answering questions using everything within reach, and "everything within reach" was never deliberately chosen.

Scoping means three decisions, made once per connector and written down:

Which specific sites, folders, or mailboxes this connector can see, chosen by inclusion rather than exclusion.
Whether it can write, or only read. Read-only is the right default and covers most real uses.
Who is allowed to create a new connector. In a small business this should be one named person, and it should not be whoever is most excited about AI.

The last one matters more than it sounds. Connectors are self-service by design. A user with the right subscription can wire an AI tool into a company data source in about ninety seconds, without an admin ever seeing it. That is the same problem as employees quietly adopting AI tools nobody approved, except the blast radius is your file server rather than a single chat window.

2. Put a gate in front of anything you cannot undo

Reading is recoverable. Sending is not.

The useful distinction is not "AI good, AI bad." It is which actions can be reversed. An assistant that drafts an email into a folder for review has done something you can walk back. An assistant that sends it has not. Same for posting to a client portal, updating a record, issuing a credit, or moving money.

So draw the line at irreversibility and put a human on the far side of it:

Anything leaving the company gets reviewed by a person who is accountable for it. Not skimmed. Read.
Anything that writes to a system of record gets reviewed the same way.
The review is a named role, not "somebody should check." Questionnaires ask who, and "the team" is not a who.

This is also the honest answer to the hallucination-controls question, and it is a better answer than most enterprises give. You are not claiming the model never invents things. You are describing where a wrong output would get caught before it did damage. That is a control a reviewer can actually evaluate.

3. Write down the client-data line

One page. Plain sentences. What client information may go into which AI tool, and what may not.

Two rules make it work. First, the line has to be specific enough to apply without judgment calls. "Use good discretion with sensitive data" is not a rule, it is a wish. "Client names, account numbers, medical information, and anything from the Contracts folder do not go into any AI tool other than Copilot in our own tenant" is a rule, and an employee at 4:45 on a Friday can follow it.

Second, it has to name tools, not categories. Employees do not think in categories. They think "I have ChatGPT open." If the policy says "approved AI tools," everyone will assume the one they are already using is approved.

Then tell people. A rule nobody was trained on exists only in the questionnaire response, and reviewers ask how you communicate it. Twenty minutes at a staff meeting and a copy in the handbook is enough for a small company. We build the practical version of this into AI governance work, and it is usually shorter than the email announcing it.

This puts you further ahead than it feels like it should. A 2026 Founder Reports survey found 59% of workers at companies with fewer than ten employees say their employer has no clear AI policy at all. One page separates you from most of the competitors bidding on the same work.

4. Have an audit trail, and know exactly what it does not contain

Most people either assume they have no audit trail or assume they have a complete one. Both are wrong, and Microsoft's documentation is specific enough to quote.

If you run Microsoft 365 with auditing turned on, Copilot interactions are logged automatically under Audit (Standard). No extra configuration, no extra license. That part is free and already running in most tenants.

What the log contains is the interesting part. The audit record's Messages property holds a message ID and an isPrompt boolean flag. It does not contain the text of the prompt or the response. If you need the actual words, you run a Purview eDiscovery search against the user's mailbox, where prompts and responses are stored as messages. Two different tools, two different access paths, and the one people assume covers it does not.

The genuinely valuable field is AccessedResources. For every interaction it lists each file, document, or email Copilot read to build its answer, along with SensitivityLabelId, the action taken (read, create, modify), and whether a policy blocked it. That means you can answer the question a client actually cares about: did this AI tool touch information we labeled sensitive? The records also carry JailbreakDetected on prompts and XPIADetected for cross-prompt injection attempts on accessed resources.

Now the catch, and you want to know this before you promise anything in writing. Audit logs for non-Microsoft AI applications are not included in an enterprise subscription. They exist, under the AIAppInteraction record type and the AIApp workload, and they retain for 180 days. But they have to be explicitly enabled, they are pay-as-you-go, and they are billed per audit record ingested. So the Microsoft half of your AI audit trail is free and already on, and the everything-else half has a meter attached to it.

That is a budget conversation, not a blocker. Retention is 180 days on Audit (Standard) and 365 days by default on Audit (Premium), configurable up to ten years. Most small businesses land in a sensible place: leave the free Microsoft logging on, then decide deliberately whether the third-party logging is worth the ingestion cost given how much you actually use those tools. A documented "we accepted this gap and here is why" is a legitimate questionnaire answer. An undocumented gap is not.

SOC 2 does not cover your AI unless someone put it there

This one catches people who thought they were ahead of the game.

SOC 2's Trust Services Criteria contain no AI-specific control by default. An AI control has to be deliberately added to the description of the system. If you have a SOC 2 report and you assume AI use is inside it, check, because otherwise your auditor tested access controls and change management and never looked at the assistant your staff pastes client documents into.

Clients assume the opposite. They see SOC 2 in your response, file the AI section as answered, and move on. If a control was never in scope, saying so is better than a client discovering it during an incident. Adding AI controls to the next examination is a scoping conversation with your auditor, not a rebuild. Raise it before a client raises it for you.

If you handle CUI, this section is a stop sign

Defense contractors and their suppliers have a harder constraint, and vendor marketing muddies it badly enough that it needs stating flatly.

Under DFARS 252.204-7012, any cloud service that processes, stores, or transmits Controlled Unclassified Information has to hold FedRAMP Moderate authorization at minimum. No major commercial AI service's standard consumer or business tier meets that bar. ChatGPT holds a FedRAMP 20x Low accreditation, which is real but is not sufficient for CUI.

The practical consequence: putting CUI into commercial ChatGPT, Claude, or standard commercial Copilot moves that CUI outside your assessment boundary. It is not a finding you argue about with an assessor. It is a data spill.

The compliant paths are narrower and more expensive. A government cloud, meaning Azure Government or GCC High with the corresponding Copilot offering, or a private deployment on infrastructure inside your own boundary. If you are pursuing CMMC and someone in your shop has been running drawings or statements of work through a commercial AI tool, that is the first thing to stop this week, before any policy gets written.

What to do this week

In the order we would tackle it:

Find out what is in use. Do not send a survey, go look. Check which AI subscriptions appear on the credit card statement, and check the Microsoft 365 admin center for which users have Copilot licenses assigned.
Check the tier and the contract. For each tool, what plan is it on, does that plan support a BAA if you need one, and did anyone actually execute it. Write the answer down next to the tool name.
List the connectors. Every connection between an AI tool and a company data source. Then narrow the scope of each one to what the job needs, and turn off the ones nobody can justify.
Draw the irreversibility line. Decide which AI-assisted actions require a human before they take effect, and name the human.
Write the one page. Which tools, which data, who to ask when it is unclear.
Confirm auditing is on in Microsoft 365, and make a deliberate decision about third-party AI logging rather than discovering the meter later.

That list is not exciting and it is not long. The reason it is worth doing before the questionnaire arrives is that every item takes ten minutes when you are calm and a week when a client is waiting.

Where we come in

Answering a security questionnaire honestly is a strange job. It sits between IT, legal, and sales, and in a small business it lands on whoever has the least time. The answers have to be true, defensible if challenged, and consistent with what you said last year and what is on your insurance application.

That is the work our virtual CISO service exists for. Not a dashboard. A person who reads the appendix, checks whether the control actually operates the way the answer claims, and tells you plainly when the honest answer is "not yet, and here is our timeline." Clients respect that answer far more often than people expect. What they do not respect is discovering that a confident answer was wrong.

RNITS is an IT and cybersecurity company in Tyngsboro, Massachusetts, working with small businesses across New Hampshire and Massachusetts. Onsite within about 150 miles, remote nationally. We are not going to sell you an AI governance platform to solve a problem that four configuration changes and one page of writing will solve.

If a questionnaire is sitting on your desk right now, or you would rather sort this out before one shows up, get in touch and we will go through your actual tools and tiers with you.

The Rnits Company. The un-MSP. (978) 226-8931.

Related services from RNITS

Written by The RNITS Company. For more information, visit www.rnits.com.

The One Workflow We'd Automate First in Your Industry

rnits — Sat, 01 Aug 2026 17:15:53 +0000

Last time we went through the five places automation pays in almost any business — proposals, repetitive forms, email, intake, and the marketing upkeep that quietly stopped happening. All five apply whether you pour concrete or file motions.

The specifics do not. Which form, which system, which regulator is watching, and which mistake costs you a client versus a license — those are entirely different, and they decide where you should start.

So this is the promised follow-up: six industries we work in across New Hampshire and Massachusetts, what the paperwork actually is in each one, what the credible data says about it, and the single workflow we would build first if you handed us the keys.

One warning about that last part. In every one of these, the first workflow is not the famous one. It is rarely the task that generates the most complaining, and it is almost never the one a vendor demoed to you. The first workflow is the one that is high-volume, low-judgment, and cheap to check — because that is the one that earns enough trust to make the second one possible.

A note on the numbers below. Some come from real surveys with published methodology. Some come from companies selling the software that fixes the problem they measured, which does not make them false but does make them convenient. We have flagged which is which, because you should weigh them differently.

General contractors and the trades

The paperwork is prequalification packets, insurance certificates, bid packages, RFIs, submittals, change orders, and lien waivers. On public work in Massachusetts, add the prequalification and filed sub-bid paperwork that shows up before you have earned a dollar.

RFIs are the famous number here. The Navigant Construction Forum's study put the average cost to review and respond to a single RFI at roughly $1,080, with a median of about 9.7 days from creation to closure. That study is over a decade old and its project sample skews large — 800 RFIs on a job is not your world if you run a twenty-person shop. Do not import the headline. Do take the shape of it seriously: an RFI is expensive because it stalls work while it sits, not because writing it is hard.

Which is exactly why RFIs are the wrong place to start. The delay is usually the architect's or the owner's, not yours, and automating your half of a conversation you do not control buys you very little.

What we would build first: bid package and prequalification assembly.

Watch what happens when a bid invitation lands. Someone pulls the last similar proposal. Someone hunts for the current certificate of insurance, the bonding letter, the safety record, the list of comparable projects, the W-9, and the licenses — all of which exist, all of which are current, and none of which are in one place. Someone rewrites the company background paragraph again. Then somebody reads the instructions to confirm every required attachment is actually attached, which is the step that gets skipped at 6pm on a due date.

None of that is estimating. Estimating is scoping the work and pricing it, and that stays with your estimator. The assembly around it is mechanical, it is identical across every bid, and it is the reason your best estimator spends evenings formatting instead of takeoffs.

Build a workflow that keeps your qualification documents current in one place, assembles the standard packet, and checks the submitted package against the invitation's requirement list. The payoff is not hours saved. It is that you bid more jobs, and you stop losing one a year to a missing attachment.

Medical and dental practices

The paperwork is patient intake, insurance eligibility, prior authorization, referrals, and claim denials. This is the industry where the administrative burden is not merely expensive — it delays care, and the people doing it know that.

The data here is unusually good, because the AMA measures it every year. Its 2025 physician survey, fielded to 1,000 practicing physicians, found practices complete an average of 40 prior authorization requests per physician per week and spend about 13 hours of physician and staff time on them. Two in five practices employ someone whose entire job is prior authorization. Ninety-four percent of physicians said it contributes to burnout, and more than one in four reported that the process had led to a serious adverse event for one of their patients.

CAQH, the industry association that indexes administrative transactions, puts a manual prior authorization at roughly 24 minutes of provider staff time by phone or fax, about 16 minutes through a payer portal, and around $3.41 per transaction against about a nickel when it runs fully electronically. Treat CAQH's cost figures as directionally right rather than precise — they lean on self-reported data from the people being measured.

Here is where we will disappoint you. We would not start with prior authorization.

Not because it is not the biggest number. It is. But prior auth runs through payer portals that fight automation on purpose, the rules change per plan, the stakes are clinical, and a workflow that gets it subtly wrong produces a denied claim and a delayed patient. That is the opposite of a cheap-to-check task. It is a fine second or third project, once the practice has seen the approach work.

What we would build first: eligibility and benefit verification before the visit, plus a prior authorization status board.

Verification is high-volume, rule-based, and instantly checkable — the answer is either right or it is not, and you find out before anyone is in a chair. Getting it done ahead of the appointment is also what prevents the downstream denial, which means you are attacking the prior-auth problem from the end where mistakes are cheap.

The status board is the unglamorous half and the one your staff will thank you for. Most practices cannot answer "where does this authorization stand" without someone opening four portals. A workflow that tracks every outstanding request, its age, and who touched it last does not submit anything — it just makes the queue visible. That alone stops the ones that fall through.

Everything in this category is PHI, which changes the engineering. You need a business associate agreement with whatever platform you use, the consumer tiers of these tools are not eligible, and access has to be scoped so a workflow can read what it needs and nothing else. That is the same discipline that lives in our HIPAA compliance work, and it is not optional here.

Law firms

The paperwork is intake, conflict checks, engagement letters, discovery, document assembly, and time entry.

Clio's Legal Trends research puts the average utilization rate at about 38% — roughly 3.0 billable hours captured in an eight-hour day. Apply an 88% realization rate and about 2.6 of those hours actually get invoiced. Clio sells practice management software, so read the framing with that in mind, but the underlying finding has been stable for years across sources: most of a lawyer's day is not billable, and most of the non-billable part is administrative rather than business development.

The temptation is to point AI at drafting. Resist it for now. Drafting is where the judgment is, where the malpractice exposure is, and where a confident wrong answer looks exactly like a right one.

What we would build first: intake capture and first response.

A prospective client calls, fills out a web form, or emails an address three people half-monitor. The response time on that first contact is the single biggest predictor of whether they retain you, and it is almost entirely a routing problem. Nothing about it requires legal judgment — it requires that the message reach a human quickly, with the relevant facts already pulled together.

Build the workflow that captures every inbound matter from every channel into one queue, classifies the practice area, runs the preliminary conflict search against your existing client list, and drafts the acknowledgment for a person to send. Note the word preliminary. The conflict check is surfaced for a human to clear, never cleared automatically. That is the line, and it does not move.

The second thing worth building is contemporaneous time capture, because the gap between 3.0 hours worked and 2.6 hours invoiced is partly reconstruction at the end of the week.

Confidentiality changes the rules here the same way PHI does in a practice. Privileged material does not go into a personal AI account, and the tenant it does live in needs to be configured deliberately — which is the Microsoft 365 management side of the work rather than an afterthought.

Accounting and bookkeeping firms

The paperwork is client onboarding, engagement letters, the document chase, and the reconciliation of whatever the client sent against what you actually asked for.

This is the industry where the public numbers are worst, and we would rather say so than dress it up. Almost every statistic about "hours spent chasing client documents" traces back to a company selling a document portal, and the figures are suspiciously round. Thomson Reuters' 2025 State of Tax Professionals report is the more credible read, and it is less quotable — efficiency and growth top the strategic agenda, about 37% of tax teams are automating compliance processes, and talent shortages are the binding constraint. Nobody has published a trustworthy number for how many hours busy season loses to unanswered document requests, so we will not invent one. Every firm we have asked describes it as one of the top two problems and none of them measure it, which is itself the finding.

What we would build first: the document request cycle.

One list per client of what you need, generated from what that client's engagement actually requires rather than a static checklist. Automatic reminders on a schedule, so nobody on your staff has to decide whether it is rude to follow up a third time. A running status anyone in the firm can see without asking. And an intake step that checks what arrived against what was requested, so the missing 1099 gets flagged the day it did not show up instead of three weeks later when a preparer opens the file.

The reason this is first, rather than the more glamorous return-preparation automation, is that it compounds. It applies to every client, it runs the whole season, it requires no judgment, and every mistake it makes is visible immediately. It is also the workflow that most directly buys back the thing you cannot hire your way out of — capacity in March.

Take the baseline before you build it. Count how many request rounds a typical client takes today. Without that number you will spend next April arguing about whether it helped.

Manufacturers and machine shops

The paperwork is RFQs, purchase orders, order acknowledgments, routers and travelers, material certifications, and — for anyone in the defense supply chain — the compliance documentation that decides whether you stay on the approved list.

Fictiv's 2025 State of Manufacturing report puts the average complex RFQ at about 11.5 hours of work, with roughly 18% of that time spent on anything you would call value-adding. The rest is looking for data, waiting on approvals, and reconciling systems that do not talk. Fictiv is a manufacturing marketplace, so that report is not disinterested. It also matches what we see on shop floors closely enough that we will cite it.

On the demand side, buyer surveys consistently find most procurement people expect a quote inside 24 hours and very few will wait past three days, while typical shop turnaround is one to three days. Those surveys are run by quoting-software vendors, so discount them — but every shop owner we know has lost a job to a faster competitor and can name it.

What we would build first: RFQ triage.

Triage rather than quote generation, because most shops quote too many jobs and the estimator's time is the scarcest resource in the building.

The workflow reads inbound RFQs — from email, from portals, from the PDFs and BOMs that arrive as attachments — extracts the part, quantity, material, tolerance, and required date, and scores each one against what you actually want to run: is this in your capability envelope, is the quantity in your sweet spot, is this a customer who buys or a customer who collects quotes? Then it routes the worthwhile ones to the estimator with the data already pulled, and flags the rest for a fast, polite decline.

That last part is worth more than it sounds. Declining in an hour preserves the relationship. Silence for four days does not.

Quote assembly is the natural second build, once triage has proven the extraction is accurate. And if you supply defense primes, the certification and compliance paperwork is its own project — the requirements are specific enough that it belongs in a CMMC compliance conversation rather than a general automation one.

Property managers

The paperwork is work orders, vendor coordination, tenant communication, lease renewals, owner reporting, and the applications and screening that come with turnover.

Buildium and NARPM's 2026 industry report found 38% of rental owners name maintenance as their top source of stress — ahead of vacancies, residents, and rent collection — and it ranks as the second-highest operational challenge for property managers. Hemlane, looking at more than 193,000 maintenance requests in its own system, reports a median resolution of about 13 days. Read that as one company's book of business rather than an industry census.

The more useful finding, and the one that shapes what to build, is that tenant satisfaction tracks communication quality more closely than it tracks actual repair speed. A resident who knows a part is on order Thursday is calmer than one whose faster repair happened in silence.

What we would build first: work order intake and automatic status updates.

Requests arrive by text, by portal, by phone, and by a resident stopping someone in the parking lot. Consolidating them into one queue, classifying by urgency and trade, and routing to the right vendor is the ordinary half of the build.

The part that changes your week is the status updates. Every stage change — received, assigned, scheduled, parts ordered, completed — generates a message to the resident automatically. That is not a technology achievement. It is the difference between a resident who waits and a resident who calls you three times, then complains to the owner, then posts a review. Most of the phone calls your office fields are not new information requests. They are people who have no idea what is happening.

Vendor dispatch decisions and anything involving money stay with a person. The workflow assembles and informs. It does not spend.

If your industry is not on this list

The pattern generalizes. Look for the task where somebody retypes information that already exists in a system you already own, where the rules are consistent, where a mistake is visible immediately, and where the person doing it would be relieved to stop. That is your first workflow, whatever business you are in.

Then check it against the same three questions from the last post before anyone configures anything. What is the baseline — how many of these a week, how long does one take now? What happens to the weird one, and does the workflow know when it is out of its depth? Where is the approval gate, and is it on every step where money leaves or a client hears from you?

Notice what is absent from all six recommendations above. Not one of them is a workflow that talks to your customers unsupervised, and not one of them makes a decision that costs money. Every one assembles, sorts, tracks, or checks, and then a person acts. We pick them for that reason. Those are the projects that survive contact with a real office, and the ambitious ones account for most of the failures.

Where we come in

We are an IT and cybersecurity company in Tyngsboro, Massachusetts, working with small businesses across New Hampshire and Massachusetts — onsite within about 150 miles, remote nationally. We are not an AI consultancy and there is no five-figure discovery phase attached to any of this.

What we do is the missing part: spend a few hours with the people who actually do the work, map the process including the exceptions everybody handles by instinct, and identify the one or two workflows that pay for themselves inside a quarter. Then design them, connect them to the systems you already run, put approval gates where money and client data are involved, and train the people who have to live with them. The design and build side of that is our AI automation practice.

We stay stubborn about permissions. When a workflow connects to QuickBooks, a practice management system, or your Microsoft 365 tenant, it inherits whatever access you hand it, and the fast path is always to hand over everything. We do the slower version — narrowest access that still finishes the job — which matters more in a regulated industry than anywhere else, because the audit question is not whether the automation worked but who could see what.

If you want a straight conversation about which part of your week is worth automating, get in touch. We will walk your real processes with you and tell you where the hours are hiding, including the cases where the honest answer is to fix the process or drop it rather than automate it.

The Rnits Company. The un-MSP. (978) 226-8931.

Related services from RNITS

Written by The RNITS Company. For more information, visit www.rnits.com.

You Filled Out That Same Form for the Ninth Time This Week

rnits — Fri, 31 Jul 2026 12:54:58 +0000

Somebody in your office is retyping the same fifteen fields into a portal they have used four hundred times. Somebody else is rebuilding a quote from a price list and a phone conversation, the way they rebuilt one on Tuesday and will rebuild another on Friday. A third person has 180 unread emails and no working method for deciding which twelve of them matter today.

That is a normal week at a normal small business. None of it is a technology problem.

Every one of those tasks is a process nobody ever wrote down. It lives in one person's head, it gets done by hand at whatever pace that person can manage, and when that person is out for a week the work simply stops. You did not decide to run the business that way. It accumulated. Somebody needed to get invoices out, so they started getting invoices out, and eleven years later that is still how invoices go out.

The tools to fix a good portion of this got cheap and capable in 2026. We went through the three that matter — Claude for Small Business, Microsoft 365 with Copilot, and ChatGPT Work — in our last post on AI automation, and the short version is that they all run $20 to $32 a seat and they all now connect to the systems a small business actually uses. QuickBooks. Microsoft 365. Google Workspace. HubSpot. Docusign.

So the licenses are not the obstacle, and they have not been for a while. The obstacle is that a license does nothing until somebody looks at how your work actually moves through your office and designs the workflow. That is a design job, it takes a few hours of someone's attention, and at most small businesses it is nobody's job. Which is precisely why most small businesses are not doing it.

We spend our days inside other people's companies across New Hampshire and Massachusetts, and after enough of them you stop seeing industries and start seeing the same handful of tasks eating everybody's week. Here is where the hours actually are.

The five places automation pays in almost any business

A task is worth automating when it is high-volume, follows rules more than judgment, produces output somebody can check at a glance, and is currently being done by hand by a person who would be relieved to stop. That last criterion matters more than people expect. Automating something nobody minds doing buys you very little. Automating the job everyone avoids until Thursday afternoon changes how the office feels.

Five categories come up over and over.

Proposals, quotes, and bids

If you win work by responding to requests, this is usually the most expensive unautomated process in the building — and the one where slowness costs you deals rather than just hours.

Watch how a proposal actually gets built. Someone opens the last similar one, saves a copy, and starts overwriting. They hunt for the current pricing, which is in a spreadsheet somebody updated in March. They rewrite the company background paragraph that has been written four hundred times. They chase a colleague for the piece only that colleague knows. Then they format it, and formatting takes longer than anyone admits.

Vendor benchmarks in the proposal-software market put a typical formal RFP response around 25 hours of work. Treat that number with the skepticism any vendor statistic deserves, but ask your own estimator how long last month's big one took and you will land somewhere uncomfortable.

Almost none of that is the part that wins the job. The part that wins the job is scoping the work correctly and pricing it right, and that is your judgment. Assembly, boilerplate, pulling current numbers, checking that you answered every question asked, and formatting are all mechanical. A workflow with access to your pricing, your past proposals, and your standard language produces a complete first draft, and your estimator spends their time on the thinking instead of the document. Firms that make this change generally do not lay anyone off. They bid on more work.

The same form, over and over

This is the one that made you click on the headline, because everybody has it.

Insurance verifications. Vendor onboarding packets. Permit applications. Prequalification questionnaires. Client intake sheets. Payroll change forms. Certificate requests. Whatever your industry's paperwork is, some of your staff spend hours a week moving the same information from one place into another place, by hand, with no value added anywhere in the transfer.

Invoice processing is the version that has been measured most carefully, and it is a fair proxy for the rest. APQC's benchmarking puts the median cost of processing a single invoice around $21, with top-quartile organizations near $10. Both numbers are mostly labor. Multiply by your monthly volume and you have the annual cost of one form.

The reason this work persists is not that it is difficult. It is that it is invisible. It never appears on a budget line, no one ever proposed it at a meeting, and the person doing it has stopped mentioning it because it is simply the job. It only becomes visible when they quit and you discover nobody else knows the process.

Document-and-form work is where automation is least glamorous and most reliable. The information is already in a system somewhere. The rules are consistent. A person still reviews and submits. What disappears is the typing.

Email that nobody is really on top of

Email is the single largest unmanaged cost in most small offices, and nobody counts it because it does not look like work getting neglected. It looks like work getting done.

The commonly cited research figures put email at roughly a quarter of the knowledge-work week — somewhere near 10 or 11 hours — with the heaviest users well past that. Whatever the true number is at your company, it is larger than anyone would guess, and the damage is not only the hours. It is that important messages sit unread among the newsletters, the vendor pitches, and the fourteen replies to a thread that resolved yesterday.

Three separate jobs hide inside "dealing with email," and they automate differently.

Sorting is pure pattern recognition, and it is what the tools are genuinely good at. Real inquiry, existing client, vendor solicitation, invoice, internal noise. A workflow that reads the inbox and separates those five is not exotic, and it means the four messages that matter this morning are visibly the four that matter.

Routing is the part that saves relationships. Inquiries that arrive at info@ and sit for three days are lost revenue, and the person who sent one has already called somebody else. Getting each message to the right person, in the CRM, with a summary attached, is a solved problem now.

Drafting is the part people reach for first and should reach for third. It works well for the replies you have written a hundred times — status updates, standard answers, appointment confirmations, document requests. It works poorly for anything requiring tone, judgment, or bad news. Keep those human and keep a person's hand on send.

Requests coming in five different doors

Look at how work actually arrives at your company. A form on the website. A general inbox nobody owns. Three personal inboxes. Phone calls that turn into sticky notes. A fax line, if you are in healthcare. Text messages to whoever a client happens to have a cell number for.

Because there is no single door, there is no single queue, which means there is no way to know what is outstanding without asking four people. Things fall through — not often enough to cause a crisis, just often enough that everyone has a story.

Consolidating intake is one of the highest-value workflows we build, and it is mostly unremarkable engineering: every channel lands in one queue, each request gets classified and given a priority, the right person gets it, and a status is attached that anyone can look up. The AI part is the classification and summarizing. The valuable part is that for the first time you can see all of the work in one list.

Support and service requests are the same story with different labels. Sort by type and urgency, answer the genuinely repetitive ones from your own documentation, escalate anything unusual to a person immediately. Note the order there. Automated answers are worth having only after routing works, because a fast wrong answer is worse than a slow right one.

Marketing, SEO, and the website nobody has time for

This one belongs on the list because it is the process most likely to have simply stopped.

Your website has a blog with two posts from 2024. Your Google Business Profile has not been touched in eight months. Reviews go unanswered. Service pages describe an offering you have since changed. Nobody meant for that to happen. At a twenty-person company marketing is not in anyone's title, so it gets done in whatever gap opens up, and no gap ever opens up.

Be careful about which parts of this you hand over. Generic AI-generated content published at volume is worth roughly nothing in 2026 and can actively hurt you — search engines got good at recognizing it, and so did your customers. We would not automate your writing.

What automates cleanly is the surrounding upkeep, which is what actually fell behind:

Drafting review responses for a human to approve and post, so a two-star review does not sit unanswered for a month
Keeping business listings and profile information consistent across directories, which is unglamorous and directly affects whether you appear in local search
Watching rankings and traffic and telling you when something moves, instead of you remembering to check
Turning work you already did — a completed project, a solved problem, a common customer question — into a first draft that a human with actual expertise then finishes
Refreshing pages that have drifted out of date

That last one is worth its own sentence. Search engines pay attention to whether a page has genuinely changed, not whether a timestamp moved. We learned that the hard way on our own site this month, which is a story for another post. Automate the part that finds the stale pages. Have a person make the real change.

Why almost nobody is doing this

Between those five categories, a typical twenty-person company is losing somewhere between fifteen and forty person-hours a week. The tools cost a couple hundred dollars a month. The arithmetic is not close. So why is this not already done everywhere?

Four honest reasons.

Nobody owns it. You are running the business. Your office manager is the person doing the tasks you would be automating, so asking them to design their own replacement workflow is both unfair and impractical — they are underwater, which is the whole problem. Nobody's calendar has two clear days in it for process design. So it gets raised in January, agreed to be a good idea, and raised again in April by the same person in the same words.

Nothing is written down. You cannot automate a process you cannot describe. Ask three people how a new client gets set up and you will get three different answers, all partly right, each containing a step the others forgot. That is not dysfunction, it is how undocumented work always looks. But it means the first real task is not configuring software. It is writing down what actually happens, including the exceptions everybody handles by instinct.

Somebody already tried and it went badly. This is more common than the vendors let on. Gartner expects more than 40% of agentic AI projects to be cancelled outright by the end of 2027, and the failures cluster around a few causes: the tool could not reach the data it needed, nobody defined what should happen to the odd cases, no baseline existed so nobody could prove it helped, and one visible mistake destroyed everyone's trust in it. Notice that none of those are the model being insufficiently smart. They are design failures, and they are avoidable.

The license got bought and never wired in. We see this constantly. A business pays for Copilot seats for a year, people use it as a slightly better search box, and the renewal conversation is about whether AI was worth it. The seats were never the thing. The wiring was the thing, and nobody did the wiring.

Map the process before you automate it

Here is the part that separates the businesses getting real returns from the ones with an expensive subscription and a bad taste in their mouth. Before anything gets configured, somebody sits with the person who does the work and follows it end to end.

What that takes is an hour and a legal pad, not a workshop with a name. Show me how a quote gets built. Where does the pricing come from? Who checks it? What happens when the customer asks for something not on the price list? What did you do the last time one came in wrong?

That last question is the important one, because exceptions are where automation dies. Everybody can describe the normal path. The value is in the odd cases — the client who insists on being invoiced a particular way, the county that wants a different form, the project type where your usual markup does not apply. Those live entirely in the heads of the people who handle them, and an automation that does not account for them will produce confident, plausible, wrong output until somebody notices.

The mapping also routinely finds that a step should be eliminated rather than automated. We have watched a business prepare to automate a weekly report and discover, mid-conversation, that the two people it was built for stopped reading it in 2023. That is a five-minute win nobody had noticed in two years. Automating it instead would have been an efficient way to keep doing something pointless.

Then, before anything goes live, three things get settled:

A baseline. How many of these do you do a week, and how long does one take now? Without that number you will never be able to tell whether this worked, and you will end up arguing about it based on impressions.

Exception handling. What happens to the weird one? The answer should almost always be "a person looks at it," and the workflow needs to know how to recognize when it is out of its depth.

An approval gate anywhere it matters. Money leaving, contracts going out, messages to clients, data being deleted. Preparing an invoice batch and sending an invoice batch are two different permissions, and the workflow should only ever hold the first one. All three of the major platforms ship this capability and default it on. The mistake we see is somebody turning it off in week three because the approvals felt like friction, which is roughly the same instinct as taping over a smoke detector.

Get those three right and you can start with two workflows, prove them over a month, and expand from something that works. Skip them and you get the 40% outcome.

What this looks like in your industry

Everything above applies whether you pour concrete or file motions. But the specifics — which form, which system, which regulator is watching — are entirely different, and the specifics are what determine where you should start.

A general contractor's version is takeoffs, bid packages, RFIs, and submittals. A medical practice's is patient intake, insurance verification, and prior authorization, where the paperwork is not merely annoying but actively delays care. An accounting firm's is client onboarding and document collection. A law firm's is intake and conflict checks. A manufacturer's is quotes, purchase orders, and certification paperwork. A property manager's is work orders and tenant communication.

Each one has a highest-return starting point, and it is rarely the task that feels most urgent. That is the next post: industry by industry, what the actual paperwork is, what the credible data says about it, and which single workflow we would build first if you handed us the keys.

Where we come in

We are an IT and cybersecurity company based in Tyngsboro, Massachusetts, working with small businesses across New Hampshire and Massachusetts, onsite within about 150 miles and remote nationally. We are not an AI consultancy, and there is no five-figure discovery phase attached to any of this.

The work we do is the work that is missing. Spend time with your staff, watch how a job actually moves through the office, and identify the two or three processes where automation pays for itself inside a quarter. Then design the workflow, connect it to your systems, put approval gates where money and client data are involved, and train the people who have to live with it. That last piece decides whether any of it survives. A workflow your staff do not trust gets quietly routed around by the second month, and nobody tells you until you ask why nothing changed. The design and build side of that is our AI automation work.

Permissions are the place we are stubborn. When you connect an agent to QuickBooks or your Microsoft 365 tenant, it inherits whatever access you hand over, and the fast path is always to hand over everything. We do the slower version and give each workflow the narrowest access that still lets it finish the job. A connector is also only as trustworthy as the tenant behind it, which is why tenant hygiene sits inside our Microsoft 365 managed services work instead of off to one side. And if your people have already started pasting client information into whatever free AI site came up first in a search, that is a problem you have today rather than one you might get later. Shadow AI earned its own post.

Two situations where you should not hire us for this. If you run a small crew and most of them are on job sites rather than at keyboards, there is not enough paperwork in the building to justify the engagement, and you will hear that in the first conversation rather than after a signature. And if you already employ somebody sharp who has genuine room in their week, hand them this article instead. They will do a good job of it and it will cost you nothing.

Everybody else is in the same spot. The software is cheap, the connectors for the systems you already run now exist, and the missing ingredient is a few hours of deliberate design that nobody has managed to get on the calendar.

We can get it on the calendar. If you want a straight conversation about which parts of your week are worth automating, get in touch. We will walk your real processes with you and tell you where the hours are hiding, including the cases where the right answer is to fix the process or drop it rather than automate it.

Related services from RNITS

Written by The RNITS Company. For more information, visit www.rnits.com.

Everyone Says They Use AI. Only 1 in 5 Small Businesses Really Does

rnits — Tue, 28 Jul 2026 19:54:42 +0000

You have read the headline. Sixty-three percent of small businesses now use AI. Some surveys put it at 68%, one at 71%. The number goes up every quarter and the implication is always the same: you are behind, everyone else has figured this out, get moving.

Now here is the number nobody puts in a headline. The U.S. Census Bureau, which asks businesses about actual production use rather than whether anyone has ever opened a chatbot, put it at 17 to 20% as of May 2026. JP Morgan Chase Institute, working from transaction data rather than self-reported surveys, landed at 17.7%.

Both sets of numbers are real. They are measuring different things. "Do you use AI?" catches every owner who tried ChatGPT once in March. "Is AI running in your operations?" catches the businesses that actually changed how work gets done. The first group is most of the 63%. The second group is the 17%.

That gap is the whole story, and it is good news for you. The businesses genuinely pulling ahead are not doing it because they have better AI than you can buy — the tools run $20 to $32 a seat for everybody, including them. They are ahead because somebody sat down and wired the tools into the actual work. That is a setup problem, not a technology problem, and setup problems are solvable in an afternoon.

What the 17% are actually getting

Before spending money, look at what the return actually looks like for businesses that got past the experiment stage. The 2026 survey data is consistent enough across sources to trust the shape of it:

5.6 hours saved per employee per week, on average — 7.2 hours for managers, 3.4 for individual contributors. Managers gain more because more of their week is coordination, summarizing, and drafting.
58% of small business AI users report saving 20+ hours per month, and 66% report saving between $500 and $2,000 per month.
26 to 55% productivity gains in the specific functions where AI is deployed. Note the qualifier. Nobody gets a 40% lift across the whole company. They get it in invoice processing, or lead triage, or first-draft copywriting.
78.6% of businesses using AI report reduced costs or improved efficiency — which sounds impressive until you remember this is the group that already stuck with it. Survivors report success. That is how surveys work.

Run the math on the first number for a ten-person shop. If half your staff does knowledge work and each saves four hours a week, that is 20 hours a week — half a full-time position — for roughly $250 a month in licenses. Even if the real number is half that, the arithmetic works.

The other side of it deserves saying too: the 80% who are not seeing these numbers are not lazy or stupid. They opened a chat window, asked it to write a marketing email, got something mediocre, and reasonably concluded the hype was hype. Chatting with an AI is the demo, not the product. The value shows up when the tool can reach your files, your inbox, your accounting system, and your CRM, and can finish a job without you babysitting each step.

Until 2026, doing that in a small business meant hiring a developer. That changed this year.

What changed: all three vendors came for your back office

Here is the part that should get your attention more than any single product. Between the middle of May and the end of July 2026 — about ten weeks — Anthropic, Microsoft, and OpenAI each shipped a package aimed specifically at businesses your size. Not enterprise pilots. Small business.

When three competitors independently decide the same neglected market is worth building for, the market usually was worth building for. It also means you are about to get pitched all three, probably by people who have not read past the press release.

Anthropic shipped Claude for Small Business on May 13, 2026. It runs through Claude Cowork, the agentic mode that arrived as a desktop preview in January and reached web and mobile in July, and it ships with 15 ready-to-run workflows and 15 skills. The connectors are the giveaway — Intuit QuickBooks, PayPal, HubSpot, Canva, Docusign, Google Workspace, and Microsoft 365. Nothing on that list is a developer tool. It is the back office of a typical ten-to-fifty person company. The named example workflows: planning payroll and 30-day cash forecasts, monthly close and reconciliation, sales campaigns, invoice chasing, content in Canva, contract review through Docusign, tax season prep, lead triage, and customer sentiment analysis.

One detail from Anthropic's own usage data is worth sitting with: across 1.2 million Cowork sessions, more than 90% of the work was not coding. It was business operations and content creation. A tool built for engineers got adopted by everybody else, which tells you where the unmet need actually was.

Microsoft announced Microsoft 365 Business Standard with Copilot and Business Premium with Copilot on May 28, 2026, and made them generally available July 1. The pitch is that Copilot sits inside Word, Excel, PowerPoint, Outlook, and Teams where your people already work, with a layer Microsoft calls Work IQ that gives it context on your projects and deadlines. More than 1,000 connectors, including Shopify, PayPal, Xero, and Asana. Both plans cap at 300 users.

Two things make Microsoft's version genuinely different, and neither gets enough attention. First, it routes to models from both OpenAI and Anthropic — you are not betting on one lab. Second, it honors the security controls you may already have: sensitivity labels and data loss prevention apply, so Copilot only sees what your tenant permits it to see. If you have spent money on compliance tooling in M365, that is the option that respects it.

OpenAI shipped ChatGPT Work on July 9, 2026 — an agentic mode that acts across your connected apps, files, desktop, and the web, breaks larger goals into steps, produces spreadsheets, decks, documents and dashboards from a single prompt, and asks for human approval before sensitive actions. Named integrations include Slack, Microsoft Teams, Gmail, Google Drive, Salesforce, and SharePoint. Then in late July, OpenAI followed with a small business program: virtual training, in-person AI academies, ready-made workflow templates, and partner integrations including Shopify, QuickBooks, and Slack.

Note what OpenAI led with. Not a feature — training. That is a tacit admission that the bottleneck was never the technology, and it matches what we see in the field.

Read those three paragraphs again and count how many of the named workflows are currently sitting on one overloaded person's desk at your company. That is the honest test of whether any of this is worth your attention.

Which one, honestly

We have no vendor relationship with any of the three and no reason to steer you. The decision is mostly determined by where your data already lives, not by which model benchmarks better this month.

If this is you	Start with	Why
Already on Microsoft 365 Business Standard or Premium	Microsoft 365 Copilot	Your data, permissions, and DLP rules are already there. Nothing new to connect and nothing new to secure.
Google Workspace shop, or heavy QuickBooks and Docusign use	Claude for Small Business	Prebuilt workflows for exactly those tools, and the least setup work to a first result.
Already paying for ChatGPT and your team likes it	ChatGPT Work	Adoption is the hard part and it is already solved. Do not fight a tool your people use voluntarily.
Under about 10 people, mostly non-desk staff	None yet	The return will not cover the setup effort. Revisit in six months.

Three practical notes on top of that table.

Do not run two of them in parallel to "compare." We have watched businesses try it. You end up with two half-configured tools, two sets of connector permissions to audit, double the license spend, and no clear read on either. Pick one on the logic above, give it a real 60 days on two or three workflows, then judge it.

Pricing is close enough to ignore as a factor. Microsoft 365 Business Standard with Copilot is $23.50 per user per month paid yearly, Business Premium with Copilot is $32, and there are cheaper variants without Teams at $20.30 and $28.80. A Claude Team seat is $20 per seat per month billed annually, $25 monthly. ChatGPT Business sits in the same $20-to-$25 range. Anyone telling you one of these wins on price is selling.

The switching cost is the connectors, not the subscription. Cancelling a license takes a minute. Redoing the permission scoping, workflow configuration, and staff training is the part that hurts. That is the real reason to choose deliberately up front rather than to churn.

The five things worth automating first

Most businesses pick wrong here. They start with the most visible task — usually marketing copy — because it feels like what AI is for. Marketing copy is a poor first project: quality is subjective, you will argue about the output, and you cannot measure the win.

Start where the task is repetitive, the output is checkable, and somebody is currently doing it by hand. In a 10-to-50 person business, that is usually these five.

1. Invoice chasing and receivables follow-up. Somebody runs an aging report, figures out who is 30 days late, and writes the same polite email for the eleventh time. An agent connected to QuickBooks can pull the report, draft the follow-ups with correct amounts and dates, and queue them for your approval. Nobody has to like doing it, because nobody has to do it. This is the single highest-return starting point we see, because late receivables cost real money and the task is universally hated.

2. Monthly close and reconciliation prep. Not the accounting judgment — the gathering. Matching transactions, flagging the ones that do not reconcile, pulling the supporting documents, and handing your bookkeeper a tidy exception list instead of a shoebox. Your accountant still closes the books. They just stop spending six hours assembling inputs.

3. Lead and inbox triage. Inquiries arrive through a web form, an info@ address, three personal inboxes, and sometimes a phone message somebody transcribes. Sorting them by whether they are a real prospect, a vendor pitch, or a support question is pattern-matching work — exactly what these tools are good at. Route them into the CRM with a summary attached and watch how many leads stop falling through the cracks.

4. Meeting notes into actual records. The recording exists. The transcript exists. What does not exist is the CRM note, the follow-up task, and the two-line summary the other four people needed. Closing that loop is boring, high-value, and completely automatable.

5. Quote and proposal first drafts. If you build quotes from a price list and a scope conversation, the first draft is assembly, not craft. Your estimator's judgment belongs in reviewing and adjusting, not in formatting a document from scratch for the ninth time this month.

Notice what these have in common. Each one keeps a human making the final call, while taking away the gathering, formatting, and first-pass drafting. That is the sweet spot in 2026. Anything where the AI has final say is a project for later and a different risk conversation.

What not to hand it

An honest post about AI automation has to include this part, and most do not.

Anything where being wrong is expensive and nobody checks. Payroll submission, tax filings, wire transfers, contract execution. Have the agent prepare it. A person approves it. The gap between "drafts the payroll run" and "submits the payroll run" is the entire difference between a productivity tool and an incident.

Client data going into tools you have not vetted. This is the one that bites small businesses hardest, and we wrote about it at length in the shadow AI problem. An employee pasting a client contract into a random free AI site is a data disclosure, and depending on your industry it may be a reportable one. The fix is not a ban — bans just push it underground. The fix is giving people a sanctioned tool that is actually good enough to use, then saying clearly which one it is.

Regulated decisions. If you are in healthcare, legal, or financial services, some determinations need a licensed human and a documented process. AI can prepare the file. It cannot own the judgment, and your regulator will not be charmed by the efficiency gains.

Anything you cannot audit. If you cannot answer "why did it do that" six months from now, do not put it in a workflow that touches money or customers.

The governance floor, in four items

You do not need an AI policy committee. You need four things settled before you turn agents loose on business systems, and they take about an hour with someone who knows what they are doing.

One sanctioned tool, named out loud. People use AI whether you approve it or not. The only real choice is whether they use the one you control. At roughly $20 to $32 a seat, "we cannot afford it for everyone who needs it" is rarely the true objection.
Connector scoping. When you connect QuickBooks, Google Workspace, or Microsoft 365, the agent inherits whatever permissions you grant. Grant the narrow ones. Most businesses hand over full admin because it is the default and faster, then have no idea what the tool can reach. This is the item people skip and the one we most often have to unwind later.
An approval gate on anything irreversible. Money out, contracts signed, messages to clients, data deleted. All three platforms support human-in-the-loop checkpoints natively — Cowork notifies your phone, ChatGPT Work pauses before sensitive actions, Copilot inherits your existing tenant controls. Turn them on and leave them on.
A written line on client data. Two sentences is enough: what may go into the sanctioned tool, and what may never go into any AI tool. Then tell people, once, in plain language.

That is the floor. If you handle PHI, cardholder data, or CUI, there is more to it — and it connects to the compliance work you are likely already doing for HIPAA or a client security questionnaire. But the four items above cover the majority of small businesses, and having them is the difference between AI as an asset and AI as an unlogged hole in your environment.

What this actually costs

Licensing is not the expensive part, and you have the figures above. For a fifteen-person company giving seats to the eight people who do real knowledge work, any of the three lands around $160 to $260 a month. That is a phone line, not a capital decision — and treating it like one is how businesses spend two quarters deliberating over $200.

The real cost is the setup. Connecting the tools correctly, scoping permissions so an agent cannot reach more than it should, deciding which workflows actually run, testing them against real data, and training the people who will use them. That is a handful of hours, once, and it is precisely the work that separates the 17% from the 63%.

It is also the work most owners never get to, because it is nobody's job. The owner is running the business. The office manager is doing the tasks you would be automating. There is no obvious person whose calendar has room to sit down and wire it up, so it stays on the someday list for another quarter, and the license you already bought goes unused.

Where we come in

We are an IT and cybersecurity shop in Tyngsboro, Massachusetts, and we work with small businesses across New Hampshire and Massachusetts — onsite within about 150 miles, remote nationally. We are not an AI consultancy and we are not going to sell you a transformation roadmap.

What we do is the unglamorous middle: help you pick which of the three actually fits your stack, choose the two or three workflows worth automating first, connect them with permissions scoped properly instead of wide open, put approval gates where money and client data are involved, and train your people on the thing they will actually use. That is our AI automation and AI training work, and it sits alongside the AI governance basics so you are not creating a compliance problem while solving a productivity one.

We are not a reseller for any of these three, which is the whole reason we can tell you that Microsoft's is usually the right answer for an M365 shop even though there is nothing in it for us either way. An MSP with a vendor quota will reliably discover that your business needs whatever they have a quota for.

If your Microsoft 365 tenant is where most of this will connect, that matters too — the connector is only as safe as the tenant behind it, which is part of our Microsoft 365 managed services work.

Two caveats before you call us. If you are a five-person trades business where three people never touch a computer, the return here is small and you should skip it. We will tell you that on the phone rather than after you have signed something. And if you already have a capable internal person with time to do this, buy them the afternoon and keep your money.

For everyone else: the tools are cheap, the workflows now ship pre-built, and the businesses getting 20 hours a month back are not smarter than you. They just had somebody set it up.

If you want a straight conversation about which two or three tasks in your business are worth automating first, and which ones you should leave alone, get in touch. We will look at what your people actually do all week and tell you where the hours are.

Written by The RNITS Company. For more information, visit www.rnits.com.

Ransomware With Nobody Driving: An AI Agent Just Ran the Whole Attack

rnits — Fri, 24 Jul 2026 17:50:55 +0000

Back in June we wrote a post telling small business owners not to panic about attackers using AI. The argument was simple: one person with an AI assistant could suddenly work like a whole crew, but the doors they came through were the same old doors. Unpatched servers. Reused passwords. Missing MFA.

That post needs an update, not a retraction.

On July 1, Sysdig's threat research team published an analysis of an attack they're calling JADEPUFFER, and they assess it as the first documented case of ransomware run end to end by an AI agent. Not AI-assisted. Not a human using AI to write better malware. The large language model did the reconnaissance, stole the credentials, moved across the network, escalated its own privileges, encrypted the data, and wrote the ransom note. Nobody was sitting at a keyboard making those calls.

That still isn't a reason to panic. It is a reason to go look at a specific list of things on your network, and that list is shorter and more boring than the headlines suggest.

What actually happened

The target was a company running Langflow — a tool for building AI workflows visually — on a server exposed to the internet. That server had an unpatched vulnerability, CVE-2025-3248, which allows remote code execution without authenticating at all. Not a zero-day. A publicly documented hole with a patch available since 2025.

The agent got in through that. Then it went to work.

It looked around. Basic host enumeration — who am I, what OS is this, what's the hostname, what network interfaces exist, what's running. The same commands any sysadmin would type, in roughly the same order.

It emptied the environment variables. This is the part that should make anyone running AI tooling sit up. Langflow's environment held API keys for OpenAI, Anthropic, DeepSeek, and Gemini, plus cloud credentials for AWS, GCP, Azure, Alibaba, Tencent, and Huawei, plus database credentials. All sitting in plaintext env vars because that's how these tools get configured in a hurry. The agent scooped up every one.

It dumped the database behind Langflow — the Postgres instance holding the application's own data.

It scanned the internal network and tried default passwords. It found a MinIO object store still using minioadmin:minioadmin. Inside that, a credentials.json file with more service access keys.

It set up persistence. A crontab entry firing every 30 minutes, beaconing out to a command-and-control address so it could keep coming back.

It got into the production MySQL database as root, then attacked a Nacos configuration server using a 2021 auth-bypass vulnerability (CVE-2021-29441) and forged its own JWT tokens using the default signing key — a key that is published in Nacos documentation and that a great many deployments never change.

It gave itself a permanent admin account by writing a bcrypt password hash directly into the Nacos database.

Then it destroyed things. It encrypted 1,342 Nacos configuration items, dropped the original tables along with their history, created a table literally named README_RANSOM holding a Bitcoin address and a ProtonMail contact, and dropped several other databases on its way out.

The destruction happened days after the initial reconnaissance. This wasn't a smash-and-grab. The agent sat in the environment, learned it, and came back.

The 31 seconds that matter

This is the part that changed how we think about automated attacks.

Partway through, the agent's attempt to plant that backdoor admin account failed. It had written a blank password hash, so the login didn't work. Any automated script would have simply failed there and stopped, or kept retrying the same broken thing forever. That's what automation does.

Instead the agent diagnosed the problem, figured out the hashing call had failed because of how it was invoking the library, rewrote the payload to import bcrypt directly instead of shelling out to a subprocess, and got a working backdoor.

Time from failed login to successful fix: 31 seconds.

It did this twice more. When a MinIO API request returned XML instead of the JSON it expected, it rewrote its parser on the spot to handle the S3 response format. When a DROP DATABASE command failed because of foreign key constraints, it wrapped the next attempt in SET GLOBAL FOREIGN_KEY_CHECKS=0 and tried again.

That adaptive quality is what's actually new here, and the distinction is narrow enough to be worth spelling out. Automated attack tools have existed forever. Worms, exploit kits, scanners — all fast, none of them able to think their way around an unexpected error message. Every prior generation of automated attack had a failure mode you could exploit: put something slightly non-standard in its path and it broke. Sysdig also noted the agent's payloads were full of comments explaining its own reasoning — at one point labeling its targets "high-ROI databases to drop" and noting the data was already copied to a staging server. It wasn't following a script. It was reasoning, badly narrated, in real time.

An adaptive attacker doesn't break on the unexpected. It reads the error and tries something else, at machine speed, over and over, without getting bored or discouraged.

What it didn't do

Now the part the vendor emails will leave out, because it doesn't sell anything.

Look back at that attack chain and find the clever part. There isn't one.

The way in was a known vulnerability with a patch available.
The object store was using its factory default password.
The config server was trusting its documented default signing key.
The production database was reachable with root credentials.
Cloud and AI provider keys were sitting in plaintext environment variables on an internet-facing box.

An AI agent ran this attack, and every single step of it was a failure of basic hygiene. The agent didn't defeat a control. It walked through gaps where controls were absent. Take any one of those five items away and the chain breaks — patch the Langflow instance and it never gets in at all.

This is exactly the point we made in June, and it survived contact with a much scarier example: AI doesn't pick a lock you've already deadbolted. What it does is check every door on the street, at once, forever, and get through the ones that were never locked.

There's an uncomfortable consequence to that. "We're too small and boring to be targeted" was never much of a defense, and it's now worthless. Targeting used to cost an attacker time and attention, which is a real constraint on a human crew deciding who's worth the effort. An agent doesn't allocate attention. Your 12-person firm in Lowell is exactly as interesting to it as a company a hundred times your size, because it costs the same either way.

Paying wouldn't have helped

There's a nasty footnote in the Sysdig writeup that has real operational consequences.

The ransom note claimed the data was encrypted with AES-256. It wasn't — the agent used MySQL's built-in AES_ENCRYPT() function, which defaults to AES-128 in ECB mode. More importantly, the encryption key was generated on the fly from a couple of random UUIDs, printed once, and never stored or transmitted anywhere.

Nobody has that key. Not the victim, not the attacker.

The data was unrecoverable the moment it was encrypted. Paying the Bitcoin address would have accomplished exactly nothing, because there was no decryptor on the other end of that transaction and never could have been.

This is what sloppy autonomy looks like, and it changes the calculus. With a human ransomware crew there's at least a functioning criminal business model — they want a reputation for delivering decryptors, because that's what makes the next victim pay. An agent improvising its own crypto has no such incentive and no quality control. It can wreck your data while sincerely believing it's holding it hostage.

Which means your recovery plan cannot include "we'd pay if we had to." A tested restore is the entire plan now, because there may be nothing to buy back at any price.

"But we don't run Langflow"

Fair. Most small businesses in New Hampshire and Massachusetts don't have a Langflow server, and if you're picturing your office you're probably picturing laptops, a firewall, and Microsoft 365.

Two things about that.

First, you might have something like it without knowing. The last two years pushed a lot of AI experimentation into small companies, and a good chunk of it got deployed by whoever was most enthusiastic rather than by whoever manages infrastructure. Langflow, n8n, Flowise, a local Ollama instance, an automation container someone stood up to test an idea and never turned off. These tools get spun up on a spare box or a cheap VPS, exposed to the internet so it's easy to reach from home, configured with default credentials because it's "just a test," and stuffed with API keys and database connection strings so it can actually do something useful.

That's a description of the JADEPUFFER victim. It's also a description of a shadow IT problem we find fairly often once we start looking. We wrote about employees quietly using unapproved AI tools and the data governance mess that creates. This is the infrastructure version of the same problem, and it's more dangerous, because a forgotten server is a foothold rather than a leak.

If nobody in your company can name every internet-facing service you're running, you don't know whether you have one of these. That's a question worth answering this week.

Second, the pattern generalizes. Strip the specific product names out of the attack chain and what's left is: get in through something unpatched and exposed, harvest whatever credentials are lying around, use them to reach further, establish persistence, then destroy the data. That is a completely ordinary ransomware playbook. It works the same against a Langflow box, an unpatched VPN appliance, a Remote Desktop port someone opened during COVID and forgot, or a server running an operating system that went end-of-support two years ago.

Neglect is the only real prerequisite. The specific software barely matters.

What to actually do

None of this requires new products. In the order I'd tackle it:

1. Inventory what's exposed to the internet

You cannot patch a server you've forgotten you own. Get an actual list of every service reachable from outside your network — VPN appliances, remote access, web apps, file transfer tools, anything a vendor set up, anything a staff member spun up. Then decide which ones genuinely need to be public. Most don't. This is the foundation of network monitoring and management, and it's usually the fastest place to find something alarming.

2. Patch on a schedule, and mean it

The way in was a vulnerability with a patch available before the attack happened. That's the whole story. A documented patch management cadence — with actual verification that patches landed, not just a policy document saying they should — closes the door this attack came through. Prioritize internet-facing systems first. They're the ones getting scanned continuously by things that never sleep.

3. Kill every default credential

Go looking specifically for defaults: admin consoles, object storage, databases, network gear, printers, cameras, that appliance the vendor installed in 2019. minioadmin:minioadmin handed this agent the keys to a credential store. Default signing keys let it forge authentication tokens outright. This is unglamorous, free, and one of the highest-return hours you'll spend. Ongoing server management should be catching these, and if yours isn't, ask why.

4. Get credentials out of environment variables and config files

Every API key and connection string sitting in plaintext on a server is a credential an intruder inherits the moment they land. Move secrets into a managed vault, scope them down to the minimum they need, and rotate them on a schedule. Then rotate them again if a host is ever compromised — assume anything that machine could read is gone.

5. Segment, and control what can talk outward

The agent moved from a peripheral AI tool to the production database because nothing stopped it. Network segmentation means a compromised test box can't reach your critical systems. Egress controls mean it can't beacon out to a command-and-control server every 30 minutes either. Both are configuration, not purchases.

6. Make your backups actually survive this

The ransom in this case was unpayable, so backups were the only exit — and the agent dropped tables and their history, which is exactly the kind of thing that quietly defeats backups that live on the same system they're protecting. You want copies that are offline or immutable, retained long enough to cover an intruder who lurked for days before acting, and — this is the part people skip — restore-tested. An untested backup is a hypothesis. We handle this under cloud backup solutions, and the test restore is the part that matters.

7. Watch for behavior, not just files

There was no malicious executable to catch here. The activity was database queries, cron jobs, and Python one-liners — individually mundane, collectively an attack. Signature-based antivirus has nothing to match against that. What catches it is noticing that a scheduled task started making outbound connections, or that a database process is doing something it has never done before. That's what remote monitoring and management is for: someone watching behavior, at 2 a.m., when an agent that doesn't sleep decides to act.

8. Decide who's allowed to deploy AI infrastructure

The governance gap is what created the target. Somebody should have to say yes before an AI tool with database credentials goes on a public IP. Not a bureaucracy — one named person and a two-line rule. We build this into AI governance engagements, and it's the difference between running AI tools and hosting an unmonitored one.

The honest read

JADEPUFFER is a real milestone and it deserves the attention it's getting. The skill barrier for running a competent, adaptive, multi-stage intrusion just dropped close to zero. In June the story was one person doing the work of a crew. Now it's no person at all, which means the volume of credible attacks is going to keep climbing regardless of how many skilled criminals exist.

The reassuring part is that the defense list above is the same list we'd have given you in 2024. Patch what's exposed. Change the default passwords. Don't leave secrets lying in plaintext. Segment your network. Test your restores. Watch for weird behavior.

We're not going to sell you an "agentic threat defense platform." That product category is being invented right now specifically to be sold into this news cycle, and for a small business it's mostly a repackaging of controls you either already own or can turn on for free. The attack that made all these headlines was stopped by patching one server. It just happened to be a server nobody was patching.

If you can't confidently answer "what do we have exposed to the internet, is it patched, and would our backups survive somebody dropping our databases," that's the gap — and it's the same gap it's always been. It's just being probed by something a lot more persistent now.
Schedule a free audit or get in touch if you'd rather just ask a question first.

The Rnits Company. The un-MSP. (978) 226-8931.

Written by The RNITS Company. For more information, visit www.rnits.com.

The Free AI Tool Your Employee Just Installed Might Be Malware

rnits — Mon, 20 Jul 2026 16:53:20 +0000

An office manager at a construction firm outside Nashua called us in a mild panic in June. Her estimator had spent the morning trying to install "the ChatGPT desktop app" so he could stop copy-pasting into a browser tab all day. He searched for it, clicked the first result that looked official, ran the installer, and clicked through the prompts the way everyone clicks through installer prompts.

By lunch his machine was throwing certificate warnings, Outlook was asking him to sign in again, and a browser extension he did not recognize had appeared in Chrome. He had not installed ChatGPT. He had installed an infostealer that was already working through his saved passwords.

This is the fastest-growing attack pattern we are seeing against small businesses in 2026, and it works precisely because your employees are trying to be productive. They want the AI tools everyone is talking about. Attackers know that, and they have flooded the space with fakes.

The numbers are not subtle

In the first four months of 2026, Kaspersky counted more than 33,000 attacks on small and midsize businesses that were disguised as popular AI tools. That is roughly five times what they logged over the same window in 2025. The lures were not obscure. They impersonated the exact tools your team already knows by name — ChatGPT accounted for about 42 percent of the fakes, Claude around 24 percent, and DeepSeek roughly 20 percent.

The surge tracks one thing: AI adoption ran ahead of AI governance. Employees at small businesses started reaching for these tools before their employers had any policy about which ones were approved or how to install them safely. That gap — real demand, no guardrails — is exactly the environment attackers exploit. They do not have to trick anyone into wanting the software. The wanting is already there. They just have to be the search result, the ad, or the download link that gets clicked first.

How the scam actually works

There is no single technique here. It is a cluster of related tricks, all pointing the employee at a malicious file instead of the real thing.

Poisoned search results and ads. An employee searches for "ChatGPT desktop download" or "Claude app for Windows." Attackers buy search ads and build lookalike sites that rank for those exact terms. The page looks right — logo, screenshots, a big download button. The file behind the button is not the product.

Fake installers that look legitimate. The download often runs a real-looking setup wizard. Some even install a working web shortcut to the actual AI tool so nothing seems wrong, while the malware installs quietly in the background. The employee ends up with a bookmark to ChatGPT and an infostealer, and only notices the first one.

Trojanized browser extensions. "Add AI to your browser" extensions are a huge vector. The employee installs what looks like an AI helper. It asks for permission to read and change data on every website they visit — which most people approve without reading — and then it does exactly that, siphoning session tokens and form data from every page including your email and banking portals.

Cracked or "unlimited" versions. Some employees go looking for a way around the paywall. "ChatGPT Plus free," "unlimited Claude," "premium AI cracked." Every one of those searches leads somewhere dangerous. There is no free lunch here, only bait.

The payload varies. Sometimes it is an infostealer that grabs saved browser passwords, session cookies, and crypto wallets. Sometimes it is a remote-access trojan that gives the attacker a foothold to move through your network. And increasingly it is the first stage of a ransomware deployment, where the fake AI installer is simply how they got in the door.

Why this hits small businesses harder

Large companies lock down what employees can install. Software goes through an approval process, endpoints are managed, and downloading a random installer from a search result is often blocked outright. Most small businesses have none of that. The estimator in Nashua had local admin rights on his own laptop because that is how the machine was set up years ago and nobody ever changed it. He could install anything, and he did.

Three things make SMBs the softer target:

Local admin rights are everywhere. At most small businesses we assess, the majority of employees can install software on their own machines without asking anyone. That single setting turns a bad download into a full compromise.

There is no approved-tools list. When nobody has said "here is the AI tool we use and here is where you get it," every employee makes their own decision, using their own judgment, under time pressure. Some of those decisions will be wrong.

Consumer-grade endpoint protection. A lot of SMBs are still running basic antivirus that catches known-bad files by signature. Modern infostealers are repacked constantly to dodge signatures. Without behavioral detection — the kind that notices a "ChatGPT installer" reading your entire password store — the download sails right through.

None of this is the employee's fault. Someone handed them a laptop with admin rights, no policy, and no protection, then trusted them to make security-grade decisions about software they had never been taught to evaluate. The estimator did what almost anyone would do.

This is not the same as shadow AI

It is worth drawing a line here, because the two problems get confused. Shadow AI is when employees use real AI tools without approval and leak sensitive data into them — pasting client records into the genuine ChatGPT. That is a data governance and compliance problem.

What we are talking about in this post is different. This is malware wearing an AI costume. The tool is fake. The danger is not where your data goes; it is that a hostile program is now running on your network. The two problems overlap — both come from the same ungoverned rush to adopt AI — but the fixes are not identical. Shadow AI needs a usage policy. Fake AI tools need download controls, endpoint protection, and least-privilege access. A serious program addresses both.

How to shut this down

The good news is that defending against fake AI installers does not require buying a pile of new products. Most of what you need is configuration and a couple of decisions you have probably been putting off.

1. Remove local admin rights

This is the single highest-value change, and it costs nothing. When employees cannot install software without an administrator, a poisoned installer simply fails to run. Standard-user accounts for daily work, with a separate path for legitimate software requests, would have stopped the Nashua incident cold. We handle this through workstation management — it takes an afternoon to roll out and it closes the door on an entire class of attack.

Yes, it means a few more "can you install this for me" requests in the first month. That is a feature, not a bug. Every one of those requests is a chance to catch a fake before it runs.

2. Publish an approved AI tools list

Employees are going to use AI. If you do not tell them which tools are sanctioned and exactly where to get them, they will keep guessing — and some guesses will be malicious downloads. A short, plain document that says "we use these AI tools, here are the official links, do not install anything else" removes the guesswork. This is the same governance work we do under AI governance, and it pairs naturally with basic AI training so your team can spot a fake download page on their own.

Front-load the official URLs. Most of these tools are web apps that need no installation at all — the fact that your estimator thought he needed a "desktop app" is itself a sign the team was never told how the real product works.

3. Run real endpoint protection

Signature-based antivirus is not enough against malware that is repacked daily. You want endpoint detection and response — behavioral protection that flags a program acting maliciously regardless of whether it has seen that exact file before. If you run Microsoft 365 Business Premium, Defender for Business is already included in your license. Most SMBs are paying for it and have never deployed it. Turning it on and managing it through remote monitoring gives you the behavioral layer that catches an infostealer masquerading as an AI app.

4. Filter downloads at the network

DNS and web filtering blocks known malicious and lookalike domains before an employee ever reaches the fake download page. Combined with your network monitoring, it also gives you visibility into what is being downloaded and from where — so a suspicious "AI installer" from a domain registered last week gets stopped, not celebrated.

5. Keep everything patched

Some of these fake installers exploit unpatched vulnerabilities to dig in deeper once they run. A documented patch management cadence shrinks the window that malware can use to escalate. It is unglamorous and it is one of the highest-return controls you can maintain.

What to do if you think you already clicked one

If an employee downloaded something questionable, speed matters more than blame. Do this, in order:

Disconnect the machine from the network — pull the Wi-Fi or unplug the cable. This limits an infostealer's ability to exfiltrate and a trojan's ability to spread.
Reset that user's passwords from a different, clean device — starting with email, then anything with financial access. Assume saved browser passwords are already gone.
Revoke active sessions. Infostealers grab session cookies, which can bypass MFA. In Microsoft 365 or Google Workspace, sign the account out of everywhere and force re-authentication.
Do not just delete the file and move on. If it ran, deleting the installer does nothing about what it installed. The machine needs a real cleanup or, more often, a wipe and reimage.
Call your IT provider. This is exactly the kind of thing we handle. The first hour determines whether this stays a scare or becomes a breach.

The honest read

We are not going to use this to sell you a six-tool "AI security stack." That is the traditional MSP move — new threat, new line items on the invoice. The truth is less profitable and more useful: the defenses against fake AI tools are mostly things you either already own or can turn on for free. Remove admin rights. Tell people which tools to use. Deploy the endpoint protection in the license you already pay for. Filter your downloads. Patch on a schedule.

The reason this attack is exploding is not that it is technically clever. It is exploding because small businesses adopted AI faster than they governed it, and attackers noticed the gap. Close the gap and the fakes have nothing to work with.
Schedule a free audit or get in touch. No pitch, no tool stack — just a straight answer.

The Rnits Company. The un-MSP. (978) 226-8931.

Written by The RNITS Company. For more information, visit www.rnits.com.

Hotel IT Support: Meeting Franchise Brand Standards Without Overpaying

rnits — Sat, 18 Jul 2026 13:02:16 +0000

When you signed the franchise agreement for your hotel, you agreed to more than a sign on the building. You agreed to a technology standard — guest WiFi that performs to the brand's spec, a network that passes PCI, payment and property-management systems that talk to the brand's reservation platform, and security controls the flag can audit whenever it likes. Miss those and the consequences are not abstract. They range from a bad brand quality inspection to fines to, in the worst case, losing the flag entirely.

Here is the part nobody explains at the franchise sales meeting: the brand tells you what the standard is, but running to that standard is your problem as the owner or operator. And the vendors on the brand's approved list know you are on the hook, so they price accordingly. We have looked at enough hotel IT invoices across New Hampshire and Massachusetts to say it plainly — a lot of franchised properties are paying premium rates for guest WiFi, network support, and phones because they assumed the brand-approved vendor was the only option that keeps them compliant. It usually isn't.

This post walks through the three systems most franchisees ask us about — the network, guest WiFi, and phones — plus the PCI and security floor underneath all of them. The goal is simple: understand what your flag actually requires, so you can meet it without overpaying the vendor who knows you feel captive.

What your flag actually requires — and audits

Every major hotel brand publishes a technology standard, and while the details differ, the shape is the same across the national flags. As a franchisee you are contractually responsible for:

Guest internet that meets a performance spec. Brands set minimum bandwidth per room and uptime expectations, and guest WiFi shows up directly in your guest satisfaction scores. Weak WiFi is not just an amenity complaint — it moves the numbers the brand grades you on.
PCI DSS compliance. This is not optional and it is not new, but PCI DSS v4.0 became mandatory in March 2025, and the requirements got stricter. Non-compliance fines run as high as $100,000 per month, and that is before the cost of an actual breach.
Network segmentation. Guest traffic, your payment systems, your property-management system (PMS), and back-office devices are not allowed to share one flat network. The brand requires separation, and PCI requires it independently.
Approved integrations. Your PMS and point-of-sale (POS) have to connect to the brand's reservation and loyalty platforms, which means specific, correctly configured, correctly maintained integrations — not a setup someone stood up once and never touched.

None of that is unreasonable. It is the modern floor for running a hotel that takes card payments and puts strangers on your network every night. The problem is not the standard. The problem is being told the only way to meet it is the brand's premium vendor.

Guest WiFi: the amenity guests rank first

Start with the system your guests judge you on before they have unpacked. In survey after survey, roughly 92% of hotel guests name strong WiFi as a top booking priority — ahead of amenities that cost you far more to provide. A guest who can't stream in their room writes the review. A guest whose video call drops during a work trip does not come back.

So it matters that most hotel WiFi problems are diagnosed backward. When rooms complain about dead zones and slow speeds, the instinct is to blame the access points and buy new ones. But the failure usually lives one layer down — in aging switches, tired cabling, and an internet circuit that was sized for a hotel with half the devices.

The WiFi 7 upgrade that quietly changes nothing

Here is a mistake we see often enough to warn you about it directly. A property decides to modernize, approves a WiFi 7 access-point refresh based on the shiny AP line item, and deploys the new hardware on the existing switches. Then the new APs throttle themselves down to stay within the old switches' power limits (PoE+), and deliver throughput barely better than the WiFi 6 gear they replaced. The invoice was real. The improvement was not. Nobody checked whether the switches feeding the APs could actually power them at full capacity — which is exactly the kind of thing that gets caught when someone is looking at the whole network instead of one product line.

Bandwidth math that actually holds up

Brands set per-room minimums, but the useful way to size a hotel network is to do the math for real occupancy. A 30-room property at 80% occupancy needs roughly 120 to 240 Mbps of total usable bandwidth to keep guests happy, and current guidance runs about 10 to 25 Mbps per room for mid-scale properties, more for upscale. Every guest now arrives with a phone, a laptop, and often a streaming stick — three to four devices per room is normal, not heavy.

The number that matters is not what your circuit is rated for. It is what is left over for guests after your PMS, POS, cameras, and back office take their share — on a network that keeps all of that traffic properly separated. Getting guest WiFi right is really a network management and monitoring problem, which is why treating the WiFi as its own island is how properties end up with a fast circuit and slow rooms.

The network underneath: segmentation isn't a suggestion

Guest WiFi sits on top of the network your business actually runs on, and this is where brand standards and PCI stop being paperwork and start being the thing that keeps you out of a breach notification.

The rule is straightforward: guest traffic must never be able to reach the systems that handle card data. A guest on your WiFi should be able to get to the internet and nothing else — not your POS, not your PMS, not your cameras, not the back-office PCs. PCI DSS requires this separation, your brand requires it, and the attack data explains why both do.

In hospitality breaches, POS and payment systems are the targeted system in about 72% of cases, guest WiFi in 56%, and front-desk systems in 34%. When those live on the same flat network — which we still find in hotels that "have always done it this way" — a compromised guest laptop or a phished front-desk login becomes a direct path to cardholder data. The cost of getting this wrong is not theoretical: the average hospitality data breach now runs about $9.23 million once you count response, legal exposure, and brand fallout, and 44% of attacked hotels reported 12 or more hours of downtime — a front desk that can't check anyone in during peak arrival.

Segmentation done right means separate networks for guests, payment/PMS, back office, and building systems, with a properly configured firewall between them and monitoring that actually watches the boundaries. That last part matters because segmentation is not a set-and-forget project. Configurations drift, someone plugs the wrong device into the wrong jack, a firmware update resets a rule. Remote monitoring and management is what keeps the separation you paid for from quietly eroding between brand audits. And when the PCI questionnaire comes due, PCI DSS compliance support is far easier when the network was built to pass it in the first place instead of being retrofitted the month before the deadline.

Cloud phones: the front desk can't drop a call

The third system franchisees ask about is the phone, and it is the one most likely to be running on equipment older than some of the staff. Legacy on-premise PBX hardware is expensive to maintain, impossible to support remotely, and a genuine risk the day the one technician who understood it retires.

A hosted cloud phone system fixes the reliability problem and usually cuts the bill at the same time. For a hotel specifically, the features that matter are not exotic:

Calls that survive an internet hiccup. If the circuit drops, calls automatically forward to a mobile or an alternate line. A flagged property cannot send a prospective guest to a dead line during business hours — that is a booking walking to the hotel down the road.
Auto-attendant and routing. Front desk, reservations, housekeeping, and after-hours all handled by a professional greeting and menu instead of a phone ringing at an empty desk.
Softphones for a mobile staff. A manager can take the front-desk line from anywhere in the building — or from home during an overnight incident — on a laptop or phone.
Honest, flat pricing. Our cloud business phone system is $15 per user per month, everything included — unlimited US and Canada calling, softphone, call recording, and number porting. Most providers advertise $20 to 25 and land at $30 to 40 once the softphone license, recording, and regulatory fees hit the invoice. Over a full property, that gap is real money.

The phone runs on the same network as everything else, which is the recurring theme of this whole post: these are not four separate vendor relationships. They are one connected system, and they succeed or fail together.

The brand-approved vendor markup

So why do so many franchised properties overpay? Because the brand hands you a list of approved or preferred technology vendors, the assumption sets in that the list is the only compliant option, and those vendors price for a customer who believes they have no alternative.

Here is what is actually true. The brand sets the standard — bandwidth, segmentation, PCI, integrations. It does not, in most cases, require one specific local support company to hold your hand for a premium monthly fee. A competent managed IT provider can build and run your environment to the brand's published standard, document it, and hand you the evidence when the brand or a PCI assessor asks. Meeting the spec is what matters. Being locked to the priciest vendor who happens to know the spec is not the same thing.

What we do differently for hotels is the same thing we do for every client:

We show up. We are based in Tyngsboro, MA, and provide onsite support across New Hampshire and Massachusetts within 150 miles — which matters when a switch dies at a property, not a help desk in another time zone.
Pricing is published and flat. No captive-customer markup, no three-year lock-in with a termination penalty, no "call us for a quote" until a salesperson has sized up your budget.
We onboard in 24 to 48 hours, not the one to two weeks that is standard in this industry.

How RNITS runs a franchised property's IT

Put the pieces together and a hotel's IT is one managed environment, not a pile of separate subscriptions:

Network built to pass. Proper segmentation of guest, payment, PMS, and back-office traffic, with a firewall configured to brand and PCI standards and documented topology so support is not guesswork.
Guest WiFi that performs to spec. Sized to real occupancy, with the switches and cabling underneath actually able to deliver what the access points promise — and monitored so a degrading link is caught before the reviews are.
Phones that don't drop. A hosted system with failover, auto-attendant, and softphones, at honest flat pricing.
A security floor that holds up to audit. MFA enforced, endpoint protection everywhere, monitored and tested backups, and patching — the controls PCI v4.0 and your cyber insurance both now expect.
Monitoring that keeps it compliant between audits. Because the expensive failures are the ones nobody was watching for.

You get one accountable partner for the whole environment instead of a WiFi vendor, a phone vendor, a network vendor, and a security vendor pointing at each other while your front desk waits.

Frequently asked questions

Does my hotel brand require a specific IT vendor?

Almost never. The major hotel brands set technology standards — guest WiFi performance, PCI compliance, network segmentation, approved PMS/POS integrations — and hold the franchisee responsible for meeting them. They typically publish approved or preferred vendor lists, but those are options, not a mandate to use the most expensive one. Any competent managed IT provider can build and document your environment to the brand's published standard.

Is PCI compliance really mandatory for a small franchised hotel?

Yes. Any property that accepts card payments falls under PCI DSS, regardless of size, and PCI DSS v4.0 has been mandatory since March 2025. Non-compliance fines reach $100,000 per month, and that is separate from breach costs — which in hospitality average around $9.23 million. Network segmentation that keeps guest WiFi away from your payment systems is one of the core requirements, and it is also just good sense.

Why is our hotel WiFi slow even though we pay for a fast circuit?

Usually because the bottleneck is not the circuit. Most hotel WiFi problems trace to aging switches, tired cabling, or access points that were added to a network that was never sized for today's device counts — three to four devices per guest is now normal. A network review looks at the whole path from the internet handoff to the guest room, not just the access points, and sizes bandwidth to your real occupancy.

Can we switch hotel IT vendors without breaking brand compliance?

Yes, as long as the new provider builds and runs your environment to the brand's standard and can produce the documentation the brand and PCI assessors ask for. The compliance lives in how the network, payment systems, and security controls are configured — not in the name of the company supporting them. A clean migration keeps you compliant throughout the transition.

How much should a franchised hotel pay for managed IT?

It depends on room count, systems, and how much is onsite versus remote — but the honest test is whether the pricing is transparent and the scope is clear. Captive-vendor markup shows up as vague quotes, long lock-in contracts, and per-feature add-ons. Our phone system, for example, is a flat $15 per user per month all-in, and our managed IT tiers are published. If your current provider's pricing gets vaguer the more you ask, that is worth noticing.

Get a straight answer on your property's IT

If you run a franchised hotel in New Hampshire or Massachusetts and you are not sure whether you are meeting your brand's IT standards — or you suspect you are overpaying the vendor who told you that you had to — the fastest way to find out is to look at the actual environment: how your network is segmented, whether your WiFi is sized to your occupancy, what your phone system really costs, and where the PCI gaps are.
Or just start a conversation. We will walk your property's setup with you before anyone talks about a contract.

The Rnits Company. The un-MSP. (978) 226-8931.

Written by The RNITS Company. For more information, visit www.rnits.com.

MSP Pricing Models: Why Break-Fix Still Works for Some Businesses

rnits — Tue, 14 Jul 2026 22:12:19 +0000

Search "break-fix vs managed services" and read the first ten results. Every one of them was written by an MSP, and every one of them arrives at the same conclusion: break-fix is dead, reactive IT is irresponsible, and the only sane choice is a monthly managed services contract.

We are an MSP, and we are going to tell you something different: break-fix is not dead. For a specific kind of business, it is still the right answer. The reason you never read that in an MSP blog is not that it is untrue. It is that no MSP makes recurring revenue off a client who calls twice a year.

That conflict of interest sits underneath almost everything written about IT pricing, and it is worth naming before we walk through the models. MSP valuations are built on monthly recurring revenue. When an MSP sells its business, the buyer pays a multiple of contracted monthly revenue — break-fix income barely counts. So the entire industry has a structural reason to declare the reactive model dead, whether or not it is dead for you.

This post is the honest version of the comparison — including which businesses should not hire us on a monthly contract. It is the third post in our un-MSP series, following why SMBs overpay for security tools and what no lock-in, no upsell, no tool sprawl means in practice.

The four MSP pricing models, in plain English

There are more variations than this, but nearly every IT support arrangement in the SMB market is one of four shapes.

Break-fix (pay per incident). Something breaks, you call, someone fixes it, you get a bill. Hourly rates in the NH/MA market run roughly $125 to $250 per hour depending on the shop and the severity. No contract, no monthly fee, no ongoing relationship beyond the vendor knowing your name. You own all the risk of things breaking and all the savings when they do not.

Block hours (prepaid retainer). You buy a block of hours — say 20 or 40 — at a discounted rate, and the provider draws them down as you call. It is break-fix with a volume discount and slightly better response times, because prepaid clients get bumped ahead of pure walk-ins. Blocks usually expire after a year, which is a detail worth reading twice in any agreement.

All-in managed services (per user, per month). The model most MSPs sell. A flat monthly fee per employee covers monitoring, patching, help desk, security tooling, backup management, and vendor coordination. Market rate for a real stack in our region is $100 to $175 per user per month. The MSP takes on the risk of your environment being noisy, so it has a direct financial incentive to keep things from breaking — which is the genuinely good part of the model, and the part the marketing gets right.

Co-managed / hybrid. You have an internal IT person or a small team, and the MSP fills specific gaps: security monitoring, after-hours coverage, patching infrastructure, big projects, or the specialized work — like a cloud migration — that does not justify a full-time hire. Pricing is usually a smaller per-user fee, a fixed monthly scope, or project rates.

None of these models is a scam and none of them is automatically right. They are different allocations of risk and cost between you and the provider. The question is which allocation matches your business — and that depends on numbers, not philosophy.

The math the "break-fix is dead" posts skip

Here is the comparison the industry does not like to write down.

Take a 10-person business at $125 per user per month on a managed contract. That is $1,250 a month, $15,000 a year, every year, whether anything breaks or not.

Now take the same business on break-fix at $175 an hour. For break-fix to cost more than the managed contract, that business needs to consume roughly 85 hours of IT labor a year — more than seven hours of billable break-fix work every single month, indefinitely.

Some 10-person businesses consume that easily. Plenty do not. A landscaping company where eight of the ten employees never touch a computer, the "server" is a QuickBooks file, and email lives in Google Workspace might generate fifteen billable hours in a bad year. Telling that business it is irresponsible not to spend $15,000 annually on managed IT is not advice. It is a sales pitch wearing advice's clothes.

The honest comparison has three parts, and most blog posts only show you the first:

The direct cost — contract fee versus expected hourly spend. This is the easy part, and it is the part the math above covers.
The downtime cost — what an hour of outage actually costs your business. For a law firm billing $300 an hour per attorney, a half-day email outage is a five-figure event and break-fix response times are intolerable. For the landscaping company, the crew keeps mowing while the office computer waits until Thursday. Same outage, wildly different cost.
The risk cost — the low-probability, high-severity events: ransomware, business email compromise, a failed drive with no tested backup. This is where pure break-fix has a genuine hole, and we will be straight about it below.

If you run this three-part math and break-fix wins, break-fix wins. You are allowed to believe an MSP that tells you that. You should be suspicious of one that never does.

Who break-fix actually fits

Based on what we see across small businesses in New Hampshire and Massachusetts, the reactive model genuinely works when most of these are true:

Under about 10 employees, with only a handful doing real computer work.
No compliance obligations. No HIPAA, no CMMC, no PCI beyond what your payment processor handles, no contractual security requirements from a big customer.
Downtime is an annoyance, not a hemorrhage. If your revenue-producing work continues while a workstation is down, your downtime cost is low.
Cloud-first and simple. Email in Microsoft 365 or Google Workspace, files in the same place, no on-premises server doing anything important.
Someone on staff is capable of basic triage — rebooting a router, running an update, telling a phishing email from a real one.

That describes a lot of real businesses: trades, small retail, single-location restaurants, owner-operator professional shops. For them, the disciplined move is not a $1,250 monthly contract. It is a relationship with a shop that answers the phone, plus a small set of non-negotiables handled once and checked occasionally.

And that last clause matters, so here is the caveat we owe you.

Where pure break-fix genuinely fails

Security is the one category of IT work that cannot be done reactively.

Nobody calls their break-fix vendor to report an attack in progress, because nobody knows it is in progress. Ransomware does not schedule an appointment. By the time a reactive vendor hears about a compromise, the interesting part is over and the expensive part has begun. The 2026 numbers on this are brutal: recovery from a ransomware event routinely costs more than a decade of managed service fees, and it kills a meaningful percentage of the small businesses it hits.

The same is true of backups — a backup that nobody tests is a theory, not a control — and increasingly of cyber insurance, where carriers now ask for MFA enforcement, endpoint protection, and tested recovery before they will write or renew a policy. Attest to controls you do not have and the carrier can deny the claim precisely when you need it.

So the honest recommendation for a break-fix-appropriate business is not "wing it." It is break-fix for support, plus a minimal always-on baseline:

MFA enforced everywhere, with the built-in security features of the Microsoft or Google license you already pay for actually configured
Real endpoint protection on every machine
Automated, monitored, periodically test-restored backups
Someone patching, even if it is just well-configured automatic updates with a quarterly check ## Who all-in managed actually fits

The flat-fee model earns its cost when the three-part math flips:

Compliance is in the picture. HIPAA, CMMC, SOC 2, or a customer contract with security requirements effectively mandates continuous monitoring, documented patching, and evidence on demand. Reactive support cannot produce an audit trail.
Downtime is expensive. When employees bill by the hour or the business stops when the systems stop, the response-time difference between a contract client and a break-fix call pays for itself in one bad morning.
Headcount is 10 to 15 or more. The volume of routine IT work — onboarding, offboarding, license management, the endless stream of small issues — starts consuming enough hours that predictable flat pricing beats the hourly meter, and the owner stops being the de facto IT department.
You would rather budget than gamble. Some owners rationally prefer a known $1,250 a month over a lumpy $400-one-month, $6,000-the-next pattern, even when the expected totals are similar. Predictability has value. Just price it consciously instead of being scared into it.

When those conditions hold, all-in managed is not an upsell — it is cheaper than the alternative once downtime and risk are priced in. Both things in this post are true at once: the model is oversold to businesses that do not need it, and it is genuinely the right answer for businesses that do.

Co-managed: the model nobody pitches you

If you already have an IT person, most MSPs see a competitor to displace. That is backwards. A solo internal IT admin covering 40 users is stretched across help desk, projects, patching, and security — and cannot be on call 365 days a year, because they take vacations and get sick. The gaps are predictable: after-hours coverage, security monitoring, and the specialized project work that comes up twice a year.

A co-managed arrangement fills exactly those gaps and nothing else. The MSP provides the monitoring and management infrastructure and the escalation depth; your internal person keeps the local knowledge and the daily relationship. It costs a fraction of full management because the MSP is not duplicating work your employee already does. We have these arrangements, and they are some of our most stable relationships — precisely because the scope is honest on both sides.

How we handle this at RNITS

The un-MSP position on pricing models is the same as our position on tools and contracts: the model should fit the business, not the MSP's revenue chart.

In practice, that looks like this.

Our managed pricing is published. Standard is $100 per user per month, Premium is $125, Enterprise is $150 — it is on the pricing page, with what each tier includes. No "call us for a quote," no "it depends" until a salesperson has qualified your budget.

Month-to-month exists, and the exit clause is on page one. If managed service has to be earned every month, the pricing conversation stays honest permanently. A client who can leave without penalty does not need to be oversold carefully — they need to be served well.

We will tell you if you do not need us monthly. Prospects walk in assuming they have to buy the full contract because that is what every competitor pitched. When the three-part math says a security baseline plus on-call support is the right fit, that is what we say — and we set up the baseline, stay reachable, and check in periodically. It costs them a fraction of the contract they walked in expecting to sign.

Businesses change models as they change. Break-fix clients grow into managed contracts when headcount or compliance arrives. Managed clients hire an internal IT person and shift to co-managed. A few have left for in-house IT entirely and come back years later when it did not pan out. Every one of those transitions is fine. The relationship survives the model changing because the relationship was never held together by an early-termination penalty.

Clients tell us the flexibility is a large part of why they stay — which is mildly ironic, since the industry's argument for lock-in contracts is retention. Our retention sits at roughly 100 percent without them. When leaving is easy, staying means something.

How to decide: five questions

You do not need an IT assessment to get most of the way to the right model. Answer these honestly:

What did you actually spend on IT support in the last 12 months — invoices, plus the owner-hours spent playing help desk? If it is well under what a managed contract would cost, that is data.
What does one full day of downtime cost you in hard revenue and missed obligations? Under a thousand dollars, break-fix is survivable. In the five figures, it is not.
Does anyone — regulator, carrier, or customer — require you to prove security controls exist? If yes, some form of ongoing management is effectively mandatory, because evidence cannot be produced reactively.
Is your security baseline real? MFA everywhere, endpoint protection, tested backups, current patches. If you cannot say yes with confidence, that gap needs closing regardless of which support model you pick — and closing it is a project, not a contract.
Are you at an inflection point — passing 10-15 employees, taking on compliance-bound work, hiring your first IT person? Model changes belong at inflection points, not at whatever moment an MSP's sales quarter ends.

If your current provider has never walked you through a version of this — if every conversation ends at the same all-in tier regardless of your answers — you have learned something about whose interests the recommendation serves.

Frequently asked questions

Is break-fix IT support cheaper than managed services?

For small, simple, low-downtime-cost businesses, usually yes — often dramatically. A 10-person business needs to consume roughly 85+ hours of billable work a year before typical managed pricing wins on direct cost alone. The comparison flips when you add downtime cost, compliance requirements, or security risk, which is why the honest answer depends on your numbers rather than on a universal rule.

What does managed IT cost per user in 2026?

In the New Hampshire and Massachusetts market, $100 to $175 per user per month for a genuine stack: monitoring, patching, help desk, endpoint protection, backup management, and security baseline. Meaningfully below that usually means an under-resourced provider; well above it without a clear explanation usually means tool sprawl. Our tiers run $100 to $150 and are published.

Can I mix break-fix and managed services?

Yes, and more businesses should. A common right-size for very small companies is a managed security baseline — MFA, endpoint protection, monitored backups, patching — with support handled on-call. Co-managed arrangements do the same thing for businesses with internal IT. The industry rarely pitches hybrid models because they produce less recurring revenue, not because they do not work.

Why do all MSPs push monthly contracts?

Partly for defensible reasons: proactive maintenance genuinely prevents problems, and flat pricing aligns the MSP's incentive with your uptime. And partly for a reason nobody puts in the pitch deck: MSP business valuations are calculated on contracted monthly recurring revenue. A break-fix client adds almost nothing to what the MSP is worth; a three-year contract adds a lot. Both motives are real. Only one of them is about you.

When should a business switch from break-fix to managed IT?

At an inflection point: crossing roughly 10-15 employees, taking on compliance obligations (HIPAA, CMMC, cyber insurance requirements with teeth), a downtime scare that revealed the real cost of waiting for a callback, or an owner realizing they have become the unpaid IT department. If none of those has happened, the pressure to switch is probably coming from the vendor's needs rather than yours.

Talk to an MSP that will run the math with you

If you are trying to figure out which model fits — or you are on a full managed contract and quietly suspect a smaller arrangement would do — the fastest way to find out is to look at the actual numbers: what you spend, what downtime costs you, what your licenses already include, and where the real security gaps are.
Or just start a conversation. We will run the three-part math with you, on paper, before anyone talks about a contract.

The Rnits Company. The un-MSP. (978) 226-8931.

Written by The RNITS Company. For more information, visit www.rnits.com.

Device Code Phishing: The M365 Attack That Skips Your Password

rnits — Sat, 11 Jul 2026 15:07:26 +0000

A dental office manager in Nashua forwarded us an email last week and asked a simple question: "Is this real?"

It looked like a shared-folder notification. A vendor she worked with wanted her to review a document. The email pointed to a page that asked her to open the real Microsoft sign-in and type in a short code to "connect the shared workspace." No fake password page. No misspelled domain. The Microsoft login it sent her to was the genuine one.

She had done half the steps before something felt off and she stopped.

Good instinct, because that email was a device code phishing attempt, and the reason it felt legitimate is that most of it was legitimate. The attacker never needed her password. He needed her to approve a login he had already started. If she had finished, he would have walked into her Microsoft 365 account with a valid session, MFA and all, and she would have gotten nothing but a document that never showed up.

This attack has been picking up all summer. Security researchers have been tracking a phishing-as-a-service platform behind a wave of it running from late June into July, and the pattern is worth understanding, because it defeats exactly the defense most small businesses think has them covered. If your whole security answer is "we have MFA," this is the attack that walks around it while you watch.

What device code phishing actually is

To understand the attack, you have to understand a normal, boring Microsoft feature it abuses.

Some devices can't show you a real login screen. Think of a smart TV, a conference room display, a printer, or a command-line tool. Microsoft built a way for those devices to sign you in anyway. The device shows you a short code. You go to a Microsoft page on your phone or laptop, type in that code, and approve the login. The device is now signed in as you. It's called the device code flow, and it exists for good reasons.

The attack hijacks that handshake.

Here's the move, stripped down. The attacker starts a device code login himself, on his own machine, pretending to be a device that needs to sign in to your Microsoft 365. Microsoft hands him a real code. He then emails you and gets you to type that code into the real Microsoft page and approve it. You think you're connecting to a shared folder, a Teams workspace, a new app. What you're actually doing is approving his login. Microsoft sees a legitimate approval from the real account owner, completes the sign-in, and hands the attacker a valid session token.

He's now signed in as you. He never saw your password. He never had to defeat your MFA, because you passed it for him.

That's the whole trick, and its ugliness is that every individual step is real. Real Microsoft page. Real login. Real MFA prompt. Real approval. The only lie is what you were told the code was for.

Why "we have MFA" doesn't stop this

We spend a lot of time telling small businesses to turn on multi-factor authentication, and we stand by every word of it. MFA blocks the overwhelming majority of credential attacks. If you don't have it on every account yet, that's still the first thing to fix.

But MFA checks one thing: are you the person who owns this account? In a device code attack, the answer is yes. You really are that person. You really did approve the login. MFA did its job perfectly and let the right person in. The problem is that the right person was tricked into opening the door for someone standing behind them.

We wrote recently about how hackers aren't breaking in anymore, they're logging in. Device code phishing is the cleanest example of that shift we've seen. There's no exploit, no malware, no vulnerability. There's a person, a code, and a moment of misplaced trust. The attacker doesn't fight your security. He borrows your credentials by asking you to use them on his behalf.

This is why treating MFA as the finish line is dangerous. MFA is the floor, not the ceiling. The attacks that matter in 2026 are built specifically to get around ordinary MFA, and this is one of them.

How the email gets to you

The delivery is deliberately low-drama, which is part of why it works.

The lures researchers are seeing lean on collaboration themes: a shared document, a payment or invoice you need to review, a Teams message, a folder someone wants you to access. Nothing screams emergency. Nothing asks for your password. The email just wants you to click through and "connect" or "verify."

In the campaign tracked this summer, the link often led to a legitimate but compromised website, a real business's site that had been quietly taken over to host the attacker's device code prompt. So even a careful person checking where the link goes might see a real company's domain, not some sketchy string of characters. From there, the page walks you through entering the code on the genuine Microsoft site.

The whole experience is designed to feel like setup, not like an attack. You're "linking an app." You're "connecting a workspace." That framing is doing a lot of work, because approving a login feels routine when you think you're the one setting something up.

Notice what's missing from all of this: a fake login page. Traditional phishing had to build a convincing counterfeit of the Microsoft sign-in and hope you didn't notice the URL was wrong. Device code phishing skips that entirely. It sends you to the real Microsoft. That's harder to catch, because the usual advice, "check that it's really the Microsoft login," passes with flying colors. It is really the Microsoft login.

What happens after you approve

If someone completes the flow, the attacker gets a session token, and a session token is a set of keys.

With it, he's inside the Microsoft 365 account as that user. He can read email, including everything in the archive. He can search for the words that matter to him, invoice, payment, wire, bank, routing, and learn exactly how your business handles money. He can set up a quiet inbox rule to hide his tracks or intercept vendor replies. He can send email as the compromised user, which is where business email compromise and fraudulent wire requests come from. And depending on how the account is set up, he can move toward other systems and other users from there.

This is the same damage pattern we see after any account takeover, and we've walked through where it lands inside a tenant in our piece on why your Microsoft 365 tenant is probably misconfigured. The account is the front door to the whole company now. Email, files, chat, admin controls, password resets for other services, it all sits behind that one login. A stolen session doesn't just cost you one mailbox. It can cost you the business's money and its relationships with the vendors and clients who trust email from your domain.

And because the attacker came in through a valid session, nothing looks obviously broken. No alarm goes off saying "malware detected." From most monitoring, it looks like the user is just working. That's exactly why detection and a human watching for the odd sign-in matters so much, and we'll get to that.

The controls that actually stop it

Here's the reassuring part, and as usual with us, it's not a pitch for a new product. The controls that shut down device code phishing are mostly settings you already own if you pay for Microsoft 365. The work is turning them on and configuring them for how your business actually operates.

Block the device code flow if you don't need it

Most small businesses do not use the device code flow for anything. No conference room displays signing into your tenant, no command-line tools your team runs daily. If that's you, Microsoft 365 lets you block the device code flow with a Conditional Access policy, and blocking something you never use is the cleanest fix there is. An attack that depends on a feature you've turned off simply doesn't work.

If you do have a genuine need for it, on a handful of specific devices, that exception can be scoped narrowly and documented instead of left open for everyone. This is exactly the kind of tenant-wide decision that proper Microsoft 365 managed services exist to make: knowing which features you can safely close off without breaking anyone's day.

Conditional Access, doing the work behind every login

Blocking device code is one policy. The broader control is Conditional Access, which lets you put rules around every sign-in, not just the password check.

If your company operates in New Hampshire and Massachusetts and nobody works overseas, a sign-in tied to another continent should be denied, not merely noticed. Access to sensitive data can require a known, company-managed device, which a random attacker machine won't be. Legacy authentication, the old protocols that can't do MFA at all, should be off entirely. Configured well, Conditional Access turns "the attacker got a valid session" into "the valid session still can't get anywhere it shouldn't."

Conditional Access is the single most valuable Microsoft 365 control that small businesses already pay for and almost never switch on. It's the difference between a login being enough and a login being just the first hurdle.

Phishing-resistant MFA for the accounts that matter

Ordinary MFA didn't stop this attack because the user approved it. But phishing-resistant MFA, passkeys and hardware security keys, changes the math for other attacks in this family, and it's the strongest identity upgrade available right now. Roll it out first to the people who touch money, hold admin rights, or own the company. It's included in the licensing most small businesses already have.

Pair it with token protection and shorter session lifetimes for sensitive apps, so that a stolen session is worth less and expires sooner. Both are configuration, not new purchases.

Someone watching the logins who will actually react

The dental office almost got got, but the manager stopped and asked a human. That's the pattern that saves businesses: a person in the loop.

On the technical side, the equivalent is real monitoring with someone who reads the alerts. A device code approval from an unusual place, a brand-new inbox rule quietly forwarding mail, a sign-in at 3 a.m. from a region you don't operate in, these show up in the logs. The account takeovers that turn into disasters are almost always the ones where nobody was watching the logs for weeks. Solid remote monitoring and management with a human who acts the same day is the difference between catching this on day one and finding out when a vendor calls about a payment you never authorized.

Train people on this specific move

General "don't click bad links" training won't catch this, because the link goes to the real Microsoft. The training that helps is specific: never enter a code into a Microsoft sign-in page unless you personally started the process on the device asking for it. If an email, a document, or a "connect this workspace" prompt hands you a code and tells you to approve a login, stop. You didn't start that login. Someone else did.

That one rule, taught plainly, would have stopped every version of this attack we've seen. It pairs with the broader habit we push at every business we work with: slow down and verify anything involving money, credentials, or a login you didn't personally initiate.

A short checklist before you close this tab

Run these against your own Microsoft 365 setup. If any answer is "I'm not sure," that's the one to chase down.

Is the device code flow blocked in your tenant, or scoped to only the devices that truly need it?
Do you have Conditional Access policies on sign-ins, or is a valid login enough to go anywhere?
Are logins from countries you don't operate in blocked outright?
Is legacy authentication turned off?
Do the people who touch money and admin accounts have phishing-resistant MFA?
Is someone, internal or your MSP, actually watching sign-in activity and able to react the same day?
Does your team know not to approve a login or enter a code they didn't personally start?

None of these are spending problems. They're configuration-and-attention problems, which is genuinely good news, because those get fixed in weeks and usually without a bigger bill.

The honest takeaway

Device code phishing isn't clever because it's technically advanced. It's clever because it's honest about being Microsoft the whole way through, and it lets your own trust do the breaking-in. There's no wall to smash, no lock to pick. There's a code, a request, and a person who was told the wrong thing about what they were approving.

The defense is a mix of a few settings you already own and one clear habit for your team. Close the door you don't use. Put rules behind the logins you do. And teach people that a login they didn't start is not a login they should finish.

Written by The RNITS Company. For more information, visit www.rnits.com.

Your Microsoft 365 Tenant Is Probably Misconfigured

rnits — Tue, 30 Jun 2026 11:14:43 +0000

A small business owner in southern New Hampshire called us after a wire transfer almost went sideways. The email looked normal. The vendor name was right. The invoice thread was real. The only thing that changed was the bank account at the bottom of the PDF.

The owner wanted to know which security product would have caught it.

That was not the first question we asked. We looked at the Microsoft 365 tenant first. No Conditional Access policies. Legacy authentication still allowed. MFA was enabled for some people, but not enforced consistently. Admin accounts were mixed in with daily-use mailboxes. A few users had forwarding rules nobody remembered creating. Audit logging was on, but nobody was reviewing it.

They were not careless. They were paying for Microsoft 365 Business Premium and assumed the security came with it.

That assumption is where a lot of small businesses get hurt. Microsoft 365 gives you a strong set of controls, but it does not run your business for you. If the tenant was set up years ago, touched by three different IT providers, and never reviewed as a whole, there is a good chance the dangerous parts are not the missing tools. The dangerous parts are the defaults nobody changed.

Microsoft 365 is usually the front door now

For most small businesses, Microsoft 365 is not just email. It is the front door to the company.

It holds email, calendars, Teams chats, SharePoint files, OneDrive folders, vendor invoices, client documents, password reset links, payroll notifications, and the admin accounts that control half the other cloud services in the business. If someone gets into a Microsoft 365 account, they may not need to touch your server or firewall at all.

That is why the tenant configuration matters so much. A stolen password is bad. A stolen password inside a loosely configured tenant is much worse.

The attacker can read old conversations, wait for invoice timing, create mailbox rules, register a new MFA method if the policy allows it, search for insurance paperwork, and reset passwords elsewhere. From the outside, it looks like normal user activity because the attacker is using a real account.

We wrote recently about why hackers are logging in instead of breaking in. Microsoft 365 is where that shift lands for a lot of small businesses. Identity is the perimeter now, and the tenant is where that perimeter is either locked properly or left half open.

The common problem: security is licensed, not configured

Microsoft licensing creates a false sense of safety. A business owner hears that the company has Microsoft 365 Business Premium, or E3, or some bundle with security features, and assumes the hard part is done.

The license is just the shelf. Someone still has to take the controls off the shelf and configure them for the way the business actually works.

That work is not glamorous. It is policy cleanup, sign-in rules, admin separation, device requirements, alert routing, mailbox review, and documentation. It does not make for a flashy dashboard, but it is the work that stops the most common attacks.

Here are the areas we would check first in a small business tenant.

1. MFA has to be enforced, not just available

A lot of tenants show MFA as "enabled" somewhere. That does not mean every user is protected.

We still see tenants where MFA is optional, enforced only for admins, skipped for service accounts, or handled through old per-user settings that nobody has reviewed in years. Sometimes a few people enrolled when prompted and everyone else clicked past it. Sometimes the owner has MFA, but the bookkeeper does not. That is backwards.

The first question is simple: can any normal user sign in to email with only a password?

If the answer is yes, fix that before buying anything else. Every mailbox should have MFA enforced. High-risk accounts, including owners, finance staff, HR, and admins, should move toward phishing-resistant MFA such as passkeys or hardware security keys. Basic push MFA is better than nothing, but attackers have learned how to abuse push prompts and relay codes through fake login pages.

For a business that handles payments, payroll, insurance paperwork, or client data, the target should be stronger than "we turned on MFA once." The target should be that a stolen password by itself is useless.

2. Conditional Access should block nonsense logins

Conditional Access is one of the most valuable Microsoft 365 controls small businesses already pay for and often do not use.

It lets you put rules around sign-ins. Not vague rules. Real ones.

If your company operates in New Hampshire and Massachusetts, and nobody travels internationally for work, a sign-in from a country you do not operate in should not quietly succeed. If an admin account signs in from an unmanaged personal laptop, that should be blocked or challenged. If a user tries to access company files without MFA, that should fail. If an old mail protocol tries to connect without modern authentication, that should be denied.

This is where Microsoft 365 managed services can make a direct difference. The value is not just "we manage Microsoft." The value is knowing which policies reduce real risk without making employees hate their computers.

Bad Conditional Access creates lockouts and workarounds. Good Conditional Access makes normal work feel normal and suspicious work hit a wall.

3. Legacy authentication should be gone

Legacy authentication is the old way some apps and protocols connect to mailboxes. Think IMAP, POP, SMTP AUTH, and older clients that do not handle modern MFA properly.

Attackers love it because it can be a side door around the controls you think you have.

A business can proudly say "we have MFA" while still allowing an old protocol that does not enforce MFA the same way. That gap is exactly the kind of thing cyber insurers ask about after an incident. If the application said MFA was enabled, but the tenant allowed a path around it, the conversation gets uncomfortable fast.

Most small businesses do not need legacy authentication anymore. If a line-of-business app truly still depends on it, that exception should be documented, monitored, and scheduled for replacement. It should not be left open for the whole company because nobody wanted to break an old scanner.

4. Admin accounts should not be everyday mailboxes

One of the quickest ways to spot a messy tenant is to look at the admin accounts.

If the owner uses the same account to read email, browse the web, approve invoices, and administer Microsoft 365, that account is carrying too much risk. If a helpdesk tech has global admin all day, every day, that is also too much. If former providers still have admin accounts, that is worse.

Admin access should be separated, limited, and reviewed.

For a small business, that usually means dedicated admin accounts, no daily email on those accounts, MFA stronger than the rest of the company, and fewer global admins than people expect. It also means removing stale partner relationships and old accounts left behind by previous IT providers.

This is not about making administration painful. It is about making sure one phished mailbox does not become a full tenant takeover.

5. Mailbox forwarding and inbox rules need review

Mailbox rules are a favorite hiding place after account compromise.

An attacker logs in, creates a rule to hide security alerts or vendor replies, and then waits. They may forward mail to an outside address. They may move anything with words like invoice, payment, wire, bank, or password into a hidden folder. The user keeps working, unaware that someone else is reading the room.

A tenant review should include suspicious forwarding, inbox rules, delegates, and mailbox permissions. This is especially important for finance, ownership, HR, and anyone who works with vendors.

The fix is not complicated. Block automatic external forwarding unless there is a documented business reason. Review rules that move or delete mail. Alert on suspicious changes. Teach users to treat missing replies and strange thread behavior as warning signs, not just Outlook being Outlook.

6. Devices matter more than most SMBs think

A clean Microsoft 365 configuration can still be weakened by unmanaged devices.

If users can download company files to any personal laptop, sync OneDrive to an old home computer, or approve logins from a phone with no screen lock, the tenant is not really controlled. The data is just moving to places the business cannot see.

You do not need to turn a 25-person company into a bank. You do need a reasonable device policy.

For many small businesses, that means company-managed machines for regular access, basic endpoint protection, disk encryption, screen locks, patching, and rules for what personal devices can and cannot do. It also means knowing which devices are connected to Microsoft 365 right now.

This ties directly into workstation management and software updates and patch management. Microsoft 365 security does not live only inside the browser. It depends on the condition of the devices people use to reach it.

7. Alerts need an owner

Microsoft can generate a lot of alerts. Some are useful. Some are noise. None of them help if they go to a mailbox nobody checks.

A common pattern is that security alerts route to the person who originally set up the tenant, a former MSP, or an admin mailbox that is rarely opened. The business technically had alerting. Practically, nobody owned it.

Decide who receives alerts, what gets reviewed daily, what requires immediate action, and how incidents get escalated. A suspicious sign-in for the bookkeeper should not sit unread for a week. A new forwarding rule on the owner's mailbox should not wait until month-end.

Good remote monitoring and management is partly about this ownership problem. Tools can surface the signal, but a person still has to know what matters and act before a small incident grows teeth.

8. The tenant should match your insurance answers

Cyber insurance applications have become more specific. They ask about MFA, backups, privileged access, logging, endpoint protection, encryption, and sometimes Conditional Access or equivalent controls.

The risk is not only getting declined. The bigger problem is answering optimistically and then discovering after a claim that the tenant did not match the answer.

If the application says MFA is enforced for all email users, verify that it is true. If it says admin access is limited, check the admin list. If it says alerts are monitored, know who monitors them. If it says backups are protected, test the restore path.

This is where cyber insurance readiness should be practical, not theoretical. The goal is not to make the application look good. The goal is to make the business actually match what the application says.

What we would check first

If we were reviewing a small business Microsoft 365 tenant tomorrow morning, we would start with these questions:

Can any user sign in with only a password?
Are admins using separate accounts from daily email?
Is Conditional Access blocking risky sign-ins?
Is legacy authentication disabled?
Are external forwarding and suspicious inbox rules controlled?
Are old employees, old vendors, and old MSP accounts removed?
Are security alerts going to someone who acts on them?
Are finance and owner accounts protected more strongly than average users?
Do the tenant settings match the cyber insurance application?
Can the business explain these controls without guessing?

That list is not exotic. It is the plumbing. But plumbing is what keeps the building from flooding.

The fix is usually smaller than the fear

The good news is that most Microsoft 365 tenant problems are fixable without ripping everything out.

You usually do not need a new email platform. You usually do not need six new security products. You need a careful review, a prioritized cleanup plan, and someone who understands how to tighten the tenant without breaking the way people work.

Start with identity. Lock down the obvious paths. Remove stale access. Turn on the controls you already own. Route alerts to a real owner. Document what changed so the next provider, insurer, or internal admin is not guessing.

That work is not dramatic, but it is the work that prevents the common mess: an attacker using a real password, walking through a tenant that trusted too much, and turning one mailbox into a business problem.

If you are not sure whether your Microsoft 365 tenant is configured safely, RNITS can review it with you. Start with a free cyber security audit or contact us through /contact/. We will show you what is actually exposed, what already works, and what should be fixed first.

Written by The RNITS Company. For more information, visit www.rnits.com.