Blog

Quantum Computing Is Coming for Your VPN — Here's Why Quantum-Safe IPsec Can't Wait

Aaron Wickware, 7/13/2026

The Threat Isn’t Science Fiction Anymore

For years, “quantum computers will break encryption someday” has sounded like a problem for the next decade. It isn’t.

It’s a problem for today’s traffic. Here’s the uncomfortable part: an attacker doesn’t need a working quantum computer right now to hurt you later. They just need to record your encrypted traffic today and decrypt it once the technology catches up. Security researchers call this harvest-now-decrypt-later — and it’s already happening. Nation-states and well-funded threat actors are quietly capturing VPN traffic, site-to-site tunnel data, and encrypted backups, banking on the fact that a “cryptographically relevant quantum computer” will eventually make today’s Diffie-Hellman and RSA key exchanges trivial to unwind.

If your organization moves anything sensitive over an IPsec VPN — financial records, engineering data, client files, offshore operations data — that traffic could already be sitting in someone’s archive, waiting.

What Actually Breaks

Classic IPsec key exchange (IKEv2) leans on Diffie-Hellman and elliptic-curve math. That math is currently unbreakable by any conventional computer. It is not unbreakable by a sufficiently powerful quantum computer running Shor’s algorithm. Once that hardware matures, the key exchange that protects your VPN tunnels stops being a wall and starts being a formality.

Symmetric encryption (AES) holds up reasonably well against quantum attacks. Key exchange does not. That’s the part of the handshake that needs to change — and the industry is already moving.

The Fix: Post-Quantum Hybrid Key Exchange

The IETF has already standardized the path forward. RFC 9370 extends IKEv2 to allow multiple key exchanges within a single IKE SA negotiation, and a companion draft defines how to fold NIST’s ML-KEM (the standardized post-quantum key encapsulation mechanism, formerly known as Kyber) into that exchange alongside traditional elliptic-curve Diffie-Hellman.

This combined approach — called PQ/T Hybrid key exchange — is deliberate. Instead of ripping out proven classical cryptography and betting everything on algorithms that are still relatively new, hybrid key exchange runs both simultaneously. Your tunnel is only as breakable as the stronger of the two methods. If ML-KEM ever turns out to have a flaw nobody’s found yet, the classical exchange still protects you. If a quantum computer eventually breaks the classical exchange, ML-KEM still protects you.

A few practical notes for anyone planning a migration:

– ML-KEM comes in three strengths — ML-KEM-512, -768, and -1024 — mapped to NIST security levels roughly equivalent to AES-128, AES-192, and AES-256.

– Packet size matters. ML-KEM-768 and ML-KEM-1024 public keys and ciphertexts can exceed typical network MTU, which is why the IETF added the IKE_INTERMEDIATE exchange (RFC 9242) — it gives large post-quantum key material room to travel without breaking existing packet handling.

– Performance impact is minimal. IPsec tunnels stay up for long stretches and move large volumes of data relative to the one-time cost of the key exchange, so the extra math at negotiation time is a rounding error in practice.

– This is already shipping in real firewalls. Fortinet’s FortiOS supports PQC-hybrid IPsec key exchange today, letting administrators select up to three post-quantum KE groups per negotiation round alongside classical Diffie-Hellman. Cisco and Palo Alto Networks are on the same path.

What This Means for a Mid-Size Business

If you’re running a lean IT team without a dedicated cryptography specialist, here’s the honest read: you don’t need to panic, but you do need a plan. The transition to quantum-safe IPsec isn’t a single flag you flip — it’s a coordinated update across every VPN endpoint your organization touches: site-to-site tunnels between offices, remote access VPNs for staff, and any partner or vendor tunnels carrying sensitive data.

A few things worth doing now, well before this becomes an emergency:

1. Inventory your VPN endpoints. Know which firewalls, routers, and VPN concentrators are handling IPsec traffic and whether their firmware supports RFC 9370 hybrid key exchange.

2. Check your firmware and licensing. Post-quantum support is a firmware-level capability. If you’re running older code, this is one more reason to get current.

3. Prioritize by sensitivity, not convenience. Tunnels carrying financial, legal, health, or regulated data should move to hybrid key exchange first — not whichever tunnel is easiest to touch.

4. Don’t wait for a mandate. Financial services and defense-adjacent industries are already seeing early compliance pressure toward quantum-resistant cryptography. Being ahead of that curve costs a lot less than scrambling to catch up.

Where This Fits Into a Bigger Picture

Quantum-safe key exchange is one piece of a much larger security posture — but it’s a piece that’s easy to overlook because the payoff isn’t visible today. Nobody sees the traffic that was harvested two years ago sitting in an adversary’s archive. That’s exactly what makes it dangerous.

This is the kind of gap a network security assessment is built to catch: not just “is your firewall configured correctly today,” but “are you positioned for the threats that are already in motion.” If you don’t know whether your VPN infrastructure supports hybrid post-quantum key exchange, that’s a five-minute conversation worth having before it becomes a much longer one.

Bullroar Telecom provides managed network security and engineering services built on Fortinet infrastructure, including our Cyber Threat Assessment Program (CTAP) — a complimentary evaluation of your network’s real-world security posture.

The Internet Is Full of Scavenger Hunts. Here's How to Find Them.

Aaron Wickware, 7/6/2026

Every so often we like to step away from firewalls and failover configs and talk about something just plain fun. This week: internet scavenger hunts — the strange, sprawling world of puzzles, hidden pages, and rabbit holes that people have been building into the web since roughly the moment the web existed.

What counts as an internet scavenger hunt?

Broadly, three flavors:

Alternate Reality Games (ARGs). Elaborate, often years-long puzzles woven across websites, phone numbers, forums, and real-world locations. The most famous is probably Cicada 3301, which appeared in 2012 as a cryptic image posted to an anonymous forum and spiraled into a labyrinth of steganography, prime numbers, Mayan numerals, and physical flyers taped to lampposts in a dozen countries. Nobody has ever definitively confirmed who ran it or why. That mystery is basically the whole appeal.

Website Easter eggs. Smaller-scale, usually built by developers with a sense of humor and a little spare time. Google’s search bar still responds to commands like “do a barrel roll” and “askew.” Type the Konami code on plenty of sites and something changes. These are low-stakes hunts — no prime numbers required, just curiosity and a willingness to poke at things.

Geocaching and location-based hunts. The physical-world cousin, where GPS coordinates lead to hidden containers stashed in parks, under bridges, and in suspiciously specific tree stumps. There are millions of active caches worldwide, logged and tracked by a community that treats it with startling seriousness.

Why do people build these things?

Mostly for the same reason anyone builds anything elaborate and useless: because it’s satisfying to make something only a few people will ever fully understand. There’s also a real craft to it — a good puzzle has to be hard enough to resist a five-minute Google search, but not so hard that nobody ever solves it. That balance is harder to hit than it sounds.

If you want to try one:

– Cicada 3301 archives are still online and well-documented, if you want to see how deep a puzzle can go.

– Geocaching.com has a free tier and probably a cache within walking distance of wherever you’re reading this.

– Keep an eye on 404 pages — some companies use them as a spot for a hidden joke or puzzle, precisely because almost nobody looks there.

There’s a certain kind of mind that likes taking things apart to see how they work, whether that’s a cryptic puzzle, an old website’s source code, or — if we’re being honest about what pays the bills around here — a network that’s been humming along fine for years and nobody’s quite sure why. Same instinct, different Tuesday.

That’s it for this one. No pitch, no CTAP mention, just wanted to share something fun.

FortiBleed Wasn't About Weak Passwords. It Was About Exposed Management Interfaces.

Aaron Wickware, 6/30/2026

What Actually Happened

In June 2026, security researchers uncovered a sprawling credential-harvesting operation targeting Fortinet FortiGate firewalls and VPN gateways. Dubbed “FortiBleed,” the campaign compiled a verified database of tens of thousands of working administrator and VPN credentials — estimates from different researchers ranged from roughly 30,000 to over 86,000 compromised devices across 194 countries. The victim list reads like a roll call of global industry, and it wasn’t confined to small, under-resourced organizations.

Here’s the headline that matters more than the number: there was no new Fortinet vulnerability involved. No zero-day, no novel exploit. Researchers were explicit about this. What made FortiBleed effective wasn’t sophistication — it was scale. Attackers scanned the internet for exposed FortiGate devices, intercepted SSL-VPN authentication hashes, cracked them offline on a dedicated GPU cluster running well over a billion attempts, and tried curated lists of previously leaked passwords against every device they found. Once inside, the compromised device became a launchpad for harvesting the next set of credentials, creating a self-sustaining cycle.

The Story Everyone’s Telling Is Slightly Wrong

Most of the coverage has framed this as an SSL-VPN problem, and as a password-hygiene problem. Both are true, but neither is the actual root cause — and the distinction matters if you’re deciding what to fix.

UK’s National Cyber Security Centre described the exposure as brute-force, dictionary, and credential-stuffing activity against internet-facing FortiGate and VPN portals — language that includes the management interface, not just SSL-VPN specifically. And the remediation guidance from multiple security researchers backs that up: reset administrator accounts and local user accounts, not only SSL-VPN credentials; upgrade FortiOS to force migration off legacy SHA-256 password hashing onto PBKDF2; and — as a separate, non-negotiable step — block external access to FortiGate management interfaces entirely.

That last point is the one that gets buried. An organization that migrated off SSL-VPN but still has HTTPS or SSH admin access reachable from the internet hasn’t actually closed the door. They’ve just changed which room the attacker walks into. Credential rotation on a device that’s still internet-facing resets the clock — it doesn’t stop the next scan from finding it.

The Actual Common Denominator

Pull back far enough across the reporting and a pattern emerges that has nothing to do with password complexity: the organizations that got swept up in FortiBleed had an exposed management interface, an unrestricted admin ACL, or both. A strong password doesn’t help much if the login page it protects is reachable by anyone on the internet running an automated scanner. A weak or reused password matters enormously if that same login page is wide open. Either way, the exposure — not the password — is the precondition.

We haven’t seen a single fully hardened deployment fall into this category. No internet-facing management interface, tightly scoped admin ACLs, current firmware, rotated credentials on a real schedule — check every one of those boxes and FortiBleed simply isn’t a candidate risk, regardless of how the campaign evolves next.

None of Bullroar’s managed customers were exposed to FortiBleed. Not because we got lucky on timing, but because the fundamentals — locked-down admin access, no internet-facing management interfaces, current patch levels — were already in place before the campaign started.

The Real Checklist

If you’re running Fortinet infrastructure (managed by us or otherwise), here’s what actually matters, in order:

1. Confirm your management interface isn’t internet-facing. HTTPS and SSH admin access should never be reachable from the public internet. This is the single highest-leverage fix on this list.

2. Lock down admin access with ACLs. Even where remote management is necessary, restrict it to specific trusted source IPs — not “any.”

3. Rotate credentials on a real schedule, not just after an incident makes headlines. Assume any credential that’s been sitting unchanged for years is already circulating somewhere.

4. Get current on firmware and force the hash migration. Older FortiOS versions may still be using legacy SHA-256 password hashing; current patches support migration to PBKDF2, but that migration only happens after you log in post-upgrade — it isn’t automatic.

5. Don’t treat SSL-VPN as the whole threat model. Moving off SSL-VPN is a reasonable architectural decision for other reasons, but it doesn’t substitute for closing off the management interface itself.

Why This Matters Beyond FortiGate

FortiBleed is a Fortinet story this month. The pattern behind it — internet-exposed management interfaces plus stale credentials — isn’t specific to any one vendor, and it won’t be the last campaign to exploit exactly this combination. The organizations that keep sitting out these campaigns aren’t the ones with the most exotic defenses. They’re the ones that got the boring fundamentals right and kept them right.

Bullroar Telecom manages Fortinet infrastructure for our clients with locked-down admin access, no internet-facing management interfaces, and current firmware as standard practice — not an add-on. If you’re not certain where your own deployment stands on these fundamentals, that’s worth finding out before the next campaign, not after.

Will IPv4 Really Ever Die? Do You Actually Need to Embrace IPv6?

Aaron Wickware, 6/23/2026

The Short Answer

IPv4 isn’t dying anytime soon. IPv6 isn’t optional anymore either. Both of those things are true at the same time, and understanding why is more useful than picking a side in what’s become a tired industry argument.

IPv4 Ran Out Years Ago — And Kept Running Anyway

IPv4 gives the internet about 4.3 billion possible addresses. That sounded infinite in 1981. It doesn’t sound infinite when you’ve got billions of phones, laptops, IoT sensors, cloud instances, and servers all needing one. The regional registries have been out of fresh IPv4 allocations for over a decade now.

And yet IPv4 still carries somewhere in the range of 55-70% of global internet traffic today. Fortune 500 companies overwhelmingly run primary infrastructure on it. The reason isn’t stubbornness — it’s NAT. Network Address Translation let the internet keep growing on a fixed pool of addresses by letting thousands of devices share a small number of public IPs. It’s an ugly workaround by design standards, but it’s an effective one, and it bought IPv4 an extra twenty years of life nobody expected it to get.

That’s also exactly why there’s no hard shutoff date for IPv4. There’s no single moment where it stops working. Networks migrate when the cost of extending IPv4 finally exceeds the cost of adopting IPv6 — and for a lot of organizations, that day keeps getting pushed back.

So Where Does IPv6 Actually Stand?

Global IPv6 adoption sits in the mid-to-high 40% range as of 2026, and it’s been climbing steadily for years. But that headline number hides a massive gap depending on who you are:

– Mobile carriers: roughly 70-90% IPv6-capable — carriers had the strongest incentive to escape IPv4 scarcity early, since every new phone needs an address.

– Hyperscalers (AWS, Google, etc.): around 80% IPv6-enabled on public-facing infrastructure.

– Enterprise networks: roughly 30-32%.

– Small and mid-size businesses: around 17%.

In other words: the largest, best-resourced players moved first. The businesses in the 50-200 employee range — the ones without a dedicated network engineering team — are the ones still sitting almost entirely on IPv4, often without realizing it.

Most of the internet today runs dual-stack: both protocols active side by side. Pure IPv6-only deployments are still rare outside specific mobile and data-center environments. That dual reality — not a clean cutover — is the actual shape of this transition, and it’s likely to stay that way for a long time.

Why “Just Stay on IPv4” Isn’t a Free Ride

Here’s the part that doesn’t get said enough: staying IPv4-only isn’t neutral. It has a cost; it’s just a quieter one.

IPv4 addresses are now a scarce, tradeable asset. Because the registries are out of fresh allocations, address blocks now trade like commercial real estate. Growing your IPv4 footprint — more addresses for more servers, more customers, more services — increasingly means leasing or buying addresses on a secondary market instead of simply requesting them.

NAT adds complexity and fragility at scale. Every layer of NAT is another thing that can break, another source of latency, another obstacle for peer-to-peer connections and certain VoIP or real-time traffic. It works, but it’s a workaround, not an architecture.

IPv6 removes an entire class of problems by design. No mandatory NAT. Built-in address auto-configuration. A vastly larger address space that makes clean per-customer or per-device allocation trivial instead of a constant balancing act. For an ISP or managed service provider like Bullroar, this isn’t theoretical — it’s the difference between hand-rationing a shrinking IPv4 pool and handing out clean, purpose-built /48 allocations without a second thought.

Where IPv4 Genuinely Isn’t Going Anywhere

To be fair to IPv4: there are entire categories of infrastructure where it remains the more reliable operational choice today, and will for a while. Email deliverability still leans heavily on IPv4-based sender reputation systems. Plenty of legacy applications, payment processing systems, and specialized industrial or offshore equipment simply were never built with IPv6 in mind and won’t be retrofitted soon. Ripping that infrastructure out to “go IPv6” for its own sake is a solution in search of a problem.

The Right Question Isn’t “IPv4 or IPv6”

It’s dual-stack, deployed deliberately. The businesses handling this well aren’t the ones who rushed to flip everything to IPv6 to look forward-thinking, and they’re not the ones ignoring it either. They’re the ones who enabled IPv6 on public-facing infrastructure, watched how traffic actually split between the two protocols, and made decisions based on what they observed — not what a blog post (including this one) told them to believe.

For most SMBs, that looks like:

1. Confirm what your upstream ISP actually supports. You can’t run dual-stack if your provider only hands you IPv4.

2. Enable IPv6 on public-facing services first — websites, mail servers, VPN endpoints — where the operational risk of a misconfiguration is lowest, and the visibility into what’s actually happening is highest.

3. Don’t force it onto legacy internal systems that have no real reason to change and no vendor support for it.

4. Get your addressing plan right before you need it, not while you’re scrambling to onboard a customer or spin up new infrastructure under pressure.

The Real Risk Isn’t IPv6. It’s Not Having a Plan.

IPv4 will keep working for a long time. Nobody’s turning it off. But the businesses that treat IPv6 as “someday, not now” tend to be the same ones scrambling later — paying inflated prices for IPv4 space on the secondary market, or discovering during a growth spurt that their addressing architecture was never built to scale in the first place.

You don’t need to migrate everything tomorrow. You do need to know where you actually stand, and have a real plan for the parts of your network that will need it.

Bullroar Telecom operates dual-stack infrastructure across our network and manages IPv6 addressing at scale for our business customers. If you’re not sure where your organization actually stands on IPv6 readiness, that’s a conversation worth having before it becomes urgent.

Why SSL-VPN Is Fundamentally Weak (It's Not Any One Vendor's Problem) — and Why ZTNA Is the Future

Aaron Wickware, 6/16/2026

If you’ve followed cybersecurity news over the past few years, you’ve probably noticed a pattern: SSL-VPN vulnerabilities keep making headlines, and it’s not just one vendor. Nearly every major SSL-VPN product on the market has had serious, actively-exploited vulnerabilities disclosed at some point. This isn’t a coincidence, and it isn’t really about any one company’s code quality. It’s a structural problem with the SSL-VPN model itself.

The Core Design Flaw

An SSL-VPN’s entire job is to sit on the public internet, accept connections from anyone who reaches it, and decide whether to let them in. That means the VPN appliance itself is, by definition, an internet-facing target running complex, security-critical code — and it typically gets network-level access once a connection is authenticated. Attackers don’t need to compromise a user’s laptop or steal their credentials through phishing. They just need to find a flaw in the appliance itself, because that appliance is sitting there, reachable by anyone, all the time.

This is why SSL-VPN vulnerabilities are so consistently valuable to attackers, including nation-state groups: a single unpatched flaw in the appliance can grant access to an entire network, bypassing every other control behind it. And because these appliances are complex pieces of software handling authentication, session management, and cryptography all in one place, they’ve proven to be a rich target for vulnerability research — by defenders and attackers alike.

Why “Once You’re In, You’re In” Is the Bigger Problem

Even setting aside vulnerabilities in the appliance itself, traditional VPN access has a design assumption baked in from the 1990s: once a connection is authenticated, the user is treated as “inside” the network and typically has broad access to whatever that network segment can reach. A compromised laptop, a stolen credential, or a malicious insider connecting over VPN doesn’t just get access to the one application they need — they often get a foothold across a much wider swath of the network than the job actually requires.

This is the same “flat network” problem that’s driven ransomware from a single infected endpoint into a full-blown, company-wide incident again and again. VPN access wasn’t built with the assumption that the network itself needs to be defended from something already inside it.

What ZTNA Does Differently

Zero Trust Network Access flips the model. Instead of granting broad network access after a single authentication event, ZTNA verifies identity, device posture, and context continuously and grants access to individual applications — not the network as a whole.

No broad network exposure. A user connecting through ZTNA to reach a specific application never gets placed “on the network” the way VPN access does. They get a direct, brokered connection to that one application. If their credentials are compromised, the blast radius is that one application, not the entire network segment.

Nothing internet-facing to attack. ZTNA architectures typically don’t expose an internet-facing appliance the way SSL-VPN does. Connections are brokered outbound from inside the network to a cloud-based control plane, meaning there’s no equivalent to “scan the internet for vulnerable VPN appliances” — because there’s no listening appliance to find.

Continuous verification, not one-time login. ZTNA doesn’t treat authentication as a single event that grants standing access. Access decisions factor in device health, location, and behavior continuously, so a session that starts legitimately but starts behaving suspiciously can be cut off mid-session, not just blocked at login.

Granular, least-privilege access by default. Instead of “connected to the network,” users get “connected to exactly the applications their role requires” — which is a much smaller, much more defensible target than a full network segment.

Why This Matters More Than Ever

Remote and hybrid work made VPN the default way businesses handled off-site access, but the threat landscape that made VPN reasonable in 2015 isn’t the one we’re in now. Attackers actively scan the internet for exposed VPN appliances specifically because they know how valuable a single exploit can be. Every headline about a new SSL-VPN zero-day is really the same story repeating: an internet-facing appliance with broad network access got compromised, and the damage wasn’t contained to one user or one application — it spread.

The Bottom Line

This isn’t a weakness unique to any single vendor — it’s an industry-wide pattern rooted in how SSL-VPN was designed to work in the first place: an internet-facing appliance granting broad network access after a single login. ZTNA addresses both problems at the architectural level, not just with better patching. For businesses evaluating remote access strategy, the question isn’t really “which VPN vendor is safest” anymore — it’s whether VPN is still the right model at all.

Evaluating your current remote access architecture against a ZTNA model is part of what we look at in every Bullroar Cyber Threat Assessment Program engagement — no cost, no obligation, just a clear picture of where the exposure actually is.

Bullroar Telecom is a managed network security and engineering company based in Covington, Louisiana, with additional infrastructure in Baton Rouge and Fremont, CA, and a Tampa site coming online in Q4 2026. Learn more at www.bullroartel.com.

The Importance of Good Password Hygiene (Yes, Still)

Aaron Wickware, 6/9/2026

With all the talk of FIDO2, passkeys, and zero trust architecture, it’s tempting to think passwords are a solved problem — or an obsolete one. They’re neither. Most businesses are still running on passwords for the majority of their systems today, and password-related weaknesses remain one of the most common entry points attackers use. Until the passwordless future actually arrives everywhere, password hygiene is still doing a lot of the heavy lifting for your security posture.

Why This Still Matters

As we covered in our post on identity as the foundation of access, every security control downstream depends on knowing who’s actually authenticating. A weak or reused password undermines that foundation before anything else even gets a chance to work. It doesn’t matter how well-configured your firewall is if an attacker simply logs in with a valid, stolen password.

The Habits That Actually Cause Breaches

Password reuse across accounts. This is, by a wide margin, the single most damaging habit. When one service gets breached — and services get breached constantly, often ones you’ve never heard of — every account sharing that same password is now exposed too. Attackers run these breached credential lists against banking sites, email providers, and business logins automatically, in bulk, within hours of a new breach dump surfacing. This is called credential stuffing, and it works precisely because reuse is so common.

Weak, predictable passwords. Anything based on a name, a birthday, a season and year, or a keyboard pattern gets cracked in seconds by modern password-cracking tools, which can test billions of guesses per second against a stolen password hash.

Passwords shared over insecure channels. A password sent over email, Slack, or a text message sits there indefinitely, readable by anyone with access to that mailbox or chat history — including, eventually, an attacker who compromises the account much later.

Never rotating credentials for shared or service accounts. Personal password rotation on a fixed schedule is largely outdated advice now (more on that below), but shared logins, service accounts, and vendor credentials that never change are a different story — they accumulate risk every year nobody touches them.

Writing passwords down insecurely. The sticky note under the keyboard is a cliché because it’s still genuinely common, and it defeats the purpose of a strong password entirely if anyone walking by the desk can read it.

What Modern Guidance Actually Recommends

Password guidance has shifted meaningfully in recent years, and some of the old advice is now considered counterproductive:

Length over complexity. A long passphrase like several unrelated words strung together is both easier to remember and dramatically harder to crack than a short, complex string like `P@ssw0rd1!` — which looks strong but follows a predictable pattern attackers’ tools already account for.

Stop forcing frequent rotation. Forcing users to change passwords every 30 or 90 days, without a specific reason to believe a password was compromised, is now widely considered bad practice. It reliably pushes people toward small, predictable variations (`Summer2024!` becomes `Summer2025!`) that are barely different from the last password and just as easy to guess if the pattern is known.

Use a password manager, not memory. The realistic alternative to reuse isn’t “remember more unique passwords” — it’s not needing to remember them at all. A password manager generates and stores a genuinely unique, random password for every account, and is one of the single highest-leverage tools an individual or business can adopt.

Check for exposure, don’t just guess. Services exist specifically to check whether a given password or email address has appeared in a known breach. Building a habit of checking (and immediately changing anything flagged) closes the gap between a breach happening somewhere else and it actually being used against you.

Passwords are a bridge, not the destination. As covered in our earlier post on MFA and FIDO2, the real goal is moving critical accounts toward passwordless authentication entirely. Until every system supports that, good password hygiene is what closes the gap on everything still relying on a password as the first line of defense.

What This Looks Like for a Business, Not Just an Individual

A company-wide password manager, not individual choice. Leaving password management up to individual habits guarantees inconsistency. Deploying a business password manager across the organization — with shared vaults for team credentials where needed — removes the guesswork and gives IT actual visibility into weak or reused passwords across the company.

Breach monitoring at the domain level. Services exist that monitor whether any company email address shows up in a new breach dump, so IT can force a reset on affected accounts before an attacker gets there first, rather than finding out after the fact.

Clear policy on shared and service accounts. Every shared login and every service account should have an owner, a documented purpose, and a real rotation and review schedule — these are exactly the credentials that tend to be forgotten and never touched for years.

MFA as the real safety net. Good password hygiene reduces how often a password alone is enough to get an attacker in. It shouldn’t be the only thing standing between a stolen password and a full account takeover — which is exactly what MFA, and ideally FIDO2, is there to catch.

The Bottom Line

Passwords aren’t going away as fast as the security industry sometimes likes to suggest, and in the meantime, they remain one of the most common and most preventable ways attackers get in. Length, uniqueness, a password manager, and breach monitoring do more to close that gap than any amount of complexity-rule enforcement ever did — and none of it requires new hardware or a steep learning curve to put in place.

Reviewing how credentials are managed across your business — and where password practices are quietly creating risk — is part of every Bullroar Cyber Threat Assessment Program engagement.

It's All About Identity: Who You Are Is the Source of All Access

Aaron Wickware, 6/2/2026

Every security control we’ve written about — MFA, FIDO2, ZTNA, DLP — eventually comes back to the same single question: who is actually on the other end of this connection? Firewalls, encryption, and endpoint tools all matter, but they all sit downstream of one thing. If identity is wrong, everything built on top of it is wrong too. Identity isn’t one layer of security among many. It’s the foundation everything else stands on.

Why Identity Is the Real Perimeter

For most of the internet’s history, security was built around a network perimeter: a firewall separating “trusted inside” from “untrusted outside,” with the assumption that anything past the firewall was, by default, safe. Cloud applications, remote work, and mobile devices quietly dissolved that boundary years ago. There often isn’t a single network perimeter left to defend — data lives in Microsoft 365, in cloud-hosted applications, on personal devices, accessed from home, from a coffee shop, from a job site.

What’s left when the network perimeter disappears is identity. The question stops being “are you inside our building” and becomes “can you prove you’re who you say you are, from a device we trust, doing something consistent with your role.” That’s not a network question anymore. It’s an identity question.

What Happens When Identity Fails

Almost every major breach category we’ve covered in this series traces back to an identity failure somewhere in the chain:

Stolen or reused credentials. A password breached at one service and reused at another gives an attacker a valid identity to walk in with — no exploit required, because the system correctly believes it’s talking to the real user.

Phished MFA approvals. As covered in our post on MFA weaknesses, push-bombing and real-time phishing relay attacks don’t break the technology — they trick a real identity into approving something it shouldn’t. The system worked exactly as designed and still let the wrong person in.

Over-permissioned accounts. An account that’s correctly identified but grossly over-privileged — a marketing employee with domain admin rights left over from years ago, a service account nobody remembers creating — turns a minor compromise into a major one, because identity determined access far beyond what the role actually needed.

VPN’s flat-network problem. As covered in our post on SSL-VPN and ZTNA, traditional remote access treats a single authentication event as a blank check for broad network access. That’s identity being used correctly at the front door and then ignored for everything that happens after.

In every one of these cases, the technical control wasn’t necessarily broken. The identity behind it was compromised, misused, or given more trust than it should have had.

What “Doing Identity Right” Actually Looks Like

Strong authentication as the baseline. This is where FIDO2/passkeys matter — not as a nice-to-have, but because weak authentication methods are the easiest way for an attacker to obtain a valid identity in the first place.

Least-privilege access, tied to role, not tenure. Access should map to what a person’s current job actually requires, not what accumulated over years of role changes and forgotten permissions. Every excess permission is a wider blast radius if that identity is ever compromised.

Continuous verification, not one-time login. This is the core idea behind ZTNA: identity isn’t a single checkpoint at the door, it’s something re-evaluated continuously based on device health, location, and behavior. An identity that starts a session legitimately can still be cut off mid-session if something looks wrong.

Centralized identity management. When identity lives in one well-managed system — like Microsoft Entra ID — rather than scattered across dozens of app-specific logins, it becomes far easier to enforce consistent policy, spot anomalies, and revoke access immediately and completely when someone leaves the company or a credential is compromised.

Fast deprovisioning. A former employee’s account that’s still active weeks after they left isn’t a hypothetical — it’s one of the most common, entirely preventable sources of unauthorized access. Identity governance isn’t just about granting access correctly. It’s about removing it just as reliably.

Identity-aware policy at the network layer. This is where the pieces from earlier posts connect: Fortinet’s integration with Microsoft Entra ID means network and application access decisions can factor in who’s asking, not just where the traffic is coming from — the same identity, evaluated consistently, everywhere it touches the business.

The Bottom Line

Every layer of a security program — firewalls, VPN replacement, data loss prevention, encryption — exists to enforce a decision that was already made somewhere upstream: is this really who it claims to be, and should it have access to this. Get identity right, and every downstream control gets stronger. Get it wrong, and no amount of network security fully compensates, because the system will faithfully protect access for an identity that was never legitimate to begin with.

If there’s one question worth asking before any other security investment, it’s this one: do we actually know, with confidence, who has access to what across our business right now? That question is the starting point of every Bullroar Cyber Threat Assessment Program engagement.

Social Engineering: Your Users Are the First Line of Defense, Not the Last

Aaron Wickware, 5/26/2026

Businesses spend real money on firewalls, endpoint protection, email filtering, and network monitoring — and all of it matters. But the uncomfortable truth is that a huge share of successful breaches don’t route around those defenses at all. They walk right through the front door, because someone opened it for them. Social engineering doesn’t exploit a flaw in your network. It exploits trust, urgency, and habit — and no firewall rule fixes that.

What Social Engineering Actually Is

Social engineering is the practice of manipulating a person into doing something they wouldn’t otherwise do: clicking a link, approving an MFA prompt, transferring money, sharing a password, or letting someone into a building they shouldn’t be in. It works because it targets something technology can’t patch — normal, reasonable human behavior like wanting to be helpful, trusting a familiar name, or reacting quickly to something that feels urgent.

This is why social engineering shows up as the entry point in the overwhelming majority of breaches, even at organizations with substantial security budgets. It’s simply more efficient for an attacker to convince one person to hand over access than to find and exploit a technical vulnerability.

The Common Forms It Takes

Phishing. Still the most common vector by far — an email designed to look like it’s from a trusted source (a vendor, a bank, IT support, a coworker) that pushes the recipient toward clicking a link, opening an attachment, or entering credentials on a fake page.

Spear phishing and business email compromise. A more targeted version, often using real names, real project details, or a spoofed executive’s identity to request a wire transfer, gift card purchase, or sensitive file — built specifically for one person or one company rather than blasted out broadly.

Vishing (voice phishing). A phone call impersonating IT support, a vendor, or even a company executive, asking for a password reset, a code from an MFA prompt, or remote access “to fix an urgent issue.”

Pretexting. An attacker builds a plausible cover story — a new vendor, an auditor, a job candidate — to get information or access that seems reasonable to hand over in the moment.

Physical social engineering (tailgating). Someone in a delivery uniform or carrying a box, walking in right behind an employee who holds the door — no badge, no password, no technical exploit needed at all.

MFA fatigue and push bombing. Covered in more detail in an earlier post, but worth repeating here: this is social engineering aimed squarely at exhausting a user into approving something they shouldn’t.

Why “Just Train Them Once” Doesn’t Work

A lot of businesses treat security awareness as a once-a-year checkbox: a video, a quiz, done. The problem is that social engineering tactics evolve constantly, and a single annual training session fades from memory long before it’s actually needed in the moment of a real attack. Effective awareness isn’t a one-time event — it’s an ongoing habit built through regular, low-friction reinforcement: periodic phishing simulations, short refreshers, and a culture where reporting a suspicious email is easy and encouraged, not something people avoid out of embarrassment.

Turning Users Into a Real First Line of Defense

Make reporting effortless. If flagging a suspicious email takes more than a couple of clicks, most employees won’t bother. A simple “report phishing” button integrated into the email client removes the friction and turns every employee into an early-warning sensor for the whole company.

Run realistic phishing simulations regularly. Not to catch people out and shame them, but to build the reflex of pausing before clicking. Employees who’ve seen a realistic simulated phishing attempt are measurably better at spotting the real thing later.

Normalize verification, especially for money and access requests. Any request involving a wire transfer, gift cards, credential resets, or unusual access should have a built-in verification step — a callback to a known number, a second approver — regardless of how urgent or how senior the requester appears to be. This single habit stops the majority of business email compromise attempts cold.

Remove the shame from getting it wrong. The employee who clicked a phishing link and immediately reported it is a security asset. The employee who clicked, panicked, and said nothing for three days is how a minor incident becomes a major one. A culture where people report mistakes quickly, without fear of blame, is one of the single highest-leverage security investments a business can make

Pair awareness with technical guardrails. User training reduces how often someone falls for an attack — it doesn’t reduce it to zero, and it shouldn’t have to. Email filtering, MFA (ideally FIDO2-based, as covered in an earlier post), and least-privilege access limit the damage on the occasions training doesn’t catch it.

The Bottom Line

Every technical control your business invests in exists to catch what gets past the first line of defense — and that first line is your people. Firewalls don’t get phished. Employees do. Treating security awareness as an ongoing habit rather than an annual formality, and building a culture where reporting is fast and blame-free, does more to stop real-world breaches than almost any single piece of hardware you can buy.

Assessing how your team currently handles phishing and social engineering attempts — and where the gaps actually are — is part of every Bullroar Cyber Threat Assessment Program engagement.

The AI Arms Race: Why Attackers Are Winning the Speed War

Aaron Wickware, 5/19/2026

The AI Arms Race: Why Attackers Are Winning the Speed War

Every security vendor is talking about “AI-powered protection” right now, and most of it is real — machine learning genuinely does help detect anomalies faster than a human analyst staring at logs ever could. But there’s an uncomfortable asymmetry nobody likes to say out loud: attackers get to use AI too, and right now, they’re using it to move faster than most defensive AI can keep up with.

Why Attackers Have the Easier Job

Defensive AI has to be right almost all the time. It has to tell the difference between a legitimate software update and malware, a normal login from a traveling employee and a stolen credential, an unusual-but-fine business process and a data exfiltration attempt — all while generating as few false alarms as possible, because a security team that gets flooded with false positives starts ignoring alerts altogether.

Offensive AI doesn’t have that constraint. An attacker only needs one success. They can generate a thousand phishing variations, throw them all at a target list, and only care about the ones that get through. The math favors the attacker by default — they’re playing a volume game with no penalty for the misses, while defenders are playing a precision game where a single miss can be the whole incident.

What AI-Accelerated Attacks Actually Look Like Right Now

Phishing that doesn’t read like phishing anymore. The broken English and generic “Dear Customer” phishing emails of a few years ago are increasingly a thing of the past. Large language models let attackers generate fluent, contextually appropriate emails at scale — and with enough scraped LinkedIn data or a breached vendor list, those emails can reference real names, real projects, and real business relationships convincingly enough to fool a busy employee.

Voice cloning for business email compromise. A short public sample of someone’s voice — a webinar, a podcast appearance, a company video — is now enough to generate a convincing synthetic voice call. Combined with a spoofed caller ID and a plausible urgent request, this has already been used in real wire fraud incidents where an employee received what sounded exactly like a call from their CEO.

Automated vulnerability discovery. AI tools can scan code and network configurations for exploitable weaknesses far faster than manual research, compressing what used to take skilled attackers days or weeks into hours. The gap between a vulnerability being disclosed and it being actively exploited in the wild keeps shrinking as a result.

Malware that adapts on the fly. Rather than shipping one static piece of malware that a signature-based antivirus can eventually recognize, AI-assisted tooling lets attackers generate constantly mutating variants, making traditional signature detection meaningfully less effective than it was even a few years ago.

Faster, more convincing reconnaissance. AI tools can process a target’s public digital footprint — social media, press releases, job postings, vendor relationships — and assemble a detailed target profile in minutes, work that used to require a human analyst hours of manual digging.

Why Defensive AI Genuinely Struggles to Keep Pace

Defensive AI models are typically trained on historical attack patterns. That works well against known techniques, but AI-generated attacks are specifically good at producing novel-looking variations that don’t match a known signature or pattern closely enough to trigger detection — by design, not by accident.

There’s also a resource asymmetry: a single attacker with access to commodity AI tools can generate an enormous volume of attack attempts cheaply. Defensive systems have to inspect, evaluate, and make a correct call on every single one of those attempts, in real time, without slowing down legitimate business activity. Attackers get to fail cheaply and repeatedly. Defenders don’t get that luxury.

So What Actually Helps?

This isn’t a reason to give up on AI-assisted defense — it’s a reason to be honest about what it can and can’t do on its own.

Layered detection, not a single AI tool. No single defensive product is going to catch everything. Behavioral analysis, network-level monitoring, endpoint detection, and email filtering working together catch far more than any one layer alone, precisely because an attack that slips past one layer often trips a different one.

Faster human review of what AI flags. AI is genuinely good at surfacing anomalies faster than a human could find them manually. It’s not yet reliably good at making the final judgment call on ambiguous cases. The businesses that fare best pair AI-driven detection with fast, well-trained human review of what gets flagged — not AI running fully unsupervised.

Reducing the attack surface that AI-driven attacks depend on. A lot of what makes AI-accelerated attacks effective — phishing that gets through, credentials that get reused, VPN appliances sitting exposed on the internet — are the same fundamentals covered in a solid security program regardless of how sophisticated the attack gets. Fewer entry points mean fewer places an AI-generated attack can even land.

Assume the human layer is the real target. Since AI-driven attacks are increasingly optimized to fool people rather than systems — convincing phishing, cloned voices, well-researched pretexting — ongoing user awareness training matters more, not less, in an AI-accelerated threat landscape.

The Bottom Line

AI hasn’t broken cybersecurity, but it has changed the pace of the fight, and right now attackers are better positioned to exploit that speed than most defenders are to match it. The businesses that hold up aren’t the ones chasing the newest AI-branded security product — they’re the ones with layered defenses, monitored networks, and a realistic understanding of where the human layer is exposed.

Evaluating where your business is exposed to these faster, more convincing attack techniques is part of every Bullroar Cyber Threat Assessment Program engagement — no cost, no obligation, just a clear picture of where the real gaps are.