Who is accountable when a fake company tenant is used to solicit employee activity?

Accountability sits with both the platform operator and the enterprise identity team. The platform needs stronger tenant creation and invitation controls, while the enterprise needs policy, visibility, and response rules for external memberships that can expose work activity and connected applications.

Why This Matters for Security Teams

A fake company tenant used to solicit employee activity is not just a phishing variant. It is an identity and governance problem that can expose work conversations, application connections, and trust relationships that employees assume are internal. The accountability question matters because the damage often spans two control planes: the platform that allowed the tenant to exist and the enterprise that allowed employees or data to interact with it. Guidance from the NIST Cybersecurity Framework 2.0 still applies, but the operational reality is that external tenant abuse lives in the gaps between identity policy, collaboration tooling, and user behavior.

NHI Management Group has repeatedly shown that weak visibility and poor offboarding are common failure points in identity programs, including the fact that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs. That same visibility gap often extends to external tenants, guest memberships, and automated invitations. If defenders cannot see which tenants employees joined, which apps those tenants reached, or which approvals were used, accountability becomes reactive instead of enforceable. In practice, many security teams encounter this only after employee activity has already been solicited through a tenant that looked legitimate enough to bypass normal caution.

How It Works in Practice

Accountability should be split by control domain. The platform operator is accountable for tenant creation safeguards, invitation abuse controls, domain validation, rate limiting, abuse reporting, and suspension workflows. The enterprise identity team is accountable for policy, conditional access, external collaboration rules, and monitoring of guest or federated memberships. This is where the identity perimeter matters: if a tenant can be created with a deceptive name, logo, or domain pattern, then user trust becomes an attack surface rather than a defense.

Practitioners should treat external tenant access like a governed exposure path, not a convenience feature. A workable program usually includes:

• Tenant allowlisting or verified-tenant checks before sensitive collaboration is permitted.
• Policy-based controls for guest invitations, external sharing, and cross-tenant app consent.
• Conditional access rules that require step-up verification for unfamiliar tenants or high-risk actions.
• Alerting on new external memberships, especially where workspaces connect to files, chats, or automations.
• Response playbooks that can revoke guest access, suspend links, and review downstream application tokens quickly.

The challenge is that a tenant can be socially convincing while remaining technically ordinary. That is why NHI Management Group recommends pairing visibility with lifecycle control, as outlined in the Ultimate Guide to NHIs, because identity misuse often persists when access is not revoked promptly. The practical interpretation of NIST Cybersecurity Framework 2.0 is to map this to governance, protect, detect, and respond controls across both the platform and the enterprise. These controls tend to break down when collaboration is decentralized across multiple SaaS tenants because no single team owns the full membership and approval path.

Common Variations and Edge Cases

Tighter tenant controls often increase friction for legitimate partners, requiring organisations to balance collaboration speed against impersonation risk. Current guidance suggests treating that tradeoff explicitly rather than assuming all external tenants should be blocked or all should be trusted.

Some environments make accountability harder to assign. In federated SaaS ecosystems, a fake tenant may be created on a third-party platform with no direct enterprise administration rights. In that case, the platform operator still owns abuse prevention, but the enterprise must own user guidance, monitoring, and reporting thresholds. In regulated workflows, the response bar is higher because solicited employee activity may also trigger records, privacy, or insider-risk obligations.

There is no universal standard for tenant trust scoring yet, so organisations should avoid overclaiming precision. A practical baseline is to require verified tenant signals for sensitive interactions, maintain a log of external memberships, and define who can approve exceptions. The broader lesson aligns with the NHI risk patterns documented in the Ultimate Guide to NHIs: identity exposure becomes much harder to contain once external access is granted without visibility or revocation discipline.

Related resources from NHI Mgmt Group

• Who is accountable when an employee leaks a secret into an AI prompt?
• How should security teams govern API keys used for generative AI access?
• Who is accountable when a former employee account or stolen token is used in a breach?
• What breaks when non-human identities are governed only through employee-centric workflows?