In-Account Deployment

What In-Account Deployment Means in Practice

In-account deployment describes a service runtime that lives inside the customer’s own cloud account or subscription, rather than in a separate vendor tenant. That placement matters because the customer owns the surrounding trust boundary, network paths, policy inheritance, and operational visibility.

This model is often chosen when an organisation wants the product to behave more like an internal workload than a hosted SaaS service. The deployment may still be vendor-managed, but the runtime is anchored in the customer environment, so cloud-native controls such as guardrails, logging, segmentation, and policy enforcement can apply more directly.

How the Boundary Changes Security and Control

The core security difference is where administrative control sits. In a separate provider tenant, the vendor typically governs more of the runtime environment. In an in-account model, the customer’s cloud controls are closer to the service, which can improve isolation, data locality, and alignment with internal security standards.

This does not automatically make the service safer. It changes the control plane. The customer may gain stronger visibility and tighter integration with existing governance, but also inherits more responsibility for cloud configuration, account-level permissions, network exposure, and operational ownership of the environment around the deployment.

Because the workload sits inside the customer account, it usually participates in the same identity, logging, and policy ecosystem as other internal services. That makes the model easier to fit into existing access patterns, but it also means misconfiguration in the customer environment can affect the service just as it would affect any other workload.

Typical Use Cases and Architectural Trade-offs

In-account deployment is commonly used when buyers need stronger separation from a shared vendor tenant, tighter integration with private networking, or clearer alignment with enterprise governance. It is also attractive when security teams want the runtime to inherit their own cloud guardrails instead of accepting a provider’s default operating model.

The trade-off is operational complexity. The customer environment becomes part of the service’s dependency chain, so the quality of IAM, network policy, monitoring, and resource governance directly affects the deployment. If the cloud account is noisy, over-permissioned, or poorly segmented, the “customer-owned” boundary may exist more in name than in practice.

For cloud control alignment, practitioners often map this model to the same kinds of guardrails used for least privilege, secure configuration, and continuous monitoring. Guidance such as CIS Controls v8 and NIST Cybersecurity Framework 2.0 is useful here because the deployment inherits the customer’s own control environment rather than replacing it.

Where It Sits in the Wider Cloud and Identity Model

An in-account deployment is not just a hosting choice, it is also a boundary decision. It can support stronger internal governance because the service becomes another workload subject to the organisation’s existing policies, change controls, and detection coverage. That is especially valuable when the service needs to consume internal data or operate under existing enterprise security review processes.

The model also has implications for identity and access, because access to the runtime, its supporting cloud resources, and its deployment pipeline must be governed as part of the same account. NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference point for thinking about access control, authentication, auditability, and configuration management in that environment.

In short, in-account deployment is best understood as a way to move the service closer to the customer’s trust boundary. It can improve alignment with enterprise controls, but only if the surrounding cloud account is treated as part of the product’s security perimeter, not as a passive hosting detail.

Risk and Threat Considerations

In-account deployment can reduce tenant-sharing concerns, but it also exposes the service to the customer’s own cloud security posture. If the account is over-permissioned, poorly segmented, or weakly monitored, attackers can abuse the same control plane that is meant to provide isolation and governance.

Failure mechanism: Misconfiguration, excessive permissions, or weak segmentation inside the customer account can undermine the intended boundary, allowing lateral movement, service disruption, or unauthorized access to supporting resources.

Impact: The compromise can affect both the deployed runtime and adjacent cloud assets, turning a deployment model intended to improve control into a concentration point for operational and security risk.

Practitioner Guidance

Why practitioners should care: The value of in-account deployment depends on whether the customer can actually enforce the controls it expects to inherit. Treat the customer cloud account as part of the product’s security surface, not just as a location choice.

Governance implication: Clarify ownership for cloud permissions, network policy, logging, and change management before deployment, because those controls determine whether the service truly operates inside the customer’s security model.

Practitioner takeaway: If the surrounding account is not governed well, in-account deployment can improve perceived control without materially improving real control.

Related resources from NHI Mgmt Group

• How should security teams secure browser extension deployment pipelines against phishing-driven account takeover?
• What are the signs that an AWS cross-account assessment deployment is too permissive?
• What should organisations do after discovering an insecure AWS cross-account assessment deployment?
• What happens when a human uses an NHI account?