You Can't Migrate Cryptography You Can't See: Why Post-Quantum Readiness Is a Network Visibility Problem

The quantum migration stopped being a research topic this year. NIST has finalized its post-quantum cryptography (PQC) standards, and RSA and ECC — the algorithms quietly protecting your VPN concentrators, management interfaces, iLO/iDRAC cards, and printer web consoles — are scheduled for deprecation by 2030 and removal from NIST standards by 2035. Combine that with harvest-now-decrypt-later attacks, where adversaries record your encrypted traffic today to decrypt it once a cryptographically relevant quantum computer exists, and the migration clock is already running.

Then the email lands from the CIO: we need a complete cryptographic asset inventory by end of quarter. Every sysadmin reading this knows what that sentence actually means. Someone has to figure out what is actually on the network.

So you open the CMDB, last touched 18 months ago by someone who left the company. You find the Visio diagram from 2019 in a SharePoint folder. You export the last quarterly vulnerability scan. Your RMM reports 180 managed endpoints. Then you pull the MAC address table from the core switch and count 262 entries.

Those 82 devices in between — the label printers, the IP cameras, the badge readers, the UPS management cards, the vendor appliance someone installed in 2021 and never documented — have no agent, no patch history, and no owner. They are exactly the devices that will still be negotiating RSA key exchange in 2029 unless someone finds them first. That is a network visibility problem before it is a cryptography problem.

What Your Existing Stack Gets Wrong

Your tooling was never built to answer the question what is on my network right now, and where is it connected?

RMM platforms — ConnectWise Automate, NinjaOne, Datto RMM and their peers — are agent-first by design. They are excellent at managing endpoints where an agent is installed. A printer with an embedded web server, an IP camera, an aging managed switch, or an appliance dropped in by a vendor is out of scope. No agent, no device, no visibility.

Standalone monitoring tools — PRTG, SolarWinds, LibreNMS — monitor what you pointed them at. Most have discovery, but it runs on a schedule and dumps results into a static list. The tool watches the health of known devices; it does not maintain the composition of the network. A device that joined last Tuesday stays invisible until the next scan, if anyone actually reviews the output.

Vulnerability scanners produce point-in-time snapshots that are stale the moment the scan finishes. Spreadsheets and CMDBs are maintained by hand and always lag the network, because the network changes every week and the spreadsheet changes once a quarter at best.

Why the Gap Exists

These gaps are architectural, not a skills problem. Each tool was built for a different job: the RMM for endpoint management, the monitor for uptime, the helpdesk for tickets. None of them owns network composition. Meanwhile, the devices most likely to be missed — IoT gear, cameras, printers, OT and vendor appliances — are the ones that resist agents, change rarely, and sit on the wire for a decade.

Every sysadmin has met them. The printer with an embedded web console serving TLS 1.0 and an RSA-1024 certificate issued in 2016. The IP camera with default credentials and no firmware update path. The lab switch someone plugged in under a desk, running a management GUI over a self-signed RSA cert. None have agents. All are live right now.

What It Actually Costs You

• Migration projects stall at discovery. A PQC roadmap that should take six months burns its first three on manual nmap sweeps, switch port reconciliations, and Excel archaeology.
• Your inventory numbers contradict your infrastructure. The CMDB says 340 assets. The switch MAC tables say 412. Those 72 unknowns are your compliance gap, and the auditor will find them before you do.
• Harvest-now-decrypt-later makes every missed device a future breach. Traffic captured today over RSA key exchange is readable the day a CRQC exists. The camera in the warehouse hallway does not care about your 2030 deadline; it will happily keep speaking deprecated crypto until someone walks over and deals with it.
• Technician time evaporates and morale follows. One of your people just spent four days building a spreadsheet that was wrong a week later. They will be asked to do it again next quarter.

How AlertMonitor Turns a Research Project Into an Operational Task

AlertMonitor attacks this from the opposite direction: instead of waiting for you to tell it what exists, it continuously discovers what exists. Using SNMP, ARP, and active scanning, it builds and maintains a live inventory of every device on the network — switches, firewalls, access points, printers, IP cameras, and unmanaged endpoints — including the ones no agent will ever touch.

Three capabilities make this work for a crypto-migration program specifically:

Continuous, not scheduled, discovery. The inventory does not age. There is no quarterly scan to wait for, because discovery never stops. When a new device appears on the network, an alert fires instantly — not at the next scan window.

A live topology map with full context. The new-device alert does not just say unknown host detected. It tells you which switch, which port, which VLAN, and what the MAC vendor OUI suggests the device is. That is the difference between a two-minute investigation and a two-day one.

One platform instead of five. The unmanaged camera you discover flows into the same system that runs your RMM agents, your patch status, and your helpdesk. Discovery becomes a ticket in one click, and the device record keeps its network context — where it is, what it is connected to — for as long as it exists.

The Old Way vs. the AlertMonitor Way

Old way: CIO asks for a crypto inventory → a tech opens twelve tabs across five tools → runs an nmap sweep over lunch → reconciles results into Excel over three weeks → presents a spreadsheet that is already stale → the shadow device in building C misses both the report and the audit.

AlertMonitor way: open the live topology map → filter by device class → export the current inventory → done. When a new device hits the wire next month, an alert reaches a tech in seconds with switch, port, and VLAN context. The device gets onboarded or confronted — and the answer to what is on our network stays current because the map maintains itself.

For MSPs this compounds per client. A new client onboarding that used to be a two-week discovery engagement becomes an afternoon, and the topology stays accurate without anyone maintaining it. That is how the NOC stops learning about client devices during an incident.

Practical Steps You Can Take This Week

1. Establish a live baseline

Turn on continuous discovery across every subnet and VLAN in AlertMonitor and configure alerts for new device detection. Then compare the discovered device count against your CMDB and your switch MAC tables. The delta is the real scope of your migration project — and it is almost always bigger than the CMDB claims.

If you want the manual version for comparison, a one-shot ARP sweep looks like this:

sudo arp-scan --localnet | tee device-inventory-$(date +%F).txt

Useful for a spot check — but note the filename. It is accurate for exactly one day. That is the entire problem continuous discovery removes.

2. Inventory the cryptography on your managed servers

For everything an agent does reach, enumerate certificates and key algorithms across the Windows estate:

Invoke-Command -ComputerName (Get-Content .\servers.txt) -ScriptBlock {
    Get-ChildItem Cert:\LocalMachine\My | ForEach-Object {
        [PSCustomObject]@{
            Computer     = $env:COMPUTERNAME
            Subject      = $_.Subject
            NotAfter     = $_.NotAfter
            KeyAlgorithm = $_.PublicKey.Oid.FriendlyName
            KeySize      = $_.PublicKey.Key.KeySize
        }
    }
} | Where-Object { $_.KeyAlgorithm -match 'RSA|DSA' } |
  Sort-Object Computer, Subject | Format-Table -AutoSize

Everything that comes back as RSA goes on the migration list. Anything under 2048 bits goes on a much more urgent list.

3. Check which TLS versions your servers actually accept

Deprecated protocol settings live in the SCHANNEL registry keys, and they differ per server more than most teams expect:

Invoke-Command -ComputerName (Get-Content .\servers.txt) -ScriptBlock {
    Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols' | ForEach-Object {
        $server = Get-ItemProperty -Path (Join-Path $_.PSPath 'Server') -ErrorAction SilentlyContinue
        $client = Get-ItemProperty -Path (Join-Path $_.PSPath 'Client') -ErrorAction SilentlyContinue
        [PSCustomObject]@{
            Computer      = $env:COMPUTERNAME
            Protocol      = $_.PSChildName
            ServerEnabled = $server.Enabled
            ClientEnabled = $client.Enabled
        }
    }
} | Sort-Object Computer, Protocol | Format-Table -AutoSize

This report shows whether TLS 1.0 and 1.1 are actually disabled or merely believed to be disabled.

4. Verify what a live service is negotiating right now

Registry settings describe intent; the wire shows reality. From any Linux box:

echo | openssl s_client -connect intranet.corp.local:443 2>/dev/null \
  | grep -E 'Protocol|Cipher|Server public key'

A cipher line like ECDHE-RSA-AES256-GCM-SHA384 tells you the key exchange is still RSA. For the certificate itself:

echo | openssl s_client -connect intranet.corp.local:443 -servername intranet.corp.local 2>/dev/null \
  | openssl x509 -noout -text | grep -E 'Public-Key|Signature Algorithm|Not After'

Run this against every HTTPS service you found on the topology map. If it says RSA, it goes on the migration list — including that printer console you forgot existed until the map showed it.

5. Keep the inventory from drifting back

Discovery without follow-through becomes another stale spreadsheet. In AlertMonitor:

• Route new-device alerts into the helpdesk queue so every unknown endpoint becomes a triaged ticket, not a notification someone reads on Friday.
• Use live-map filters by device class to review crypto exposure by category — printers, cameras, appliances.
• Check firmware and patch status on the same device record where the discovery data lives, so the remediation path is visible without opening another tool.

The result: a device that appears on the wire is investigated within seconds with its switch, port, and VLAN attached, then either onboards into management or gets a ticket — before it becomes the unexplained device on next year's audit exception list.

The quantum computer may or may not arrive on schedule. The 2030 deprecation deadline will. Post-quantum migration is fundamentally an inventory problem, and inventory is a visibility problem — you cannot migrate cryptography you cannot see. The teams that hit the deadline will not be the ones with the best crypto roadmap. They will be the ones whose network map is always current because it maintains itself.

Related Resources

AlertMonitor Network Monitoring & Visibility AlertMonitor Platform Overview Book a Demo Network Monitoring & Visibility Resources