Parking-meter controllers run embedded/RTOS software that is rarely patchable. Which primary techniques best compensate?

Parking meters and similar embedded or real-time operating system devices often cannot be patched on the cadence used for clerk PCs. When vendor firmware lags or update windows threaten availability, compensating controls become the practical security operations answer: network isolation so meters cannot be reached indiscriminately from the Internet or clerk VLANs, plus monitoring for anomalous traffic, authentication attempts, and configuration changes. Isolation and visibility reduce exploitability when timely patching is limited. Direct Internet exposure of every meter with default passwords for vendor ease maximizes remote attack surface on devices least able to defend themselves. Ignoring the meters because embedded devices supposedly fall outside security operations abandons a real municipal asset class. Running unvetted third-party apps on the meters to add security features often expands the attack surface and voids support without providing trustworthy controls. Exam caveat: when patching is constrained, exam answers favor compensating controls (segmentation, monitoring) over pretending the devices need no operations attention. Operational check: place meters on isolated networks with tightly scoped management access, inventory firmware versions, alert on unexpected flows, and document residual risk where patches remain unavailable.