SHA-2 in this particular case is just as secure as PBKDF/scrypt/bcrypt. Iterations are unnecessary and wasteful. Generate high-entropy (256 bit) passwords and forget about KDFs and even salts.
In fact, it makes more sense to use SHA-2 than PBKDF because there is no existing platform implementation of the algorithm and "rolling your own crypto" is a no-no.
That's quite a strong statement. The essence here in the question is that the OP has full control of the passwords he stores on the system and knows that he will be the only one storing passwords on the system.
Signal makes use of a construction called HKDF in its double-ratchet algorithm, which essentially applies the hashing algorithm for only one iteration.
Why is this okay?
Password KDFs exist for precisely one reason: low-entropy passwords. Most people won't remember a 128- or 256-bit key generated from a CSRNG in their heads. I'd venture that most people can remember at most a 40-bit random string for a long enough period of time to use it.
Pretty much all hash functions (even MD4, MD5, and SHA-1, but since you said you have SHA-2 on the platform, let's be safe here) have a feature called preimage resistance, which is good enough for your application since you control all of the passwords that get stored on your system. This means that it is computationally infeasible, given a hash, to generate something that hashes to the same hash.
Simplifying a bit, the most practical way to generate a preimage for one of these hash functions is to keep trying inputs. There are a few examples of attacks that do slightly better than brute force, but they're totally infeasible. Now, if the password/key you chose to put into the hash function only has 16 bits of entropy, this resistance property won't do you much, because the attacker will be able to try all 65536 different inputs you could have put in.
Why control of the password matters
Think less of the things that you're putting in as "passwords" but more as cryptographic keys. As long as you are hashing keys that have entropy greater than or equal to the number of bits output by your choice of hash function (for SHA-256, that's 256 bits), then you're totally fine just running one iteration of the hash over it to prevent key extraction. The preimage resistance of the hash combined with the high entropy of your key means that an attacker simply cannot guess the value that you put in. There's no need for the thousands of iterations or arguing with the business side or reasoning about an abstract attack to not-so-receptive bosses. FPGA/ASIC resistance is a moot point when you have to guess a 256-bit input into the hash function.
Generate your "passwords" with a hardware RNG or a CSPRNG and promptly destroy any seed material that could be used to recover any internal state and therefore the passwords. Make sure that these are 256 bits long. If your system doesn't support non-alphanumeric or non-ASCII passwords, then after you generate the 256 bits, encode it in base-64 or base-26 or binary if you like. (This means that the actual passwords that you submit will be longer than 32 bytes, but this doesn't help entropy much.)
Treat these passwords like cryptographic keys -- ideally, they would be stored on hardware tokens. A hardware password manager works very well for this purpose. Store the SHA-256 hashes in your system, and verify the passwords by hashing and comparing. You should reject all attempted passwords that do not match your generation criterion (an example would be a user-selected password < 256 bits), even if the hashes match, and you should not allow anyone to set a password that did not come from a CSRNG. This should be
documented. Even better is if you add some obscure checksum byte at the end of the passwords that you generate that is verified by the platform before it allows you to set the password. This should deter all but the most hilariously incompetent people from putting anything less than a cryptographic key on your platform.
Public Key Cryptography
Your use case is a bit odd. Most places maintain passwords because setting up a PKI and dealing with end-users is very difficult, especially with things like public keys. Since you seem to be the only one entering passwords into the system, maybe it would make more sense to store Ed25519 or ECDSA public keys on the system and write code there that implements a challenge-response protocol (a simple one is sign this 256-bit value -- but be careful that you don't reuse these keys, as someone might trick you into signing away your Bitcoin or a criminal confession). The device that would interface with your system here and maintain the private keys probably has a strong implementation of public-key cryptography and would have no problem authenticating itself. Your "roll my own" implementation of the signature verification could be the least secure in the world in terms of side-channel attacks (think of putting its entire state on a billboard or the blockchain), as long as it gives the correct answer, and you would be perfectly fine, as the verification algorithm simply has no access to the private keys.