CISA warned on July 7, 2026, that Digi International PortServer TS and Digi One SP, SP IA, IA, and IAP serial device servers running pre-2025 firmware contain an authentication bypass in their web interface that can let unauthenticated attackers reach restricted device resources. The advisory, paired with Digi’s own security notice and the NVD record for CVE-2025-3659, is not merely another embedded-device footnote. It is a reminder that industrial edge boxes live much longer than the assumptions baked into their web administration panels. For Windows shops that still bridge serial equipment into Ethernet networks, the risk is less about novelty and more about forgotten infrastructure becoming newly interesting.
CVE-2025-3659 sits in an uncomfortable class of industrial vulnerabilities: the exploit surface is ordinary, the affected devices are often obscure, and the operational context can be highly sensitive. According to the National Vulnerability Database entry attributed to Digi, the flaw involves improper authentication handling in a set of HTTP POST requests to the device web interface. A specially crafted request may allow an unauthenticated attacker to modify configuration settings.
That last phrase should stop administrators in their tracks. These devices are not laptops where a botched setting can be undone by a help desk visit. PortServer TS and Digi One units often sit between IP networks and serial-connected gear, including automation systems, access-control hardware, retail equipment, lab instruments, building systems, and the kind of one-off machinery that rarely appears in a tidy CMDB.
Digi’s advisory says the issue affects firmware released before 2025 across the PortServer TS, Digi One SP, Digi One SP IA, Digi One IA, and Digi One IAP families. NVD’s more specific record lists affected PortServer TS firmware up to and including 82000747_AA, Digi One SP/SP IA/IA firmware up to and including 82000774_Z, and Digi One IAP firmware up to and including 82000770 Z. CISA’s ICS advisory frames the problem for industrial-control environments, where “just patch it” is often the least realistic sentence in the room.
The severity signal is also not subtle. NVD shows Digi’s CVSS 4.0 base score as 9.4, critical, with no NVD enrichment score of its own yet. Even if some environments reduce practical exposure through segmentation, the vendor-scored risk tells us Digi considers the unauthenticated web-path problem serious enough to demand urgent action.
That makes them exceptionally useful and exceptionally easy to forget. A Windows application that once talked to a serial port on a local machine may, after a migration, talk through a virtual COM port mapped across the network. A factory-floor PC may see the old instrument as if nothing changed. The device server, meanwhile, sits in a cabinet, above a drop ceiling, behind a register, or on a DIN rail, doing its job for a decade.
Digi’s own product material for the Digi One SP IA describes it as serial-to-Ethernet connectivity for industrial automation, with support for TCP/UDP socket services, serial bridging, COM port redirection, and RealPort. That is exactly why WindowsForum readers should care. These are not theoretical OT-only curiosities; they are often part of the glue between Windows applications and physical-world devices.
The security problem follows directly from that convenience. A web management interface on one of these boxes may have been acceptable when it lived on a quiet plant network or a supposedly isolated operations VLAN. But networks accrete routes, VPNs, jump hosts, remote monitoring agents, and “temporary” firewall exceptions. The little web UI that nobody meant to expose becomes reachable by more systems than anyone intended.
For PortServer TS, CISA lists enabling HTTPS on the web server as a vendor fix and says administrators can alternatively disable the web server when it is not actively needed for configuration. For Digi One SP, Digi One SP IA, and Digi One IA, the listed fix is more severe: disable the web server. If HTTPS cannot be applied, the compensating control is to restrict access through a firewall or VPN.
The difference matters. “Enable HTTPS” and “disable the web server” are not equivalent administrative chores. One preserves the management workflow with stronger transport protection; the other removes the browser from the normal management path. In environments where technicians are used to typing an IP address into a browser, disabling the web UI will require documentation, training, and perhaps a new support playbook.
But CISA’s mitigation language also points to the uncomfortable truth: encryption alone is not the whole story. If the vulnerable logic sits in authentication handling for HTTP POST requests, then wrapping traffic in HTTPS helps protect credentials and sessions in transit, but exposure control still matters. The safer operational stance is to make the management interface reachable only from trusted administrative hosts, preferably through a controlled path such as a VPN or management network.
That creates a familiar Windows problem in a less familiar form. The server team may own the Windows host. The network team may own the VLAN. Facilities, manufacturing, security, or a vendor may own the serial endpoint. The Digi box in the middle can fall between all of them, especially if it was installed years ago during a project that has since changed hands.
The authentication bypass therefore becomes an asset-management test. Can the organization identify every PortServer TS and Digi One device? Can it determine firmware build dates? Can it tell whether the web interface is enabled? Can it confirm whether the management service is reachable from user subnets, VPN pools, monitoring networks, or third-party remote-access tools?
Those are not glamorous questions, but they decide whether this advisory becomes a controlled maintenance task or a late-night incident. In many Windows-heavy environments, the first clue may not be an OT asset inventory at all. It may be an old RealPort driver, a firewall object named after a serial server, a DNS entry created by a long-departed admin, or an application configuration that points to a device server IP.
That sounds simple until the device is supporting a fragile production workflow. If a serial server bridges a badge reader, a PLC-facing gateway, a laboratory instrument, or a retail controller, the fear of breaking connectivity can keep teams from touching it. The temptation is to accept the advisory, add it to a risk register, and promise to revisit it after the next maintenance window.
That is a mistake. The mitigations CISA lists are not exotic. They are the baseline practices that should have surrounded these devices already: trusted network segments, firewall or VPN restrictions, management access limited to known administrative hosts, and protected administrator credentials. The advisory does not ask administrators to redesign the plant; it asks them to stop treating an embedded web UI as if obscurity were a control.
The credential warning is especially interesting because the vulnerability is described as unauthenticated access to restricted resources, while CISA’s supplied text also says exploitation requires authenticated administrator access to write the affected fields. That apparent tension is a sign administrators should read the vendor and CISA material closely rather than reduce the issue to a slogan. The practical takeaway is still conservative: prevent untrusted access to the management interface, safeguard admin credentials, and assume configuration paths deserve protection even when exploit mechanics are nuanced.
A device server may define which TCP ports map to which serial ports. It may expose raw socket services, redirect COM traffic, forward industrial protocols, or bridge communications between systems that were never designed with modern authentication in mind. Changing those settings could interrupt service, redirect data flows, weaken access boundaries, or prepare the ground for more targeted interference.
That makes availability and integrity the center of gravity. Confidentiality still matters, especially if credentials or operational data traverse the device, but the nightmare scenario in many deployments is not data theft. It is a line stoppage, a disabled reader, a misrouted serial command, or a service desk discovering that the only person who knew the Digi password retired three years ago.
Digi’s own CVSS vector, as shown by NVD, reflects high impacts across vulnerable-system confidentiality, integrity, and availability. The scoring also includes adjacent attack vector rather than network-wide internet reach in the vendor vector, which is a useful reminder that local network positioning still matters. Attackers do not need global exposure if a compromised workstation, flat VPN, or poorly segmented vendor connection gives them a path to the management interface.
That is why the best response begins with staging rather than panic. Identify affected devices, capture current configurations, verify firmware levels, document dependencies, and test updated firmware or web-interface changes against representative workflows. Where patching cannot happen immediately, disable the web server or constrain access so tightly that exploitation becomes implausible from ordinary network positions.
For PortServer TS, enabling HTTPS should be treated as a minimum step, not a victory lap. Administrators should still ask who can reach the management page and whether HTTP remains active. For Digi One SP, SP IA, and IA units, disabling the web server changes the maintenance model but materially reduces the attack surface. In both cases, firewall rules should be explicit rather than inherited from broad “OT network” allowances.
There is also a procurement lesson here. Digi’s long-term recommendation to move to Digi Connect EZ or Digi Connect EZ TS is not just upselling; it is a signal that lifecycle planning has become part of vulnerability management. If the organization cannot patch, cannot disable risky services, and cannot confidently restrict access, then it is no longer operating a stable legacy system. It is carrying technical debt with an IP address.
Network discovery can help, but it should be careful in industrial environments. Aggressive scanning may be unwelcome around fragile equipment, so teams should combine passive network visibility, DHCP and DNS records, firewall logs, switch CAM tables, documentation searches, and application dependency reviews. If RealPort is in use on Windows systems, that may provide another path to identifying mapped devices.
Once found, each device needs a simple risk record: model, firmware, IP address, reachable management services, connected serial equipment, business owner, maintenance window, and compensating controls. That record is not bureaucracy for its own sake. It is how a future advisory becomes a filterable list instead of a scavenger hunt.
The same exercise should include credential hygiene. Even where the immediate flaw is unauthenticated behavior, embedded device fleets often suffer from shared admin passwords, stale vendor accounts, and credentials stored in old deployment notes. Resetting and vaulting administrator access is not glamorous, but it is part of making management interfaces boring again.
CVE-2025-3659 is exactly the kind of bug that benefits from that drift. The attacker does not need to understand every detail of the serial device behind the server on day one. Gaining access to restricted resources or altering configuration may be enough to map the environment, disrupt service, or pivot deeper into operational workflows.
The right lesson is not that every serial device server must be ripped out tomorrow. These products exist because old equipment remains valuable and because replacing physical systems is expensive, risky, and slow. The lesson is that legacy connectivity boxes must be treated as managed security assets, not as cabling accessories.
That shift is cultural as much as technical. IT teams know how to patch Windows servers, rotate service-account passwords, and retire unsupported desktops. They need the same muscle memory for the small embedded devices that make those systems useful in the real world.
The NVD record says the CVE was published on May 12, 2025, and modified in June 2026, while CISA’s ICS advisory brought renewed attention to the issue on July 7, 2026. That chronology matters because it means defenders are not looking at a zero-day dropped without context. They have vendor guidance, CISA mitigations, affected firmware identifiers, and enough detail to start targeted remediation.
It also means delay becomes harder to justify. When a vendor has identified the affected product families, developed a fix, and told customers to update or disable the web server, the burden shifts to asset owners. If a device remains exposed after that, it is no longer merely a legacy exception; it is an accepted risk that should have a name attached to it.
For WindowsForum’s audience, the operational framing is clear. If your Windows estate depends on old serial bridges, those bridges are part of your Windows risk surface. They may not run Windows, but they can still break Windows-delivered business processes.
The Vulnerability Is Small, but the Blast Radius Is Awkward
CVE-2025-3659 sits in an uncomfortable class of industrial vulnerabilities: the exploit surface is ordinary, the affected devices are often obscure, and the operational context can be highly sensitive. According to the National Vulnerability Database entry attributed to Digi, the flaw involves improper authentication handling in a set of HTTP POST requests to the device web interface. A specially crafted request may allow an unauthenticated attacker to modify configuration settings.That last phrase should stop administrators in their tracks. These devices are not laptops where a botched setting can be undone by a help desk visit. PortServer TS and Digi One units often sit between IP networks and serial-connected gear, including automation systems, access-control hardware, retail equipment, lab instruments, building systems, and the kind of one-off machinery that rarely appears in a tidy CMDB.
Digi’s advisory says the issue affects firmware released before 2025 across the PortServer TS, Digi One SP, Digi One SP IA, Digi One IA, and Digi One IAP families. NVD’s more specific record lists affected PortServer TS firmware up to and including 82000747_AA, Digi One SP/SP IA/IA firmware up to and including 82000774_Z, and Digi One IAP firmware up to and including 82000770 Z. CISA’s ICS advisory frames the problem for industrial-control environments, where “just patch it” is often the least realistic sentence in the room.
The severity signal is also not subtle. NVD shows Digi’s CVSS 4.0 base score as 9.4, critical, with no NVD enrichment score of its own yet. Even if some environments reduce practical exposure through segmentation, the vendor-scored risk tells us Digi considers the unauthenticated web-path problem serious enough to demand urgent action.
Serial Device Servers Are the Infrastructure Everyone Forgot to Inventory
The affected Digi products belong to a category that deserves more attention than it gets: serial-to-Ethernet device servers. Their job is prosaic but crucial. They take equipment designed for RS-232, RS-422, or RS-485 serial communication and make it reachable over TCP/IP, often through raw sockets, Telnet-like sessions, COM-port redirection, or vendor tools such as Digi’s RealPort.That makes them exceptionally useful and exceptionally easy to forget. A Windows application that once talked to a serial port on a local machine may, after a migration, talk through a virtual COM port mapped across the network. A factory-floor PC may see the old instrument as if nothing changed. The device server, meanwhile, sits in a cabinet, above a drop ceiling, behind a register, or on a DIN rail, doing its job for a decade.
Digi’s own product material for the Digi One SP IA describes it as serial-to-Ethernet connectivity for industrial automation, with support for TCP/UDP socket services, serial bridging, COM port redirection, and RealPort. That is exactly why WindowsForum readers should care. These are not theoretical OT-only curiosities; they are often part of the glue between Windows applications and physical-world devices.
The security problem follows directly from that convenience. A web management interface on one of these boxes may have been acceptable when it lived on a quiet plant network or a supposedly isolated operations VLAN. But networks accrete routes, VPNs, jump hosts, remote monitoring agents, and “temporary” firewall exceptions. The little web UI that nobody meant to expose becomes reachable by more systems than anyone intended.
Digi’s Recommended Fix Is Also a Product-Lifecycle Message
Digi’s notice recommends updating affected devices to the latest firmware as soon as possible. CISA’s advisory adds a more revealing long-term recommendation: Digi recommends users upgrade to Digi Connect EZ or Digi Connect EZ TS as a long-term solution. That is a vendor telling customers, politely, that some deployed product lines are now security liabilities as much as connectivity tools.For PortServer TS, CISA lists enabling HTTPS on the web server as a vendor fix and says administrators can alternatively disable the web server when it is not actively needed for configuration. For Digi One SP, Digi One SP IA, and Digi One IA, the listed fix is more severe: disable the web server. If HTTPS cannot be applied, the compensating control is to restrict access through a firewall or VPN.
The difference matters. “Enable HTTPS” and “disable the web server” are not equivalent administrative chores. One preserves the management workflow with stronger transport protection; the other removes the browser from the normal management path. In environments where technicians are used to typing an IP address into a browser, disabling the web UI will require documentation, training, and perhaps a new support playbook.
But CISA’s mitigation language also points to the uncomfortable truth: encryption alone is not the whole story. If the vulnerable logic sits in authentication handling for HTTP POST requests, then wrapping traffic in HTTPS helps protect credentials and sessions in transit, but exposure control still matters. The safer operational stance is to make the management interface reachable only from trusted administrative hosts, preferably through a controlled path such as a VPN or management network.
The Windows Angle Is the Old COM Port That Never Really Died
Windows administrators may be tempted to file this under “industrial gear,” but the boundary between IT and OT has never been clean where serial device servers are concerned. Digi’s product pages and documentation explicitly discuss RealPort and Windows operating-system support because a major use case is making remote serial devices appear usable to Windows applications. That may include line-of-business software nobody wants to touch because it still works.That creates a familiar Windows problem in a less familiar form. The server team may own the Windows host. The network team may own the VLAN. Facilities, manufacturing, security, or a vendor may own the serial endpoint. The Digi box in the middle can fall between all of them, especially if it was installed years ago during a project that has since changed hands.
The authentication bypass therefore becomes an asset-management test. Can the organization identify every PortServer TS and Digi One device? Can it determine firmware build dates? Can it tell whether the web interface is enabled? Can it confirm whether the management service is reachable from user subnets, VPN pools, monitoring networks, or third-party remote-access tools?
Those are not glamorous questions, but they decide whether this advisory becomes a controlled maintenance task or a late-night incident. In many Windows-heavy environments, the first clue may not be an OT asset inventory at all. It may be an old RealPort driver, a firewall object named after a serial server, a DNS entry created by a long-departed admin, or an application configuration that points to a device server IP.
CISA’s Mitigations Are Really a Segmentation Checklist
CISA’s ICS guidance repeats a principle that security teams know by heart but operations teams often inherit as an afterthought: do not expose these devices to untrusted or public networks. In practice, that means the web management interface should not be reachable from the internet, from general user networks, or from broad VPN address pools. It should be reachable only from systems and administrators that genuinely need to configure it.That sounds simple until the device is supporting a fragile production workflow. If a serial server bridges a badge reader, a PLC-facing gateway, a laboratory instrument, or a retail controller, the fear of breaking connectivity can keep teams from touching it. The temptation is to accept the advisory, add it to a risk register, and promise to revisit it after the next maintenance window.
That is a mistake. The mitigations CISA lists are not exotic. They are the baseline practices that should have surrounded these devices already: trusted network segments, firewall or VPN restrictions, management access limited to known administrative hosts, and protected administrator credentials. The advisory does not ask administrators to redesign the plant; it asks them to stop treating an embedded web UI as if obscurity were a control.
The credential warning is especially interesting because the vulnerability is described as unauthenticated access to restricted resources, while CISA’s supplied text also says exploitation requires authenticated administrator access to write the affected fields. That apparent tension is a sign administrators should read the vendor and CISA material closely rather than reduce the issue to a slogan. The practical takeaway is still conservative: prevent untrusted access to the management interface, safeguard admin credentials, and assume configuration paths deserve protection even when exploit mechanics are nuanced.
The Risk Is Configuration Control, Not Just Login Bypass
The phrase “authentication bypass” tends to evoke account takeover, but CVE-2025-3659 is more about control of device behavior. If an attacker can modify configuration settings through crafted web requests, the outcome depends on what the device controls and how the surrounding environment trusts it. A small change in a serial server can become a large operational problem.A device server may define which TCP ports map to which serial ports. It may expose raw socket services, redirect COM traffic, forward industrial protocols, or bridge communications between systems that were never designed with modern authentication in mind. Changing those settings could interrupt service, redirect data flows, weaken access boundaries, or prepare the ground for more targeted interference.
That makes availability and integrity the center of gravity. Confidentiality still matters, especially if credentials or operational data traverse the device, but the nightmare scenario in many deployments is not data theft. It is a line stoppage, a disabled reader, a misrouted serial command, or a service desk discovering that the only person who knew the Digi password retired three years ago.
Digi’s own CVSS vector, as shown by NVD, reflects high impacts across vulnerable-system confidentiality, integrity, and availability. The scoring also includes adjacent attack vector rather than network-wide internet reach in the vendor vector, which is a useful reminder that local network positioning still matters. Attackers do not need global exposure if a compromised workstation, flat VPN, or poorly segmented vendor connection gives them a path to the management interface.
The Patch Window Is a Governance Problem Disguised as Firmware
Firmware advisories for embedded infrastructure often fail not because the fix is technically impossible, but because nobody owns the full risk decision. Updating a device server can require coordination with operations, application owners, network teams, and sometimes outside vendors. If a firmware update changes behavior, a Windows application relying on virtual COM-port redirection may be the first thing to complain.That is why the best response begins with staging rather than panic. Identify affected devices, capture current configurations, verify firmware levels, document dependencies, and test updated firmware or web-interface changes against representative workflows. Where patching cannot happen immediately, disable the web server or constrain access so tightly that exploitation becomes implausible from ordinary network positions.
For PortServer TS, enabling HTTPS should be treated as a minimum step, not a victory lap. Administrators should still ask who can reach the management page and whether HTTP remains active. For Digi One SP, SP IA, and IA units, disabling the web server changes the maintenance model but materially reduces the attack surface. In both cases, firewall rules should be explicit rather than inherited from broad “OT network” allowances.
There is also a procurement lesson here. Digi’s long-term recommendation to move to Digi Connect EZ or Digi Connect EZ TS is not just upselling; it is a signal that lifecycle planning has become part of vulnerability management. If the organization cannot patch, cannot disable risky services, and cannot confidently restrict access, then it is no longer operating a stable legacy system. It is carrying technical debt with an IP address.
The Admin Playbook Starts With Finding the Boxes
Before anyone argues about firmware, the devices have to be found. Many organizations will have some in asset databases, but the more interesting cases are the ones installed by integrators, inherited through acquisitions, or attached to equipment contracts. The device name may not contain “Digi,” and the business owner may describe it only as “the serial adapter.”Network discovery can help, but it should be careful in industrial environments. Aggressive scanning may be unwelcome around fragile equipment, so teams should combine passive network visibility, DHCP and DNS records, firewall logs, switch CAM tables, documentation searches, and application dependency reviews. If RealPort is in use on Windows systems, that may provide another path to identifying mapped devices.
Once found, each device needs a simple risk record: model, firmware, IP address, reachable management services, connected serial equipment, business owner, maintenance window, and compensating controls. That record is not bureaucracy for its own sake. It is how a future advisory becomes a filterable list instead of a scavenger hunt.
The same exercise should include credential hygiene. Even where the immediate flaw is unauthenticated behavior, embedded device fleets often suffer from shared admin passwords, stale vendor accounts, and credentials stored in old deployment notes. Resetting and vaulting administrator access is not glamorous, but it is part of making management interfaces boring again.
The Advisory Exposes the Cost of “Air-Gapped Enough”
Many industrial and infrastructure environments still rely on a soft version of the air gap: not truly isolated, but assumed to be unreachable by normal attackers. That assumption has aged poorly. Remote support, centralized monitoring, cloud dashboards, VPN concentrators, Windows jump hosts, and managed service providers have all turned “isolated” networks into selectively connected networks.CVE-2025-3659 is exactly the kind of bug that benefits from that drift. The attacker does not need to understand every detail of the serial device behind the server on day one. Gaining access to restricted resources or altering configuration may be enough to map the environment, disrupt service, or pivot deeper into operational workflows.
The right lesson is not that every serial device server must be ripped out tomorrow. These products exist because old equipment remains valuable and because replacing physical systems is expensive, risky, and slow. The lesson is that legacy connectivity boxes must be treated as managed security assets, not as cabling accessories.
That shift is cultural as much as technical. IT teams know how to patch Windows servers, rotate service-account passwords, and retire unsupported desktops. They need the same muscle memory for the small embedded devices that make those systems useful in the real world.
The Digi Advisory Leaves Little Room for Complacency
This is the point where some readers will ask whether the issue is exploitable at internet scale. The better question is whether the organization has any reason to let unauthenticated or broadly authenticated users talk to the web management plane of a serial device server. If the answer is no, the remediation path is obvious even before exploit chatter emerges.The NVD record says the CVE was published on May 12, 2025, and modified in June 2026, while CISA’s ICS advisory brought renewed attention to the issue on July 7, 2026. That chronology matters because it means defenders are not looking at a zero-day dropped without context. They have vendor guidance, CISA mitigations, affected firmware identifiers, and enough detail to start targeted remediation.
It also means delay becomes harder to justify. When a vendor has identified the affected product families, developed a fix, and told customers to update or disable the web server, the burden shifts to asset owners. If a device remains exposed after that, it is no longer merely a legacy exception; it is an accepted risk that should have a name attached to it.
For WindowsForum’s audience, the operational framing is clear. If your Windows estate depends on old serial bridges, those bridges are part of your Windows risk surface. They may not run Windows, but they can still break Windows-delivered business processes.
The Old Digi Boxes Now Need a Modern Maintenance Contract
The concrete response to CVE-2025-3659 is not complicated, but it does require ownership. Treat this as a short, focused campaign rather than a theoretical advisory. Start with the devices that are reachable from the broadest networks and the ones attached to the most consequential equipment.- Organizations should identify all Digi PortServer TS, Digi One SP, Digi One SP IA, Digi One IA, and Digi One IAP devices and verify whether their firmware predates the vendor’s 2025 fixed releases.
- PortServer TS administrators should enable HTTPS for the web server where applicable and still restrict management access to trusted administrative hosts.
- Digi One SP, Digi One SP IA, and Digi One IA administrators should disable the web server where the vendor guidance calls for it, especially when browser-based management is not routinely required.
- Network teams should place these devices on trusted segments and block access to management interfaces from user networks, public networks, and broad VPN pools.
- Asset owners should capture configurations and dependencies before firmware work, because serial-to-Ethernet devices often support brittle legacy workflows.
- Long-term planning should evaluate Digi’s recommendation to migrate to Digi Connect EZ or Digi Connect EZ TS where older units can no longer be managed safely.
References
- Primary source: CISA
Published: 2026-07-07T12:00:00+00:00
Loading…
www.cisa.gov - Related coverage: digi.com
Loading…
www.digi.com - Related coverage: docs.digi.com
- Related coverage: es.digi.com
Centro de Seguridad | Digi International
El sitio de Digi para todas las noticias de seguridad, información y recursos relacionados con nuestros productos y servicios.es.digi.com - Related coverage: digikey.com
Digi One® SP and Digi One IA Serial-to-Ethernet Connectivity Solutions
Digi's Digi One SP and Digi One IA provide reliable, cost-effective network connectivity for industrial, commercial, and retail applications.www.digikey.com - Related coverage: hub.digi.com
- Related coverage: de.digi.com
Kompakt RS-232/422/485 Seriell-zu-Ethernet | Digi One SP | Digi International
Der serielle Server Digi One SP bietet zuverlässige und kostengünstige Netzwerkkonnektivität für praktisch alle Arten von seriellen Geräten. Er verfügt über einen der kleinsten Formfaktoren auf dem Markt, eine branchenweit führende niedrige Latenz, Baudraten von bis zu 230 Kbps und volle Modem-...de.digi.com - Related coverage: ftp1.digi.com
- Related coverage: irtfweb.ifa.hawaii.edu