Having devoted security personnel is a low priority at most companies. General engineers will be tasked with figuring out how to incorporate "security" and cryptography into products. I have visited many a company where I am talking to a room full of very sharp engineers, but there is a fundamental lack of understanding of cryptographic primitives and their applications (let alone high-level protocols using those primitives).
At large companies, having a few strong security engineers that can provide support to the various engineering areas should be a norm (if anything, from a liability perspective). At small companies, having security engineers who are also capable of general engineering is a good balance. It seems lately that neither is occurring, but this will probably correct itself as security becomes a military/gov't-demanded->(bank-demanded->)corporate-demanded->consumer-d emanded feature. Of note, in my (Washington DC Metro) area there has been plenty of demand for cryptographic/information assurance/security engineers. -Andrew PS One (vague) example of the blunders that occur... A friend of mine worked for a company and wanted me to meet a few of their engineers. We started talking about cryptography and the engineers told me a story. It seemed that this company had wanted to add encryption to their communications products and some engineers were tasked with building this feature. These engineers did some digging and they discovered asymmetric and symmetric cryptography. Since asymmetric cryptography seemed "better," they decided to use it (RSA algorithm) to encrypt/decrypt the traffic. (Bad idea.) (of note, this was eventually changed to using a public key-based key exchange of symmetric keys. These symmetric keys were then used by a symmetric algorithm to encrypt/decrypt the traffic. I do not know the details of the protocol used or if it was standards-based.) Using this example, bringing on a (probably contract) "cryptographic security engineer" would have saved a great deal of time and effort.
