Our small law enforcement agency is moving to a self-hosted dispatch and records management system running on Windows Server. The vendor's mobile app needs to connect to the server, which would require opening a firewall port. Because the phones use dynamic addresses, we cannot restrict access to a fixed list of WAN IPs.
When we asked about security, the vendor said the connection uses an encrypted, signed SSL certificate and that the web service requires Active Directory authentication plus membership in a specific security group. They also said the product is installed in many organizations without any problems.
That answer feels incomplete. Does the certificate only protect the connection, or does it also authenticate the phones? How exposed would the web service and login endpoint be to scanning, password spraying, or an application vulnerability? Should we require a VPN, zero-trust access solution, MFA, or a DMZ instead? The system may handle sensitive criminal justice information, so compliance requirements are also a concern. A VPN would add an extra step for users, but there are only a few mobile users.
3 Answers
The vendor’s explanation is not enough to establish that the system is secure. TLS protects data in transit and can authenticate the server, but it does not automatically prove that the connecting phone or user is trustworthy. If the login endpoint is publicly reachable, attackers can still scan it, exploit vulnerabilities in the web application, or attempt password spraying against the authentication flow.
Ask for an architecture and data-flow diagram, the exact authentication method, MFA support, patching and vulnerability-management practices, logging and monitoring details, and information about how the application is isolated from the rest of your network. If the system handles criminal justice information, verify the applicable policy requirements with your security or compliance contact rather than relying on the vendor’s assurances.
I would avoid exposing the Windows server directly and require an additional access-control layer. A properly configured VPN with MFA is the straightforward option, although a managed zero-trust or private-overlay solution may be easier for mobile users. These approaches can keep the application off the public internet and avoid depending on changing phone IP addresses.
If the vendor cannot support that, place the application in a DMZ or similarly isolated network segment, allow only the specific traffic it needs, and ensure it does not have unrestricted access to Active Directory or internal databases. The extra user friction is usually a much smaller risk than providing a public path into a sensitive environment.
For a small number of users, the operational burden of a VPN should be manageable. I would choose the extra support work over accepting an internet-facing service based only on ‘we have never had a problem.’
Having a certificate and AD integration is common, but those features alone do not make an application safe. The important questions are whether the certificate is actually used for mutual client authentication, how users and devices authenticate, whether MFA is available, how failed logins are handled, and how quickly the vendor patches the product.
Treat the vendor’s track record statement as marketing, not evidence. Request independent security documentation, penetration-test summaries, a software bill of materials, vulnerability-disclosure procedures, support and patching commitments, and clear responsibility for incident response. Have an independent security professional review the design before deployment, and confirm the system meets your law-enforcement data requirements.
Also determine whether the application server can reach domain controllers, databases, or other sensitive systems. Even if the web service is compromised, segmentation and least-privilege firewall rules should limit what an attacker can reach next.