Cyber Advisors Blog

Security Metrics That Matter: Reporting Risk Reduction

gbaruck@edotholdings.com (Glenn Baruck) — Thu, 30 Apr 2026 12:15:00 GMT

Executives don’t want a list of tools—they want evidence that risk is going down. Security leaders in SMB and mid-market organizations feel this tension constantly. Your team might be patching systems, tightening identity controls, backing up critical data, and training users. But when it’s time to brief the CEO, CFO, or board, the conversation often collapses into one of two unhelpful extremes:

A “security theater” slide deck full of technical jargon and tool screenshots, or
A vague, anxiety-provoking status update like “we’re seeing more threats” with no clear business meaning.

Neither builds confidence. Neither supports smart investment decisions. And neither helps leaders understand whether the organization is actually becoming more resilient.

What to Log: Practical Log Retention for Investigation and Compliance

gbaruck@edotholdings.com (Glenn Baruck) — Tue, 28 Apr 2026 12:15:00 GMT

During an incident, the first question is usually “what happened?”—and the second is “do we still have the logs?” If you’ve ever tried to reconstruct a timeline from partial records, you know the pain: a VPN log that rolled over last week, a mailbox audit trail that was never turned on, a firewall that only keeps 7 days of events, and an endpoint that was reimaged before anyone exported telemetry.

Data Classification for SMBs: A Simple Model That Makes DLP Actually Work

gbaruck@edotholdings.com (Glenn Baruck) — Wed, 22 Apr 2026 12:15:00 GMT

Most data loss prevention (DLP) programs fail for a simple reason: the organization never agreed on what “sensitive” means. This guide gives SMBs a practical 3–4 tier classification model and shows how to map labels to controls so DLP and compliance actually work in day-to-day operations.

Why classification is the foundation of DLP

DLP tools are rule engines. They need a clear signal to decide what to allow, block, encrypt, quarantine, or alert on. Without classification, DLP has to “guess” sensitivity using content patterns and generic rules. That creates three predictable problems:

DLP only finds a fraction of your sensitive data. Pattern matching catches obvious identifiers, but it won’t reliably identify contracts, HR investigations, legal strategy, customer lists, or product designs.
False positives destroy confidence. If DLP blocks legitimate work or warns constantly, users stop trusting it and create workarounds—often increasing risk.
IT becomes the bottleneck. Without a shared model, every DLP decision becomes an argument. Classification creates shared language, aligns business impact to controls, and turns compliance into daily behavior.

A simple 3–4 tier classification model for SMBs

Your scheme must be small enough for people to remember. Most SMBs can get excellent results with three or four tiers:

Tier 1: Public

Definition: Approved for public release.

Examples: Marketing materials, published content.

Handling: Share freely; protect integrity (who can edit/publish).

Tier 2: Internal

Definition: For employees and approved partners, not for broad distribution.

Examples: Internal process docs, general meeting notes.

Handling: Keep in approved corporate systems; authenticated access; avoid “anyone with the link.”

Tier 3: Confidential

Definition: Significant harm if disclosed.

Examples: Customer lists, pricing, contracts, non-public financials, HR records.

Handling: Need-to-know access; external sharing limited and monitored; stronger retention + logging.

Tier 4: Restricted (optional but recommended)

Definition: Severe harm if disclosed or altered.

Examples: Secrets/credentials, incident investigation files, board materials, regulated high-risk datasets.

Handling: Strict least-privilege; approvals for access/sharing; enhanced monitoring; strong device requirements.

Quick decision checklist

Would it hurt us if this were public? (No → Public; minor → Internal; significant → Confidential; severe → Restricted)
Is it regulated or contractually protected? (Usually Confidential/Restricted)
Does it include secrets, privileged material, or sensitive personal info? (Often Restricted)
Do we need to limit access to a small group? (Confidential/Restricted)

Common failure modes & how to avoid them

Too many labels: Keep it to 3–4.
No ownership: Assign data owners for major categories (HR, Finance, Sales Ops, Legal, IT/Security).
Unclear handling rules: Publish a one-page matrix and train from it.
Users do all the work: Use a hybrid approach: automate + prompt + accountable overrides.
Controls don’t match business impact: Restrict only what truly needs it.
No measurement: Track policy hits, false positives, overrides, and leakage events.

Examples of what belongs in each tier

Public

Website copy, brochures, and published case studies
Press announcements
Public webinars and decks

Internal

Internal “how-to” docs without credentials or client-sensitive details
Routine project plans and meeting notes
Internal training materials

Confidential

Proposals, quotes, pricing sheets
Customer contracts and contact lists
HR records (investigations, benefits enrollment)
Forecasts, budgets, and non-public financial reporting
Detailed security documentation (depending on sensitivity)

Restricted

Passwords, keys, certificates, vault exports, secrets
Security incident details and investigation notes
Board packets, legal privilege documents, M&A planning
Regulated datasets with high-impact exposure risk

Tip: Publish a short “by department” example list (Sales, HR, Finance, IT, Legal). That’s what drives adoption.

How to label & handle data: people + process + tools

Define scope: Start with 5–10 high-risk categories (contracts, customer lists, HR records, secrets, etc.).
Assign owners and stewards: Data owners decide; IT/security implements and tunes; compliance/legal validates.
Create a handling matrix: Storage, sharing, access, transmission, protection, retention.
Choose a labeling approach: Hybrid works best for most SMBs (auto-label obvious, prompt likely, accountable overrides).
Use your existing platform: Microsoft 365 or Google Workspace can usually cover v1 if configured well.

Map each tier to controls

IDENTITY & ACCESS

MFA for everyone (baseline)
Conditional/context-aware access for Confidential/Restricted
Group-based permissions and regular access reviews for sensitive repositories

Sharing

Internal: Default to org-only sharing; discourage anonymous links
Confidential: Authenticated links, expirations, partner-domain limits
Restricted: External sharing prohibited by default; approvals + managed devices

Encryption & protection

Verify encryption in transit and at rest
Use label-based protections where available (forward/print limits, view-only, re-auth prompts)

Endpoint controls

Baseline: device encryption, patching SLAs, screen locks
Confidential/Restricted: EDR, device compliance checks, restrict access from unmanaged devices

Monitoring & response

Enable audit logs and retain long enough to investigate
Alert on high-signal events (anonymous links, personal-domain sharing, mass downloads)
Tie Restricted events to incident response playbooks

High-signal policies to implement first

Stop anonymous links for Confidential/Restricted
Control external sharing by domain
Block Restricted exfiltration paths (personal email, public links, unmanaged devices)
Detect “mass behavior” (downloads, link creation, unusual sign-ins)

A practical handling matrix (what “different” actually means)

The most useful artifact in a classification program is a one-page handling matrix. It prevents endless debates and gives users a fast answer. Adapt the following to your tools and risk tolerance.

Storage

Public: Approved publishing repositories
Internal: Corporate cloud storage only
Confidential: Restricted sites/drives; avoid unmanaged local storage
Restricted: Dedicated restricted repositories or vaults

Sharing

Public: Share publicly
Internal: Internal sharing; partners as needed; avoid anonymous links
Confidential: Authenticated links + expiration; partner-domain limits
Restricted: Prohibited by default; approvals + secure transfer

Email and messaging

Confidential: Prefer links; warn/block outbound to personal domains
Restricted: Do not email as attachments; use approved secure methods

Device requirements

Confidential: Compliant devices for download; EDR required
Restricted: Managed devices only; restrict copy/paste/download where supported

Tip: Make the default label Internal for new documents/emails to reduce accidental oversharing.

Who decides what’s sensitive: data owners, policy owners, & IT

Data owners (business): Define what’s Confidential/Restricted and approve exceptions.
Security/IT: Implement controls, monitor/tune policies, provide safe alternatives.
Compliance/legal: Validate regulatory mapping, retention, and audit evidence.

Microsoft 365 & Google Workspace: keep the user experience simple

Microsoft 365 (Purview labels + DLP)

Create only 3–4 labels with short tooltips.
Start with label-based DLP rules (e.g., Confidential → warn/block anonymous links).
Use auto-labeling carefully: automate high-confidence, recommend for moderate confidence.
Control the biggest leakage paths first (links, personal domains, auto-forwarding, unmanaged devices).

Google Workspace (Drive/Gmail DLP)

Map your handling matrix to Drive/Gmail policies (policy-first approach).
Restrict risky sharing defaults (“anyone with the link”).
Use strong-signal DLP rules validated in a pilot.
Provide a safe alternative when blocking to prevent shadow IT.

Turning tiers into DLP policy: a control-by-control mapping

Use this as a roadmap. You don’t need everything on day one.

Identity controls

Internal: MFA; block legacy auth
Confidential: Conditional access; MFA re-prompts for high-risk actions
Restricted: Separate admin accounts; privileged access; just-in-time access; frequent reviews

Sharing controls

Internal: Org-only links; warn on anonymous link creation
Confidential: Authenticated links + expirations; partner-domain allowlist
Restricted: Disable public/anonymous; block external unless exception-approved; managed devices only

Email controls

Confidential: Warn/block to personal domains; prefer links over attachments
Restricted: Block outbound attachments; require secure transfer methods

Endpoint controls

Confidential: EDR; restrict unmanaged device downloads
Restricted: Managed-only; restrict removable media; monitor exports where relevant

Monitoring controls

Confidential: Alerts for unusual sharing, mass downloads, risky sign-ins
Restricted: High-priority alerts + incident response steps; automated containment where feasible

Common scenarios & how the model resolves them

Sales sharing a proposal: Usually Confidential → authenticated link + expiration; avoid attachments.
HR sharing benefits files: Confidential/Restricted → approved partner domain or secure transfer.
Passwords in spreadsheets: Restricted → move to a credential vault; enforce via policy.
Board materials: Restricted → view-only, managed devices, no forwarding/printing.
Vendor collaboration folder: Internal/Confidential → dedicated shared space, partner restrictions, minimal access.

How to keep productivity high while tightening controls

Default to safe collaboration (Internal defaults, org-only sharing).
Block only the highest-risk actions first; warn/justify for Confidential early on.
Provide an approved alternative every time you block something.
Measure friction as seriously as risk; tune noisy policies.
Treat exceptions as data; repeated exceptions indicate a workflow you should formalize.

Compliance & audit evidence

Classification makes audits easier because you can show:

Documented classification standard + handling matrix
DLP and sharing policy settings
Access control and conditional access evidence
Logging/monitoring evidence and incident response linkage
Training records, exceptions with audit trail, and monthly review cadence

Quick-start: the first 30 days

Days 1–5: Align on the model

Choose 3–4 tiers and definitions
Identify 5–10 high-risk data categories
Assign data owners
Draft the one-page handling matrix

Days 6–10: Baseline guardrails

MFA everywhere
Sharing defaults that reduce anonymous exposure
Enable audit logging and confirm retention

Days 11–15: Configure labels & pilot

Create labels/categories
Start DLP in audit/warn mode
Pilot with Sales + HR + Finance

Days 16–20: Tune

Review hits and false positives
Adjust rules and exception workflow
Publish cheat sheet + short training

Days 21–30: Selective enforcement + expand

Enforce authenticated sharing for Confidential/Restricted
Block the highest-risk Restricted actions first
Expand to all users; schedule monthly reviews

Momentum matters: a practical v1 beats a perfect plan that never ships.

What success looks like (simple metrics)

Policy hits by tier (are we seeing sensitive data where we expect it?)
User overrides/downgrades (are policies too strict or labels unclear?)
Anonymous links created (near-zero for Confidential/Restricted)
External shares to unapproved domains (down and trending down)
Confirmed exposure events and time to detection (fewer, faster)

CYber Advisors Can Help

If you want DLP and compliance controls to actually work, classification has to be practical, owned by the business, and mapped to concrete, real-world controls—not just turned on in a console and forgotten. That means your labels must be simple enough for employees to use correctly under pressure, clearly defined so that business owners—not just IT—can decide what belongs in each tier, and tightly linked to specific actions, such as who can share, how data can be sent, and what happens when something goes wrong. When classification is treated as an operational standard instead of a one-time configuration, your DLP policies stop guessing, false positives drop, and the controls you pay for start driving consistent, auditable behavior across the organization.

Cyber Advisors helps SMBs and mid-market organizations reduce risk without slowing the business. We can help you:

Define a right-sized 3–4 tier classification model tailored to your workflows
Identify your highest-risk data types and map them to handling rules
Configure and tune Microsoft Purview sensitivity labels + DLP (or Google Workspace DLP)
Reduce oversharing with secure sharing defaults, conditional access, and identity hardening
Operationalize with training, exception workflows, and measurable metrics
Connect classification to incident response and ongoing managed security monitoring

If your current DLP program feels noisy, ineffective, or constantly bypassed, it’s usually not because the tool is wrong—it’s because the organization never agreed on “what sensitive means.” Fix that, and the rest gets much easier.

Get Help Today!

Passwordless for SMB: Passkeys, Phishing-Resistant MFA, & How To Start

gbaruck@edotholdings.com (Glenn Baruck) — Mon, 20 Apr 2026 12:15:00 GMT

Passwords are still the easiest way into most small and mid-size environments—not because teams don’t care, but because the tools and priorities haven’t been clear. Attackers routinely steal credentials through phishing, password reuse, and MFA push fatigue, then pivot into email, admin portals, and SaaS apps. Passkeys and other phishing-resistant methods change the game by making “captured credentials” far less useful. In this guide, we’ll demystify passkeys/FIDO2, explain what to roll out first, and share a rollout approach that strengthens security without overwhelming users or the help desk.

Why passwords (& basic MFA) keep failing for SMBs

If you’re an SMB or mid-market IT leader, you already know the pattern: a user clicks a convincing link, enters credentials into a look-alike page, and suddenly you’re dealing with suspicious sign-ins, mailbox rules, and “urgent” payment requests. Even organizations with MFA enabled can still lose accounts because most “everyday” MFA methods can be tricked, bypassed, or worn down.

How attackers steal creds: phishing, reuse, spray, & MFA fatigue

Attackers don’t need to “hack” a password if they can convince a user to hand it over—or if the password is already floating around in a breached dataset. The most common credential attack paths we see include:

Phishing kits that proxy real login pages and capture usernames, passwords, and one-time codes in real time.
Password spraying (trying common passwords across many accounts) and credential stuffing (reusing leaked credentials).
MFA push fatigue where users approve repeated prompts to make the prompts “stop.”
Help desk social engineering that results in an attacker resetting MFA or initiating account recovery.
Session/token hijacking (more on that later) that can bypass MFA entirely once a session is established.

The common thread is simple: if authentication relies on something that can be captured and replayed (a password, a code, a prompt approval), attackers will build workflows to capture and replay it at scale.

Where SMBs are most exposed: email, remote access, & admins

Most credential-based incidents in SMB environments follow a similar path:

Entry via a user mailbox, cloud identity, or remote access portal (VPN/VDI/RDP gateways).
Persistence via mailbox rules, OAuth app consent abuse, or additional MFA methods added by the attacker.
Privilege escalation by targeting admin accounts, password reset flows, or misconfigured roles.
Lateral movement into file shares, line-of-business apps, HR/finance systems, or other SaaS.
Monetization via business email compromise (BEC), ransomware, data theft, or extortion.

The “high-value” accounts are predictable: global admins, application admins, finance leaders, executives, and anyone with access to remote admin tools. That’s why your rollout order matters. You’ll get outsized risk reduction by moving privileged and high-risk accounts to phishing-resistant methods first.

What “phishing-resistant” actually means

“Phishing-resistant” is a specific claim, not a marketing phrase. In practice, phishing-resistant authentication methods are designed so that even if a user is tricked into interacting with a fake login page, the attacker can’t capture a secret that they can reuse elsewhere.

Passkeys (based on WebAuthn/FIDO2) are phishing-resistant because they rely on public-key cryptography and origin binding. That means the credential can’t be replayed to a different site, and the “secret” (private key) never leaves the user’s device. Many security keys provide similar protections because they won’t complete an authentication ceremony for the wrong domain.

Action step: Identify your three highest-risk entry points (typically Microsoft 365/Google Workspace, remote access, and admin portals) and list the users/roles that touch them. That list becomes your Phase 1 rollout group.

Passkeys/FIDO2 in plain English

Passkeys are the most practical “passwordless” evolution in years because they can improve security and reduce user friction. But the terminology gets in the way—WebAuthn, FIDO2, authenticators, synced vs. bound, resident keys. Let’s make it simple.

Passkeys vs passwords vs OTP codes

Think of common authentication methods as answers to one question: “How do we prove you’re you?”

Method	What the user provides	What attackers can steal	Phishing-resistant?	Best use
Passwords	Something you know	Password (reusable)	No	Legacy apps only (minimize)
OTP codes (SMS/app)	Code (time-based or SMS)	Code (often replayable in real time)	Usually no	Baseline MFA when nothing else is available
Push prompts	Approve/deny prompt	Approval via fatigue/social engineering	No	Use with number matching + strict policies, not alone
Passkeys (FIDO2/WebAuthn)	Biometric/PIN to unlock device-based key	Not a reusable secret	Yes	Modern apps and identity providers
Hardware security keys	Touch key + (sometimes) PIN	Not a reusable secret	Yes	Admins/high-risk users, break-glass controls

The important difference: with passwords and many MFA codes, the user types something into a page. With passkeys, the user approves a cryptographic challenge on a trusted device, and the device proves possession of a private key without sharing it.

WebAuthn/FIDO2 basics & why phishing fails

Passkeys are built on standards:

WebAuthn (Web Authentication) is the web standard that browsers use to talk to authenticators.
FIDO2 is the broader set of standards that includes WebAuthn plus the client-to-authenticator protocols.

When a user registers a passkey with a site (or an identity provider like Microsoft Entra ID), the device creates a unique key pair for that site. The site stores the public key. The device keeps the private key protected by its security model (biometrics/PIN, secure enclave/TPM, etc.).

During login, the site sends a challenge. The device signs it with the private key and returns a signature. The site verifies it with the public key. A phishing site can’t “steal” the private key, and because WebAuthn is bound to the legitimate origin, a look-alike domain can’t successfully request the same credential.

Synced passkeys vs device-bound keys: tradeoffs

Passkeys often come in two practical flavors:

Synced passkeys (cloud-synced via a platform credential manager) are easier for users because they work across a user’s devices (e.g., phone and laptop) and can be restored if a device is replaced.
Device-bound (non-syncable) keys are typically associated with hardware security keys or device-specific credentials. They can be more controlled for admins, but require clearer lifecycle planning (spares, replacements, recovery).

For SMBs, a blended approach usually wins: use synced passkeys for broad adoption and ease of use, and use hardware security keys for admins and the most sensitive workflows.

Action step: Choose your default “user-friendly” method (often synced passkeys) and your “high-assurance” method (hardware security keys) before you write policies. Your policies should reinforce—not fight—your chosen defaults.

Phishing-resistant MFA options you can deploy today

“Passwordless” doesn’t have to mean a single method, flipped on overnight. In the real world, you’ll deploy a set of phishing-resistant options and then apply them intelligently by role, device posture, and risk. Here are the most practical options for SMB and mid-market environments.

Platform passkeys (Windows Hello, Apple, Android)

Platform passkeys use a device’s built-in security features—think Windows Hello on modern Windows devices (often backed by TPM), and passkeys stored in Apple or Android ecosystems. The benefits are significant:

Low friction: users already unlock devices using biometrics or PINs.
Reduced phishability: the private key never leaves the device, and auth is origin-bound.
Fewer resets: fewer “I forgot my password” tickets once adoption is high.
Better user acceptance: it feels modern, fast, and familiar.

The main considerations are device management and consistency. If your environment includes both managed and unmanaged devices, you’ll need Conditional Access (or equivalent) policies to ensure passkeys are used in line with your risk tolerance.

Security keys for admins & high-risk users

Hardware security keys (often called FIDO2 keys) are a strong fit for:

Global admins and privileged roles
IT staff who can approve access and perform resets
Finance leaders and executives who are common BEC targets
Users with elevated access to sensitive SaaS or critical data stores

Keys are also an excellent “hard stop” against remote phishing and MFA fatigue because the attacker can’t approve a prompt by annoying a user. The user needs the physical key (and often a PIN) to complete the login.

Practical tip: issue two keys per admin—one primary, one stored as an emergency spare—and make key registration part of your onboarding/checklist for privileged access.

Certificate/device-based & biometrics (when appropriate)

In some environments, device certificates or strong device-based signals can meaningfully reduce risk—especially when combined with conditional access. However, device-based trust is not a replacement for phishing-resistant user authentication. Instead, think of it as a multiplier:

Compliant device + phishing-resistant sign-in is stronger than either control alone.
Risk-based policies can step up requirements only when needed (new device, risky sign-in, unfamiliar location).
Legacy constraints (older apps) may require transitional controls until modernization is complete.

Action step: Create a short “authentication standards” chart for your org: which roles require security keys, which roles can use platform passkeys, and which legacy apps require transitional MFA methods—and for how long.

Readiness checklist before you flip the switch

Most passwordless initiatives fail for one of two reasons: (1) the technology is turned on before the prerequisites are ready, or (2) the rollout is treated like a policy change instead of a user experience change. Use this readiness checklist to avoid the most common breakpoints.

Identity provider support (Entra ID/Okta/etc.)

Your identity provider is the control plane for passwordless authentication. Before you start:

Confirm passkey/FIDO2 support for your tenant and licensing level.
Standardize authentication methods (remove weak options where possible; define approved methods).
Review conditional access capabilities (device compliance, location, risk signals, app-specific policies).
Document break-glass/admin recovery flows that do not rely on easily-phished methods.

If you’re a Microsoft 365 organization, plan to align passkey rollout with Microsoft Entra ID authentication method policies and Conditional Access. If you use Okta or another IdP, map equivalent controls and confirm your application integration patterns.

Device & browser compatibility

Passkeys depend on modern OS and browser support. Compatibility questions that matter:

Are user devices on supported OS versions (Windows, macOS, iOS, Android)?
Do you have a standard browser baseline (Edge/Chrome/Safari) and update policy?
Are users signing in from managed devices, BYOD, or a mix?
Do remote/VDI workflows change how passkeys are presented and used?

If device management is inconsistent, don’t stall the whole program—just define where stronger policies apply first (admins, high-risk apps, managed endpoints) and progressively expand.

Legacy apps & protocols that will break

The number one technical reason passwordless rollouts stumble is legacy authentication. Examples include older email clients, basic authentication protocols, legacy VPN portals, and apps that don’t support modern auth.

Your goal is to identify these before you force enforcement. For each legacy dependency:

Determine the owner (business unit, vendor, internal app team).
Assess replacement options (upgrade, modern auth integration, SSO enablement).
Apply compensating controls temporarily (restricted access, strict conditional access, monitoring, segmentation).
Set a sunset date so exceptions don’t become permanent.

Action step: Run a 2-week “auth dependency discovery” sprint: export sign-in logs, identify legacy protocols/apps, and categorize them into (A) ready now, (B) needs change, (C) replacement required.

What to roll out first: a practical rollout order

The fastest path to reducing credential theft is not “turn on passkeys for everyone.” It’s rolling out phishing-resistant authentication in the order that removes the highest-impact attack paths first. Here’s the rollout order we recommend for most SMB and mid-market organizations.

1) Admin & privileged accounts

Start with the accounts that can change everything: global admins, privileged role holders, and IT staff who can reset passwords, approve access, or modify authentication methods. For this group:

Require phishing-resistant MFA (preferably hardware security keys).
Enforce separate admin accounts (no daily driver admin use).
Require managed devices for access to the admin portal.
Restrict admin access by location and device compliance (where feasible).
Implement just-in-time (JIT) privilege elevation if available (reduce standing privilege).

This phase alone can materially reduce the likelihood that an initial compromise turns into a full tenant takeover.

2) Remote access / VPN / VDI / critical SaaS

Next, move the doors attackers actually use to enter: remote access portals, VPN/VDI, and your most critical SaaS apps. Ideally, these are fronted by your identity provider with modern auth and conditional access.

If some remote access systems can’t support passkeys immediately, don’t accept that as “good enough” forever. Use compensating controls (strict access policies, segmentation, logging, and monitoring) and plan modernization.

3) Finance/HR & executives

Finance and HR are high-value targets for BEC and fraud. Executives are frequently targeted because their accounts have “approval” power. For these groups:

Prioritize phishing-resistant sign-in for email and collaboration tools.
Review inbox rules, forwarding, and OAuth app consent permissions.
Enable step-up requirements for high-risk actions (new payee, external forwarding, admin consent requests).

4) Everyone else (with staged enforcement)

Once the high-risk groups are stable and you’ve learned from real user behavior, expand to the rest of the org using stages:

Registration campaign (users enroll passkeys with clear instructions and support).
Optional use (users can choose passkeys, but a password fallback is available).
Preferred use (passkeys are encouraged and made the default, where possible).
Enforced use (passwordless required for defined apps/contexts; exceptions are time-limited).

Action step: Define your Phase 1 group (admins), Phase 2 group (remote access + critical SaaS), Phase 3 group (finance/HR/executives), and a timeline for broad rollout. Put dates on each phase—even if they shift—so the program keeps moving.

Policy design: make the secure path the easy path

A passwordless initiative is a policy initiative, but it should feel like a usability upgrade to end users. The most successful programs create policies that guide users to the safest path by default—without surprises.

Conditional access: require compliant device + strong auth

Conditional Access (or equivalent controls) lets you apply “stronger requirements” only where they matter most. A pragmatic approach:

Admins: require managed device + phishing-resistant MFA; restrict access to admin portals.
High-risk apps: require phishing-resistant MFA for sign-in and re-auth.
External access: step up requirements for new locations, unfamiliar devices, or risky sign-ins.
Legacy exceptions: isolate with narrow scopes and explicit expiration dates.

Be careful with policies that are “too clever.” Complexity can create gaps and help desk headaches. Fewer well-documented policies with clear testing are better than dozens of overlapping conditions.

Registration campaigns, grace periods, & exclusions

Adoption matters. Users need time and clear prompts. A good campaign includes:

Lead time: “Here’s what’s changing and why” at least 2 weeks in advance.
Simple enrollment: a short guide, screenshots, and a 2-minute video if possible.
Grace period: allow users to enroll before enforcement begins.
Office hours: set times for live help to reduce ticket backlog.
Targeted outreach: follow up with users who haven’t enrolled before enforcement.

Exclusions should be rare and visible. If you must exclude a user or app, require documentation: who approved it, why it’s needed, and when it will be removed.

Account recovery that doesn’t reintroduce risk

Recovery is where security often collapses. If an attacker can “recover” an account with a help desk call, your passwordless effort can be undone. Strengthen recovery by:

Requiring strong identity verification for resets (especially for privileged accounts).
Providing secure backup methods (e.g., spare security key, managed device flows).
Limiting who can perform sensitive resets and adding auditing and approvals.
Using temporary access passes or time-limited recovery methods where available, with strict controls.

Action step: Write a one-page “Passwordless Policy” that includes: approved methods, required methods by role, exceptions process, and the recovery workflow for standard users vs. privileged users.

User comms + training that reduce help desk tickets

Your users don’t need a cryptography lesson. They need to know what’s changing, why it matters, and how to succeed without getting stuck. When communication is clear, tickets drop dramatically.

“What will change” message templates

Use a short, direct message. Here’s a template you can adapt:

Subject: A faster, safer sign-in is coming (passkeys)

Over the next few weeks, we’re rolling out passkeys—a simpler way to sign in that reduces phishing risk. Passkeys replace passwords with a secure sign-in using your device (Face ID/Touch ID/Windows Hello or a security key). You’ll get a prompt to set up your passkey. Setup takes about 2 minutes.

When: Enrollment opens on [date]. Enforcement begins for [group/app] on [date].
What you need: Your laptop and/or phone, and 2 minutes to complete setup.
Help: Visit [internal link] or join office hours [dates/times].

How to handle new device enrollment

Device lifecycle is normal: new laptops, phone upgrades, replacements. Plan for it:

Encourage two methods for users where appropriate (e.g., passkey + backup method).
Document the “new device” path in plain language: what users do, what IT does, and expected timing.
Standardize enrollment during onboarding and device refresh cycles.
Make recovery secure and predictable (avoid ad hoc exceptions).

Phishing-resistant habits & reporting

Passkeys reduce one category of risk, but they don’t eliminate social engineering. Train users to:

Report suspicious emails and sign-in prompts immediately.
Pause before approving any “unexpected” auth action.
Watch for “consent” prompts to new apps and report them if unexpected.
Use official bookmarks or trusted portals to access key apps.

Action step: Create a single internal page titled “Passkeys: Setup, New Device, and Help” and include it in every comms message. Repetition reduces tickets.

How to measure success & catch gaps

If you can’t measure it, you can’t manage it. Measuring a passwordless rollout is not just about adoption; it’s about understanding where users fall back to weaker methods and where attackers still try to get in.

Auth method adoption & fallback rates

The core metrics to track:

Passkey registration rate: % of targeted users enrolled.
Passkey usage rate: % of sign-ins using passkeys vs. passwords/other methods.
Fallback triggers: why users reverted (device incompatibility, app limitations, confusion).
Help desk volume: tickets per 100 users during rollout.

Fallback is not failure—fallback is feedback. If a specific app or workflow forces fallback, that’s your next modernization target.

Admin sign-ins & risky sign-in trends

Privileged sign-in telemetry is an early warning system. Monitor:

Admin sign-ins from non-compliant devices
Admin sign-ins from new countries or unusual locations
Repeated sign-in failures for privileged accounts
New MFA methods added to privileged accounts

If you’re using identity protection/risk signals, track how often risky sign-ins occur and how often policies successfully block or step up authentication.

Top blocked attempts & lessons learned

A successful rollout should show a measurable increase in:

Blocked sign-ins from suspicious sources
Denied access due to device non-compliance (where enforced)
Reduced password-based sign-ins to critical apps

Pair these metrics with a quarterly review: which apps still allow password sign-in, which users remain on exceptions, and where you can tighten controls without breaking workflows.

Action step: Schedule a 30-day and 90-day “Passwordless Health Check” to review adoption, exceptions, and risky sign-ins—then update your rollout plan accordingly.

Common pitfalls & how to avoid them

Most passwordless programs stumble in predictable ways. The good news: these pitfalls are avoidable if you plan for them up front.

Shared accounts & break-glass access

Shared accounts are dangerous because you can’t reliably attribute actions to a person, and they’re often protected with weak or reused credentials. Replace shared accounts with named accounts and role-based access wherever possible.

You will still need break-glass access—just do it deliberately:

Create two break-glass accounts with long, unique credentials and store them in a secure vault.
Restrict their use and monitor sign-ins aggressively.
Do not use them for daily administration; they exist for outages and emergency recovery only.
Test the process quarterly so it works when you need it.

Over-permissive exceptions

Exceptions are where attackers live. If an app or user is excluded from strong authentication indefinitely, your defenses have a permanent hole. Fix this by:

Requiring business justification and security review for exceptions.
Applying the minimum scope necessary (specific app, specific user group, specific condition).
Setting an expiration date and assigning an owner who must remove it or renew it with justification.
Monitoring exception usage and alerting on suspicious behavior.

Ignoring SaaS apps outside SSO

Many SMBs secure Microsoft 365 (or Google) but forget the dozens of other SaaS apps where passwords still rule. Attackers know this, and they’ll pivot to weaker apps to regain access or steal data.

To avoid this:

Inventory SaaS apps and prioritize those with sensitive data or financial workflows.
Bring apps under SSO where possible.
Require phishing-resistant auth for high-risk SaaS sign-ins.
Monitor OAuth/app consents and suspicious access patterns.

Action step: Build a “Top 20 SaaS” list and score each app on sensitivity and authentication strength. Tackle the highest-risk apps first by enabling SSO and stronger authentication.

Putting it all together: a 30-day passwordless rollout plan for SMB

If you want a simple starting point, here’s a practical 30-day plan you can adapt. The goal is to create momentum, reduce high-impact risk quickly, and avoid a drawn-out rollout that loses urgency.

Days 1–7: Assess and prepare

Identify Phase 1 users: admins and privileged roles.
Review sign-in logs for legacy protocols and risky sign-in patterns.
Confirm device readiness and standardize browser baselines.
Draft policies: approved auth methods, conditional access approach, recovery workflows.
Prepare a communication plan and an internal setup page.

Days 8–14: Pilot with admins

Enroll admins with hardware security keys (and spares).
Enforce phishing-resistant auth for admin portals and privileged actions.
Test recovery workflows and document the “what if” scenarios.
Refine policies based on real admin experience.

Days 15–21: Expand to remote access & critical SaaS

Apply stronger policies to VPN/VDI/remote access or front them with SSO where possible.
Enable passkeys for critical SaaS applications under your IdP.
Begin a registration campaign for the next targeted group (finance/HR/executives).

Days 22–30: Targeted business groups & staged broader adoption

Enroll finance/HR/executives; tighten protections for email and high-risk workflows.
Launch staged adoption for the wider user base: register → optional → preferred.
Measure adoption and help desk volume; adjust communications and training.
Document exceptions and set expiration dates.

After day 30, the job shifts from “rollout” to “optimization”—driving down password usage, reducing exceptions, modernizing legacy apps, and continuously monitoring risky sign-ins.

Trust Cyberadvisors, we've helped many organizations just like yours

Cyber Advisors helps SMB and mid-market teams take the guesswork out of going passwordless—starting with a clear assessment of your current password policies, MFA methods, sign-in logs, and “high-risk” access paths (email, admin portals, remote access, and critical SaaS). We translate those findings into a practical rollout plan—phishing-resistant authentication for admins first, staged adoption for users, and Conditional Access policies that make the secure path the easiest path—so you reduce credential theft quickly without disrupting day-to-day work.

Next steps: book a 30-minute Passwordless Readiness Review

Passwordless doesn’t have to be disruptive. With the right rollout order, strong policies, and clear user communication, SMBs can quickly reduce credential theft—without drowning the help desk or disrupting business workflows. If you want a fast, practical plan tailored to your environment, we can help.

VMware in 2026: Hybrid Cloud, Private Cloud Modernization, & AI-Ready Infrastructure

gbaruck@edotholdings.com (Glenn Baruck) — Wed, 15 Apr 2026 12:15:00 GMT

Private cloud is back—modernized. Hybrid cloud is maturing—operationally. And AI is forcing infrastructure teams to rethink performance, governance, and cost. Here’s how to make VMware a platform for measurable outcomes in 2026.

Top 10 Signs You Need a Pen Test

gbaruck@edotholdings.com (Glenn Baruck) — Tue, 14 Apr 2026 12:30:02 GMT

Penetration testing is most valuable when it answers a business question: “Could an attacker actually get in—and what would they take or disrupt?” A good pen test doesn’t just produce a list of technical issues. It produces evidence your leadership can use to make decisions: where you’re exposed, how far an adversary could go, and which fixes materially reduce risk.

If you’re an SMB or mid-market organization, the tricky part is that “time for a pen test” rarely arrives with a neon sign. It shows up as change: a new system exposed to the internet, a cloud migration, an acquisition, or a shift to remote work. Those changes can quietly create scope gaps—places your vulnerability scans and day-to-day IT processes don’t fully validate—and that’s exactly where attackers like to operate.

This post covers:

What a penetration test proves (and what it doesn’t)
The top 10 triggers that signal you should run a pen test
How to choose the right test type (external, internal, web app, cloud)
How to scope and schedule a test without wasting time or money
What to do with results so they translate into real risk reduction

What a Pen Test Proves (& What It Doesn’t)

Before you look for triggers, align on what you’re buying. A penetration test is a controlled, authorized attack simulation performed by experts to discover whether—and how—someone could compromise your environment. The goal is not to “catch your IT team doing something wrong.” The goal is to validate risk in realistic conditions.

A well-run pen test helps answer questions like:

Can an attacker gain initial access from the internet?
If they do, can they escalate privileges?
Can they move laterally to reach critical systems?
Can they access sensitive data (customer data, financials, health records, IP)?
Could they disrupt operations (encryption, deletion, business interruption)?
Which security controls detect and stop the activity?

A penetration test is not the same as a vulnerability scan, and you need both for a reliable picture of risk.

A vulnerability scan is broad, automated coverage. It uses signatures and known patterns to flag issues like missing patches, weak or default configurations, outdated software versions, and exposed services across large portions of your environment. It’s excellent for scale and consistency and should run regularly, but its output is mostly “potential risk” findings: long lists of items that might be exploitable, without confirming whether an attacker could actually use them in your environment, in the way you’re really configured.

A penetration test is narrower, deeper, and primarily manual. Instead of just listing weaknesses, testers think and act like attackers. They chain multiple conditions together—misconfigurations, weak credentials, exposed services, overly permissive roles—to see whether they can gain a foothold, escalate privileges, move laterally, and ultimately reach systems and data that matter to your business. They validate exploitability, measure real-world impact, and provide evidence you can show to leadership and auditors.

You can think of it this way:

Vulnerability scan: “These doors might be unlocked, and here’s a list of all the ones that look suspicious.”
Penetration test: “We used this specific unlocked door, got into this hallway, bypassed this camera, entered this room, and accessed these assets—and here’s how to stop it from happening again.”

A pen test is also different from a red team. A red team engagement is usually longer in duration, operated at lower noise levels, and tightly aligned to specific business objectives and threat scenarios—for example, “exfiltrate this production customer dataset without being stopped,” “gain domain admin from an external foothold without triggering alerts,” or “demonstrate how an attacker could impact plant operations.” Red teamers are explicitly tasked with emulating realistic adversaries, blending technical intrusion, social engineering, and physical avenues as appropriate, and testing not just your controls, but your people, processes, and monitoring.

Penetration testing, by contrast, is typically more time‑boxed, more constrained by defined in-scope systems, and focused on coverage of those assets. The goal is to identify and validate exploitable weaknesses across that scope, demonstrate impact, and provide clear remediation guidance—rather than to run an extended, stealth campaign.

What a pen test does not do:

It doesn’t guarantee you’re “secure” after remediation.
It doesn’t replace ongoing vulnerability management, patching, and monitoring.
It doesn’t cover everything unless you scope it to cover everything (and most engagements shouldn’t).

Top 10 Triggers: Signs You Need a Pen Test Now

If any of the scenarios below are true for your organization, you’re in “pen test territory.” Not because you’ve failed, but because your environment changed, your risk profile increased, or leadership needs verified evidence—not assumptions.

1) You launched a new internet-facing system (or changed an existing one)

The easiest way to increase risk is to expose something to the internet. That could be a new VPN concentrator, remote access gateway, customer portal, web app, API endpoint, or even a misconfigured cloud service that becomes publicly reachable.

Why it matters: Internet-facing systems are continuously scanned by attackers.

What to test:

External network penetration testing
Web application testing
Cloud configuration and identity testing

What to look for:

Weak authentication and MFA gaps
Insecure remote access paths
Exposed management interfaces
Web app vulnerabilities
Misconfigurations that bypass intended controls

2) You completed (or are in the middle of) a major cloud migration

Cloud migrations are change on top of change: new identity flows, new network boundaries, new logging, and new opportunities for misconfiguration.

What to test:

Cloud penetration testing
External testing (if cloud services are internet-facing)
Web app testing (for cloud-hosted apps)

What to look for:

Excessive permissions (roles, service principals, API keys)
Publicly accessible storage or databases
Weak segmentation between workloads
Logging gaps
Privileged pathways that were “temporary” during migration

3) You acquired a company, merged, or added a new subsidiary

M&A often creates duplicated identity systems, temporary VPN tunnels, inconsistent endpoint controls, and unmanaged assets—exactly the conditions attackers exploit. Each newly connected environment brings its own user directories, legacy VPN configurations, and device standards, and those are rarely harmonized on day one. As a result, you see orphaned accounts that still work, “quick fix” tunnels that bypass normal security monitoring, endpoints that don’t have your standard EDR or patching in place, and servers or applications no one clearly owns. For an attacker, that combination of overlap, exception handling, and unclear ownership creates low-friction entry points and quiet pathways to move deeper into both organizations.

4) Your remote work model changed (or hybrid work became permanent)

Remote work shifts the security boundary from a set of office networks and physical controls to the identities and devices your people use every day. Instead of assuming that “on-premises” equals trusted, you now have to assume users may connect from any network, on a mix of corporate and personal devices, with varying patch levels and security controls. That identity and device posture—how well accounts are protected, how strongly MFA is enforced, how endpoints are monitored and hardened—effectively becomes your new perimeter. When those controls are weak or inconsistent, remote access solutions like VPNs, remote desktops, and cloud portals turn into high‑value targets. That’s why remote access is one of the most common initial entry points for ransomware operators: they look for exposed or misconfigured gateways, stolen or phished credentials, and unmonitored endpoints they can use as a beachhead to move deeper into the environment.

5) Your “crown jewel” data grew or moved

If your data footprint expanded or moved into new platforms, your attack surface likely expanded with it. Every new data store, SaaS application, cloud workload, or analytics environment introduces additional identities, permissions, integrations, and network paths that an attacker can target. Data that used to live in a single, tightly controlled system may now be replicated across backups, staging environments, third-party tools, and vendor portals—often with different (and sometimes weaker) controls than your primary system. That change warrants a fresh look at how data is segmented, who has access, how it’s monitored, and whether your existing controls still protect the information you now consider “crown jewel” across all of the places it resides.

6) You’ve had repeated phishing incidents or a spike in suspicious logins

Identity compromise is often the starting point of modern intrusions because most attackers find it easier to steal or abuse valid accounts than to breach hardened perimeter controls. Once they have a foothold—through a phished login, a reused password, or a hijacked session—they can quietly test how much access that identity really has, which systems it can reach, and what data it can touch. A penetration test helps you validate this in a controlled way: by simulating a compromised user and measuring how far that account can go, which privileges it can escalate to, which systems and “crown jewels” it can reach, and where your existing controls actually stop the attack path.

7) You still have legacy VPN, exposed RDP, or aging remote access components

Legacy remote access is a common root cause of ransomware and intrusion cases because older VPNs, exposed RDP, and unsupported remote access tools often lack modern controls such as enforced MFA, strong encryption, and robust logging. These systems are frequently overlooked during upgrades, left with default or weak credentials, or left more open than necessary to “just keep things working,” making them prime targets for automated scanning and credential‑stuffing attacks. Validate exactly what’s exposed to the internet, confirm which users and vendors can reach what, and test whether segmentation actually contains a compromised remote session—or whether an attacker could pivot from that foothold into your core network, OT environments, or crown‑jewel systems.

8) Third-party & vendor access expanded

Vendor pathways can bypass standard controls if they’re not carefully designed and governed. Treat every vendor connection—VPN, remote access tool, API, portal, or managed service account—as a potential attack path, and validate that it truly operates on least privilege, uses strong and enforced authentication (including MFA and unique credentials), and is continuously monitored with alerting tied to your SOC or equivalent. Confirm that vendor traffic is segmented from your core network and crown-jewel systems, that access is time-bound and approved, and that you can rapidly revoke or adjust permissions if a vendor account is compromised or their environment is breached.

9) A customer, insurer, regulator, or audit requirement calls for a pen test

Meet regulatory and customer requirements while actually reducing risk in your environment—by tightly aligning scope to your real attack surface, turning findings into a prioritized remediation plan with clear owners and timelines, and validating fixes through targeted retesting so you can prove closure to leadership, auditors, and insurers.

10) You had a “close call” (or an incident that didn’t become a headline)

Close calls are signals. Treat them as controlled warning shots, not lucky breaks. After any near-miss—whether it was a blocked ransomware attempt, an unauthorized login that was caught, or a misconfiguration discovered just in time—step back and formally analyze what happened. Validate whether the same conditions could be exploited again, which controls actually prevented impact (and which ones didn’t fire at all), and how quickly you’d detect a similar attempt if it happened tomorrow. Use that review to drive concrete actions: tighten or remove risky access, close exposed pathways, improve monitoring and alerting, and, where appropriate, scope a penetration test or red team exercise that deliberately recreates the scenario so you can measure detection and response in a repeatable way.

How to Choose the Right Test Type

External network penetration test: Validates what attackers can do from the internet.
Internal penetration test: Assumes a foothold and tests lateral movement and crown-jewel access.
Web application penetration test: Tests portals, apps, and APIs for auth, access control, and logic flaws.
Cloud penetration test: Focuses on identity, permissions, storage exposure, and cloud guardrails.

How to Scope & Schedule Without Creating False Confidence

False confidence happens when the scope is too narrow to reflect reality. Start with the business question, define crown jewels and likely attack paths, agree on rules of engagement, and align success criteria to outcomes (initial access, privilege escalation, lateral movement, and data impact).

What to Do With Results: Turn Findings Into Real Risk Reduction

Translate findings into business risk: What could be reached, disrupted, or exfiltrated?
Fix root causes: Address patterns (identity, segmentation, privilege sprawl) rather than one-off issues.
Prioritize by exploitability and pathway: Focus on initial access and routes to crown jewels.
Retest: Verify closure.
Operationalize: Feed improvements into vuln management, MDR/SOC playbooks, and IR readiness.

A Simple Pen Test Readiness Checklist

Updated asset inventory (especially internet-facing assets)
Crown-jewel systems and owners identified
Escalation point of contact during testing
MFA status and privileged account lists current
Backups current and tested
Maintenance windows and blackout periods are known
Time/resources reserved to remediate findings

How Often Should You Pen Test?

After a major change, new internet-facing apps, cloud migrations, identity changes, and new remote access methods.
After M&A: before broad connectivity, and again after standardization.
On a cycle: annually is common; higher-risk orgs may test more frequently or rotate test types quarterly.
After high-impact fixes: retest promptly.

Common Misconceptions That Lead to Bad Outcomes

“We passed our last test, so we’re good.” Pen testing is a snapshot; your environment changes.
“A pen test replaces vulnerability management.” It doesn’t—discipline prevents repeat findings.
“Exclude critical systems to avoid downtime.” Use safe ROE, don’t skip the crown jewels.
“The report is the deliverable.” Reduced risk is the deliverable; plan remediation and retesting.

How Cyber Advisors Helps: Pen Testing That Drives Outcomes

Cyber Advisors helps SMB and mid-market organizations reduce real-world risk by combining experienced offensive testing with practical remediation guidance. With the addition of Stratum Security, our testing abilities have increased. With our expanded skill sets and experience, we deliver penetration testing and red teaming aligned with business outcomes—not just compliance checkboxes.

Penetration Testing (external, internal, web application, cloud)
Red Teaming and attack simulation for mature environments
Vulnerability Management & Remediation programs
Incident Response Readiness (including tabletop exercises)
vCISO Risk Roadmapping to connect results to priorities and budget

Talk to a Pen Testing Expert

If you’ve launched a new internet-facing system, migrated critical workloads to the cloud, expanded or formalized remote work, brought a newly acquired company onto your network, or weathered a security “near miss,” you’ve materially changed your attack surface. Those shifts often introduce blind spots that basic vulnerability scans and day-to-day IT processes won’t fully catch. That’s the point where a properly scoped penetration test stops being a nice-to-have and becomes a necessary validation step—so you can see exactly what’s exposed, how an attacker could take advantage of it in your real environment, and which fixes will most effectively reduce business risk.

Let’s make the outcome clear:

Confirm whether attackers can gain access
Identify realistic paths to your crown jewels
Prioritize fixes that reduce business risk
Retest to prove closure
Strengthen your security program using the findings

What Tools and Services Do Manufacturers Need to Achieve Cyber Maturity?

gbaruck@edotholdings.com (Glenn Baruck) — Tue, 07 Apr 2026 12:15:00 GMT

Manufacturing leaders have never had more pressure to keep production running while defending against ransomware, supply chain compromise, and targeted attacks on operational technology (OT). The challenge is that “cyber maturity” in manufacturing isn’t a single product you buy—it’s a coordinated set of manufacturing cybersecurity tools, processes, and OT security services that protect both IT and OT without disrupting uptime.

AI-Driven Cyber Attacks: What SMBs Must Do to Defend in 2026

gbaruck@edotholdings.com (Glenn Baruck) — Thu, 02 Apr 2026 12:15:00 GMT

If you feel like phishing suddenly got “smarter,” you’re not imagining it. Generative AI has changed the economics of social engineering. Attackers can now produce convincing emails, texts, voice calls, and even video clips at scale—tailored to your business, your vendors, your executives, and your workflows. The result is a sharp rise in targeted business email compromise (BEC), more realistic impersonation (including deepfakes), and faster reconnaissance that helps criminals choose the easiest path to credentials and money.

Building a Culture of Cybersecurity Maturity in Healthcare

gbaruck@edotholdings.com (Glenn Baruck) — Wed, 01 Apr 2026 12:15:00 GMT

Healthcare organizations don’t have a “cybersecurity technology problem.” Most have a “cybersecurity culture problem.”

Top 5 Reasons to Upgrade Your Collaboration Tools in 2026

gbaruck@edotholdings.com (Glenn Baruck) — Tue, 31 Mar 2026 12:15:00 GMT

In 2026, collaboration platforms aren’t “just” chat and meetings anymore—they’re becoming the operating system for how work gets done. The problem is that many SMB and mid-market organizations are still running on a mix of aging licenses, bolt-on apps, and inconsistent policies. That combination leads to the same three outcomes we see over and over: low adoption, shadow IT, and avoidable security exposure.