I am designing a cloud based PKI infrastructure which issues and manages TLS certificates for telemetry devices and data server. Each customer will install multiple telemetry devices and a data server in his/her premise. Data server collects telemetry data and also manages the devices (monitor status, SW update, etc). Certificate hierarchy will be like Root CA -> Region CA -> Customer CA -> Device/Server Certificate. Customer CA is an intermediate CA and every customer will have a different Cusmoter CA. Region CA is also intermediate which groups multiple customers based on geography (i.e LATAM, Europe, Asia-pacific, etc.). I am thinking to implement a segregation of trust between devices and server based on the customer they are associated with. In detail, a device belonging to one customer should not connect to server belonging to another customer and vice versa. I have two options in mind to implement this.
Use customer CA as trust anchor instead of Root CA. But revocation checking for Region CA won't be possible.
Add unique customer identifier in device/server certificate in the subject DN (Probably O or OU). But the verification can be done only at the application level whereas in option 1, the constraint is dealt by the TLS stack itself which is more secure.
Could someone recommend which implementation is more sensible and commonly followed?
Note: All CA certificates (RootCA, Region CA and Customer CA) are managed by the PKI infrastructure. Device/Server certificate generation/renewal/revocation happens through API request to the PKI server. Customers will have very limited role in certificate management.