DEV Community: Sheer Safe

SMS Login Is Fading: How to Move to Passkeys the Right Way

Sheer Safe — Tue, 22 Sep 2026 14:26:31 +0000

SMS-based login codes are being phased out because they can be intercepted, phished, or redirected through a SIM swap, and attackers have gotten good at exploiting exactly that. The fix isn't "add more MFA." It's moving to passkeys, which remove the shared secret an attacker can steal in the first place. You don't need a big-bang migration to start; you can begin a phased passkey rollout this week.

Why SMS-based MFA is losing trust

SMS one-time codes were a real improvement over passwords alone, and they're still better than nothing. But the threat model has caught up with them. Three well-known weaknesses drive the shift away from SMS:

SIM swapping. An attacker convinces (or bribes, or social-engineers) a mobile carrier to port a victim's number to a new SIM. Every SMS code now lands in the attacker's phone.
Real-time phishing kits. Modern phishing pages don't just steal a password. They relay the SMS code you type in, live, straight to the attacker's session. The code being "one-time" doesn't help if it's stolen the moment it's used.
No cryptographic binding. An SMS code is just a string of digits. It doesn't know or care which website you typed it into, which is exactly why it can be phished.

This is also why guidance from bodies like NIST (the National Institute of Standards and Technology) has, for years, steered organizations away from SMS as the primary authentication factor and toward stronger, phishing-resistant options.

Passkeys (built on the FIDO2/WebAuthn standard) are the practical answer: the credential is a cryptographic key pair tied to the specific website or app, so there's no code to steal, redirect, or trick someone into typing into the wrong place.

The business "so what"

For a CISO (Chief Information Security Officer) or owner, the real cost of SMS-based MFA (multi-factor authentication) isn't the occasional SIM-swap headline. It's account takeover of email, finance, or admin accounts that quietly leads to fraud, data exposure, or a foothold for a bigger incident. Moving high-value accounts to passkeys is one of the more effective, low-friction security upgrades available right now.

What "phishing-resistant" actually means (and why passkeys qualify)

Phishing-resistant doesn't mean harder to phish. It means the login can't be phished at all, because there's nothing for the user to be tricked into revealing. With a passkey:

The private key never leaves the user's device (phone, laptop, or security key).
The browser or OS checks that the site requesting login is the real one before it will respond. A fake lookalike domain simply won't work.
Login is a biometric tap or PIN unlock, not a code you copy and paste anywhere.

App-based authenticator codes (TOTP, or time-based one-time passwords) are a step up from SMS but are still phishable the same way SMS is; a fake page can still relay the code. If you're choosing where to invest first, prioritize passkeys over simply swapping SMS for an authenticator app.

How to start a passkey rollout this week

You don't need every system passkey-ready on day one. Use this sequence to get moving without breaking anything:

Step 1: Inventory your highest-value logins. Email/identity provider, cloud console, finance and payroll tools, code repositories, and any admin panels. These are your first targets, not your entire user base.

Step 2: Turn on passkeys as an option, not a mandate. Most major identity providers, cloud platforms, and password managers already support passkeys. Enable it alongside existing MFA rather than removing SMS immediately.

Step 3: Migrate admins and finance first. These are the accounts attackers target hardest. If your identity provider supports it, make passkeys mandatory for privileged roles before rolling out company-wide.

Step 4: Keep one fallback, not three. A common mistake is leaving SMS, authenticator apps, and passkeys all active as equal options, which just hands an attacker the weakest one to target. Keep a single, phishing-resistant fallback (a hardware security key, for example) for account recovery, and retire SMS as an active MFA method once each user has enrolled a passkey.

Step 5: Set a decision rule for the rest of the org. A simple threshold: any account with admin rights, financial access, or access to customer data moves to passkeys within your next patch/access-review cycle; everyone else moves on your normal rollout timeline.

What if not everything supports passkeys yet?

This is the honest objection, and it's a fair one. Not every legacy app, VPN (Virtual Private Network) client, or older device supports passkeys today. When that's the case:

Don't wait for 100% coverage before starting. Roll out passkeys everywhere they're supported now, and leave app-based MFA (not SMS) as the interim method for systems that lag.
Flag unsupported critical systems as a specific to-do for your IT or vendor roadmap, rather than a reason to delay the whole initiative.
If you don't have in-house resource to manage a phased identity rollout alongside everything else on your plate, that's a reasonable gap to bring in outside help for. This is exactly the kind of prioritization work a virtual CISO or managed security partner can own end-to-end, rather than it sitting on a to-do list indefinitely.

Start with a clear-eyed view of where you stand

The fastest way to know which accounts are most exposed to SMS-based attacks, and where to start your passkey rollout first, is an outside look at your current setup.

Sheer Safe offers a free security review to help you see exactly that, with no pressure and no sales pitch attached.

Want this looked at for real? Get a free security review and we will show you where you actually stand.

Cisco ISE Auth Bypass: When Network Access Control Fails

Sheer Safe — Thu, 17 Sep 2026 21:16:10 +0000

Originally published at Sheer Safe

TL;DR

An authentication bypass in a Network Access Control (NAC) platform like Cisco Identity Services Engine (ISE) means "authenticated" can't be trusted on its own — segmentation needs a second, independent control behind it, and that's true whether or not this specific scenario matches a live CVE.

This article uses an unauthenticated authentication bypass in Cisco ISE as an illustrative scenario, not a specific disclosed CVE, version range, or in-the-wild exploitation we're reporting on. We're using it because it's a realistic and recurring category of bug for any NAC platform: an attacker who can trick the system into treating an unverified device as authenticated.

If you run Cisco ISE, the right move is to check Cisco's own security advisories for any current bulletins that apply to your version, rather than relying on this piece for CVE-specific detail. What follows is what to check regardless of which vendor's NAC you run, and regardless of whether a specific bypass is currently disclosed against it.

What this vulnerability class actually changes for you

NAC platforms like ISE sit at a privileged chokepoint: they authenticate devices and users, then hand out network access accordingly. An authentication bypass in that layer means an attacker doesn't need valid credentials to get treated as authenticated. They can reach segments, VLANs, or resources that are supposed to be off-limits to unverified devices.

The risk goes beyond unauthorized access. Everything downstream of your NAC — your assumption that guest Wi-Fi can't reach finance servers, that a rogue laptop can't touch production — was built on the premise that the NAC decision was trustworthy. When that premise breaks, so does the segmentation model built on top of it.

Why a single NAC system is a single point of failure

Most mid-size organizations treat NAC as the segmentation boundary rather than one layer of it. That's the design gap this class of bug exposes, and it's not unique to ISE. It's true of any architecture where one control decides trust for an entire network.

A useful heuristic: if disabling or bypassing your NAC would let a device reach more than one trust zone, your segmentation is NAC-dependent, not NAC-assisted. That's worth fixing regardless of whether a specific vulnerability is currently disclosed, because the next NAC bug — in this product or another — will pose the same question.

What to do this week, patched or not

Whether or not you run Cisco ISE, use this as a forcing function to check your own exposure:

Confirm exposure. Do you run ISE, and is any management or policy interface reachable from outside your trusted network? Internet-facing management planes are the highest-priority item to lock down.
Check the vendor advisory directly. Go to Cisco's security advisories page and check for anything current against your ISE version, then apply patch and mitigation guidance on your normal emergency-change timeline. Don't rely on secondhand summaries (including this one) for version-specific detail.
Test your segmentation independent of NAC. Pick a device or account with no business reason to reach a sensitive segment (finance, backups, domain controllers) and confirm firewall rules or VLAN ACLs block it, without relying on NAC policy to enforce that boundary.
Pull your ISE Live Logs (or RADIUS/TACACS+ authentication logs) and look for concrete anomalies:
- Authentication events where the "Authentication Method" doesn't match what the endpoint should have used (for example, MAC Authentication Bypass succeeding where 802.1X should have been enforced)
- "Authorization Result" entries granting a device more access than its identity group should allow
- Admin audit-log entries for policy or switch-configuration changes your team didn't make

If Cisco has published a disclosure date for a bulletin that applies to your version, use that as your review start point. If you're doing this as general hygiene rather than responding to a specific bulletin, a 30-day lookback is a reasonable baseline.

If you need a structure for triaging this alongside other open vulnerabilities, CISA's Known Exploited Vulnerabilities catalog is a useful, specific reference for what's actively being exploited versus theoretical.

If you can't patch immediately

Patching windows aren't always fast. Change control, maintenance windows, or a small IT team can all slow things down. That's a real constraint, not a reason to sit on it. If the patch is going to take time, compensate at the layers NAC doesn't fully control:

Restrict management interface access to a known, small set of admin source IPs.
Tighten firewall and VLAN ACLs between segments so they don't depend on NAC decisions being correct.
Lean on endpoint detection (EDR) as a second line of defense. Even if a device gets onto a segment it shouldn't, EDR coverage can catch what it does next.

In one engagement with a venture-backed technology company, bringing the client to full EDR coverage across their endpoint fleet was a key part of containing an active intrusion, alongside the AWS/GCP cloud review and virtual CISO (vCISO) work described in the full case study. Endpoint visibility matters even when the network layer is compromised.

If you don't have the internal bandwidth to do this triage properly, that's exactly the gap a managed security function or a fractional virtual CISO is meant to close: senior judgment applied immediately, so your team's time goes into fixing the exposure rather than building the risk case from scratch.

Building segmentation that survives the next NAC bug

The fix isn't replacing your NAC vendor. It's making sure segmentation doesn't collapse when any single control fails.

A practical target: every sensitive segment (production, finance, backups, admin networks) should be protected by at least two independent controls — for example, NAC policy plus firewall ACLs plus endpoint posture checks — so a bypass in one doesn't grant free movement. If you can't name the second control for a given segment today, that's your next fix, not a someday item.

One edge case worth checking specifically: an authentication bypass in ISE doesn't just let a device onto a segment, it may also let an attacker reach ISE's own admin interface, which controls policy and can push switch configuration changes. If that's possible, your "second independent control" isn't actually independent if it's a firewall rule or ACL that ISE (or the same admin credentials) can also modify.

To verify real independence, check who and what can change each control: are your firewall ACLs and VLAN configs managed by an admin plane, credential set, or automation pipeline that's fully separate from ISE's admin access? If the same admin account, API key, or orchestration tool can touch both NAC policy and network ACLs, a bypass in one gives an attacker a path to quietly weaken the other — and that's the scenario your two-control design needs to rule out.

This is also where penetration testing earns its keep: a good test doesn't just check whether NAC blocks unauthorized devices, it checks what happens when it doesn't, and whether compromising NAC gives an attacker leverage over the controls meant to back it up. Our Vulnerability Assessment and Penetration Testing (VAPT) service is built around that kind of assumption-testing, and our approach favors fixing what's found over just handing back a report.

Where to start

If this raises questions about how your own network segmentation would hold up under a NAC failure, that's a conversation worth having before an attacker forces it.

Start with a free security review: it's a low-friction way to see where your segmentation actually depends on a single control, and where it doesn't.

Want this looked at for real? Get a free security review and we will show you where you actually stand.

Stopping Business Email Compromise Before Money Moves

Sheer Safe — Tue, 15 Sep 2026 13:15:00 +0000

Stopping Business Email Compromise Before Money Moves

The single most effective way to stop business email compromise (BEC) is to require out-of-band verification for any payment or bank-detail change before the money moves. Never trust the request just because it arrived in a familiar-looking email thread. Every other control matters, but this is the one that actually stops the wire.

BEC doesn't rely on malware or clever exploits. It relies on a convincing email, a sense of urgency, and a finance team that's moving fast. The fix isn't purely technical: it's a mix of process discipline and email hardening. Here's what to put in place, in order of impact.

The fastest way to stop BEC: verify every payment change out-of-band

If an email asks you to change a vendor's bank details, redirect a wire, or pay an "urgent" invoice from a new account, stop and verify using a channel that didn't come from that email.

The rule is simple: any request to change payment details or send funds to a new account gets a phone call to a number you already had on file — not one supplied in the email or the signature block. If you can't reach the person by phone within a reasonable time, the payment waits.

Urgency in the email is not a reason to skip verification. It's usually the tell. A new vendor, a new account, or a returning vendor with "updated" details are all treated the same way: verify before you pay.

The obvious objection: what if the vendor is genuinely in a hurry and gets annoyed at the delay? A legitimate counterparty will accept a callback to confirm a wire. It's standard practice at most companies. If someone pushes back hard on a verification call, that itself is a signal worth escalating, not ignoring.

Build a payment-change protocol your finance team can't skip

Verification only works if it's a required step, not a judgment call left to whoever is busiest that day. Put it in writing:

Define who is authorized to approve a bank-detail change or a new wire recipient, and require a second person to sign off on anything above a threshold you set internally.
Keep a maintained contact list (name, phone number, verified independently) for every vendor that receives wires. Don't rely on whatever's in the email signature.
Make "flag anything unusual" safe to do. The person who pauses a $50K wire to make a phone call should never be made to feel like they slowed the business down.

If you don't have a documented finance approval process today, that's the gap to close this week, not the email filter. Most BEC losses happen because the process allowed one person, under time pressure, to approve a change alone. A written protocol plus a mandatory second signer closes that gap even if a fake email gets through.

Harden email itself so fewer fakes reach the inbox

Process stops the money from moving; email controls reduce how often your team faces the decision at all.

Authenticate your domain. SPF, DKIM, and DMARC make it harder for attackers to spoof your company's domain in emails sent to your customers and vendors. This protects your reputation as much as your inbox.
Flag lookalike domains automatically. Most email platforms can tag messages from newly registered or similar-looking domains (a swapped letter or added hyphen, for example). Turn this on. It's often free and just switched off by default.
Add a visible external-sender banner. A simple "this email originated outside your organization" flag on inbound mail catches the classic BEC pattern: an email that looks internal but isn't.
Restrict inbox rule creation where possible, or review auto-forwarding rules periodically. Attackers who compromise a mailbox often set up silent forwarding rules to monitor invoice threads. This is one of the easiest indicators to check for and one of the most overlooked.

None of this requires a large security team to stand up. If you don't have the internal resources to configure and monitor these controls, a managed security arrangement can own this on an ongoing basis rather than as a one-time setup.

If the wire already went out, speed is everything

Even with good controls, no company is immune. If a fraudulent payment does go through, the first hour matters more than anything else.

Contact your bank immediately and request a recall or hold on the transfer. The sooner this happens, the better the odds of stopping or reversing it.
Preserve the email evidence and don't delete the thread. You'll need it for the bank, for law enforcement, and for your own post-incident review.
Loop in whoever handles incident response early, even if you're not sure yet how serious it is.

In one engagement, we saw firsthand how quickly an active intrusion can escalate once attackers have a foothold. Waiting to "confirm" the problem before acting almost always costs time you don't have.

If you don't have an incident response plan or a point of contact for this scenario today, fix that before you need it, not after. Our incident response service exists for exactly this: a senior response when something's already moving, not a form to fill out.

Where to start this week

You don't need every control above in place simultaneously. Start with the highest-leverage one: put a written, mandatory callback-verification rule in front of every payment-detail change, starting Monday. It costs nothing, takes minutes to implement, and closes the gap that BEC actually exploits.

If you want a second set of eyes on where your email, finance process, and vendor management stand today, our free security review is a low-friction way to find out — no obligation, just a clear picture of where the gaps are.

For broader guidance on protecting against email-based fraud, the Cybersecurity and Infrastructure Security Agency (CISA) also publishes general BEC awareness resources worth sharing with your team.

Originally published at sheersafe.com.

CISA's KEV List: A Free Patch Priority Shortcut for SMBs

Sheer Safe — Thu, 10 Sep 2026 17:31:54 +0000

CISA's KEV List: A Free Patch Priority Shortcut for SMBs

What the KEV List Actually Is

The Known Exploited Vulnerabilities (KEV) catalog, maintained by the U.S. Cybersecurity and Infrastructure Security Agency (CISA), is a running list of vulnerabilities attackers are actively exploiting in the wild, not just flaws that could theoretically be dangerous.

For an SMB with limited patching bandwidth, checking whether a vulnerability is on that list is the fastest, free way to decide what gets fixed today versus what waits until next quarter's maintenance window.

Federal civilian agencies have to remediate KEV entries under a binding CISA directive, on a schedule CISA sets. You don't have to follow that same directive, but the logic behind it holds for anyone: if attackers are already using a specific vulnerability against real targets, it belongs at the top of your list, no matter how important your systems feel.

You can browse the catalog directly at cisa.gov.

Why KEV Beats a CVSS Score Alone

Most vulnerability scanners rank findings by CVSS severity score. That's useful, but CVSS measures theoretical impact, not real-world attacker behavior. A 9.8-severity bug that no one is exploiting can sit behind a 6.5-severity bug that's being actively used against businesses like yours right now.

A simple decision rule fixes this:

If a vulnerability is on the KEV list, patch it fast regardless of its CVSS score. Exploitation is confirmed, not hypothetical.
If it's not on KEV, use CVSS plus exposure (is it internet-facing? does it touch customer data?) to decide urgency.

This single rule reorders most patch backlogs in a way that reduces breach risk without needing a bigger team or a bigger budget.

A Weekly Patch Triage Routine

You don't need new tooling to act on KEV. You need a short, repeatable routine:

Subscribe to KEV updates so new entries land in your inbox instead of relying on you to remember to check.
Keep a current asset list, even a spreadsheet, of the software, appliances, and cloud services you run, with versions. You can't cross-reference a list you don't have.
Cross-check new KEV entries against that list each week. This takes minutes once the habit is built.
Split matches into two buckets: internet-facing systems (patch within days) and internal-only systems (patch within weeks, but don't drop them).
Log what you patched and when. This becomes useful evidence for insurers, auditors, or customers asking about your security practices.

If you're not sure which of your assets are genuinely internet-facing, that's a gap worth closing before you build a triage routine on top of it. An external penetration test will map your real exposure rather than your assumed one.

When the Vendor Patch Isn't Ready Yet

The obvious objection: what if a vulnerability lands on KEV and your vendor hasn't shipped a fix, or shipping the fix internally means downtime you can't absorb this week?

Patching isn't always instant, and pretending otherwise sets teams up to ignore the list entirely. When you can't patch immediately, don't do nothing. Apply compensating controls until you can:

Restrict network access to the affected system (firewall rules, VPN-only access) to shrink the attack surface.
Turn on or tighten logging and alerting for that system so you'd notice exploitation attempts.
Disable the specific feature or service the vulnerability lives in, if it's not business-critical.
Set a hard follow-up date to apply the real fix. Don't let "temporary" become permanent.

The same logic applies if the affected software is niche enough that it never appears on KEV at all. Absence from the list isn't proof of safety, it just means it's not yet a documented mass-exploitation target. Keep using CVSS and exposure as your fallback, and treat KEV as a floor, not a ceiling, for prioritization.

When a List Isn't Enough on Its Own

KEV is a useful, free signal, but it only tells you what's actively exploited elsewhere. It won't tell you which of your own cloud misconfigurations, exposed admin panels, or unpatched internal systems are your actual weak points.

In one engagement with a venture-backed technology company that had no dedicated security hire, a combined cloud and infrastructure review surfaced hundreds of AWS findings and hundreds more in GCP that a patch list alone would never have caught. You can read the details in our case study.

If your team is stretched thin enough that even a weekly KEV check feels like one more thing on the pile, that's usually a sign patching needs to sit inside an ongoing program rather than a manual habit. Our managed security service builds that routine. Where incident response is already needed, our incident response team can help contain and clean up while the underlying fix is put in place.

Start This Week

You don't need a security department to use KEV. You need a list of what you run and ten minutes a week to check it against the catalog.

If you want a clear picture of where your real exposure sits before you build that routine, our free security review is a low-friction way to find out.

Want this looked at for real? Get a free security review and we will show you where you actually stand.

Remote Support Tools Are Now a Worm

Sheer Safe — Wed, 09 Sep 2026 13:31:35 +0000

Remote Support Tools Are Now a Worm's Favorite Ride

Threat Intel · 6 min read · Sep 7, 2026

Yes, remote monitoring and management (RMM) tools such as ScreenConnect are increasingly the vehicle attackers use to spread between machines. Not because the software is broken, but because it's already trusted, already installed, and rarely watched closely.

The fix is tightening who can install these tools, how they authenticate, and what happens when a new one shows up on a host that never had it before — not banning them outright.

What's actually happening

Instead of dropping custom malware that an endpoint detection and response (EDR) agent might flag, attackers who get a foothold on one machine look for a legitimate remote access tool already present, or quietly push one out themselves. Once installed, that tool gives them a signed, whitelisted, admin-level channel that looks like ordinary IT support traffic.

From there, they use the same tool, or the credentials behind it, to jump to the next host, and the next. It behaves like a worm, but it's riding infrastructure your team already approved. That's what makes it hard to catch with signature-based tools alone.

The simplest tell: a remote access tool appearing on a host, or making a new outbound connection, without a corresponding IT ticket. If you can't answer "who authorized this install and why" in under a minute, treat it as an incident until proven otherwise.

Why RMM tools make such a good ride

Three properties make remote support software attractive to an attacker once they're inside:

They're pre-trusted. Security tools are tuned to ignore known-good remote access software, so it rarely triggers an alert on its own.
They carry admin rights. Remote support tools are built to let a technician do anything on the endpoint, which is exactly what an attacker wants too.
They're often multi-tenant. If your remote support comes through a managed service provider (MSP) or a shared console, one compromised technician credential can reach every client behind it, not just yours.

Decision rule: if your business relies on a third party (an MSP, vendor, or contractor) for remote support, ask them directly how technician access is segmented between clients and whether MFA is enforced on every login to that console. If they can't answer clearly, that's a real risk, not a hypothetical one.

The checklist: are you exposed right now?

This is doable in an afternoon, not a quarter:

Inventory every remote access tool with elevated privileges across your endpoints, not just the one you sanctioned, all of them.
Flag duplicates. If you find more than one remote support tool on a single host, that's a red flag worth investigating immediately.
Check MFA on every console that can trigger a remote session, your own, and any vendor's.
Check versioning. Old, unpatched builds of remote access software are a known target; confirm auto-update is on or that patching is tracked manually.
Confirm alerting exists for new installs of remote access software on any endpoint, and for a single tool connecting to an unusual number of hosts in a short window.

What to fix this week

Once you know what's on your fleet, the hardening is straightforward:

Pick one sanctioned tool and block everything else at the endpoint level using application control or your EDR's allowlist feature.
Require phishing-resistant multi-factor authentication (MFA) on every account that can initiate a remote session. This is the single control that breaks the "steal a technician credential, ride it everywhere" pattern.
Alert on new installs of remote access software as a standing rule, the same way you'd alert on a new admin account.
Segment support access so a support session on one host doesn't implicitly grant reach into your broader network.
Watch for rapid, sequential connections. One remote tool reaching several new hosts in a short period is the lateral-movement signature, not normal support behavior.

Programs like our managed security service are built around exactly this kind of monitoring: catching the behavior pattern, not just the tool name.

"We can't just ban our remote support tool"

Fair. Most businesses genuinely need remote access for IT support, and ripping it out isn't realistic or necessary. The goal is control, not elimination.

If your remote support comes through an MSP or vendor and they're slow to answer questions about MFA, technician segmentation, or logging, don't wait for a perfect answer before you act. Tighten what you control on your end now: endpoint allowlisting, alerting on new installs, MFA on your own accounts.

Treat the vendor's response time itself as a data point. A vendor who can't explain their access controls quickly is telling you something about how they'll respond during an actual incident.

If you suspect a remote access tool has already been used to move laterally in your environment, that's an active incident, not a hardening project. Our incident response team can help contain it before it spreads further.

What this looks like in practice

In one engagement with a venture-backed technology company that had no dedicated security hire, we contained an active intrusion as part of a broader cloud and endpoint security review. This is the kind of situation where knowing exactly what has admin-level access to your endpoints, and how fast you can spot something new, determines whether an incident stays small. You can read more in the full case study.

CISA has also published general guidance on the risks of legitimate remote access software being misused, worth a look if you want the broader threat landscape.

Where to start

You don't need a big program to close this gap. You need a clear inventory, MFA everywhere, and alerting on anything new.

If you want a second set of eyes on what's actually running across your endpoints, a free security review is a quick way to find out before an attacker does.

Want this looked at for real? Get a free security review and we will show you where you actually stand.

Locking Down Remote Support Tools Before They're Abused

Sheer Safe — Mon, 07 Sep 2026 22:36:31 +0000

RMM tools like ScreenConnect are a top attacker entry point. Here's why, and what to do about it.

Remote monitoring and management (RMM) tools like ScreenConnect get abused precisely because they're supposed to be on the network. Banning them isn't practical for most businesses. Restricting what each connection can do, and watching for the few behaviors that separate a technician from an intruder, is.

These tools are on an approved list, signed by a trusted vendor, and usually exempt from the scrutiny given to unfamiliar software. An attacker who gets access to one doesn't need custom malware. They just need a session. That's what makes RMM abuse hard to catch with traditional antivirus, and why it keeps showing up in real-world intrusions.

Why RMM Tools Are a Favorite Entry Point

Three things make remote support software attractive to attackers:

Trust by default. Security tools are often configured to allow known RMM software rather than flag it.
Legitimate use as cover. A remote session at 2am can look identical to a scheduled maintenance window if no one is checking context.
Standing access. Many RMM deployments run with high privileges on every endpoint they touch, all the time. That's convenient for support, and equally convenient for an attacker who compromises one credential.

The takeaway: treat RMM software as a privileged access path, not just another app on the endpoint list.

How to Spot Misuse Early

You don't need a full SOC (security operations center) to catch the early signs. Most abuse patterns show up in a small set of behaviors. This week, check whether any of these are happening, and whether you'd even notice if they were:

Unfamiliar RMM software appearing at all. If your business uses one remote support tool, any other RMM binary showing up on an endpoint is a red flag, full stop.
Sessions outside your normal support hours or vendor list. Legitimate IT support has a rhythm. A session initiated by an account or vendor you don't recognize, at a time no one scheduled, deserves a phone call before it deserves a shrug.
New installs on servers rather than user devices. RMM tools are usually deployed to manage end-user machines. An install on a domain controller or database server that wasn't planned is worth investigating immediately.
Rapid deployment across many machines in a short window. Attackers who gain admin access often push the RMM agent to as many endpoints as possible to establish persistence. A burst of new installs is a stronger signal than any single one.

Decision rule: if you can't answer "who installed this, and why" within a few minutes of checking, treat the install as suspicious until proven otherwise.

Limit the Blast Radius With Least-Privilege

You can't always stop a stolen credential from being used. You can control what that credential is allowed to do once it's inside an RMM session.

Scope access to what the job needs. A technician resolving a printer issue doesn't need domain admin rights during that session. Map your RMM roles to the narrowest permission set that still lets people do their job.
Separate the RMM admin console from everyday user accounts. The account that manages your RMM platform should not be the same account someone uses for email. If it's phished, the blast radius shouldn't include your entire remote access fleet.
Require approval for new device enrollment. If any device can join your RMM tenant without a human checking, that's an open door. Turn on enrollment approval if your platform supports it.
Review who has standing remote access quarterly, not annually. Contractors, former employees, and old vendor relationships accumulate access that no one remembers to remove. A short quarterly review catches this before it becomes an incident.

If your current setup gives broad, always-on access "because it's easier," that's the exact configuration attackers rely on. Least-privilege access matters here: it's the difference between one compromised session and a full network breach.

Build Alerting That Actually Catches Abuse

Alerts only help if someone sees them and knows what to do. Start with a short, high-signal list rather than trying to monitor everything:

New RMM software installation on any server.
RMM session initiated from a geography or IP range you don't normally see.
A remote session that installs additional software or creates new user accounts.
Any RMM agent communicating with a domain or IP that isn't your known vendor infrastructure.

If your team doesn't have the bandwidth to watch these signals around the clock, that's a resourcing gap worth admitting rather than ignoring. A managed security arrangement exists to keep eyes on this kind of alert stream so it doesn't sit unread in a dashboard no one opens.

When It Doesn't Get Caught in Time

Even with good controls, a determined attacker with valid credentials can slip through. If you find an RMM session you can't account for, don't wait for certainty. Isolate the affected endpoint from the network first, then investigate. The cost of disconnecting a legitimate technician for ten minutes is far lower than the cost of an attacker having another hour inside your environment.

If you don't have an established process for that moment — who makes the call, who isolates the machine, who reviews the logs afterward — that's worth fixing before an incident forces the question. Our incident response service exists for exactly this: acting fast when something looks wrong, and confirming afterward what actually happened.

For general guidance on remote access risks, the Cybersecurity and Infrastructure Security Agency (CISA) has published advisories on the malicious use of remote monitoring and management software. Worth a read if you want the wider threat picture.

What to Do This Week

Pick one action from this list and do it before Friday: audit your RMM admin accounts for separation from daily-use logins, turn on enrollment approval, or set up an alert for new RMM installs on servers. Any one of these closes a real gap.

If you're not sure where your remote access exposure actually stands, a free security review is a low-friction way to find out. No commitment, just a clear picture of what needs attention first.

Artifactory Token Forgery: Why Your Build Tool Needs Prod-Level Scrutiny

Sheer Safe — Thu, 03 Sep 2026 17:36:41 +0000

Artifactory Token Forgery: Why Your Build Tool Needs Prod-Level Scrutiny

Advisory · 6 min read

The short answer

If an attacker can forge or steal a token for your artifact repository, they don't need to touch production at all. They can poison the builds that become production instead.

Token forgery flaws in tools like Artifactory are a reminder that artifact stores aren't back-office plumbing. They're a privileged system, and they deserve the same access control, monitoring, and testing rigor you already apply to production.

Why your artifact store deserves production-grade scrutiny

Security researchers have repeatedly found authentication and token-handling flaws in popular artifact repository platforms — the kind of software that stores your build outputs, container images, and dependency caches. A forged or misused token in one of these systems can let an attacker impersonate a legitimate service account, pull signing keys, download proprietary code, or push a tampered artifact that your pipeline then deploys as if it were legitimate.

That's the uncomfortable part. Most teams put real effort into locking down who can touch production servers, databases, and cloud consoles. Far fewer apply the same discipline to the artifact store sitting upstream of all of it. But if that store trusts a forged token, it hands over exactly what an attacker needs to walk straight into your deployment path — often with less logging and fewer alerts than production itself.

The practical takeaway: your CI/CD (continuous integration/continuous delivery) artifact repository is not a convenience tool. It's an identity and access boundary, and it should be treated as one.

A checklist to run this week

You don't need a major project to start closing gaps. Work through this list against your actual artifact repository (Artifactory, Nexus, GitHub Packages, or equivalent):

Inventory every token and service account with write access. If you can't produce this list in under ten minutes, that's your first finding, not a footnote.
Apply the "if you can't remember, rotate it" rule. If nobody can say when the admin or CI token was last rotated, rotate it now and put rotation on a recurring calendar item.
Separate read from write. Most humans and pipelines only need to pull artifacts. If a broad group of accounts can push or promote artifacts, tighten that to the smallest set that actually needs it.
Turn on artifact signing and verification if your tooling supports it. If your pipeline can't distinguish a signed artifact from an unsigned one, an attacker doesn't need to forge a token — they just need to slip in a lookalike package.
Check where your artifact store logs go. If access and download events aren't flowing into the same monitoring you use for production, treat that as a gap to close, not a someday item.

Most of this doesn't require new tooling. It requires spending an hour treating the artifact store like the privileged system it is.

The obvious objection: "We don't have the resources to review this ourselves"

Fair pushback, especially for teams without a dedicated security hire. Two realistic paths from here:

If your team already runs a DevSecOps practice, fold artifact repository review into the pipeline hardening work you're doing anyway. Token hygiene and access review fit naturally alongside dependency scanning and build integrity checks. Our DevSecOps work is built around this kind of pipeline-level scrutiny.

If you don't have that capacity in-house, a focused penetration test that covers your CI/CD and artifact infrastructure — not just your web app — will surface these gaps concretely instead of leaving them as an assumption. That's the scope we cover in our VAPT (vulnerability assessment and penetration testing) engagements.

In one engagement with a venture-backed technology company that had no dedicated security hire, our review of their cloud and infrastructure surfaced hundreds of findings across their AWS and GCP environments and led to the discovery of a contained active intrusion. It's a useful illustration of how much sits undiscovered in infrastructure teams assume is "just tooling."

What you shouldn't do is wait for a vendor patch and call the job done. Patching a specific flaw closes one door. It doesn't fix the underlying habit of treating artifact stores as lower-trust than production. Even after a patch ships, the access-control and monitoring gaps above will still be there unless someone actually reviews them.

Make it part of an ongoing program, not a one-time fix

Artifact repository security isn't a project you finish. It's a posture you maintain, the same way you maintain production access reviews. New service accounts get created, tokens get issued for one-off automation and never revoked, and permissions creep outward over time. A single audit fixes today's problem. A recurring review catches next quarter's.

For general guidance on securing software supply chains and build infrastructure, CISA's (Cybersecurity and Infrastructure Security Agency) resources are a solid public reference point.

If you want a second set of senior eyes on where your build pipeline and artifact store actually stand today, start with our free security review. It's a quick way to find out whether your build tool has quietly become the most trusted admin account in your environment.

Want this looked at for real? Get a free security review and we will show you where you actually stand.

Originally published at sheersafe.com

MFA Fatigue: Why Employees Approve the Push That Isn't Theirs

Sheer Safe — Tue, 01 Sep 2026 01:03:02 +0000

Employees approve pushes that aren't theirs because tapping "Approve" has become a reflex, not a decision. Push-bombing (also called MFA fatigue) exploits that habit: attackers already have a valid password and just need one tired, distracted, or annoyed employee to make the prompts stop.

A stronger MFA (multi-factor authentication) app won't fix this. What works is a written rule employees actually follow, backed by settings that make the reflex harder to trigger.

What Push-Bombing Actually Does

This attack doesn't break your MFA. The attacker just needs a username and password already in hand, from a breach dump, a phishing kit, or credential stuffing. From there:

The attacker logs in with the stolen credentials, which triggers a legitimate MFA push to the real employee's phone.
Denied once, they try again, sometimes dozens of times, often late at night or during a known busy stretch.
Eventually the employee, mid-meeting, half-asleep, or just done with the buzzing, taps Approve to make it stop.
The attacker now has a fully authenticated session, indistinguishable from a normal login.

Nothing about your encryption, your password policy, or your MFA vendor failed here. A person made a split-second decision under annoyance, and the system did exactly what it was built to do: let an approved push through.

Why Habit Beats Technology Here

MFA approval is trained behavior. Employees see the prompt dozens of times a week for legitimate reasons: a VPN reconnect, an app token refresh, a new device login. Approving on sight becomes automatic, the same way people click through cookie banners without reading them.

Attackers know this. They're not trying to fool a security control; they're trying to trigger a conditioned response. That's why MFA strength alone can't close this gap. The weak point is the moment of habit, not the cryptography behind the prompt.

The Fix Is Procedural First, Technical Second

Two layers matter, and most businesses only build one:

Technical layer: where your identity provider supports it, move to number-matching push approval (the user types a code shown on-screen instead of tapping a single button) or phishing-resistant options like passkeys/FIDO2. Also enable any built-in alerting or lockout after repeated failed or denied prompts. Most modern platforms offer this, but it's rarely turned on by default.

Procedural layer: a written, one-line rule every employee can apply without thinking: if you get an MFA prompt you didn't just trigger by logging in yourself, deny it and report it immediately. Don't just dismiss it.

The reporting part is the piece most policies skip. An employee who quietly denies five pushes in a row and moves on has just watched an active attack and told no one. A denied-and-reported push is a signal your team can act on. A denied-and-ignored push is a near-miss nobody learns from.

A Decision Rule Employees Can Actually Use

Skip the long security-awareness deck. Give people this instead:

Did you just try to log in yourself, right now?

If yes, approve.
If no, or if you're not sure, deny it.
If you get more than one unexpected prompt in a short window, treat it as an active attack: deny all of them and report immediately, don't wait to see if they stop.

This is deliberately simple. Simple rules survive 2am and Monday-morning chaos; nuanced ones don't.

What To Do If You See a Burst of Denied Pushes Right Now

If your logs show repeated MFA denials for one account in a short window, don't wait for a definitive answer on whether it was "just noise." Force a password reset for that account, revoke active sessions and tokens, and check recent login activity for that user across your key systems. Treat it as a likely compromised credential first, and downgrade it later if it turns out to be nothing.

Waiting for certainty is how a contained incident becomes a real one.

If it does turn into something bigger, this is exactly the scenario our incident response service is built for. The goal is containing access fast, not documenting it after the fact. In one engagement with a venture-backed technology company, our team contained an active intrusion during the assessment, a reminder that the gap between "a credential looked odd" and "an attacker has real access" can close very quickly.

If You Don't Have a SOC Watching This

Most small and mid-size businesses don't have someone watching authentication logs at 2am, and that's a fair objection to all of the above. None of it matters if nobody sees the burst of denied pushes.

Two things help without requiring a full security team:

The policy and decision rule above cost nothing and work regardless of tooling. Put it in writing, tell people once, and reinforce it when someone reports a denied push (praise the report, don't scold the trigger).

For the monitoring gap, you don't need to build a SOC (security operations center). You need someone checking the right signal at the right time. A managed security setup or ongoing virtual CISO support can configure alerting so a burst of MFA denials reaches a person, not a log file nobody opens.

For general background on phishing-resistant authentication, CISA (Cybersecurity and Infrastructure Security Agency) publishes practical guidance worth a read.

Start With a Free Review

If you're not sure whether your MFA setup, alerting, and employee policy actually close this gap, that's worth a look before an attacker finds out for you.

Sheer Safe offers a free security review to help you see where the real gaps are. No pressure, no long sales process.

Want this looked at for real? Get a free security review and we will show you where you actually stand.

PaperCut Zero-Day: Why 'Boring' Internal Apps Get Hit First

Sheer Safe — Fri, 28 Aug 2026 01:20:07 +0000

Attackers hit tools like PaperCut first because those tools are trusted, internet-facing more often than IT realizes, and almost never on anyone's patching priority list. The fix isn't a bigger firewall. It's knowing which "boring" internal apps you're running and treating them like the front door they actually are.

What happened with PaperCut, in plain terms

PaperCut is print management software used by thousands of organizations to control who can print what, and how much it costs. It's the definition of unglamorous IT plumbing. That's exactly why it became a headline: serious vulnerabilities in PaperCut's server software were exploited by ransomware operators to gain an initial foothold inside networks, then move laterally to more valuable systems. Government advisories, including from CISA (the Cybersecurity and Infrastructure Security Agency), flagged active exploitation and urged organizations to patch immediately.

Nothing about PaperCut itself is unusual. Print servers, license managers, backup consoles, VPN (Virtual Private Network) appliances, internal wikis: these are the tools nobody demos to the board, nobody threat-models, and nobody remembers exists until something breaks. That's the pattern worth paying attention to, not the specific product name.

Why "boring" internal apps get hit first

Attackers aren't picking targets based on how exciting the software is. They're picking based on three things:

Trust level. Internal apps often run with elevated privileges. A print server frequently has domain-level access to talk to every printer and print queue on the network.

Exposure you forgot about. Many of these tools were set up years ago by an admin who's since left, sometimes with remote or web-based admin consoles left reachable from outside the network "temporarily."

Low monitoring, low patching. Nobody watches a print server's logs. Nobody schedules its updates. It sits there, working fine, until a vulnerability is found. Then it sits there, still working fine, but now compromised.

Put together: a vulnerability in a system nobody's watching, with more access than it needs, that nobody patched. That's not bad luck. That's the profile attackers scan for.

A one-week checklist: find your own PaperCut

You don't need a full audit to make real progress. Set aside a few hours this week and work through this:

List every internal-facing app with an admin web console. Print management, backup software, network monitoring tools, license servers, old intranet portals. If it has a login page, it's on the list.
Check what's reachable from outside your network. For each item, confirm whether it's actually restricted to internal access or accidentally exposed. Anything with a public IP and a login page is a priority.
Ask "who owns this?" If nobody can answer in under a minute, that's a red flag. Unowned systems don't get patched.
Check the vendor's advisory page for each tool, once. Most vendors publish security bulletins. A ten-minute check now beats finding out from a ransomware note later.
Apply this decision rule: if a system is both internet-reachable and running with elevated network permissions, patch it within days of any vendor advisory, not on your normal quarterly cycle.

This kind of inventory-and-triage work is exactly what a structured vulnerability assessment and penetration test is designed to surface, instead of relying on someone remembering to check.

The objection: "We can't patch everything immediately"

Fair. Most IT teams are short-staffed, and patching production systems carries its own risk of breaking something. Two realistic fallbacks if immediate patching isn't possible:

Restrict exposure first, patch second. If you can't patch a vulnerable admin console today, you can usually take it off the public internet today: put it behind a VPN or restrict it to internal IP ranges. That single step closes off the most common exploitation path while you plan the patch.

Segment the blast radius. If a print server or similar tool doesn't need domain admin-level access to do its job, it shouldn't have it. Reducing its permissions won't stop an intrusion, but it limits what an attacker can do once they're in.

If your team doesn't have the bandwidth to track vendor advisories and triage this kind of risk on an ongoing basis, that's a program gap, not a one-time task. That's the problem managed security and virtual CISO support exist to close.

Treat "boring" as a category, not a one-off fix

The lesson from PaperCut isn't "patch PaperCut." It's that any internal tool can become the entry point, and the ones most likely to be missed are exactly the ones that feel too unimportant to review.

The fix is a habit: inventory internal apps, check exposure, confirm ownership, and treat vendor advisories for infrastructure tools with the same urgency as advisories for your core business software.

If you'd like a second set of eyes on what's quietly exposed in your environment, our free security review is a low-friction way to start. No pressure, just a clear picture of where you stand.

Originally published at sheersafe.com

The First Five Logs Worth Turning On With No Security Team

Sheer Safe — Mon, 24 Aug 2026 12:53:19 +0000

No SOC, no budget for tools yet? Turn on these five logs first — identity, admin actions, cloud API, endpoint, and network egress.

Before you buy a single security tool, turn on logging for five things: identity and authentication events, admin actions, cloud API activity, endpoint activity, and network egress. Most of the breaches a small IT team actually has to deal with leave a trail in one of these five places, and most cloud platforms give you the raw logs for free.

The gap usually isn't budget. Most of the time, nobody flipped the switch.

None of this requires a security operations center. It just means that if something goes wrong, you have evidence to work with instead of guesses.

Log 1: Identity and authentication events

Your identity provider (Microsoft Entra ID, Okta, Google Workspace) already logs every sign-in attempt. Most SMBs never turn on the audit or sign-in log export, or they turn it on and never look at it.

Decision rule: if you see a successful login from an unfamiliar country or an "impossible travel" pattern (same account, two locations, minutes apart) followed by a password reset or new device registration, treat it as a compromised account until proven otherwise. Lock it down first, investigate second.

This week: confirm sign-in logging is enabled and set a retention period long enough to look back at least a month. That's the minimum window most incidents take to surface.

Log 2: Admin actions

Authentication logs tell you who got in. Admin action logs tell you what they did with that access. Every major platform — your identity provider, your cloud console, your firewall — has an audit trail for privileged changes: new admin accounts created, MFA disabled, permissions escalated, firewall rules changed.

Decision rule: any MFA disablement, new admin or owner account, or permission escalation that happens outside a known change window is worth a five-minute check, every time. These are rare events in a healthy environment, which is exactly why they're cheap to monitor and expensive to ignore.

Log 3: Cloud API activity

If your infrastructure runs on AWS, GCP, or Azure, the platform is already recording every API call: who called it, from where, and what it changed. AWS CloudTrail, GCP Cloud Audit Logs, and Azure Activity Log are on by default in most accounts, but often not routed anywhere useful or retained long enough to matter.

This log category tends to reveal the most, and the fastest. In one engagement with a venture-backed technology company that had no dedicated security hire, a cloud security review across AWS and GCP surfaced more than 900 AWS findings and over 580 GCP findings once the logs and configurations were actually examined. Most of it was invisible until someone looked. Read more in the case study.

Decision rule: if you can't answer "who created or deleted this resource and when" within a few minutes, your cloud API logging isn't usable yet. Fix that before buying a cloud security tool on top of it. See our cloud security service for what a proper review looks like.

Log 4: Endpoint activity

You don't need a full EDR (Endpoint Detection and Response) platform to start. Windows Defender, macOS's built-in logging, and most modern OSes already capture process execution, new persistence mechanisms, and security tool tampering. You just need it centralized somewhere, even a simple log collector, instead of trapped on each individual machine.

Decision rule: treat any of the following as an automatic escalation, not a "look at it later" item: antivirus or EDR disabled without a ticket, a new scheduled task or startup item you didn't create, or an Office document spawning a command shell. These three patterns show up in a disproportionate number of real intrusions.

Log 5: Network egress

Inbound traffic gets all the attention. Outbound traffic, what's leaving your network, is where data theft and command-and-control activity actually show up. Firewall logs, VPC (Virtual Private Cloud) flow logs, and DNS (Domain Name System) query logs will tell you this if they're turned on and someone's watching for the obvious patterns.

Decision rule: flag large or unusual outbound transfers to destinations you don't recognize, and DNS lookups to newly registered or oddly-named domains. You don't need to catch every anomaly. You need to catch the two or three patterns that account for most real exfiltration attempts.

"We don't have anyone to actually watch these logs"

This is the honest objection, and it's fair. Turning on five logs doesn't help if nobody ever reads them. There are three realistic paths:

Set narrow, high-confidence alert rules (the ones described above) so you're only interrupted for things that genuinely matter, not every anomaly.
Do a scheduled weekly review instead of real-time monitoring. Slower, but far better than nothing, and manageable for a lean IT team.
Hand ongoing monitoring to a partner built for this. Our managed security service exists for exactly this gap — teams with real infrastructure and no bandwidth to watch it around the clock. If something does slip through, our incident response service picks up from there.

Whichever path you choose, the logs need to exist first. You can outsource watching them. You can't outsource having them.

Where to start this week

Confirm sign-in and admin audit logs are enabled in your identity provider, with at least a month of retention.
Turn on CloudTrail, Cloud Audit Logs, or Activity Log in every cloud account you run production in, and check they're not just enabled but actually routed and retained.
Centralize endpoint logs from every machine, even into a basic collector, rather than leaving them local.
Enable firewall and DNS logging for outbound traffic, and write down the two or three patterns you'd escalate on immediately.

None of this requires a big budget or a security hire. It requires someone to spend an afternoon flipping the right switches.

If you want a second pair of eyes on what's already on, what's missing, and what's worth fixing first, start with a free security review: no pressure, just a clear picture of where you stand.

Want this looked at for real? Get a free security review and we will show you where you actually stand.

Why Legacy Auth Fuels Mass Password Spraying

Sheer Safe — Thu, 20 Aug 2026 11:28:49 +0000

Legacy IMAP, POP3, and basic-auth sign-in paths let attackers skip multi-factor authentication (MFA) entirely, because those protocols predate MFA and many mail and identity systems still accept them by default. If any of these paths are open on your tenant, disable them this week. They're one of the most common ways a mass password-spraying campaign turns a handful of leaked passwords into a real breach.

Why legacy protocols skip MFA entirely

Modern sign-in flows (OAuth, modern authentication) can enforce a second factor and conditional access checks before granting access. IMAP, POP3, and basic auth were designed to send a username and password in one shot. There's no step where a challenge, push notification, or one-time code fits in.

So if legacy auth is still enabled anywhere on your tenant, an attacker who has your password doesn't need to defeat your MFA. They just walk in through a door that was never built to ask for it.

How mass password spraying scales through this gap

Attackers spraying passwords aren't guessing one account at a time. They take huge credential lists, usually assembled from unrelated breaches, and try a small number of common or reused passwords across thousands of accounts and domains.

They favour legacy auth endpoints for two reasons:

In many environments, these endpoints receive less rate-limiting and less monitoring than modern sign-in flows, since security tooling and alerting have typically been built around OAuth and conditional access, not older protocols.
A successful hit produces no MFA prompt, no push notification, no OTP request, so the account owner usually has no idea anything happened.

That gap means a spray campaign can succeed quietly against a slice of your organization's mailboxes without a single "approve this sign-in" alert ever firing.

Check this week: are you exposed right now?

Don't assume. Verify. Pulling and reviewing the right logs is a quick, well-scoped task for most IT teams, not a major project:

Microsoft 365 / Entra ID: pull sign-in logs and filter by client app. Look for IMAP4, POP3, Authenticated SMTP, or "Other clients." Any hits mean legacy auth is live.
Conditional access / Security Defaults: confirm a policy actually blocks legacy authentication. Having MFA enabled is not the same as blocking these protocols.
Google Workspace: check whether any organizational unit still allows "less secure app access" or basic-auth IMAP/POP.
On-prem Exchange or hybrid setups: legacy auth risk doesn't disappear just because you're not fully cloud-hosted. Check IIS/Exchange logs for IMAP4, POP3, and basic-auth SMTP AUTH entries, and confirm your hybrid connector isn't silently passing basic auth through to Exchange Online.
Other mail or identity providers: if you're not on Microsoft 365 or Google Workspace, ask your provider directly whether IMAP/POP/basic-auth sign-in is enabled by default and how to view a log of it. The exposure exists across most mail platforms; the audit trail just looks different.

No full admin log access? A lightweight check: try connecting to your own mailbox with an old-style email client using just a username and password. If it connects without any second-factor prompt, legacy auth is open on that account.

Decision rule: if legacy auth sign-ins show up anywhere in the last month of logs, treat it as active exposure, not a theoretical risk. Someone or something is using that door right now.

How to disable it without breaking the business

Legacy auth usually survives because IT teams worry about breaking an old scanner, a mail-merge tool, or a script nobody remembers writing. The phased rollout below avoids that problem, and most organizations can move through it in a matter of weeks rather than months:

Inventory first (days, not weeks). Use your sign-in logs to identify which accounts and apps are actually using legacy auth today.
Migrate what you can (roughly one to a few weeks). Move real users and supported apps to modern auth; for line-of-business tools, check for an updated connector or app-password option.
Block in phases (staggered over the following weeks). Start with a conditional access policy that blocks legacy auth for standard users, then extend it to service and shared accounts once you've confirmed nothing breaks.

Decision rule: if you can't identify a legitimate business reason for a legacy-auth connection within a short investigation, block it. Re-enable only if something breaks and you can name the owner and the reason. The cost of a forgotten integration is far lower than the cost of leaving a standing MFA bypass open.

What if you can't fully disable it yet

Sometimes a vendor is slow, or a piece of hardware (an old scanner, a legacy CRM sync) genuinely can't speak modern auth yet. That's a real constraint, not an excuse to leave it wide open. If you're stuck:

Restrict the legacy connection to a known IP range or location via conditional access, instead of leaving it open to the internet.
Put it on a dedicated service account with a long, unique password, and monitor its sign-ins specifically.
Set a hard retirement date. A temporary exception should have an end date attached to it, or it becomes permanent by default.

If you already suspect a spray has succeeded — unexplained sign-ins, forwarding rules you didn't set, mailbox rules that redirect finance emails — treat it as an active incident and get eyes on it fast.

In one engagement with a venture-backed technology company, fast-growing and without a dedicated in-house security hire, we contained an active intrusion while also running a broader AWS and GCP cloud security review, application and infrastructure penetration testing, and virtual CISO leadership. If you're in a similar position, our incident response service is built for exactly this kind of situation.

Make this part of an ongoing routine, not a one-off fix

Legacy auth has a way of quietly re-appearing: a new integration, a re-enabled setting after a tenant migration, a forgotten exception nobody closed out. Treat identity configuration as something to review on a schedule, not a box you tick once. Our managed security service is built around exactly that kind of ongoing, fix-first program rather than a one-time audit.

For background on requiring multi-factor authentication and reducing identity-based attack paths, CISA maintains guidance worth bookmarking on MFA.

Frequently asked questions

What is password spraying?
Password spraying is an attack technique where an attacker tries a small number of common or previously leaked passwords against a large number of accounts, rather than repeatedly guessing many passwords against one account. It's designed to avoid account lockouts while still finding the small percentage of accounts using weak or reused passwords.

Does turning on MFA automatically stop legacy auth attacks?
Not by itself. MFA has to be enforced on the sign-in path the attacker is using. Legacy IMAP, POP3, and basic-auth connections don't pass through the modern authentication flow, so they can bypass MFA entirely even when MFA is switched on for your organization. You need a separate policy that blocks legacy auth outright.

How do I know if legacy auth is actually being used in my environment?
Check your sign-in or authentication logs for the specific client app or protocol (IMAP4, POP3, Authenticated SMTP, "Other clients," or basic-auth entries in on-prem mail logs). If you don't have full admin log access, a simple test connection with an old-style mail client, as described above, will tell you quickly whether the door is open.

Is it safe to disable legacy auth for everyone at once?
It's safer to phase it: inventory first, migrate the accounts and apps you can identify, then block standard users before extending the block to service and shared accounts. That sequence surfaces the occasional forgotten integration before it becomes an outage, while still closing the gap in a matter of weeks.

If you want a fast, no-pressure look at whether legacy auth or other MFA gaps are open on your tenant right now, start with a free security review.

When a Vendor You Use Gets Breached: What to Do Next

Sheer Safe — Mon, 17 Aug 2026 12:47:41 +0000

When a vendor is breached, don't wait for their update page: figure out fast what that vendor can see or touch inside your business, and act on that answer before you have all the facts.

Vendor breaches are a recurring headline: a phone system, messaging platform, or file-sharing tool used by thousands of businesses discloses an incident, and every customer of that vendor suddenly has to ask what it means for them, usually with almost no visibility into the vendor's internal investigation. The gap between "something happened to our vendor" and "here's what we do about it" is where most companies lose time they can't get back.

Quick answers

What's the first thing to do when a vendor is breached?
Confirm exactly what that vendor can access in your systems — before you do anything else.

Should I rotate credentials before the vendor confirms exposure?
Yes, for anything plausibly exposed — even though it may briefly disrupt a live integration.

How often should I re-check a slow-to-disclose vendor?
It depends on how much access they hold — high-privilege vendors need a 48–72 hour check-in, not a week.

Do I need a written plan before an incident happens?
Yes — a one-page plan per privileged vendor, reviewed at least yearly.

Why vetting a vendor once isn't enough

Most businesses do vendor due diligence at signup: a security questionnaire, maybe a look at their trust page, a checkbox before the contract is signed. That's reasonable, but it only answers the question that matters on day one: is this vendor safe to start using?

It doesn't answer the question that matters every day after: if this vendor gets breached, what happens to us, and what do we do?

Vetting is a point-in-time filter. A breach is an ongoing event with a timeline, and your response needs its own plan, separate from the vetting checklist you ran before signing.

The fix is simple: treat vendor risk as a lifecycle, not a gate. Vet before you sign, revisit access and exposure on a regular cadence, and have a response plan ready for the vendors that matter most.

Your first 24–72 hours: a vendor breach checklist

When a vendor discloses an incident, work through this in order rather than waiting for their full report:

Confirm what the vendor actually does for you. List every system, integration, and data type connected to that vendor — not what you think it touches, but what it's actually configured to access.
Check what credentials or tokens are shared. API keys, SSO connections, webhooks, and stored payment or contact data are what attackers pivot on. Rotate anything that's plausibly exposed, even before the vendor confirms it was — accept that this may briefly break a live integration. That's a smaller cost than leaving a compromised credential live, but coordinate with whoever owns the integration so the break is expected, not a surprise outage.
Check what your contract actually gives you. Look for a breach notification clause (how fast the vendor is contractually required to tell you), any SLA language on incident disclosure, and a right-to-audit clause you can invoke to get more than their public statement offers. If your contract has none of these, that's a gap to fix at renewal — not something you can retrofit mid-incident.
Pull recent activity logs. Look for unusual logins, data exports, or configuration changes tied to that vendor's integration in the window since the breach likely started. Vendors often understate this window early on.
Loop in whoever owns customer communication and compliance. If customer or employee data may have moved through the vendor, your own notification obligations may kick in. Check what applies to your industry and state rather than assuming a fixed deadline.
Document the decision, not just the action. Write down what you knew, when, and why you chose to rotate credentials, pause the integration, or wait for more information. Log it in the same one-page plan or incident doc (see below), owned by whoever is running the response, and retain it for as long as your industry's record-keeping obligations require — this matters if a regulator or customer asks later.

If you don't have anyone in-house who can run this checklist under pressure, that's a gap worth closing before the next vendor incident, not during it. This is exactly the kind of work covered under incident response.

Figure out your actual blast radius

Not every vendor breach is your problem. A breach of a vendor's marketing database is very different from a breach of a vendor that holds your SSO tokens or has admin access to your cloud environment.

A simple heuristic: rank your vendors by what they can do, not what they cost. A vendor with write access to your infrastructure, your identity provider, or your customer data deserves an incident plan. A vendor that only has your name and email for a newsletter probably doesn't need the same level of response.

In one engagement, a venture-backed, fast-growing technology company with no dedicated security hire brought us in for a cloud security review across AWS and GCP, alongside manual application and infrastructure penetration testing and virtual CISO leadership. The review surfaced 900+ AWS findings and worked through 580+ GCP findings to remediation, brought endpoint EDR coverage to 100%, and — during the engagement — we identified and contained one active intrusion.

That containment was only possible because the access map already existed: we knew which systems, credentials, and integrations mattered before the intrusion turned up, which is exactly the map you need on hand before a vendor breach forces the same question about a system you don't control. Details are in our case study.

Build the plan before you need it

Handling a vendor breach well comes down to one thing decided in advance: who owns the call to cut a vendor's access, and how quickly that can actually happen on your systems. A vetting spreadsheet doesn't make that call under pressure — a named owner and a tested process do.

Here's a template you can copy directly, for any vendor with privileged access (identity, payments, cloud infrastructure, core communications):

Vendor Breach Response Plan — [Vendor Name]

Owner: [name/role] — the person authorized to cut access without a meeting
Access this vendor holds: [systems, data types, integrations, credential types]
Notify first, in order: [internal roles]
Immediate action: [specific credentials/integrations to rotate or disable]
Customer/compliance trigger: [conditions requiring external notification, and who drafts it]
Re-check date: [set explicitly — see blast-radius guidance below]

Format: one page, kept wherever your team already stores operational runbooks (shared drive, wiki, or IR tool) — not buried in email.

Owner: whoever holds the security lead or vCISO role keeps it current.

Retention: keep completed plans, with decisions logged, for as long as your compliance obligations require incident records to be retained; review the plan itself at least once a year or whenever the vendor relationship changes significantly — a new integration, more data, or a higher access level.

If you don't have the internal bandwidth to build and maintain this across a growing vendor list, a fractional security lead can own it without you hiring full-time. That's the core of what a virtual CISO does, and it pairs naturally with compliance support if notification obligations are part of the picture.

What if the vendor is slow or won't tell you anything?

This is the realistic failure mode, and it's common. Vendors under legal advice often say very little in the first days. Don't wait for their statement to act.

Work from what you control: rotate your own credentials and tokens regardless of confirmation (accepting the integration risk noted above), restrict the vendor's access to the minimum your operations can tolerate, and set a firm re-check date rather than "when they update us."

How firm depends on the same blast-radius logic from earlier: for a vendor with privileged access to identity, payments, or infrastructure, check back in 48–72 hours, not a week — that's the reason they landed in the high-risk tier in the first place. For a lower-access vendor, a week is a reasonable cadence.

If a high-access vendor stays silent past your re-check date, that silence is itself a decision point — consider suspending the integration until you get real answers.

The takeaway

Vendor breaches are going to keep happening. That's the reality of running a business on other people's software. What separates a bad week from a bad year is whether you had a response plan sitting ready, or whether you're building one from scratch while the news is still breaking.

If you're not sure how exposed your business is to your current vendor stack, a good starting point is a free security review. It's a low-friction way to see where your real access risks sit before you need to react to one.

Want this looked at for real? Get a free security review and we will show you where you actually stand.