The SCEP library as implemented acts as both a SCEP service and as a CA which is currently coupled. While its true the Depot interface exists for changing how certificates are stored and accessed the actual certificate issuance is still assumed to be in the domain of the SCEP library by nature of the SignCSR() method being a part of the PKIMessage struct which creates only its own certificates currently:

In order to better support proxying SCEP requests (what the SCEP spec calls a "Registration Authority") or otherwise issue certificates outside of the SCEP library this should be completely decoupled. This would support the SCEP server being a thin SCEP-protocol wrapper around another CA — or even proxying to to other SCEP servers.

Other open issues along this same theme are #2, #61, and #77.

As far as implementation goes, as a suggestion, perhaps instead of a Depot interface a CA interface can exist that that represents the signing & other CA work which, for the reference built-in CA, in turn uses the Depot interface — or maybe just consolidate to a single CA interface (or expand the Depot interface to also issue certificates). Also, the server will need to support an RA keypair for SCEP-only operation while including the CA certificate as per the SCEP spec.

For reference here's the current Depot interface: