Who should remain accountable for the app registration and workspace used by a third-party security engine?

Why Accountability Must Stay With the Customer

When a third-party security engine is granted access through an app registration and a workspace, the accountability boundary should stay with the customer because those resources define who can authenticate, what can be read, and what can be revoked. If a partner owns either side of that boundary, the customer loses direct control over access changes, auditability, and offboarding. That creates a governance gap even when the operational service is outsourced.

In practice, the most damaging failures happen when teams assume “managed by the partner” also means “owned by the partner,” and only discover the distinction during a credential reset, tenant review, or incident response.

How This Division of Responsibility Works

The clean model is simple: the customer owns the app registration, the workspace, and the permissions granted to the third-party engine; the partner operates the engine and supports its use. That means the customer controls consent, scope, rotation, revocation, logging, and retention decisions, while the partner receives only the minimum access needed to deliver the service. The principle is the same whether the engine writes alerts, enriches telemetry, or queries security data: operational delegation does not transfer administrative ownership.

This matters because app registrations and workspaces are not just integration details. They are the trust anchor for the service relationship. If the partner creates or controls the registration, the customer may be unable to independently remove access, inspect delegated permissions, or recover cleanly if the relationship ends. If the partner also owns the workspace, the customer can lose practical control over security telemetry, retention settings, and the ability to validate what data was accessed. The safer pattern is to separate operator duties from owner duties so that support can continue without handing over custody of customer data or credentials.

That separation should be documented in the service design, not left to informal practice. A well-run integration defines who approves access, who can change it, who can rotate secrets, who can delete the app registration, and who can export or retain workspace data. Where teams use a managed security partner, they should also verify that the customer can still enforce revocation even if the partner is unreachable or the contract ends. The OWASP Non-Human Identity Top 10 is useful here because it frames the risk around machine identities whose lifecycle must remain owned and governable by the organisation that bears the exposure.

NHIMG research on non-human identity control failures also shows why this model matters: The State of Non-Human Identity Security reports that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which is exactly the kind of visibility gap that appears when ownership and operation are blurred. These controls tend to break down when the workspace is treated as a vendor-managed service boundary rather than a customer-controlled data store.

Common Variations and Edge Cases

Tighter customer ownership often adds administrative overhead, so organisations have to balance operational convenience against the need for revocation authority and evidence of control. The main exception is a fully customer-managed service account model in which the partner never holds standing ownership and only receives narrowly scoped access for support.

Another edge case appears when the workspace is shared across multiple services or business units. In that situation, the customer still needs a named owner and a clear recovery path, because shared custody usually weakens traceability and makes deprovisioning slower. Best practice is evolving, but the core rule has not changed: if the customer is accountable for the data and the risk, the customer should be able to remove the engine without depending on the vendor’s continued cooperation.

Risk and Threat Considerations

The material risk is loss of revocation control and delegated trust sprawl. If a third party owns the app registration or the workspace, the customer may no longer be able to cut off access quickly, prove what the engine could reach, or contain exposure after a contract dispute or compromise.

Failure mechanism: The risk materialises when ownership is confused with operation. A partner-held registration can preserve active credentials, stale consent, and excessive permissions beyond the customer’s immediate control, while a partner-owned workspace can obscure retention and access governance. That creates an attractive path for persistence and data access if the vendor environment is abused or if offboarding is delayed.

Impact: The likely outcome is delayed revocation, weaker auditability, and broader exposure of telemetry or security data than the customer intended. In the worst case, the partner becomes the de facto administrator of customer data and access, which undermines incident response and creates avoidable third-party concentration risk.

Practitioner Guidance

What to verify: Confirm that the customer tenant can independently revoke the app registration, rotate any secrets or certificates, and remove the partner’s access without waiting on vendor action. If that is not true, the ownership model is already too weak.

Decision rule: If the third-party engine can read security telemetry, change detections, or authenticate into customer systems, treat customer ownership of the registration and workspace as non-negotiable rather than a contractual preference.

Practitioner takeaway: Keep the operator separate from the owner, because support can be outsourced but accountability for access, data custody, and revocation cannot.

Related resources from NHI Mgmt Group

• What breaks when customer identity, app access, and third-party services are not controlled in one place?
• How should security teams govern API keys used for generative AI access?
• How should security teams respond when a third-party OAuth app is compromised?
• How do security teams know if third-party app access is out of control?