The Port That Isn't There: Tactical Software and the 89-Day Windows Clock

Summary

• Tactical Software, LLC, of Bedford, New Hampshire, currently sells the final 4.10 versions of Serial/IP, COM/IP and DialOut/EZ, along with TacServe and related tools. Their economic function is to preserve the COM port and modem assumptions of existing Windows applications while moving the actual connection to TCP/IP.
• This preservation can be far less expensive than rewriting a validated industrial, plant control, point-of-sale or device application. The apparent simplicity is produced by a kernel-level driver and, in some editions, a network licence manager — components that concentrate dependencies on the operating system, signing, security, recovery and the vendor beneath the application.
• The company's public support calendar reaches a decisive date on 13 October 2026, 89 days after the publication of this article. This is the published support horizon for Windows 11 Home and Pro 24H2 and Windows Server 2022, even though Microsoft's extended support lifecycle for Server 2022 continues until 2031 and newer Windows versions already exist.
• Buyers must not confuse RFC 2217 compatibility, TCP failover or an SSL/TLS checkbox with proof of secure or transactionally safe operation. Purchases require application-specific testing for serial control semantics, timing, certificate validation, driver compatibility, licence server failure, endpoint failover and recoverability — and an exit plan that does not rely on the eternal persistence of the virtual port.

Eighty-Nine Days on COM3

On 16 July 2026, a procurement team evaluating Tactical Software faces a particular countdown. Eighty-nine days later, on 13 October, the company's published technical support horizon reaches end of line for Windows 11 Home and Pro version 24H2 and Windows Server 2022. Tactical'scurrent lifecycle FAQstates that version 4.10 is the final release of Serial/IP, COM/IP and DialOut/EZ. Perpetual licences may continue to be used on later Windows versions at the customer's discretion and risk, but the public commitment is no longer an open promise to follow Microsoft.

This does not mean the software will stop working on 14 October. It does not prove that a newer Windows version is incompatible. It means something narrower and more consequential: the operating environment may continue to evolve while the vendor's declared product line does not. Microsoft'sWindows 11 release tableshows that 24H2 Home and Pro support ends on 13 October 2026, while Enterprise and Education 24H2 continue until 12 October 2027. Windows 11 25H2 has been available since 30 September 2025. Tactical's public product pages mention 24H2, not 25H2, and Windows Server 2022, not Server 2025. The absence of these names is not a finding of incompatibility; it is a question the buyer must resolve with a tested build and a written support response.

The mismatch is more pronounced on the server side. Microsoft'sWindows Server 2022 lifecyclesplits support into mainstream support, ending 13 October 2026, and extended support, ending 14 October 2031. Tactical ties its declared support to the first date. A company could therefore remain on a Microsoft-supported server operating system for five additional years while using a redirector whose vendor has ended its public technical support commitment.

This countdown reveals what Tactical Software is really selling. It is not simply a utility that converts serial bytes into packets. It sells time: time before a legacy application must be modified, revalidated or replaced. A program written to open COM3, set the baud rate and wait for Data Carrier Detect can continue to behave as if a physical serial or modem interface still existed. The hardware can be moved to a device server across a plant network, a data centre or a virtual machine boundary. The application is spared immediate change.

But the time bought is financed by a new stack of dependencies. The old program now relies on a virtual COM implementation within Windows, the compatibility of a kernel driver with Microsoft security policy, the exact interpretation of serial control signals over a network, the protocol behaviour of a remote endpoint, firewall rules, certificates or other transport controls, licence enforcement, and the willingness and ability of a small specialist vendor to help. Tactical's software can be an excellent bridge. The business mistake is to price it like a cable and govern it as if it had removed the river.

The Exact Company Behind the Virtual Port

The subject here is Tactical Software, LLC, of Bedford, New Hampshire — not Digi International, not a serial device server manufacturer that bundles a redirector, and not a generic product category. Tactical'scurrent company pagegives the legal name Tactical Software LLC and an address at 3 Executive Park Drive, Suite 243, Bedford, New Hampshire. Its online store andhome pageactively present Serial/IP, COM/IP and DialOut/EZ. The company describes itself as an independent vendor focused on network-enabling legacy applications and emphasises that its redirectors do not require a proprietary Tactical server protocol. These claims of independence and compatibility are assertions by the company, though the product documentation provides concrete mechanisms for testing them.

TheBetter Business Bureau company profileidentifies an LLC at the same Bedford address, states that the business started in July 1996 and names Michael Krueger as managing director. The BBB also warns that it does not independently verify all information provided by third parties. The profile is useful corroboration of operational identity and longevity, but not a substitute for a state certificate of good standing, financial due diligence or product assurance. The public evidence examined for this article did not include a current New Hampshire registration certificate, audited accounts, headcount or beneficial ownership disclosure.

The exact entity also appears in a useful piece of market history. In 2003, the US District Court for the District of New Hampshire issued anopinion in Tactical Software, LLC v. Digi International, Inc.. The opinion describes Tactical marketing a COM port redirector called Serial I/P and Digi claiming it infringed US Patent 6,047,319. The court denied Digi's motion to dismiss Tactical's declaratory judgment action for lack of subject matter jurisdiction. It did not decide whether the patent was valid or infringed, and it did not grant Tactical a technological victory. The underlyingpatent recordfrom Digi concerns a network terminal server with a full programming interface and is now listed by Google Patents as expired. The episode matters because it shows the boundary between local serial APIs and network terminal servers was commercially important enough to litigate. It says nothing about current infringement exposure or product quality.

These identity proofs support a modest conclusion. Tactical is a long-time specialist with an active sales and support surface for a narrow family of Windows connectivity products. It does not establish deployment scale, revenue stability, engineering headcount, support depth or the ability to maintain a kernel driver indefinitely. Those questions remain part of the vendor risk.

Four Ways to Preserve an Old Assumption

The products address different but related application assumptions. Treating them as interchangeable obscures the migration problem.

Serial/IPis the most straightforward case. An administrator creates a virtual COM port and associates it with an IP address or hostname and a TCP port. When the Windows application opens that COM port, Serial/IP establishes the TCP connection to the remote serial device server. The current page announces version 4.10 FINAL, support for Windows 11 24H2 and Windows Server 2022 on Intel x64 systems, a 30-day trial and perpetual licences starting at $100. It allows thousands of ports configured, while the paying tier is determined by the active count at once. The application does not need to learn sockets; it continues to call the Windows communications interface it already understands.

COM/IPpreserves a more specific fiction: that the application is talking to a dial-up modem. It presents a virtual modem on a COM port, accepts Hayes-like AT commands and translates a 'dialled' destination into an IP address and TCP port. The current product is also version 4.10 FINAL, sold under perpetual licence with support included and a starting price of $100. Tactical'sCOM/IP quick start documentationshows the operational consequence. The old application selects the virtual modem, supplies an initialisation string and dials an encoded IP endpoint. An application whose workflow, user interface or database expects phone numbers can therefore reach an Ethernet service without being rewritten around a socket API.

DialOut/EZworks in the other direction. It allows Windows applications to use a pool of physical modems attached to a remote modem server. Opening a virtual COM port reserves a modem; closing the port releases it. This is not simply 'modem emulation'. The modem exists, but it is shared over a network and allocated as a managed resource. The current product page again identifies 4.10 FINAL, a perpetual licence and a starting point of $100.

TacServe provides a server-side counterpart. Tactical'shelp centredescribes it as a Windows service software that exposes serial ports or modems attached to a PC to RFC 2217 clients. This allows a Windows computer to become a serial or modem pool server instead of requiring a dedicated hardware terminal server. A buyer should keep the roles clear: Serial/IP, COM/IP and DialOut/EZ primarily preserve COM or modem expectations on the client side; TacServe makes local server hardware available over the network.

Tactical'sproduct comparisonmakes the dividing lines concrete. Serial/IP uses preconfigured network endpoints; COM/IP allows the application to select a destination via modem commands; DialOut/EZ connects to a remote modem pool. The options differ for incoming connections, proxies, login prompts, RFC 2217 control, failover, site licences and administration. The choice therefore starts with the old application's behaviour, not a generic desire for 'serial over IP'.

This distinction is economically important. If an application always communicates with one controller, Serial/IP can preserve a fixed COM mapping. If it chooses between remote systems by 'dialling', COM/IP can preserve the selection workflow. If it must place real calls through centrally managed modems, DialOut/EZ preserves access to physical telephony. Selecting the wrong redirector may still produce a successful TCP connection while breaking the business process the serial or modem interface was meant to embody.

A Kernel Driver Makes the Continuity

The central illusion is created beneath the application. Tactical states that all its redirectors use kernel-level drivers. Its support documentation indicates that the virtual ports intentionally do not appear as ordinary Plug-and-Play devices in Windows Device Manager; Tactical wanted to avoid automatic enumeration and preserve explicit COM port numbering. Applications nevertheless see and open the ports through the Windows communications APIs.

This design has real advantages. A program can run without a user logged in. A Windows service can open the port at startup. The data path does not depend on a system tray application staying alive. Port names can remain stable even when a physical adapter is removed. A virtual machine can retain a known interface while the physical serial endpoint is elsewhere. These properties matter in unattended systems and in applications whose installers or configuration files have hard-coded COM1 through COM4.

They also explain why the software's risk is greater than its user interface. A normal user-space utility can often be isolated, restarted or replaced with limited effect. A kernel driver participates in the operating system's trusted computing base. Microsoft'skernel-mode code signing policyrequires new Windows kernel drivers to go through Microsoft's signing process, with production submissions normally backed by Hardware Lab Kit testing. Windows security policy constantly changes around these drivers. Microsoft'smemory integrity guidanceadvises administrators to test compatibility before broad deployment because an incompatible driver can misbehave and, in rare cases, interfere with boot.

Nothing in these Microsoft documents proves that Tactical's 4.10 driver is incorrectly signed or incompatible with memory integrity. The point is structural: the customer cannot evaluate the redirector only by checking whether its control panel launches. It must verify the actual driver package, signer, version, architecture and behaviour under the security controls used on the target Windows image. An application-level compatibility test on a permissive workstation is not enough.

The kernel placement also changes network operations. Tactical's help centre explains that the driver's traffic appears as part of the Windows System process rather than as a conventional executable that can simply be exempted in a host firewall. The installer adjusts the Windows Firewall for common use, but inbound modes and enterprise security products may require explicit handling. TheSerial/IP quick start guideidentifies TCP and UDP port 2392 for licence-related communication in applicable configurations. A network team that approves only the remote device's application port may find that the data plane works during a trial while site licences, discovery, incoming connections or recovery fail after deployment.

At the top of the stack, the application still thinks it owns a local serial port. Below, a single open call may trigger DNS resolution, proxy negotiation, TCP handshake, Telnet option exchange, RFC 2217 commands, authentication, TLS setup and serial port allocation from a remote device. Closing the COM port may release those resources.

A one-line application error like 'cannot open COM3' can therefore represent a driver problem, a licence conflict, an unreachable licence manager, a firewall rule, exhausted ephemeral ports, a certificate failure, a busy serial endpoint or a remote server that accepted TCP but not the intended device operation.

This is why virtual COM software often has a low purchase price and a high diagnostic value. It compresses a distributed system into an interface that old code understands. When the compression works, the application remains blissfully unaware. When it fails, the operations team must expand the abstraction again and identify which hidden layer broke.

RFC 2217 Restores Control, Not Co-location

Raw TCP can carry the bytes that would have traversed a serial cable, but serial applications often need more than bytes. They set baud rate, parity, stop bits and flow control. They raise or lower DTR and RTS. They inspect CTS, DSR, ring indicator and carrier detect. They may flush buffers or wait for a notification when a modem control line changes.

RFC 2217, published in 1997 as an experimental Telnet option, defines a way to control a serial port over a network. It includes commands for baud rate, data size, parity, stop bits, flow control, line status notification, modem status notification and buffer flushing. Tactical supports RFC 2217 where the remote server does. This is a significant interoperability choice: a standards-based server can expose more of the serial interface than a raw byte stream, and Tactical is not inherently tied to a server it manufactures.

The standard should not be strained to prove more than it does. RFC 2217 does not make Ethernet latency identical to a local UART. It does not guarantee that a device server correctly implements every option. It does not make a multi-hop network deterministic in timing. Its security discussion predates current transport security expectations and does not turn the protocol itself into an encrypted channel. Compatibility is a negotiation between the two endpoints and the application's actual dependencies.

Tactical'sSerial/IP control panel documentationillustrates the trade-offs. A port can use raw TCP, Telnet or RFC 2217. If the server cannot report control signals, Serial/IP can emulate DSR, DCD or CTS as always high, always low or following connection state. This can be exactly what an old application needs to continue. It can also manufacture a reassuring signal that no longer corresponds to the physical equipment. 'Carrier detected' may mean 'TCP is connected' rather than 'the modem or field device has reached the state the application designer intended'.

COM/IP introduces another translation layer. Its documentation explains that some applications are limited to low COM port numbers and that Telnet processing can alter the handling of certain byte values unless both ends agree. The destination selection encoded in a modem dial string is clever because it preserves the application's control flow, but it also means that parsing and configuration rules are part of the operational contract. An application that uses unusual initialisation strings, S-registers, break sequences or binary transfer needs a test built around those exact behaviours, not a generic ping.

Vendor-independent documentation confirms that these semantic differences are practical, not theoretical. Moxa'sReal COM performance advicewarns that a networked virtual COM port can be slower than a native one, especially under heavy traffic, and recommends tuning flush, transmit and FIFO behaviour. This advice concerns Moxa's implementation, not Tactical's. It nevertheless demonstrates the class of problem: packetisation, buffering and operating system scheduling can expose timing assumptions that a short local cable concealed.

Rigorous proof therefore has three levels. First, the TCP session must connect. Second, the required serial controls must be consistently represented and interpreted. Third, the business operation — reading a meter, authorising a transaction, commanding a controller, downloading a device configuration or placing a call — must complete correctly under normal and abnormal conditions. Most weak acceptance tests stop at the first level.

Failover Is a Connection Decision, Not a Transaction Guarantee

Serial/IP can be configured with up to four destination addresses for one virtual port. According to the control panel guide, it tries alternatives when it cannot establish a connection. DialOut/EZ can similarly try multiple modem servers. These features can remove a single unreachable IP address from the path, but 'failover' is an overloaded word.

The redirector can tell whether a TCP connection was established. It can tell whether an RFC 2217 server accepted a port. It cannot, without application-specific knowledge, prove that the replacement endpoint represents the same physical process, has the same device state, contains the same queued bytes or has not already executed the last command. A backup server may be reachable while the connected instrument is wrong, outdated, busy or configured differently.

The distinction becomes sharper after an interrupted session. Tactical offers an option to restore a failed connection, but its documentation explicitly warns that the feature should only be used when the application can continue normally after restoration. This caveat is correct. If a command and its acknowledgement were separated by the failure, neither the COM abstraction nor the TCP reconnect can decide whether retrying would duplicate an action or whether continuing would skip one.

A point-of-sale transaction, a device firmware operation or a controller command may require application-level idempotency, sequence numbers or operator reconciliation.

Purchases should therefore describe failover in observable terms. What failures trigger an alternative endpoint: DNS failure, connection refusal, handshake timeout, certificate error, established connection loss or unresponsive application protocol? How long does Windows wait before the next address is tried? Does the application tolerate that interval? Are buffers flushed, replayed or left ambiguous? Is the backup connected to the same device? Does a returned DCD signal mean network recovery or confirmed process recovery? Until these questions are tested, a checkbox labelled failover is a potential for availability, not an uptime outcome.

Security Begins Where the Serial Cable Ends

A local serial cable has obvious physical limitations. Replacing it with TCP/IP broadens the scope, centralises equipment and supports virtual machines, but also creates a routable attack surface. The security objective must cover the redirector host, the remote device server, credentials, certificates, network segmentation, configuration, logs and the legacy application's inability to authenticate what is on the other end.

Tactical's current comparison and support documents indicate proxy, authentication and SSL/TLS options in some parts of the product family. Configuration snapshots include SSL/TLS settings. Acurrent COM port redirector pagefrom Sena Technologies indicates that its HelloDevice products can be supplied with Tactical Serial/IP and advertises use of SSL/TLS with the redirector. This is evidence that encrypted configurations exist in the ecosystem. It is not sufficient to determine the protocol version, enabled cipher suites, trust store behaviour, hostname validation, revocation checking, mutual authentication, private key storage or the actual cryptographic library in Tactical 4.10.

The most detailed public manual found for Tactical TLS configuration is an olderSerial/IP 4.3 guidehosted by an OEM. It describes per-port SSL/TLS configuration, certificate exchange and cipher choices that include algorithms now considered obsolete. It also warns that a sample certificate is for testing only. This manual is a useful historical piece of evidence and a dangerous present one. The 4.3 documentation cannot establish what 4.10 negotiates today. Its old cipher list should neither be attributed to the current release nor dismissed as irrelevant: it demonstrates why a buyer needs a live handshake capture and a current vendor response rather than a checkbox or a legacy PDF.

The current end-user licence agreement reproduces OpenSSL licence notices, but those notices do not identify the version of OpenSSL linked or its patch state. The current public documents examined here do not answer whether certificate names or IP subject alternative names are verified, whether the product can require client certificates, whether expired or revoked certificates fail secure, or whether TLS is available in every product and licence tier. They also do not provide a public software bill of materials, cryptographic module certification or security hardening guide. These are evidence gaps, not findings that the controls are absent.

Distribution integrity merits similar precision. Tactical'sSerial/IP download pagepublishes the archive size of the version 4.10 installer and an MD5 digest. MD5 can still reveal accidental corruption, butRFC 6151says it is not safe where collision resistance is required. A procurement team should verify the installer's Authenticode signature and certificate chain, obtain a SHA-256 digest through a trusted channel and preserve the exact approved package. The presence of an MD5 value should not be misrepresented as proof that the package is malicious; it is simply weaker than a modern authenticity check.

For industrial and operational technology environments, availability and security constraints complicate every security update.NIST SP 800-82 Revision 3highlights the distinctive performance, reliability and safety requirements of operational technology, as well as asset management, supply chain risk, controlled remote access, tested patching and recovery. A redirector may sit outside the security logic while being needed for monitoring, billing, maintenance or command delivery. That makes it important enough to inventory and test, without justifying unsupported claims that Tactical is deployed in safety-critical control loops.

The safest architectural assumption is that the legacy application does not provide modern peer assurance. Place the redirector and the device server in a tightly authorised network zone. Restrict destinations and inbound listeners. Use encryption with verified certificate behaviour where supported, or an independently managed secure tunnel where that is the approved design. Protect the control panel, registry settings, licence service and snapshot files. Treat traces as sensitive because they may contain commands, credentials, process data.

Above all, verify the architecture against actual protocol reality; encryption can protect the wrong endpoint as effectively as the right one.

Implementation Is an Exercise in Revealing Hidden Assumptions

Tactical's frictionless trial is commercially sensible. Serial/IP advertises a fully functional 30-day evaluation with up to 256 active ports. An engineer can install the driver, create a port, point it at a device server and quickly discover whether the application opens it. The danger is to let a successful demonstration become the acceptance test.

The implementation sequence should start with an inventory of the application's behaviour. Which executable or service opens the port? Is the COM number hard-coded? Does the application enumerate Device Manager or call the communications API directly? What baud, parity, flow control and modem line changes does it make? Does it expect exclusive access? Does it open and close the port per transaction or keep it open for days? Does it depend on break signals, fax timing, transparent binary Telnet handling or an unusual modem initialisation string? Tactical's support documentation notes, for example, that Class 1 faxing is very timing sensitive.

This is a useful warning against assuming every modem-like workload survives packetisation.

Next comes endpoint and network configuration. Serial/IP supports hostnames as well as IP addresses, which introduces DNS as a dependency. Proxy options may introduce another. Incoming modes reverse firewall assumptions. A remote serial server may allocate a port exclusively, require credentials or wait for RFC 2217 negotiation. Network address translation may affect management and licensing even where the data connection itself traverses NAT successfully.

Tactical provides tools for disciplined deployment. Itsfree utilities pageoffers configuration snapshots and directs operators to packet and port monitoring tools. Theconfiguration snapshotcan capture port mappings, IP and TCP settings, proxies, Telnet options, authentication and SSL/TLS choices. It deliberately does not include the licence key or licence manager configuration. This exclusion is good secret hygiene, but it means a snapshot alone is not a complete disaster recovery package.

TheSerial/IP port monitor guideexplains that tracing can log timestamped operations, line signal changes and actual data. The same guide warns of performance and memory overhead. In practice, traces should be enabled for a limited diagnostic window, stored as sensitive operational data and correlated with packet captures and server logs. Tactical support routinely asks for such evidence because 'the port failed' is otherwise too compressed a symptom.

Scale must also be tested rather than read from the maximum configured count. Tactical allows up to 4,096 ports configured, but its help centre notes that a default Windows system has about 3,975 outbound TCP ports available at once and can exhaust them. The relevant limit depends on connection turnover, TIME_WAIT behaviour, other workloads, inbound sessions, destination diversity and Windows configuration. A licence for dozens of active ports does not prove that a host can open, fail and reopen them at the required rate.

A production driver should run through application startup before user login, Windows service restart, host reboot, network outage, DNS failure, endpoint refusal, certificate expiry, full modem pool, busy serial server, licence conflict and licence manager failure. It should compare data and control line traces with a reference physical connection. It should measure recovery time, not just steady-state throughput. It should also test the organisation's endpoint security baseline — including memory integrity, application control and firewall management — because a permissive lab machine proves little about the target fleet.

Cheap Licences, Expensive Context

Tactical's list prices start at $100, and its product pages describe perpetual licences with support included. The pricing scale is based primarily on concurrent active ports: Serial/IP and DialOut/EZ offer tiers up to 48 active ports, while COM/IP reaches 64, with larger or site arrangements available. Thousands of ports may be configured even if only a smaller licensed number may be used simultaneously.

This logic matches the customer problem. A configured port is just a mapping; an active port consumes operational value. Charging by concurrent use can be cheaper than licensing every possible device endpoint. A perpetual licence also avoids the obvious failure mode of a subscription expiring during a long-lived installation.

The purchase price, however, is not the economic centre. The value comes from avoiding or deferring changes to an application that may be undocumented, vendor-abandoned, validated against regulated equipment or embedded in a plant workflow. Rewriting it may require source code access, specialist knowledge, protocol reverse engineering, user retraining, regression testing and requalification. A $100 redirector can rationally protect a process worth far more.

One public purchase record gives a useful but narrow price point. AMay 2015 school purchase card reportlists $150 paid to Tactical Software LLC for 'com/ip-2 ports software'. It proves that a public institution bought a two-port COM/IP item at that time. It does not show why it was bought, whether it was successfully deployed, how long it ran or what the current price should be.

Historical integration documentation is also limited. A1999 technical notefrom GE Power Management Control System explains how to configure Tactical DialOut/IP with an Ethernet gateway for remote telemetry equipment. Sena's current page still presents Serial/IP as an option for its device servers. These documents show that Tactical's approach has been integrated into real OEM and industrial ecosystems over many years. They do not establish current installed base, uptime, security performance or customer satisfaction.

The business model appears to combine low-priced entry perpetual licences, higher concurrent-port tiers, site licences and support around a specialised compatibility layer. The public documents do not disclose maintenance revenue, support headcount, response time commitments or the proportion of customers using each edition. They also do not show whether paid future engineering is available after the published support period. A buyer whose avoided rewrite is worth millions should not assume that a low licence fee buys a corresponding support obligation.

Perpetual Does Not Mean Independent

Tactical'slicensing FAQdescribes seat keys and a conflict detection mechanism. A key can be moved after uninstalling or testing another Tactical redirector, but concurrent use on two systems may disable both installations. This protects the vendor's entitlements. It also makes licence state part of system availability.

Site editions add a control plane. Tactical's support documentation indicates that client systems contact a licence manager, normally on TCP port 2392. Network address translation is not supported between client and manager. If authorisation is lost, affected connections may be limited to about one minute. Up to four licence managers can be configured for resilience, but the server key is bound to one IP address. Its relocation involves vendor assistance and may include a temporary overlap period.

These details create a different risk profile from a simple file-based perpetual licence. A site deployment requires redundant managers, routable and authorised communication, monitored service health, recovery documentation and a plan for IP address changes. A data centre migration, subnet redesign, cloud move or disaster recovery exercise can become a licence event. Backup licence managers reduce the risk of a single host failure; they do not remove dependence on the licence architecture or vendor cooperation for certain changes.

Theend-user licence agreementreinforces the risk allocation. It grants a non-exclusive internal use licence, restricts reverse engineering and transfer, describes the product as licensed rather than sold and allows Tactical to modify features or availability. The express warranty is limited, and the agreement disclaims broad categories of indirect damages, including work stoppage and computer failure, subject to applicable law. This wording is common for commercial software, but it counts disproportionately when a small utility sits in a critical workflow. The customer's operational exposure may be far larger than the licence fee and far larger than the vendor's contractual remedy.

The perpetual licence therefore resolves one question: the right to continue using the licensed version does not automatically expire each year. It does not resolve driver compatibility, certificate lifecycle, lost keys, concurrent use conflicts, licence manager reachability, support availability, software modification rights, source code access or the ability to migrate the licence after an organisational change. 'No subscription' is not the same as 'no vendor dependence'.

The Final Release and the Shifting Windows Floor

Tactical'srelease notesshow a mature product family with shared versioning. Earlier 4.9 releases fixed installation failures, licence timing issues, DNS resolution, tracing defects, a rare race condition and a rare driver crash, among other fixes. Version 4.10 is labelled FINAL and described as a compatibility update for Windows Server 2022 and Windows 11 24H2 rather than a feature release.

The notes should be read as evidence of maintenance, not as an incident register. A fixed race condition or rare crash tells a buyer that driver defects have existed and been corrected. It does not reveal how many customers were affected, whether an industrial process stopped or what the mean recovery time was. Conversely, the absence of a public incident report does not prove no incident occurred.

There is also a timeline question worth resolving directly with the vendor. The lifecycle FAQ states that 4.10 was released in 2019, while the current version description mentions operating systems and builds that appeared later. This could reflect an updated installer or documentation under the same product version, but the public pages do not clarify the build lineage. A buyer should record the installer file, internal file and driver versions, signing timestamp and supported Windows version — not rely on '4.10' as if it necessarily identified an immutable binary.

The archive size and digest on the download page can help detect whether the file changes while the displayed version stays the same. A controlled software repository should preserve the approved installer and its cryptographic hash. If Tactical later refreshes the archive without changing the marketing version, the customer must know which build was validated.

The end of feature development can be rational for a stable niche product. The serial API behaviour does not change every quarter, and Tactical says it has used stable Windows kernel interfaces for many years. Stability, however, is a company assertion and not a guarantee that signing policy, virtualisation-based security, endpoint protection or future Windows internals will remain compatible. Mature code can be operationally valuable precisely because it is unchanged; a kernel component can become risky for the same reason.

The right lifecycle decision is not to automatically retire the product before 13 October, nor to ignore the date because the licence is perpetual. It is to convert the date into a decision portal. Before it arrives, every owner should know which hosts use Tactical drivers, which product and licence edition they use, which Windows version is approved, what the vendor will support next, what replacement paths have been tested and how long a migration would take.

Competition Changes the Shape of Lock-in

Tactical's strongest differentiator is independence from a single device server manufacturer. A standards-oriented redirector can be appealing when a fleet contains equipment from multiple vendors or when the customer wants to change server hardware without also changing the Windows client software. The current compatibility claims and Sena bundling support this proposition, but each server and firmware combination still requires testing.

The main alternatives fall into five groups.

First, virtual port drivers from device server vendors themselves. Moxa'scurrent NPort driver pagelists a January 2026 version of Windows Driver Manager with support for Windows 11, Windows Server 2022 and Windows Server 2025 and WHQL status for the covered NPort range. Digi'sRealPort installation guidedocuments encrypted RealPort options, including a minimum TLS 1.2 mode, certificate configuration and a shared secret for supported Digi devices. Perle'sTruePort download pageoffers a current version for Windows 11 and Server 2025 alongside Linux and Unix variants. These vendors may provide more active operating system lifecycle and tighter hardware integration. In exchange, the redirector is generally coupled to their device server family.

Second, a native network rewrite. The application can be modified to use TCP, TLS and an application protocol directly. This removes the virtual COM driver and can expose errors, identity and retry logic more honestly. It is the cleanest architectural exit when source code, expertise and validation budget exist. It can also be the most expensive option because the old application may encode decades of business rules around serial timing and modem state.

Third, a protocol gateway rather than a byte-stream bridge. A gateway can translate Modbus, DNP3, IEC protocols, proprietary device messages or machine data into a supported API, message broker, OPC UA or other managed interface. This can improve observability and identity, but it changes more of the system and may not preserve obscure device commands.

Fourth, containment. An organisation can freeze the old application and redirector within a tightly isolated virtual machine, preserve the Windows image and communicate with the rest of the environment through controlled services. This can buy time, but it does not stop the clock on certificates, hypervisor, hardware, backup or security policy. Isolation is a risk treatment, not rejuvenation.

Fifth, a return to physical interfaces: PCIe serial cards, USB adapters or direct connection to a nearby gateway. This removes serial-over-network semantics but can be difficult in virtualised data centres and may introduce its own driver dependencies, cabling and hardware lifecycle.

No option eliminates lock-in; each chooses its location. Tactical may reduce lock-in to a single device server vendor while increasing dependence on a Windows driver and Tactical's licensing. An OEM driver may simplify support escalation while tying together client and server lifecycles. A native rewrite moves dependence to owned code and engineering capability. A protocol gateway creates a new platform boundary. The purchasing question is not 'Which choice has no dependency?' It is 'Which dependency can the organisation observe, test, support and exit?'

Switching Costs Accumulate in the Exceptions

Replacing Tactical is easy in the abstract: install another redirector, give it the same COM number and point it at the same server. The expensive part lies in the behaviours that were never documented because the old system just worked.

One application may expect DCD to go high before sending data. Another may toggle DTR to reset a device. A third may depend on the exact delay between opening the port and receiving a modem response. A service may start before the network is ready and rely on a particular retry interval. A binary protocol may be sensitive to Telnet escaping. An operator may diagnose faults through Tactical's trace format. A deployment script may write configuration directly into registry locations. A recovery procedure may depend on a site licence manager and preassigned COM numbers.

These exceptions become switching costs because the virtual port layer absorbed them. They are not visible in the application's feature list, and they may emerge only on failure. The longer the bridge stays in place, the more likely it is that staff remember the interface but not the reason for each setting.

Tactical's configuration presets and snapshots reduce some exit costs by making mappings and options visible. However, credentials and licence state are deliberately excluded from certain exports, and another vendor's will differ. A migration package should therefore include human-readable port inventories, endpoint ownership, protocol mode, signal behaviour, security requirements, firewall rules, certificates, licence topology, application owners, tested failure cases and packet/serial traces of a reference transaction.

The most valuable exit asset is not a spare installer. It is a behavioural test suite. If a team can replay representative reads, writes, control line transitions, disconnects and retries against another path, it can evaluate a new driver, a native TCP client or a protocol gateway. Without such a suite, every migration becomes an archaeological project and the seemingly cheap bridge gains negotiating power through uncertainty.

What a Serious Buyer Should Test

A Tactical purchase can be sensible, but the purchase file should be built around evidence rather than the small invoice. At a minimum, it should answer the following questions.

1. Is the entitlement attached to the correct legal and operational entity?Confirm that the quote, invoice, EULA, support contact and licence key all identify Tactical Software, LLC. Obtain current legal status and payment details through normal vendor onboarding rather than inferring them from the website or BBB.

2. Which exact build is approved?Record the SHA-256 of the archive, Authenticode signer and chain, driver file versions, signing timestamp, catalogue status and installer size. Ask Tactical to explain the 4.10 build timeline and whether the currently downloadable package differs from the original 4.10 release.

3. Does it work under the production Windows security baseline?Test the exact Windows 11 or Server image, including 25H2 or Server 2025 if those are the target, with memory integrity, endpoint detection, application control and centrally managed firewall policy enabled. Get a written statement on supported editions, architectures and future support.

4. Does the application use only the serial semantics the path preserves?Capture COM operations on a reference physical system. Test baud and frame changes, flow control, DTR/RTS, CTS/DSR/DCD, breaks, buffer flushing, binary data, timing and exclusive access. Do not accept a successful port open as proof.

5. Is the remote endpoint actually interoperable?Record the device server vendor, model, firmware and protocol mode. Test raw TCP, Telnet and RFC 2217 separately where relevant. Confirm which RFC 2217 commands and notifications the server actually implements. Treat a compatibility list entry as a lead, not a certification.

6. What does failover preserve?Induce DNS failure, refusal, timeout, cable loss, server reboot and mid-transaction disconnect. Measure when an alternative endpoint is selected and whether the application receives an error. Prove that the alternative server reaches the intended device and define how partial commands are reconciled.

7. What exactly does TLS validate?Capture a handshake from the current build. Identify protocol versions and cipher suites. Test an expired certificate, untrusted issuer, wrong hostname or IP, changed server certificate and, where relevant, missing client certificate. Document key storage and rotation. If Tactical TLS cannot satisfy policy, design and test an approved external protection layer rather than assuming 'SSL/TLS supported' is sufficient.

8. Can the network path be least privilege?List every data flow, inbound, proxy, discovery and licence manager. Restrict destinations and sources. Test DNS and proxy failure. Confirm how the System process is handled by host controls and whether security tools can attribute traffic.

9. Can licences fail safe?For seat licences, duplicate a key only in an isolated test and observe conflict behaviour. For site licences, stop the primary manager, block port 2392, change routes and exercise backup managers. Verify what happens to established and new sessions, how quickly authorisation expires, and how an IP migration or disaster recovery activation would be approved.

10. Is scale measured at failure as well as success?Open the planned number of ports, cycle them at production rates and monitor ephemeral port usage, CPU, non-paged memory, logs and TIME_WAIT accumulation. Include other workloads on the host. The configured port ceiling is not a capacity guarantee.

11. Are support and recovery obligations explicit?Obtain support hours, response targets, escalation contacts, supported log formats and policy after 13 October 2026. Preserve the installer, documentation, licence records, snapshots and a reconstruction procedure. Determine what assistance requires the vendor and what can be done independently.

12. Is sensitive diagnostic data governed?Review Tactical traces, packet captures and support bundles before transmission. Define retention, redaction and secure transfer procedures. Serial payloads may expose operational commands or customer data even when the application itself has no modern logging.

13. Is there a funded exit?Choose a trigger — unsupported Windows migration, failed security control, unavailable licence transfer, unacceptable support, device server replacement or application modernisation. Estimate the timeline for an OEM driver, native network change, protocol gateway or confined legacy environment. Rehearse at least one alternative before the current path becomes urgent.

These tests convert a generic compatibility promise into evidence about one application, one Windows image, one network and one device fleet. They also give Tactical a fair basis to support the deployment. Without them, the vendor may receive a defect report that simply says 'COM3 stopped', while the customer assumes a level of system assurance no redirector vendor could infer.

What the Public Evidence Cannot Establish

Tactical's public documentation is unusually detailed on configuration and mature product behaviour, but it leaves important commercial and assurance questions unanswered.

There is no audited public figure for customers, active ports, revenue, headcount, support ticket volume or geographic deployment. OEM references and compatibility lists do not fill this gap. The GE technical note and school purchase record demonstrate particular historical uses, not market share or current adoption.

The documents do not provide independent results for uptime, latency, security or customer success. They do not disclose a public support service level agreement. They do not show an archive of current security advisories, software bill of materials, penetration test results, secure development certification or complete third-party component inventory. No publicly attributed field failure or security incident was established from the evidence used here, but this absence must not be converted into an assertion that none have occurred.

Current TLS and certificate behaviour remains insufficiently documented publicly. The legacy 4.3 manual cannot answer for 4.10. Current compatibility with Windows 11 25H2, Windows Server 2025 and future kernel security requirements also remains publicly unresolved. The 'final' status of the product makes these gaps larger because documentation and direct support responses may now weigh more than a future release roadmap.

The company's financial resilience and succession plan are not public. This matters for any specialist vendor whose software includes a licence application and whose assistance may be needed to relocate a site licence. A customer does not need to demand the disclosure expected of a public company, but it should size its contingency against the consequences of support unavailability.

Watch the Bridge, Not Just the Traffic

The coming year should tell whether Tactical's final releases settle into a stable long-term retirement or meet friction with the next Windows baseline. Four signals merit attention.

One is any explicit compatibility statement for Windows 11 25H2, Windows Server 2025, memory integrity and future driver signing policy. A support statement is useful; a tested and signed build with a clear lineage is better.

Two is the post-October support model. Tactical may continue to answer questions or offer paid arrangements after the published date, but buyers should get that commitment rather than assume it. The difference between 'the software continues to work' and 'the vendor will investigate a kernel failure' is substantial.

Three is security transparency. A current TLS matrix, certificate validation description, SHA-256 downloads, component inventory and advisory channel would materially reduce uncertainty without changing the product architecture.

Four is the customer's own migration progression. If the bridge remains needed, its inventory, behavioural tests and recovery package should improve every year. If these artefacts do not exist, each year of successful operation can paradoxically increase exit risk by allowing knowledge to fade.

Preserve Deliberately

Tactical Software's products solve a real and persistent problem. Industrial and commercial systems do not become worthless simply because their applications were written for serial ports or modems. A kernel-level virtual COM port can keep a machine, meter, terminal, controller or service accessible while hardware and networks change around it. In many cases, it is more responsible than forcing a hurried rewrite.

The success is also the source of the risk. A good compatibility layer makes old assumptions disappear from view. Tactical transforms a distributed chain of Windows policy, TCP behaviour, serial controls, remote hardware and licensing into a port name that feels local. The application continues to work precisely because it does not know how much has changed.

The right answer is neither to dismiss the software as legacy nor to treat its longevity as proof it will work forever. Buy the bridge if it is the best economic route. Verify the exact driver, protocol and security behaviour. Design licence and endpoint failure as operational scenarios. Preserve the installer and configuration, but invest more heavily in behavioural evidence and an alternative path.

On 13 October 2026, COM3 will not suddenly cease to exist. What ends is the comfort of an unexamined support horizon. From that point on, every continued year should be a deliberate decision: the value of preserving the old interface must still exceed the growing cost of depending on the machinery that makes the port seem to be there.