If you're writing the driver, you have total control over what you might include to effectively disable at least the telnet portion. For example: you could have a custom command that you run (manually or schedule an app or have another automation, e.g., a physical or virtual button press, to do the same thing). The command could modify a state value you can use to track whether it's "disabled." Obviously this can't totally "disable" the driver itself, or you wouldn't have a way to automate the re-enabling with a similar command (nor can a driver truly do that to itself to the extent that it completely stops running/waking up; it's just a matter of how you choose to have the driver react when that happens).
The only way to totally disable the entire driver is to use Hubitat's built-in feature for manually disabling apps and drivers. The original intent of this feature was that you could use it if trying to troubleshoot a hub problem (like if you suspect runaway code causing slowdowns on the hub), but you can use it for whatever purpose you want. The tradeoff is that there is no way to automate this--you have to go into the admin UI and enable/disable yourself. If this is not a driver you're writing, this will likely be the easiest option. For how to do that, see here:
I'm not sure which of these options you'd actually want, but hopefully one of these suggestions helps.
