They need a documented manual revocation process with a named owner, a removal checklist, and periodic verification that the process still works. If the tool cannot be reached by enterprise identity controls, governance has to shift to operational discipline rather than assumption.
When a marketing tool cannot integrate with enterprise identity controls
The problem is not just convenience, it is governance. If the tool cannot participate in SSO or SCIM, the organisation loses automated enforcement for login, provisioning, and deprovisioning, so access control must be handled through a documented manual process that can be owned, checked, and proved. That shifts the burden from platform integration to operational discipline.
A practical response is to treat the tool like a controlled exception, not a special case. The organisation should define who can approve access, who removes it, what evidence proves removal, and how often the process is tested so that orphaned access does not persist after role changes or offboarding.
For broader identity management, the same pattern is why Joiner-Mover-Leaver (JML) Guide matters: when automation is unavailable, the lifecycle still has to close cleanly.
What the manual fallback must cover
Manual revocation needs more than a spreadsheet entry. It should include a named owner, a removal checklist, a trigger for when access must be removed, and a record of the account or token that was revoked. If the tool uses shared admin roles, API keys, or delegated access, the checklist should spell out each path separately because one revocation step may not cover them all.
Verification is as important as removal. A useful control checks that the account no longer signs in, that any linked session or token is invalidated where possible, and that the next periodic review confirms the process still works end to end. For lifecycle gaps and deprovisioning logic, SCIM and Automated Provisioning Guide is the closest control model, even when the actual tool does not support SCIM.
When the vendor route is weak, procurement and ownership decisions matter too. An IAM and Identity Provider Buyer’s Guide helps frame the more important question, which is whether the product should be accepted at all if it cannot support basic lifecycle governance.
How to judge whether the exception is acceptable
The key question is whether the tool can be bounded enough to be safe without enterprise identity integration. Some low-risk tools may be manageable with short-lived access, a very small admin set, and frequent attestations. Others create too much exposure because the inability to automate revocation turns every move, leave, or contractor change into a manual security event.
For sign-in and federated access assumptions, the control baseline should still reflect how modern enterprise identity is supposed to work, including OpenID Connect Core 1.0 for authentication and single sign-on. If a tool cannot align with that model, the organisation should decide whether the business value justifies the added operational risk and review cost.
The strongest practical standard is to require periodic recertification of every exception, not just initial approval. That review should confirm the owner, the current users, the removal path, and whether the vendor has introduced SSO or SCIM support since the last assessment.
Risk and Threat Considerations
A marketing tool without SSO or SCIM increases the chance of standing access, delayed offboarding, and unnoticed privilege drift. The most common failure is not an attacker bypassing a control, but an internal process failing to keep pace with role changes, contractor exits, or dormant accounts.
Failure mechanism: Access removal depends on human follow-through instead of system-enforced lifecycle controls, so stale accounts, shared credentials, or unreclaimed tokens can survive long after they should have been removed.
Impact: An abandoned marketing account can expose customer data, campaign lists, analytics, or connected SaaS data, and it can also become a pivot point into other integrated systems if the tool has API access or delegated trust.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Manual revocation must still control credential lifecycle and disable stale access promptly. |
| AC-2 — Account Management | The question is about provisioning, deprovisioning, and ownership of access when automation is missing. | |
| Recommendation — Document and test revocation steps for every credential or token the tool uses. Assign a named owner for account removal and periodic access review. | ||
| CIS Controls v8 | CIS-5 — Account Management | Unintegrated tools require accountable account inventory, removal, and verification. |
| Recommendation — Inventory the tool's accounts and remove any access that is no longer justified. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | The subject is governing identities and access where enterprise automation is unavailable. |
| A.5.18 — Access rights | The answer depends on granting, removing, and periodically checking access rights. | |
| Recommendation — Maintain a documented identity process for manual revocation and review. Review access rights on a schedule and revoke them when no longer required. | ||
Practitioner Guidance
What to verify: Confirm that the manual revocation path works for every access mode the tool uses, including console logins, shared admin accounts, API tokens, and any delegated integrations. A process is not real unless someone independent can follow it and remove access without guessing.
Decision rule: If the tool can reach sensitive data or other connected systems, require tighter approval, shorter review cycles, and explicit offboarding checks. If the vendor cannot support either enterprise identity integration or a credible manual control, treat that as a material governance weakness rather than a minor inconvenience.
Practitioner takeaway: The absence of SSO or SCIM is manageable only when the organisation can prove that revocation is fast, owned, and repeatable, because the security risk comes from unreconciled access persisting after the business no longer needs it.