FIPS 140 is a security standard for cryptographic devices which specifies what measures are used by a particular device to secure it. Compliance with FIPS 140 is required to sell a cryptographic device to the US government, so it is fairly common for crypto libraries or devices to be FIPS 140 validated. Examples of FIPS 140 validated produces are Blackberry wireless email devices and RSA's BSAFE crypto library. It is defined by NIST, and is currently at revision 2 (so the current standard is FIPS 140-2).
FIPS 140 specifies 4 levels of security. Level 1 is fairly simple, and can be implemented in software (essentially any crypto library can be validated at level 1). Higher levels require some level of tamper resistance or tamper detection, which requires at least some of the functions be implemented in hardware, though most of the Level 2/3 validated products do use some software running on a general purpose operating system.
A product validation is handled by an independent (licensed) testing facility, which usually charges between $10,000 and $100,000 for it's services. For this reason, only companies hoping to get major government contracts go for FIPS validation.
The requirements of FIPS 140 are not exactly iron clad: anything below Level 4 actually doesn't mean too much. For example, at Level 3, NIST has this to say about how much testing should be done to ensure that "non-removable covers/doors" are, in fact, non-removable: "'Remove' shall NOT consist of drilling, milling, burning, melting, griding or dissolving the cover/door/enclosure ...", which seems to leave you with plenty of leeway in attacking such a cover (for example, using a power drill). In fact, NIST restricts the testers to use only tools like a "screwdriver, x-acto knife, or other basic instrument."† Level 4 hardware, on the other hand, is pretty hard core, and usually includes very advanced tamper countermeasures.
For this reason, it's usually expensive (often over $10,000 per piece), and is mostly used by banks and similarly security-sensitive places.
One failure of FIPS 140 (IMO) is the lack of distinction between logical protections and physical protections. For example, if a module, implemented as a separate process running on a Unix box, is completely, 100% totally secure (as viewed from other software, including software that uses the module)‡, it can only make Level 1, because tamper-evidence is basically impossible to perform without some hardware (a seal on the case, or whatever). This would put it on the same level as any random Level 1 validated crypto library, even though such a module would be, in most cases, measurably more secure. Part of this problem is that historically, FIPS 140 assumed the module under validation was at least partially hardware, and the ability to validate pure software implementations was shoehorned in during the second revision. Often it's not a great fit.
† Implementation Guidance for FIPS PUB 140-1 and the Cryptographic Module Validation Program, NIST, January 10, 2002
‡ Here I'm referring to a module that implements something similar to the IBM 4758, but running in software instead of on a special hardware platform.