If the RNG of a HSM is said to be compliant to FIPS 140-2 (approved DRBG - SP 800-90 CTR mode) does also imply that it is compliant to FIPS 186-2 ?
FIPS 140-2 refers the task of standardizing RNGs to SP800-90 (PDF) which specifies software-based pseudo random number generators, to which your module seems compliant.
FIPS 186-2 only talks about RNGs in one place, in Appendix 3, where it says that using the RNG from appendix C of ANSI X9.17 is appropriate (it no longer is as of today) and it also says that using other FIPS approved is appropriate. As it stands it looks like the RNG can be considered appropriate because FIPS 200 (PDF) says, that you should follow SP800-53 (PDF) which in turn says that SP 800-90 should be followed, which specifies the RNG in question and thereby the RNG is "FIPS-approved".
Note though that you can't claim FIPS 186-2 compliance just because you use a compliant RNG because FIPS 186-2 specifies the RSA, DSA and ECDSA signature algorithms which you'd have to implement and provide properly in order to claim FIPS 186-2 compliance.
The relevant quote from FIPS 186-2 Appendix 3 (PDF):
Any implementation of the DSA requires the ability to generate random or pseudorandom integers. Such numbers are used to derive a user's private key, x, and a user's per message secret number, k. These randomly or pseudorandomly generated integers are selected to be between 0 and the 160-bit prime q (as specified in the standard). They shall be generated by the techniques given in this appendix, or using other FIPS approved security methods.
One FIPS approved pseudorandom integer generator is supplied in Appendix C of ANSI X9.17, "Financial Institution Key Management (Wholesale)".
I don't think it does.
On one hand, FIPS 186-2 is a standard regarding digital signatures, as said in the abstract of this document:
This standard specifies a suite of algorithms which can be used to generate a digital signature. Digital signatures are used to detect unauthorized modifications to data and to authenticate the identity of the signatory. In addition, the recipient of signed data can use a digital signature in proving to a third party that the signature was in fact generated by the signatory. This is known as nonrepudiation since the signatory cannot, at a later time, repudiate the signature.
On the other hand, FIPS 140-2 defines standards for cryptography modules that include both hardware and software components. As said in the abstract:
The security requirements cover areas related to the secure design and implementation of a cryptographic module. These areas include cryptographic module specification; cryptographic module ports and interfaces; roles, services, and authentication; finite state model; physical security; operational environment; cryptographic key management; electromagnetic interference/electromagnetic compatibility (EMI/EMC); self-tests; design assurance; and mitigation of other attacks.
So here you are interested in the authentication area, which is clearly and closely related to digital signatures. But that does not necessarily imply that your HSM is compliant with the FIPS 186-2 specification.
FIPS 140-2 is more about general requirements while FIPS 186-2 describes en details (i.e. mathematically) digital signature algorithms (such as ECDSA).
Note that the section 4.3.3 Operator Authentication in FIPS 140-2 concerns various type of authentication, not only digital signatures:
Various type of authentication data may be required by a cryptographic module to implement the supported authentication mechanisms, including (but not limited to) the knowledge or possession of a password, PIN, cryptographic key, or equivalent; possesion of a physical key, token, or equivalent; or verification of personal characteristics (e.g., biometrics). Authentication data within a cryptographic module shall be protected against unauthorized disclosure, modification, and substitution.