diff --git a/daprdocs/content/en/operations/components/pluggable-components-registration.md b/daprdocs/content/en/operations/components/pluggable-components-registration.md
index a4dda6ddf..5454c30c6 100644
--- a/daprdocs/content/en/operations/components/pluggable-components-registration.md
+++ b/daprdocs/content/en/operations/components/pluggable-components-registration.md
@@ -57,7 +57,7 @@ Since you are running Dapr in the same host as the component, verify this folder
 
 A pluggable component accessible through a [Unix Domain Socket][UDS] can host multiple distinct component APIs . During the components' initial discovery process, Dapr uses reflection to enumerate all the component APIs behind a UDS. The `my-component` pluggable component in the example above can contain both state store (`state`) and a pub/sub (`pubsub`) component APIs.
 
-Typically, a pluggable component implements a single component API for packaging and deployment. However, at the expense of having dependencies and security, a pluggable component can have multiple component APIs implemented to ease the deployment burden. Best practice for isolation, fault tolerance, and security is a single component API implementation for each pluggable component.
+Typically, a pluggable component implements a single component API for packaging and deployment. However, at the expense of increasing its dependencies and broadening its security attack surface, a pluggable component can have multiple component APIs implemented. This could be done to ease the deployment and monitoring burden. Best practice for isolation, fault tolerance, and security is a single component API implementation for each pluggable component.
 
 
 ## Define the component