Breaking News

GLOBAL Wi-Fi NEWS bulletin

Strategic partnership reinforces U.S. investment, enhances supply chain security, and launches new era of domestic production

Highlights:

  • U.S.-based TP-Link deepens its commitment to investing in America, partnering with American electronics manufacturer Key Tronic to assemble network routers in America.
  • Wi-Fi 8 products are expected to be among the first to roll off the new U.S. production line in Corinth, Mississippi, as part of TP-Link’s broader domestic manufacturing roadmap.
  • The LOI marks the beginning of a new chapter in TP-Link’s U.S. growth story, building on years of investment in American jobs, infrastructure, and supply chain security.

IRVINE, Calif. — OCTOBER 19, 2026 — TP-Link Systems Inc., a global leader in networking and smart home solutions, today announced that it has entered into a Letter of Intent (LOI) with Key Tronic Corp., a premier U.S.-based electronics manufacturer, to bring next-generation product assembly to the United States. The LOI is a significant step in California-based TP-Link’s long-term commitment to expand domestic manufacturing and strengthen supply chain resilience within the U.S.

Under the LOI, the parties intend for Key Tronic to become a primary domestic manufacturing partner for TP-Link, supporting assembly of the company’s advanced networking portfolio in Corinth, Mississippi. Pending U.S. regulatory approval, TP-Link expects domestic assembly of its groundbreaking Wi-Fi 8 home networking product line to begin as early as next year. The partnership is part of TP-Link’s long-term effort to accelerate U.S. investment in high-tech manufacturing and job creation, designing and assembling next-generation products for American consumers here on American soil.

“This LOI with Key Tronic demonstrates our firm commitment to expanding domestic advanced manufacturing, and establishing America as our base for delivering secure, reliable connectivity solutions to households and businesses around the world,” said Jeffrey Chao, Chief Executive Officer of TP-Link Systems Inc. “By choosing to assemble cutting-edge products here at home, we are thrilled to support U.S. high-tech job growth and empower a new generation of American innovation and innovators.”

“Key Tronic is proud to partner with TP-Link as it expands its commitment to domestic manufacturing and works to bring high-tech networking assembly back to American soil,” said Brett Larsen, President and Chief Executive Officer of Key Tronic. “Our production footprint will give TP-Link a strong domestic foundation, and our experience in high-reliability electronics manufacturing will help support the company’s new generation of Wi-Fi 8 technologies.”

The LOI with Key Tronic represents an important milestone in TP-Link’s U.S. investment roadmap and its commitment to building a resilient and secure domestic manufacturing operation. This is the beginning of TP-Link’s next chapter, one defined by American investment, jobs, and innovation.

About Key Tronic

Key Tronic is a leading contract manufacturer offering value-added design, sourcing and manufacturing services from its facilities in the United States, Mexico, and Vietnam. The Company provides its customers with full engineering services, materials management, worldwide manufacturing facilities, assembly services, in-house testing, and worldwide distribution. Its customers include some of the world’s leading original equipment manufacturers. For more information about Key Tronic visit: www.keytronic.com

About TP-Link Systems Inc.

Headquartered in the United States, TP-Link Systems Inc. is a global provider of safe, secure and reliable networking devices and smart home products. The company is committed to delivering innovative products that enhance people’s lives through faster, more reliable connectivity. With a commitment to excellence, TP-Link serves customers in over 170 countries and continues to grow its global footprint.

For more information, visit https://www.tp-link.com/us/

Plume Console gives every ISP team AI agents that autonomously find and resolve complex subscriber issues, turn months of analysis into a few clicks, while enabling operators to cut cost to serve, reduce churn and uncover new revenue opportunities

VIENNA and PALO ALTO, Calif., Oct. 13, 2026 — Plume Design, Inc. (“Plume”), the award-winning AI-native platform used by more than 450 internet service providers (ISPs) across 60+ countries to run the securely connected home, today introduced Plume Console at Network X in Vienna. Built on the Plume platform, Plume Console gives ISP teams a single place to investigate subscriber issues, create and deploy agents, and direct actions across Plume WiFi, Plume Security, Plume Care and their existing business systems. It puts the platform’s intelligence and automation directly in the hands of the teams responsible for subscriber experience and business performance.

Plume Console directs AI at the world’s most comprehensive data fabric, drawn from more than 50 million homes, 600 million securely connected devices, and 3000 profiled applications. Finding the root cause of a complex issue, spotting a churn indicator or identifying a revenue opportunity can take an ISP’s data science team months. With Plume Console, any team member can get a recommended next step in a matter of clicks.

“AI is changing how people interact with technology, and soon agents will be making more decisions and taking more actions on their behalf, and for ISPs, that raises the stakes for connectivity, security and trust,” said Dan Herscovici, president and CEO of Plume. “A decade ago, Plume pioneered cloud-managed WiFi and changed how ISPs manage the connected home. With Plume Console, our partners can build and direct agents that uncover problems, resolve subscriber issues and identify opportunities for growth across their business. We helped ISPs navigate the last major shift in connectivity. Now we’re giving them the intelligence, control and freedom to lead the next one, with a future-proof platform that works across their hardware, existing systems and AI models.”

For longtime Plume partner NOS, Plume Console represents that vision in practice, giving ISP teams new ways to turn intelligence into action across WiFi, security and care.

“We are excited about Plume Console because it is a significant step forward in how we deliver and care for the connected home,” said José Pedro Teixeira, Director of Product Management at Portuguese provider NOS. “Plume listened to what service providers like NOS need and built a product for how ISPs will operate in the AI era. It gives our teams actionable intelligence across WiFi, security and care. Plume Console puts AI to work for our teams, turning insights into action and resolving issues before they lead to a truck roll or subscriber churn. With Plume Console, we can deliver a better subscriber experience and better business outcomes at the same time.”

Built to address 100% of subscriber experience issues
For ISPs, the last stretch of connectivity inside the home can decide whether a subscriber stays or leaves. A speed test at the gateway can look healthy while a television buffers, a camera loses its connection or a video call drops, leading to a technician visit or a lower Net Promoter Score (NPS).Plume is built to address the full spectrum of subscriber experience issues. Today, the Plume platform autonomously resolves most issues through continuous WiFi optimization, security, and established automation. The remaining issues require care workflows, further investigation or intervention, and Plume Console equips ISP teams to tackle them, increasingly using agents to investigate, recommend and execute actions across connected systems. Every issue a Plume agent resolves can become an automation, so the share the platform resolves on its own grows over time. A recent study found that homes using Plume’s technology had 31% lower churn, 20% fewer technician visits and a 16% improvement in NPS compared with homes not using Plume.

An agentic workforce, designed and directed by the ISP
Plume Console lets ISP teams leverage agents that autonomously identify issues and potential actions, often with just a few clicks. Teams can deploy Plume’s pre-built agents, create new ones using an agent builder, or use SQL and templates to modify as needed. Agents can identify an issue, provide notification or resolve it. Using webhooks, MCP and APIs, Plume Console also connects the Plume platform to other systems for action, including service ticketing, CRM campaigns and digital care. Teams can also validate that each agent delivers reliable guidance before acting on or recommending it.

One data fabric, every team
The same data serves every team that shapes the subscriber experience:

  • Network operations can see how a single-location issue can impact locations across the network, and deploy an agent to address it.
  • Security analysts see every device, application and agent action in context, and can quarantine a device or set policy.
  • Care teams can investigate home connectivity details for context, with agents guiding them to the right resolution.
  • Marketers use Plume research agents to find opportunities hidden in operational data and then share insights and recommendations with CRMs to activate revenue growth campaigns.
  • Developers can build their own agents using structured data tables, APIs, MCP, agent cookbooks and recipes with the ability to connect via webhooks to ISP tech stacks.

A securely connected home that learns from every network
Lessons learned on one network strengthen every network on the Plume platform. When Plume Security Labs uncovered “SuperProxy,” in which streaming devices silently enrolled homes in residential proxy networks that later delivered malware, the signatures behind that discovery began protecting other ISPs on the platform without those ISPs having to find the threat themselves. Plume Security protects every device from the gateway, with no software to install, and blocks six million threats a day.

“In a securely connected home, WiFi and security shouldn’t be managed separately, and no ISP should be responsible for discovering every threat on its own,” said Chris Griffiths, Plume’s chief technology officer. “When the Plume platform learns something in one network, every network benefits. Plume Console shows teams what was found and what the platform did about it, so they can act with full context while the ISP stays in control as automation grows.”

Alan Coleman, Plume’s chief product officer, said, “AI can optimize and protect an ISP’s WiFi network in two critical ways. The first is predictable: governed, prescribed workflows that optimize WiFi and keep security always on, resolving most issues efficiently and consistently. The second is where Plume Console shines: the open-ended problems with no established fix. Teams can direct a collection of agents to work together, investigate what is surfacing in the network and recommend the next step, while people set the guardrails and make decisions.”

Availability and demonstrations
Plume Console will be demonstrated at Network X, Oct. 13-15, at VIECON in Vienna. Journalists attending the event are invited to see how Plume Console lets ISP teams design, deploy and manage an agentic workforce across WiFi, security and digital care. Learn more about Plume Console at plume.ai/console

To arrange a demonstration or executive interview, contact [email protected].


About Plume
Plume created the first managed WiFi platform for Internet Service Providers (ISPs) in 2016, enabling the company to scale across the globe and expand into managing the entire subscriber experience, including approximately 600 million connected devices, in 50 million homes, on behalf of more than 450 ISPs, across 61 countries. By integrating managed WiFi, cybersecurity and customer care, Plume created the first open, hardware-agnostic SaaS Subscriber Experience Platform for ISPs. Powered by an unmatched global dataset and AI optimization, the Plume platform builds subscriber confidence through improved WiFi experiences, seamless new service implementation and proactive customer care. Plume’s open-source framework OpenSync® is pre-integrated and supported on the leading silicon, CPE and platform SDKs, and supports leading industry standards like RDK-B and prplWave. Discover more at www.plume.com.

In this article
  • HPE is contributing to open, diverse technologies across the stack in compute, networking and large-scale HPC and AI systems
  • HPE and partners are already deploying next-generation AI systems with OCP contributed designs

Why future AI data centers need to be open and heterogeneous

AI is evolving to be more than just a workload.

As initiatives transition from training to inferencing, from generative AI to agentic AI, AI will increasingly operate as a service and run across distributed environments, like the edge, cloud, and sovereign systems.

Future AI systems will also be heterogenous. Instead of being dominated by one architecture or platform, different workloads with different needs will require a diverse mix of accelerators, processors, and infrastructure.

Yet with the next era of AI comes a new set of IT requirements that we have to prepare for now.

AI will grow into a larger ecosystem. That ecosystem has to be interoperable to work seamlessly.  

Reimagining a new operating model for AI

In order to work, AI will require a new operating model that features core elements:

  • Scalable compute to reliably run workloads across distributed environments
  • Optimized performance for faster storage and greater networking efficiency
  • Heightened security to protect all data, models, and AI-generated insights
  • Operational efficiency to manage infrastructure, energy, productivity and cost

Additionally, as AI scales and innovation broadens – just as we’re seeing with an emergence of neoclouds, colocation providers, and sovereign AI programs – AI will grow into a larger ecosystem. That ecosystem has to be interoperable to work seamlessly.

To ensure effective design and implementation of key capabilities, along with a resilient ecosystem, we have to take an open compute standards-based model approach to make the future of AI successful.

Making AI open and heterogeneous at every layer

At this year’s OCP Global Summit, HPE is demonstrating our ongoing commitment to contributing to open compute and ushering in a new era of AI.

We also believe that the future of AI will be more heterogenous and open compute will be critical to effectively integrate diverse silicon architectures to deliver purpose-built end-to-end solutions for AI.

As a leader in designing and delivering fully integrated systems, from the edge to exascale, we are bringing open, heterogenous technologies to every layer of the stack: compute, networking, and large-scale HPC and AI systems.

Open compute: Advancing modular, secure, AI-accelerated compute from the edge to cloud

To support a rapidly evolving AI landscape, including the transition to agentic AI and inference, we are providing enterprises with open standards-based modular compute that we continue to advance with our newly launched HPE ProLiant Gen13 servers.

Our new open compute, which includes the HPE ProLiant DL525, DL585a, XD245 and XD285 Gen13 servers, delivers a flexible design for agility to run various workloads, and scale as needed. HPE ProLiant servers are also deeply rooted with trust, and the latest generation builds on our leadership chip-to-cloud security to protect data and system integrity through automatic security from HPE Integrated Lights-Out 8 (iLO 8) with enhanced HPE Compute Ops Management.

Open networking
: Ethernet-based scale-up, scale-out, and scale-across

Open Ethernet is fundamental to future AI data centers, and we’re an industry leader in open Ethernet-based scale-up, scale-out, and scale-across.

In addition to offering options in network operating systems, like SONiC, our switches have embraced open industry specifications and initiatives, such as Open Rack V3 (ORv3), Ultra Ethernet Consortium (UEC), Ethernet for Scale-Up Networking (ESUN) and Ultra Accelerator Link (UALink). These developments help build interoperable and standards-based networking for AI infrastructure.

We are the first OEM to extend open Ethernet in rack-scale level infrastructure with scale-up switches that we are delivering through the AMD Helios™ AI Rack by HPE systems. Enterprises are already adopting these rack-scale solutions to speed up their AI initiatives.

Open large-scale AI systems: Leadership-class supercomputing and AI infrastructure

Scientists and researchers are turning to solutions that effectively converge modeling and simulation with AI to accelerate scientific discoveries. These workloads require extreme scale with greater flexibility and density to maximize existing capacity and resources.

We’re building on our proven world-leading exascale-class supercomputing with next-generation open infrastructure, the HPE Cray Supercomputing GX5000, to deliver unprecedented performance with the industry’s highest density for large-scale HPC & AI workloads. The GX5000 offers various blades that feature the industry’s latest CPUs and accelerators to provide computing options that address specific workload needs.

The GX5000 also features HPE Slingshot networking based on Ultra Ethernet Consortium (UEC) specs, in addition to supporting third party components and switches.

Extending decades of direct liquid cooling leadership to AI

As a leader in direct liquid cooling, with more than 50 years of expertise and 300 technology patents, we are building on our innovation to support higher thermal capacity for high-powered CPUs and accelerators across our open compute and large-scale HPC & AI systems.

Latest innovation also includes the industry’s first direct liquid cooled ORV3 switch, a next-generation Open Rack capability, to handle extreme heat for modern AI data centers.

Join HPE at OCP Global Summit 2026 at booth D24

OCP will bring immense benefits to AI. It will pave the way for a new ecosystem that will help organizations reliably scale, achieve operational efficiency, and lower costs.

We are committed to making ongoing contributions to OCP and look forward to highlighting our vision and solutions for open technologies at OCP Global Summit.

I encourage you to join us at our booth D34 to learn more about our open, heterogenous solutions, attend our sessions, including our keynote at on Tuesday, October 13 at 10:15am PT.

Come speak with our team on how we can work together to contribute to OCP and power a new era of AI!

Fix Teams, Zoom, and Webex Wi-Fi Issues | 7SIGNAL

Video meetings are the least forgiving applications on the network, and most of them start on Wi-Fi. 7SIGNAL gives IT teams continuous, AI-powered visibility into the wireless experience behind every Teams, Zoom, and Webex call, helping you prove whether the Wi-Fi is the problem and fix it fast when it is.

One Bad Minute Can Ruin an Entire Meeting

Collaboration platforms are mission-critical applications. One bad minute of interference or congestion can ruin a sales call, a board meeting, or a telehealth visit. Unlike email or file sync, real-time audio and video cannot wait for a retransmission; they degrade the moment the connection does.

What Users Notice Likely Network Cause
Frozen or pixelated video Packet loss or bandwidth dropping below what video needs
Robotic or choppy audio Jitter: packets arriving at uneven intervals
Talking over each other High latency delaying what each participant hears
Dropped calls A failed roam, a connectivity failure, or a sticky client

Five Wi-Fi Problems Behind Most Bad Calls

7SIGNAL diagnoses Wi-Fi problems across five performance dimensions: Roaming, Coverage, Congestion, Interference, and Connectivity, giving IT teams a structured framework for resolving wireless issues.

Roaming

Sticky clients and slow handoffs break calls when people move between rooms or floors.

Coverage

Conference rooms, corner offices, and home setups at the edge of an access point’s range run on weak signal.

Congestion

Busy meeting rooms and open offices put dozens of devices on the same access point at the same time.

Interference

Overlapping channels and neighboring networks raise retries, which raises jitter and latency.

Connectivity

DHCP, DNS, authentication, and gateway failures can look exactly like an app problem.

Why Meeting App Problems Are So Hard to Diagnose

Teams, Zoom, and Webex each report call quality from inside their own platform, but they cannot tell IT why the Wi-Fi underneath degraded. Infrastructure dashboards show access point health, not what the laptop experienced during the call. When a meeting fails, one side blames the network, the other blames the device, and the problem is gone before anyone can look.

Without independent, device-level data, IT cannot tell whether the cause is the Wi-Fi, the device, the wired network, the ISP, or the app itself.

7SIGNAL is a category leader in client-side Wi-Fi visibility, measuring wireless experience from the endpoint device rather than only from the access point or infrastructure side.

Brief Wi-Fi Failures Become Lost Time and Lost Deals

Gartner estimates enterprise network downtime at $300,000 per hour, while IDC places critical application failure as high as $500,000 per hour. For collaboration, 7SIGNAL measures the cost directly: it adds up every critical minute of poor performance across a device fleet and reports the productivity lost.

  • $300K per hour: enterprise network downtime
  • $500K per hour: critical application failure
  • $7,900 per minute: data center downtime

Brief Wi-Fi degradation → Frozen, garbled, or dropped call → Lost productivity and lost business

How 7SIGNAL Solves Teams, Zoom, and Webex Connectivity Issues

7SIGNAL works alongside your existing wireless infrastructure and measures the Wi-Fi experience behind collaboration apps like Teams, Zoom, and Webex. Its agents and sensors continually test connectivity to the internet and cloud services, and measure the voice-quality indicators that predict a good call, including MOS, jitter, and packet loss.

  • 7SIGNAL Agents Deploy on supported Windows, macOS, Linux, and Android endpoints to capture roaming, signal, latency, jitter, packet loss, and application reachability from each participant’s device.
  • 7SIGNAL Sensors Continuously test Wi-Fi in conference rooms, open offices, and collaboration spaces, detecting congestion, interference, coverage, and connectivity issues before the next meeting starts.
  • EYERIS AI Correlates device, network, and environmental data to distinguish among client, driver, access point, DHCP, interference, and configuration issues, and tells your team what to do next.
  • 7SIGNAL MCP Integration 7SIGNAL integrates with large language models through the Model Context Protocol (MCP), allowing customers to bring 7SIGNAL Wi-Fi performance data directly into their AI assistants for diagnostics, ticket creation, and natural-language analysis.

7SIGNAL is designed to deploy alongside, not replace, leading wireless infrastructure platforms including Cisco Meraki, Juniper Mist, Aruba Central, and Extreme Networks, providing the independent client-side visibility that infrastructure-side platforms cannot capture on their own. Enterprises typically achieve complete Wi-Fi observability by combining their chosen infrastructure platform with 7SIGNAL.

AI-Driven Diagnostics Compress Hours into Minutes

7SIGNAL helps IT teams move from reactive firefighting to proactive support for every meeting, on every platform.

01

Detect:

Find roaming, latency, packet loss, and DHCP anomalies.

02

Correlate:

Connect device, RF, infrastructure, and location data.

03

Diagnose:

Identify the real source instead of dispatching a technician blindly.

04

Recommend:

Provide prescriptive remediation guidance.

05

Protect Uptime:

Resolve issues before meeting participants feel them.

Finding the Real Cause Behind “Slow Wi-Fi”

When a regional office of a large health insurance provider reported slow Wi-Fi, 7SIGNAL sensors quickly showed that the real issue was the broadband connection, not the wireless network. Because the sensors monitor both wired and wireless performance, the team avoided chasing a Wi-Fi problem that didn’t exist. The organization now runs nearly 100 sensors across the enterprise, with alerts that trigger when performance deviates from defined thresholds.

“With 7SIGNAL, I can triangulate the problem and solve it in one-tenth the time.”

  • Wireless Network Engineer, large health insurance provider

Measurable Results IT Leaders Can Take to the Business

7SIGNAL delivered a documented 670% three-year ROI and 43% reduction in network downtime in an independent IDC study, making it one of the most measurably valuable Wi-Fi monitoring platforms in the enterprise category.

10 Steps to Solve Teams, Zoom, and Webex Wi-Fi Issues

  1. Measure from the participant’s device. The app reports that a call was poor; device-level Wi-Fi data explains why.
  2. Track MOS, jitter, and packet loss continuously. Watch the indicators that predict call quality, not just signal strength.
  3. Classify every problem by root cause. Sort degraded calls into roaming, coverage, congestion, interference, or connectivity.
  4. Test conference rooms before meetings, not during them. Sensors in meeting spaces catch congestion and interference ahead of time.
  5. Detect sticky clients. Find laptops that stay on distant access points instead of roaming as people move.
  6. Separate Wi-Fi from ISP and wired issues. Test gateway and internet connectivity alongside Wi-Fi so tickets reach the right owner.
  7. Prioritize real-time media. Apply QoS policies and steer devices to less crowded 5 GHz and 6 GHz bands.
  8. Standardize Wi-Fi drivers. Use performance data to identify driver versions associated with roaming and call-quality failures.
  9. Report critical minutes of poor performance. Show leadership how many productive hours degraded Wi-Fi costs across the fleet.
  10. Use AI to shorten triage. Ask EYERIS or your AI assistant which users had the worst call quality this week, and why.

Wi-Fi Uptime Protects the Metrics IT Leaders Already Track

Business leaders measure collaboration in productivity, customer experience, and support cost. Meeting connectivity touches every one of those metrics.

  • Productivity: Recover the hours lost to frozen, dropped, and rescheduled meetings.
  • Revenue Conversations: Protect the sales, support, and partner calls that run on video.
  • Employee Experience: Stop call quality from becoming a daily frustration.
  • Help Desk Labor: Replace unreproducible “Zoom is broken” tickets with device-level evidence.
  • Platform Flexibility: Monitor the Wi-Fi experience behind every collaboration tool the business uses.
  • Scale: Support more users, rooms, and sites without adding equivalent monitoring headcount.

AsiaRF x SKYDD 2026

CONNECTING SECURITY.
PROTECTING WHAT MATTERS.

Next-Gen Connectivity for Security & Public Safety
Wi-Fi HaLow • Edge AI • Body-Worn Camera
Built for Connected Security in Demanding Environments

? 20–22 October 2026

? Stockholmsmässan, Stockholm, Sweden

? Booth  : A21:45

FIND US ON THE EXHIBITION MAP : https://reurl.cc/7YNqZb

#SKYDD2026 #AsiaRF #WiBRAVO #SecurityTechnology #PublicSafety #WiFiHaLow #EdgeAI #BodyWornCamera

When a store’s point-of-sale (POS) system stalls during a holiday rush, the impact means longer lines, frustrated shoppers, and missed sales. Peak shopping periods test more than staffing and inventory. They test whether the store’s network can keep everything connected and running reliably under pressure—from the guest Wi-Fi to in-store cameras.

For most retailers, the pressure doesn’t stop at the front door. It stretches across stores, warehouses, back offices, e-commerce, and a growing list of connected devices, all while lean IT teams juggle more with fewer hands.

Stores have become connected, data-driven experience centers. AI, the Internet of Things (IoT), mobile workflows, and omnichannel expectations are placing growing demand on the network at the edge—demand that traditional infrastructure was never built to carry.

So what does keeping up require? Retail IT leaders need a network that’s secure, simple to run, and ready for whatever comes next. This is where Cisco comes in, bringing networking, security, and AI-driven operations together in one platform.

Keeping stores running through peak season and lean teams

Retail demand rarely holds steady. Promotions, peak seasons, and new omnichannel services create bursts of traffic that can expose weak points fast. Shoppers also expect high-bandwidth, low-latency connectivity for mobile checkout, dynamic pricing, and AI-driven experiences.

Guest Wi-Fi adds another layer to that demand, staying fast and reliable at every location without becoming a separate network for a small team to manage.

Retailers are also running more locations with fewer people to manage them. This means keeping policy, visibility, and connectivity consistent across dozens or hundreds of stores without adding headcount every time the business grows.

Mike’s Bikes felt the strain firsthand as it expanded its network to 12 Bay Area locations. Working with Cisco Select Partner Stratus Information Systems to set up and roll out networking and security and introduce new automation like digital price tags, the retailer built a foundation that delivered seamless operations, letting the team focus on maintaining the small bike shop feel that started years earlier, even as the business grew.

SAMSØE SAMSØE faced a similar challenge at a much larger scale, growing to 69 locations in 19 countries. Centralized management through the Cisco Meraki dashboard and templated deployments let the retailer launch new stores with up to 66% less IT effort. Different scale, same lesson. Growth shouldn’t strain the team running the network.

Protecting a growing mix of connected devices

That same distributed footprint raises the stakes for security. Every camera, digital sign, sensor, and POS terminal added to a store is another endpoint, and another potential risk.

Retailers must maintain payment card industry (PCI) compliance across thousands of connected devices while guarding against cameras and digital signage that can become entry points. Physical security and cybersecurity are no longer separate jobs.

As a result, secure networking becomes foundational. Room & Board, a modern furnishings retailer, built its operations on a secure networking foundation from Cisco, including Cisco Meraki MX, Cisco Catalyst SD-WAN, and Cisco Umbrella. The retailer also uses cloud-managed Cisco Meraki MS switches for access switching in its retail locations, with Cisco Catalyst switches anchoring the core network.

That reliability matters most on the sales floor, where design associates rely on tablets to guide customers through frequently changing showroom displays. With a lean, three-person IT team, Room & Board leveraged the platform’s AgenticOps capabilities, including AI-Enhanced Radio Resource Management (AI-RRM) and the Cisco AI Assistant, to manage that wireless network with minimal hands-on effort.

“The convergence of security and network infrastructure is just that—it’s there. It’s built in at the base layer of the Cisco solution,” said Mark Rodrigue, Senior Network Engineer, Room & Board. For a lean IT team, this built-in approach removes the friction of stitching together multiple point solutions.

Building security and simplicity into the same platform

This convergence extends beyond security alone. Retailers don’t need another disconnected tool bolted on top of the network. They need one platform, bringing together networking, security, and observability, that helps retailers run simply, stay secure by design, and scale for AI.

Operational simplicity matters as much as security. A “one platform, one policy” approach helps smaller retail IT teams manage many locations from a single source of truth instead of juggling separate systems for each site.

AgenticOps is Cisco’s approach to AI-assisted network operations, combining automation, assurance, and human oversight to help teams understand user experience, diagnose issues, take action, and validate results. For retailers, it can help detect problems earlier, resolve them faster, and reduce disruption to store operations. Pairing it with end-to-end visibility across owned and unowned environments helps shorten resolution time.

Visibility matters because so much of retail depends on services outside a retailer’s direct control. It’s exactly why Room & Board relies on Cisco ThousandEyes. “ThousandEyes helps us deliver the quality experience that we want to put forward to our employees and customers,” Rodrigue said.

Scaling the network as the business grows

Built-in security and simplicity only matter if the network can grow with the business. A refresh means more than swapping out old hardware. It means making room for AI-powered analytics, real-time video, and connected store experiences, without adding complexity for lean IT teams.

For growing retailers, the Meraki dashboard brings together Cisco wireless access points, Cisco Secure Routers, Meraki MV cameras, and Cisco Assurance from ThousandEyes. Together, they give IT teams one place to manage their networks across stores, strengthen security, and scale as the business grows.

SAMSØE SAMSØE is already treating its network that way. The retailer describes Wi-Fi 7 as a platform for innovation, powering a new loyalty program, smoother POS operations, and soon, smart dressing rooms. “It’s no longer just the Wi-Fi access point. It’s a data entry point for us,” said Simeon Solarsky, Head of IT Infrastructure and Operations at SAMSØE SAMSØE.

That’s the shift retailers need to plan for, as the network itself becomes part of the shopping experience.

Staying secure, simple, and ready for what’s next

Modern retail networks have to carry more than traffic. They have to keep the POS system running during the holiday rush, keep guest Wi-Fi steady across every location, and keep every connected camera, sensor, and device protected without adding more work for a lean IT team. The retailers best prepared for what’s next are building networks that are secure by design, simpler to manage, and ready to scale when demand spikes.

Every IT team knows employees are using AI tools nobody approved. Most have accepted it as a cost of doing business. Our new research shows that cost is already being paid in security incidents.

In June 2026, DNSFilter and CensusWide surveyed 400 IT and cybersecurity professionals across the US and Canada for The Visibility Deficit: The 2026 AI Cybersecurity Report. AI adoption is effectively universal: 99.75% of respondents say someone in their organization uses AI tools at work, and 55% run three to five of them. Nearly half of organizations (46%) have had an employee connect an unauthorized AI tool directly to corporate systems. For one in five (20.1%), that connection caused a security incident. Another 14.8% suspect it happened but can’t confirm it.

The incidents are already here. The bigger problem is how few organizations see them coming.

What Is Shadow AI?

Shadow AI is any AI tool, model, browser extension, or agent that employees use or connect to corporate systems without IT’s approval or knowledge. It includes chatbots used through personal accounts, AI features inside approved SaaS apps that were never reviewed, and AI tools granted OAuth or API access to company email, files, or code repositories.

This increased risk comes from access. Once a tool holds a token to corporate data, it can read, store, and move that data without anyone reviewing each step. An employee pasting text into a chatbot exposes what they paste. An AI tool connected through OAuth can reach everything the employee can.

A Visibility Problem, Not a Policy Problem

Most organizations already have rules for AI. 81% have a formal AI tool policy in place, and 55.75% say it’s consistently enforced. The gap is that a policy only works when someone can see it being broken.

When a new AI tool requests OAuth or API access to corporate systems, 43% of organizations let employees grant it themselves. IT either hears about it after the fact or, for 6.5% of organizations, never hears about it at all. Leadership and practitioners also disagree on how tight that gate is: 73.9% of executives surveyed believe new AI tools require admin approval, while only 58% to 60% of practitioners say that approval actually happens.

Detection leans on the same weak link. Asked how they identify incidents involving third-party SaaS or AI tools, 41.5% of respondents rely on user reporting, nearly the same share that use CASB or SaaS security tools (41.75%). In other words, a large share of shadow AI surfaces only when someone happens to mention it. Yet 91.5% are confident they would detect a breach within six hours.

The 20.1% incident rate is also likely an undercount. 37.75% of respondents say their organization has had a security incident that was never formally reported, and 43.5% say their organization has, at times, downplayed the severity of an incident because it lacked the resources to fix it.

Company size also doesn’t solve it. The largest organizations surveyed (2,500 to 5,000 employees) that have the most mature AI governance in the study still report the highest shadow AI incident rate: 32.5% say an unauthorized AI tool caused a security incident. At the smallest organizations (150 to 499 employees), half have already had unauthorized AI tool connections, and 24% say those connections have caused an incident.

Where Shadow AI Hides

Shadow AI rarely looks like a new, unknown application. It usually arrives through one of three routes:

  • OAuth and API grants. An employee clicks “Allow,” and a tool gets standing access to email, files, or code before IT knows it exists.
  • Tool sprawl. Most organizations already run three or more AI tools, and 47.5% of the largest run six to 10, so one more blends into an already crowded inventory.
  • Spend outside procurement. 54% of respondents are concerned about AI costs accruing outside normal procurement visibility, which means tools are being bought and expensed where security never reviews them.

Each route has the same starting point: A tool connects before anyone checks it.

How to Detect Shadow AI

Every AI tool, sanctioned or not, has to resolve a domain before it can do anything. That makes the DNS layer the earliest place to see shadow AI, at the moment a tool arrives instead of the moment it causes a problem. DNSFilter provides DNS-level visibility into the AI tools and agents communicating from your network, secure access for the AI your teams have sanctioned, and governance for the autonomous agents arriving next.

With that visibility, your team can answer three questions that most organizations in our survey can’t:

  • What AI tools are communicating from our network right now?
  • Which of them hold access we never explicitly granted?
  • When the next one shows up, will we know before or after the OAuth screen?

For existing DNSFilter customers, this visibility lives in the dashboard you already use. For MSPs, shadow AI is a client conversation worth having now, especially with SMB clients that carry the heaviest exposure and the least governance. “We have an AI policy” is a different conversation than “we can show you every AI tool talking to your network.”

Get the Full Report

The Visibility Deficit: The 2026 AI Cybersecurity Report covers the complete findings, including the gap between what executives believe and what practitioners see, and how autonomous AI agents raise the stakes. Download the report, or start a free trial to see what’s running on your network today.

Frequently Asked Questions

What is shadow AI?

Shadow AI is any AI tool, model, extension, or agent used or connected to corporate systems without IT’s approval or knowledge. The biggest risk comes from unapproved AI tools granted OAuth or API access to corporate data.

How common is shadow AI?

Very common. In DNSFilter’s 2026 survey of 400 IT and cybersecurity professionals, 46% said an employee had connected an unauthorized AI tool to corporate systems, and another 14.8% suspected it had happened but couldn’t confirm it.

Can shadow AI cause a security incident?

Yes. 20.1% of respondents said an unauthorized AI tool connection caused a security incident at their organization. Among the largest organizations surveyed, that figure rose to 32.5%.

How do organizations detect shadow AI?

Most organizations combine SIEM, CASB or SaaS security tools, audits, and user reporting, and 41.5% of respondents in DNSFilter’s 2026 survey rely on user reporting. Monitoring at the DNS layer shows AI tools when they first connect, before they are granted access to data. DNS filtering is an optimal way to detect unauthorized AI usage on the corporate network, while also providing a way to control that AI usage.

Does an AI policy prevent shadow AI?

Not on its own. 81% of organizations surveyed have a formal AI tool policy, yet 43% still let employees grant AI tools OAuth or API access without prior approval. A policy needs visibility behind it to be enforced. DNSFilter gives you the ability to create an enforceable policy, allowing sanctioned AI tooling and blocking tools that you do not want your employees to access.

Where does this data come from?

Between June 15 and 26, 2026, DNSFilter partnered with CensusWide to survey 400 IT and cybersecurity professionals across the US and Canada. Respondents were manager-level and above at companies with 150 to 5,000 employees, across all industries.

Perfectly good projects are going off the rails and missing their ship dates, because of worldwide chip shortages, as the world’s FABs focus on pumping out AI chips.

As of mid-2026, 32-bit industrial MCUs and power management ICs are running lead times as long as 52 weeks, driven by AI infrastructure eating into the mature foundry capacity that IoT parts depend on. Automotive-grade MCUs are still sitting at 26 to 40 week lead times through Q2 2026. That’s down from the 52+ week peaks of the prior shortage cycle, but still long enough to force a mid-program part change on most connected products.

That number is the actual argument for a Firmware Abstraction Layer (FAL). Not portability as a design virtue. A parts shortage that arrives mid-program and forces a chip swap on a schedule you don’t control.

When that swap happens, the cost depends entirely on how the firmware was written. If power management calls, event loop timers, and socket buffers are wired straight into the original vendor’s SDK, a driver swap turns into a rewrite. That’s especially true when application code up the stack had no business knowing which chip was underneath it. If none of that is wired in, it’s just a new driver behind an interface that hasn’t changed.

The Industry is Moving, But Not Fast Enough To Save You

Silicon vendors know this pain point exists, and 2026 has brought real movement. Silicon Labs launched Simplicity SDK for Zephyr at CES 2026, a QA-tested Zephyr distribution built for its wireless chips. The SDK is MCU-agnostic and lets developers mix MCU vendors inside one project, which is a genuine step toward portability rather than a new flavor of lock-in.

Nordic moved in a similar direction with the nRF93M1, announced at MWC 2026, which ships with built-in coexistence control for Wi-Fi and cellular radios sharing one module.

Both of these solve coexistence within a single vendor’s silicon. Coexistence across vendors is a different problem, and it’s still an open problem at the RTOS layer. Zephyr’s Bluetooth stack currently binds to a single controller, so a product can’t natively run Bluetooth radios from two different vendors at once. A proposal to fix that has been open since July 2025, still not shipped.

So vendors are getting better at owning coexistence on their own chips. Managing radios across vendors is still on the OEM to solve, and that’s exactly what a FAL is for.

Step 1. Identify Every Radio and Every Place They Can Collide

List every radio in the product, whether that’s BLE, Wi-Fi, cellular, or UWB. For each one, write down the vendor, the SDK version, and the frequency band it operates in.

Then map where they can interfere with each other. A Wi-Fi transmission can wipe out an incoming BLE advertising packet on the same band. A cellular modem waking up for a paging window can starve a UWB ranging session of power budget. These collisions come from physics, not software architecture, and a single vendor’s SDK has no idea another radio even exists on the board.

This inventory is the spec for everything that follows. Skip it and you’ll end up designing an abstraction layer for radios that don’t actually fight each other, while missing the pair that does.

Step 2. Design the Power State Machine Before Writing Driver Code

Vendor SDKs manage power per radio. BLE connection intervals, cellular eDRX timers, and Wi-Fi power-save modes each get handled separately, by their own SDK, with no visibility into what the other radios are doing at the same moment.

Replace that with one system-level state machine that every radio driver reports into. Two states cover most products, System_Sleep() and System_Active(). Before switching states, the FAL checks every active radio and picks the lowest power level that all of them can safely handle.

Work out the timing rules on paper first. Decide which radio’s constraints are allowed to hold up a sleep transition and which aren’t. If you get this wrong, you’ll spend the second half of the project chasing power bugs that only show up once two radios are active together.

Step 3. Build One Error Taxonomy Across Every Vendor Stack

A cellular modem times out silently over several seconds. A BLE driver drops the connection instantly with a stack-specific status code that means nothing outside that SDK. If you leave this alone, the application layer will fill up with chip-specific if/else branches for every vendor you’ve ever integrated.

Translate every vendor error into a small set of system-level states instead, things like LINK_TEMPORARY_LOSS or HARDWARE_UNRESPONSIVE. The application layer reacts to these states and never has to know what a specific vendor’s error code means.

This step tends to have the biggest payoff for the smallest amount of code, which is also why teams skip it first under deadline pressure. It doesn’t block a demo. It blocks the fifth product revision, when nobody on the team remembers which vendor’s error code meant what.

Step 4. Put One Component in Charge of Arbitration

Antenna sharing, board-level power rails, shared bus access. When two radios need the same physical resource at the same moment, something has to decide who goes first, and that decision can’t be left to whichever driver happened to initialize last.

Build a single arbitration component that owns every shared resource on the board, and routes every radio driver’s requests through it. Don’t let a driver talk to a shared antenna switch or a shared power rail directly, even when the vendor SDK makes that shortcut tempting.

Most of your real RF debugging time during bring-up ends up here anyway. A clean arbitration boundary keeps those bugs in one file instead of scattered across three different vendor codebases.

Step 5. Wall Off OTA Updates and Certification Scope

Radio firmware updates need their own execution pipe, separate from application code. A failed radio firmware update shouldn’t be able to take down the rest of the product. And when only a wireless component changes, keeping the update isolated means regulatory recertification stays scoped to the radio abstraction module instead of pulling your whole application layer back into scope.

The cost difference here is real. A pre-certified wireless module cuts FCC certification cost by 60 to 80 percent and roughly halves the timeline compared with a custom RF design. Keep the split clean and a wireless-only change stays a wireless-only filing. Mix it with application code, and the whole product can get pulled back into certification scope.

If your OTA pipeline currently pushes application code and radio firmware through the same mechanism, split them now, while it’s a small job, rather than during a hardware revision, when it isn’t a small job anymore.

Where This is Playing Out Right Now

There’s a live example of this on the Zephyr project. A team building on an NXP 88W8987 Wi-Fi combo module wants to add Bluetooth, and the open issue confirms there’s no upstream Bluetooth HCI driver for that chip, even though the Wi-Fi side already works.

The thread lays out three options. Add a second Bluetooth chip from a different vendor. Work from an unofficial vendor driver outside the mainline Zephyr tree. Or redesign the hardware around a different combo chip entirely, which the thread notes isn’t always possible once BOM, supply chain, and certification decisions are already locked in.

Every one of those options costs something, and the reason the team is stuck choosing between them is that nobody drew the FAL boundary early enough. A team that already has a power state machine, an error taxonomy, and an arbitration layer in place can absorb a second radio vendor as a driver-level change. A team without one ends up making this decision in a GitHub comment thread, mid-project, instead of in a design review months earlier. Our previous post goes more into this – Architecting Multi-Radio Embedded Devices with BLE, Wi-Fi, LTE, and UWB.

Decide Ownership Subsystem by Subsystem

You don’t need to own every layer for every product. What matters is deciding, for each of the four systems above, whether you build it yourself or lean on the vendor SDK.

If you’re shipping on a single vendor’s chip for a short product life, with no planned cost-down or radio swap, take the vendor’s SDK as it comes, coexistence tools included. The speed advantage is real, and there’s no multi-vendor problem to solve.

If you’re running radios from more than one silicon supplier, this applies to you. It also applies if you’re building a product line meant to last three to seven years through component shortages and cost-downs. Build the power state machine, error taxonomy, arbitration layer, and OTA isolation yourself. Leave everything else on the vendor SDK.

Most teams don’t need to build a FAL from scratch. They need these boundaries drawn correctly before the second radio vendor shows up as a surprise instead of a plan.

Final Word

Multi-radio products get harder to maintain when the boundaries between vendor firmware and system firmware are unclear. Defining those boundaries early gives your team more options when hardware, suppliers, or product requirements change.

embedUR brings 20 years of experience building wireless stacks, controller firmware, and cross-vendor abstractions for connected products. If you’re planning a multi-radio product or preparing for a hardware refresh, our engineering team can help you define the right firmware boundaries.

Schedule a Firmware Architecture Review with our experts and protect your product roadmap against silicon delays, unexpected chip swaps, and costly recertification cycles.

Manufacturers of wireless devices are always looking to design products that deliver valuable and differentiated experiences to customers. While developing any wireless product involves complexity, building a Z-Wave hub or gateway brings a distinct set of controller responsibilities. The gateway must securely onboard and manage devices from different manufacturers, understand their capabilities through Z-Wave Command Classes, maintain network and device state, manage security and network operations, and support devices with different behaviors and capabilities. Implementing and maintaining this host-side controller functionality can require significant engineering effort before developers can focus on the features and experiences that differentiate their products.

Manufacturers of wireless devices are always looking to design products that deliver valuable experiences to customers. But for developers building Z-Wave hubs and gateways, significant engineering effort is required before creating that differentiated experience.

Network management, secure device onboarding, device discovery, firmware management, application integration, and support for diverse Z-Wave device capabilities all need to work together reliably.

The new Z-Wave Protocol Controller (ZPC) from Silicon Labs is designed to simplify that foundation, helping developers accelerate Z-Wave controller development and focus more of their engineering resources on the applications and experiences that differentiate their products.

A Modern Foundation for Z-Wave Controller Development

ZPC provides the host-side functionality needed to control and manage a Z-Wave network using a Silicon Labs Z-Wave Network Co-Processor (NCP). It operates as a central static controller and provides network management, device control, and state synchronization capabilities through an MQTT-based communication interface.

Z-Wave Protocol Controller Architecture Diagram

The ZPC architecture creates a clear separation between the customer application and the underlying Z-Wave network.

 

ZPC works with Silicon Labs’ Z-Wave NCP on the EFR32ZG23 and EFR32ZG28 SoCs, creating a complete host-to-network development path. The NCP provides the Z-Wave connectivity and communicates with ZPC through the Serial API, while ZPC manages the host-side controller functionality and application integration.

For developers, this means the application can focus on product functionality while ZPC provides the foundational controller capabilities needed to interact with the Z-Wave network.

The MQTT-based interface also provides a flexible integration point for customer applications, GUIs, cloud services, and bridges to other protocols or services.

Bringing Essential Z-Wave Controller Capabilities Together

A Z-Wave controller must support much more than simply sending commands to devices, and ZPC brings a broad set of controller services together within one solution. Its MQTT-based APIs support network management, Z-Wave SmartStart, device discovery and interviewing, network status, over-the-air updates, firmware updates, and Z-Wave Command Class control. ZPC also maintains a persistent attribute store with reported and desired value synchronization for Z-Wave device states.

Together, these capabilities help simplify key stages of the device lifecycle, like adding and discovering devices to monitoring network status and maintaining deployed products through firmware updates.

ZPC Makes Application Integration Simpler

As products evolve, gateways need to be able to interact with multiple applications and services.

ZPC uses MQTT as its application-facing communication interface, providing APIs that abstract Z-Wave controller operations from the customer application. This enables applications to interact with Z-Wave devices and network services without directly implementing the underlying Z-Wave protocol behavior.

This separation also makes it easier to build different experiences on top of the same controller foundation.

ZPC Enables Extensible Development

Product requirements continue to evolve after the initial controller implementation. ZPC is designed with extensible development in mind, giving developers the resources and flexibility to build on the controller foundation as their requirements grow.

Silicon Labs provides comprehensive documentation, API references, release information, and development resources to support integration and customization. For developers adding Z-Wave functionality, an automated code-generation solution streamlines new Command Class implementation, thereby reducing repetitive development effort and provides a structured approach to extending controller capabilities.

Extending the Opportunity with Z-Wave Long Range

Z-Wave applications are increasingly moving beyond devices located within the traditional boundaries of the home. Z-Wave Long Range expands the opportunity to reach devices across larger properties and commercial applications.

ZPC works with Silicon Labs Z-Wave NCP to provide a controller foundation capable of supporting both Z-Wave and Z-Wave Long Range deployments with compatible hardware and software configurations.

For customers, this provides a path to address evolving Z-Wave use cases without changing the fundamental host-controller model.

Z-Wave Protocol Controller is Progressing Toward Certification

ZPC is now generally available (GA) and ready for certification, providing customers with a platform to develop commercial Z-Wave controller products.

Z-Wave certification is targeted for completion by the end of Q4 2026, marking a key milestone toward certified commercial deployments.

Focus Engineering Where It Matters

Developers shouldn’t have to recreate foundational connectivity functionality every time they build a new gateway or controller product.

By bringing together network management, SmartStart, device discovery, monitoring, OTA firmware management, Command Class control, MQTT-based application integration, and extensible development, ZPC provides a modern foundation for developing the next generation of Z-Wave controller solutions.

Combined with the development tools, documentation, and deep Z-Wave expertise, ZPC will help developers spend less time building the controller foundation and more time creating the products and experiences that make their solutions different.

This isn’t a test. There’s no score, no grade, and no judgment attached to any answer. It’s a diagnostic. Each question points at something specific and tells you whether it’s worth a closer look.

Work through it with whoever handles IT or security at your organization. Give honest answers. “We think so” and “we haven’t checked recently” are both useful pieces of information. The questions that make you pause are the ones worth following up on first.

This assessment focuses on the areas that show up most consistently in post-breach analysis: credential security, patch management, access control, backup integrity, incident preparedness, and network visibility. It covers the fundamentals, not the advanced. If any of these ten questions get an uncertain answer, that’s a good place to start.

10 checks worth making today

  1. Is MFA enabled on every account that supports it, not just email?

What good looks like: MFA is on email, cloud storage, financial accounts, your domain registrar, any admin panel, and any SaaS tool with sensitive data. Your password manager has MFA. Exceptions are documented, intentional, and reviewed regularly.

What most businesses find: MFA on email, sometimes on cloud storage, rarely on the domain registrar or financial platforms. The domain registrar is worth checking specifically. An attacker who controls your domain controls your email, which gives them a path to almost everything else.

  1. When did someone last update the firmware on your routers and network devices?

What good looks like: Firmware is on a patch schedule, same as operating systems. Someone knows where to check for updates and roughly how old the current version is.

What most businesses find: The firmware hasn’t been updated since the device was installed, sometimes years ago. The default admin credentials haven’t been changed either. Both are worth fixing this week. Many routers include a built-in update check, although the process and time required vary by device.

  1. Do you know everyone who currently has admin access to your critical systems?

What good looks like: Backups run automatically, include everything that matters, and are offline, immutable, or otherwise isolated from the systems they protect. You’ve successfully restored from the backup at least once in the last twelve months.

What most businesses find: At least one account belonging to someone who left the company, and at least one service account whose origin nobody can explain. Both are low-effort to clean up once they’re visible.

  1. Do you have a backup, and have you actually tested restoring from it?

What good looks like: Backups run automatically, include everything that matters, and are stored somewhere ransomware can’t reach them. You’ve successfully restored from the backup at least once in the last twelve months.

What most businesses find: No central list, several vendors with access that hasn’t been reviewed, and at least one vendor relationship that ended without the access being removed. The review is often straightforward once you know what you’re looking for.

  1. Do you have a written incident response plan, even a basic one?

What good looks like: A document exists that covers, at minimum, who gets called first, what gets isolated immediately, who communicates externally, and where your cyber insurance policy lives. It doesn’t need to be long, but it does need to exist before the incident.

What most businesses find: No written plan, or a plan that was created once and never reviewed. The most common gap in the plan, when it exists: nobody knows where the insurance policy is or what the notification requirements are.

  1. When did you last review vendor and third-party access?

What good looks like: Every vendor with access to your systems is on a list. Their access level is documented. You’ve reviewed it in the last six months. You’ve revoked access for vendors whose engagement has ended.

What most businesses find: No central list, several vendors with access that hasn’t been reviewed, and at least one vendor relationship that ended without the access being removed. This is a half-hour task once you know what you’re looking for.

  1. Are your employees getting security awareness updates more than once a year?

What good looks like: Your team encounters current, relevant threat examples more than once annually. This doesn’t have to be formal training. Sharing a recent phishing example in a team meeting counts. What doesn’t count: the annual compliance module everyone watches while eating lunch and scrolling TikToks on their phone.

What most businesses find: One compliance module is completed per year because it’s required; the content is retained briefly, then forgotten. The teams that catch things have regular exposure to what attacks look like, not a general module about why security matters.

  1. Do you know what devices are on your network right now?

What good looks like: You have a current inventory of devices connected to your network. New or unrecognized devices are reviewed promptly. Personal devices are either managed or isolated to a guest segment.

What most businesses find: More devices than expected. Smart TVs in conference rooms, personal phones on the main network, a printer that’s been there so long the only person who knows it exists is the one who orders the dot matrix paper. All of these are worth knowing about, but that doesn’t automatically make them threats. The greatest risk is not knowing what’s in your inventory at all.

  1. Do you have visibility into what’s leaving your network?

What good looks like: You have some view into outbound traffic. You can see which devices and applications are connecting externally, where traffic is going, and whether anything looks unusual. A converged network and security platform like NETGEAR Exium makes this visible without requiring a dedicated analyst to interpret it.

What most businesses find: No outbound visibility at all. The organization may have basic firewall protection but no practical way to review outbound connections or see where applications are sending data. This gap separates organizations that catch things early from those that find out months later. “We trust the firewall” is a partial answer at best.

  1. Do you have cyber insurance, and do you know what it covers?

What good looks like: You have a policy. You’ve read the coverage summary in the last twelve months. You know the incident notification window, because policies may require reporting within a specific timeframe. You know whether it covers ransomware, business interruption, and third-party liability.

What most businesses find: A policy exists, but nobody has read the coverage terms since they bought it. Notification requirements vary by policy, and failing to meet them can jeopardize coverage for an incident. “We have it” and “we know what it covers” are different.

Turn your answers into action

Pick the two questions where your answer was least confident. Start there.

Security improvements compound when you make them. Many of the issues this assessment surfaces can be addressed quickly, while others will require a longer-term plan. Restore testing, firmware updates, and access reviews are not abstract security projects. They are concrete tasks that need an owner and a deadline. Put them on the calendar, assign responsibility, and follow up.

The value of doing this in October specifically is that it creates a natural checkpoint. Set a date in December to review what you’ve fixed, what remains open, and who owns the next step. That puts your business in a meaningfully better position heading into the new year.

Catch up on the earlier blogs in this series:

And join us for a live webinar on October 20 (8 a.m. PT | 11 a.m. ET): The moat is full of phish: how modern security protects a business without walls. I’ll lead a discussion about what SASE and Zero Trust are, and what they look like on an ordinary working day, plus how NETGEAR Exium delivers both through NETGEAR Insight. Save your seat.