The thing is, if everybody and their dog can read your chip as easily as you can, there’s no point in adding extra doors when the key to the whole castle is hanging in the breeze on a hook outside. That’s what I meant: readily readable information - be it NDEF records, UIDs and whatnot - are only “secure” if you don’t tell anybody you have a chip and what it contains (security through obscurity), or you’re awake and quick enough to punch someone who tries to read your chip surreptitiously in the face before they manage to do it (security through Mohammed Ali). That is, not very secure at all.
What you want is 2FA, one of the factors being a challenge-response exchange with the chip, and the other is a PIN or something else that doesn’t depend on the chip. But of course the technical implementation is more complicated and less ubiquitous.
A mitigation strategy if you insist on keeping all that stuff as a NDEF record is to add a PIN that stays in your brain at the end of the record. Or said another way, your NDEF record holds a partial code to your encrypted file, and the rest of the code is your PIN. The encrypted file can only decode with the NDEF record and the PIN concatenated to each other.
Another mitigation strategy is to apply some kind of “recipe” that only you know. For instance, say your apparent secret code in the NDEF record is 12576 (I know it’s short, it’s just an example) and the recipe is “add 1 to all the odd digits, and 2 to the even digits”. You can then read the NDEF record, but enter your real code manually, which is 24697. That way you don’t have to remember a mountain of digits, just the recipe.
It’s not ideal, but it’s better than what you do now if you care about security.