Security requirements for EC Diffie Hellman implementation I'm working on a crypto library to be used in a firmware product.
Beside other things we need key agreement based on Diffie Hellman.

Since resources are very limited we use a crypto accelerator on the MCU for which a low level library exists, allowing beside other things to make elementary calculations on elliptic curves over $GF(p)$ and $GF(2^p)$. 

Now I tried Diffie Hellman and tested the results against various test vectors. It works fine.

But, of course, I know that this self-made approach can be dangerous, when the detailed implementation is open for attacks, whatsoever kind of.

So the question: What requirements must be considered additionally to plain algorithms in order to make the outcome a "secure" solution?

To make a statement to the answers below:

1) We must use P-256 (it's not a choice)

2) What do you mean with large private multiplier? In my implemantation the private key is taken randomly between $ 1 \ldots 2^{256}$ (32 Bytes) and then reduced to modulo group order. Is this acceptable?

3) I use a hardware RNG (TRNG). 

4) We must use KDF specified within NIST 800-56A Rev2

5) The other side is authenticated by ECDSA based on a certifcate

6) 


  side channel resistance is a hairy issue


I have to larn about what this is 

7)


  If you only have the really basic operations: make sure your scalar
  multiplication is constant-time.


Why is this required?
Here's the obvious advice (other than "don't roll your own protocol/solution; reuse one that has already been vetted"):


Make sure that you use a secure curve.  Obvious alternatives are P256 (with possible P224 or P192 if you need better performance, and don't mind cutting into the security somewhat), or (if you don't trust the US Government) a NUMS curve or a Brainpool curve.  Normally, I'd suggest Curve25519; however if you have a crypto accelerator that's targeted towards arbitrary curves in Weierstrass form, well, it could do Curve25519, but it's more hassle, and you lose the advantages you normally gain from Curve25519.
Make sure that you use a large sized private multiplier; for P256 (or any other curve based on a 256 bit prime), that means a 256 bit multiplier (and note: this doesn't mean that the 255th bit must be set; it means that all values between 1 and $2^{256}$ are possible).  You can make things go a bit faster if you use a smaller range, however that also cuts into the security.
Both sides need good entropy; if the attacker can guess the private multiplier of either side (or even reduce it to a not-huge subspace), he can recover the shared secret.
Validate the point that you receive from the other side, that it is a point on the curve; for example, if the other side sends both $x$ and $y$ coordinates, make sure that when you plug them into the Elliptic Curve equation, both sides evaluate to the same value.  There are cases where you can skip this (for example, if you use "point compression", or if you always generate a fresh random private multiplier for each exchange), however it's so cheap that it just makes sense.
Use a good KDF to convert the ECDH shared secret into the keys that you'll actually use.
Remember that ECDH does not authenticate who you're actually talking to.  Unless no one other than the person you're talking to can possible send (or modify) a message to you, you need a way to authenticate the other side.