Who is accountable when an MSP adopts new platform features without updating controls?

Why This Matters for Security Teams

When an MSP turns on a new platform capability without updating controls, the problem is not the feature itself. It is the gap between operational change and accountable governance. New capabilities often alter access paths, logging, approval flows, and customer notification duties, which means inherited controls may no longer match the real risk. NIST’s Security and Privacy Controls make clear that controls need to be selected and maintained against current conditions, not assumed to remain valid after a platform update.

That is especially true in managed service environments, where the MSP may operate the tool while the customer remains exposed to the downstream impact. NHIMG’s Ultimate Guide to NHIs — Standards frames this as a lifecycle issue: access, rotation, revocation, and evidence all need an owner. In practice, many incidents start with a feature enablement that looked low risk during a vendor session but later changed privilege boundaries, audit scope, or data sharing without a corresponding control review.

One NHIMG finding is especially relevant here: only 5.7% of organisations have full visibility into their service accounts, which means change often lands in an environment already missing clear ownership and evidence. In practice, many security teams encounter accountability disputes only after a customer asks who approved the change, rather than through intentional control design.

How It Works in Practice

Accountability should follow the operating model, not the vendor narrative. If the MSP enables a feature, the MSP owns the decision to assess impact, update control mappings, and document the change. If the customer contract requires notification, evidence sharing, or approval, those obligations still need to be translated into operational steps before rollout. The key question is simple: what changed in access, configuration, monitoring, retention, or escalation paths?

Practically, teams should treat each new platform feature as a control delta and run it through a repeatable change-review path. That usually includes:

• Confirming who approved the change and who can reverse it.
• Checking whether the feature adds new privileged access, API scopes, or service accounts.
• Updating logging, alerting, and evidence retention before enabling it.
• Notifying customers where the feature affects data handling, incident response, or reporting.
• Revalidating vendor assumptions against internal policy and contract terms.

For service-account-heavy environments, the risk is amplified because NHIs can quietly accumulate excessive privilege. NHIMG’s Ultimate Guide to NHIs — The NHI Market highlights how widely these identities are distributed across modern enterprises, which makes change control and audit evidence harder to maintain if ownership is vague. For implementation discipline, the NIST control family around configuration management and change tracking in SP 800-53 Rev. 5 is the right baseline.

These controls tend to break down when the MSP relies on vendor-led training as a substitute for formal change approval because no one translates the new feature into accountable control ownership.

Common Variations and Edge Cases

Tighter change control often increases operational overhead, requiring organisations to balance speed against auditability. That tradeoff becomes sharper when the platform feature is presented as a minor enhancement but actually affects multi-tenant segregation, customer-visible reporting, or privileged automation. Best practice is evolving here, but current guidance suggests treating any feature that changes identity, data flow, or recovery responsibilities as a control-impacting event.

There are a few common edge cases. First, if the vendor enables a feature by default, the MSP is still accountable for deciding whether to keep it on and for documenting the risk acceptance. Second, if customer consent is required, the MSP cannot shift accountability to the customer simply because the feature came from a vendor webinar. Third, if the change affects an NHI such as an API key, automation account, or integration token, the control review should include rotation, scope reduction, and revocation paths rather than only human approval.

Current NHI guidance from NHIMG and control expectations in NIST SP 800-53 Rev. 5 both point in the same direction: feature adoption is not complete until ownership, evidence, and rollback are explicit. That is the practical test for whether the MSP actually remains accountable after the change.

Related resources from NHI Mgmt Group

• How should security teams migrate identity governance from on premises platforms to cloud based identity security without disrupting access controls?
• Who is accountable when fraud controls fail across registration, deposit, and withdrawal flows?
• Who should be accountable when platform claims do not match the actual identity security architecture?
• How should security teams improve compliance and budget outcomes without making identity controls too rigid for users to work around?