[prerok]

I don't understand the question.

We created software and we wanted it to be secure (by ourselves). When it came to FIPS compliance, we had to pay for certification, but we were already compliant anyway, so it was only procedure.

It's definitely not as strict as the latest developments in crypto would demand, but it does cover the product in its entirety. Like, oh, you have encryption, but you have a backdoor here: not FIPS-2 compliant.

So, yes, plenty of software and products are FIPS compliant. And if it's mandated, then the provider is not chosen.

[lantastic]

FIPS and "be secure" aren't necessarily a full overlap: there's plenty of ways to be secure that isn't even allowed in FIPS, so you need to actively disable that set if you run FIPS mode (depending on libraries used, this may e.g. disqualify hardware intrinsics because it was not covered by CMVP, creating potentially material performance consequences).

If you're already compliant (implying you are using FIPS compliant crypto in all situations), the matter is tautological.

[prerok]

Well, I agree that if you are using alternate means to achieve the same effect (or better!) and that's not recognized by the FIPS compliance then that can be painful.

My experience lies mostly in C and embedded applications, where the physical security was also in question and that is where the most of the effort to certify went. Software was relatively easy by using the right versions. So, maybe not just a certification, but non-fretting one.