This is not how macOS's code signing system works; e.g. it does not use .cire files.
I tried installing two of those applications and I can't reproduce the error myself, but I can see the "Error loading the application. Contact your administrator." message within the strings of /Applications/SecurID.app/Contents/MacOS/SecurID, along with references to ".cire" and some strings from the .cire file ("certificate", "hash"). edit: I also see references to SecTrustCreateWithCertificates, SecTrustEvaluate, and other related functions from Security.framework which are designed to validate certificates (but wouldn't be called directly by applications as part of standard macOS code signing).
Conclusion: They probably rolled their own custom code signing system, albeit one that uses the system trust store to verify certificates.
Nor is this related to Qt in any way. As far as I know Qt has never shipped .cire files as a way to sign the libraries. This is something the vendor of the software token library (stauto32) has done when embedding Qt.
Yep, nothing to do with GateKeeper as the article imply. If I had to guess, the security framework returns that the bundled certs are invalid, and that crashes the apps in question as they can't go forward ?
I tried installing two of those applications and I can't reproduce the error myself, but I can see the "Error loading the application. Contact your administrator." message within the strings of /Applications/SecurID.app/Contents/MacOS/SecurID, along with references to ".cire" and some strings from the .cire file ("certificate", "hash"). edit: I also see references to SecTrustCreateWithCertificates, SecTrustEvaluate, and other related functions from Security.framework which are designed to validate certificates (but wouldn't be called directly by applications as part of standard macOS code signing).
Conclusion: They probably rolled their own custom code signing system, albeit one that uses the system trust store to verify certificates.