That is the correct starting point. However, you must still pair it with a good security process that properly manages and integrates your components otherwise you can still create easily exploitable critical weaknesses. As a trivial example, I remember a proposal by some large networking company to build out a separate parallel network that is exclusively for critical infrastructure devices, thus introducing an air-gap between normal computers and critical infrastructure devices. However, this neglects the fact that there would likely be millions to billions of such devices on the network distributed and likely easily physically accessible which would thus make it easy to still gain access to the "air-gapped" network for nefarious purposes. Maybe not quite as easy a if they were on the same network, but from an objective point of view it would not be a meaningful impediment which would stop any real adversary from defeating it.

What should actually be done is start from an adequate, but possibly impractical or ineffective solution and a process that properly manages the creation of that system then figure out how to make it practical without making it inadequate. If it is impossible to come up with an adequate, but impractical solution to start with, then it is highly unlikely that an adequate practical solution will show itself. This is far easier than starting with a practical, but inadequate solution and making it adequate without making it impractical since, as most engineers know, it is almost always easier to simplify a working design than to bolt things onto a non-working design until it works. If you can not simplify a working design, then it is highly unlikely that you will be able to create a better solution from scratch which is borne out by the continuous failure of pretty much everybody who has ever tried doing so in the cybersecurity industry.

In this particular example, if security is actually important, you should likely start the consideration with an air-gapped system and an adequate security process which assumes that primitive and then see if you can loosen that restriction. But, as I must stress, the key element is actually in having a process that can properly utilize, manage, and reason about the components in a way that can create secure systems. Secure primitives without a good security process can easily create an insecure system. However, a good security process with insecure primitives at least stands a chance (which even ignores the fact that a good security process should filter out insecure primitives that can not be usefully integrated). As for how you can determine if a security process is any good, you can do this by seeing if the process has consistently created systems that reach an adequate objective level of quality given different circumstances. In this case, air-gap based processes have seen material success in actually achieving an adequate level of security in certain circumstances, so it is probably good to start from there though there are actually other potential solutions.