IT Guidance for Cybersecurity Clients in the Pacific Northwest

I spend most weeks talking to businesses in Washington and Oregon about their IT security posture. Not audits. Not certifications. Conversations about what actually protects them versus what looks good on paper. The distinction matters more than most owners realize when they're deciding what to spend money on.

Start with what we actually see happening in this region. Phishing campaigns targeting healthcare practices in Spokane look identical to the ones hitting law firms in Portland. Same infrastructure, same lures, same credential-capture pages. The attackers are not local. They do not care about your industry verticals or your employee count. They care about whether your environment will let them in and whether you have something worth taking. Email access is worth taking. Financial data is worth taking. Customer lists are worth taking. You do not need to be interesting to be profitable to an attacker.

The first gap I find when a new client brings me their current setup: someone configured controls years ago, then nobody validated whether those controls still fire. MFA rolled out in 2021, but the legacy app that bypasses MFA is still running because one person needs it for one task. Conditional access policies exist in the tenant, but they're set to report-only mode instead of enforce mode because someone was worried about locking out a remote user. The firewall has rules, but the rules allow RDP from any IP because it was easier than maintaining a list. These are not theoretical gaps. This is what I see in the first two hours of a technical review.

What matters for businesses in the Pacific Northwest specifically: you have remote users. Sometimes in Eastern Washington where broadband is inconsistent. Sometimes working from home in Seattle where they're on residential cable. Sometimes at a job site with no reliable connectivity at all. Your security model has to account for the fact that your users are not always on your network, not always on a managed device, and not always making decisions with full context when a phishing email lands in their inbox at 4:30 on a Friday.

This is where documented policy and enforced control diverge. A policy that says "users must use MFA" is not the same as a technical control that prevents login without MFA. A policy that says "only company devices can access email" is not the same as a conditional access rule that blocks unmanaged devices. I can show you a compliant environment where an attacker walks right in because the paperwork says one thing and the configuration does another.

What I recommend for clients in this region, based on what actually stops the attacks we see:

Enforce MFA everywhere, but configure it so that repeated prompts during a short window do not fatigue your users into approving a fraudulent login. Number-matching or app-based authentication is stronger than push notifications. An attacker in another country spamming MFA prompts until your user clicks yes to make it stop is a real pattern, not a hypothetical. Conditional access rules that actually enforce. Not report mode. Enforce mode. Block unmanaged devices from accessing corporate email and file shares. Block legacy authentication protocols that bypass MFA entirely. Block logins from impossible-travel scenarios where the same account authenticates from Seattle and then Lagos twelve minutes later. Logging that you actually review. You need to know when someone logs in from an unusual location, when someone accesses files they have never accessed before, when someone changes a forwarding rule in email. These events generate logs. The logs sit in a tenant somewhere generating noise unless someone is looking at them with a clear question: is this normal behavior for this user? Phishing-resistant training. Not annual compliance training with a quiz at the end. Simulated phishing that mirrors the actual lures your users are seeing this month, with immediate feedback when someone clicks, and metrics that tell you which users are high-risk. Training works when it is specific and repeated. It does not work when it is generic and annual. Patching that actually happens. I have seen environments where critical patches sit unapplied for 90 days because nobody has a process for testing and deploying them. Attackers do not wait 90 days. They wait until the exploit drops on GitHub, then they scan for vulnerable systems. Your patch cycle needs to be faster than their exploit cycle.

None of this is exotic. None of it requires a budget that only enterprises can afford. It requires someone looking at your environment with the question: what would an attacker do here, this week, with the tools that are currently available? Then configuring controls that answer that question, not controls that check a compliance box.

If you are currently working with a managed IT provider, ask them to walk you through the last time they reviewed your conditional access policies, your MFA configuration, and your logging rules. If the answer is "we set that up when you onboarded," you have a gap. Attackers change their methods every quarter. Your defenses should change with them.

Email us at craftworkgrp.com to schedule a technical review of your current security controls. We will tell you what is actually enforcing and what is just documented.