The problem asked is not easily solved. To authenticate using cryptography as Dev1 in a way that a rogue Dev3 does not allow to imitate, Dev1 must know some secret key (or private key) that Dev3 does now contain (or does not allows to either extract or misuse), but that the CA can verify because it knows it (or knows the corresponding public key). Conventional cryptography (including public key cryptography, but perhaps not PUF-based cryptography or/and novel uses of quantum cryptography, which I won't consider further) has nothing else to offer.
The easiest workaround is to consider that Dev1 is whatever can prove being able to use the private key associated to the first public key for which the CA computes a certificate for something allegedly named Dev1, and have the CA reject any further attempt at obtaining a certificate under the name Dev1 (possibly: with the exception of duly authenticated certificate renewal requests if these are in the picture). When done properly, that can prevent Dev1 from working at all when it can be impersonated, which is better than nothing.
One method of solving the problem rather than working around it is to perform step 2 in an assumed secure location (e.g. factory) where the authentication of Dev1 is performed by non-cryptographic means.
Another method is to inject a secret key in Dev1 at a secure location, known also to the CA, so that step 2 can be performed with authentication using secret-key cryptography. That secret key can be a random octet string assigned at the secure location, and securely communicated (associated to the identifier Dev1, or the public Media Access Control address (MAC) of Dev1 if it has no name at that stage) to the CA, or the other way around.
As a more convenient variant of the above, the secret key can be a so-called diversified key, obtained using a key derivation function from a master key (known to the entity operating the secure location and the CA) and whatever identifies Dev1; the benefit is that only the master key needs to be securely communicated from/to the CA, which can recompute the diversified key of all devices. Note: for key diversification we do not need an entropy-streching key derivation function, and can use e.g. HMAC or AES (with the master key as key, and the identification as the other input); or any of the functions in NIST SP 800-108.
The key can be a Message Authentication Code of the Media Access Control address. The collision in TLA is accidental.
There are other methods, like embedding the same secret in all devices, and hoping it will not be extracted or misused; but they tend to have no operational advantage compared to the previous one when there is a CA, and be more brittle.