If you take rip-off's comment and Nanook's comments together, they're quite spot on here. It sounds to me as though you've approached separating code into classes using an extreme separation of concerns. What I might suggest is you have a rendering system that does the main bulk of what it implies, renders. You have a set of other classes that hold data specific to certain rendering needs such as vertex buffers, index buffers, vertex declarations, shader programs, etc.
If you think about the bigger picture here, your render system and all these classes that hold data can be abstracted one level farther to where you have a common interface the engine exposes for them with implementation specific classes for DX9, DX11, and OpenGL. Your API asks the render system to allocate you an object, the implementation specific class does so and gives you the object back via interface. You work with a vertex buffer the same way regardless if its DX9, DX11, OpenGL or w/e.
Now you no longer need to be concerned with passing this device handle everywhere because its centralized, primarily used by the specific render system implementation. On those corner cases where it makes sense for a separate class to perhaps hold a reference, just pass it as a constructor argument.
This doesn't necessarily blur the lines with separation of concerns and single responsibility principals and keeps your code quite clean.