Integration card is a configuration object or UI panel that represents one integration and its key settings in an IT platform. It typically stores connection details, credentials, scopes, endpoints or enabled actions, and is used to manage how that integration is configured or authorised.
What an integration card represents
An integration card is the operational record for a single integration inside a platform. It is not just a label or shortcut, it is the place where the system keeps the settings that determine how one connected service is allowed to talk to the platform and what actions it can perform.
Because the card often includes endpoints, scopes, credentials, and toggles for enabled capabilities, it becomes a high-value control point. A well-designed integration card gives administrators a concise view of configuration state while also exposing the minimum details needed to manage the integration safely.
Why integration cards matter for platform security
The security significance comes from concentration: one panel may govern many sensitive settings at once. If those settings are misread, overexposed, or too broadly editable, the integration can become an easy path for unauthorized access, excessive permissions, or service disruption.
Integration cards also shape how trust is established between systems. They often contain the material that lets a third-party service, workflow, or API call authenticate and operate, so any weakness in how the card stores or displays that material can affect both confidentiality and authorization.
Common design and governance patterns
Most integration cards follow the same practical pattern: identify the integration, show its status, and expose the configuration fields needed for administration. The best implementations separate readable status from sensitive material, and make it clear which values are editable, inherited, or hidden.
- Connection details should be organised so administrators can see what the integration points to without exposing unnecessary internals.
- Credentials and tokens should be treated as sensitive configuration, not ordinary metadata.
- Scopes and enabled actions should be easy to review, because they define the integration’s effective authority.
- Lifecycle status should be visible, so disabled or stale integrations do not linger unnoticed.
That governance layer matters because integration cards are often where configuration drift starts. A card that is convenient for setup but vague about ownership, scope, or current state can leave teams with orphaned integrations or permissions that no longer match the business need.
What can go wrong if the card is poorly controlled
Problems usually arise when the card becomes a repository for secrets, broad privileges, or unclear change ownership. If too many people can view or edit it, the integration may be reconfigured silently, cloned incorrectly, or left active long after it should have been removed.
Another risk is false confidence: an integration may look healthy in the interface while the underlying credentials have expired, the endpoint has changed, or the granted scopes are wider than intended. In practice, the card is only as safe as the controls around who can change it and how often its settings are reviewed.
Failure mechanism: Weak access control or insecure secret handling inside the card can expose credentials, permit unauthorized configuration changes, or leave excessive scopes in place for longer than intended.
Impact: Attackers or careless operators can use the integration’s trusted path to reach data, trigger actions, impersonate legitimate system activity, or disrupt the connected service.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Integration cards often store or govern credentials and tokens. |
| AC-6 — Least Privilege | Scopes and enabled actions on an integration card define effective access. | |
| CM-6 — Configuration Settings | The card is a configuration object whose settings need controlled baseline management. | |
| Recommendation — Protect integration secrets with lifecycle controls and rotate them when access changes. Limit each integration card to the minimum privileges required for its function. Standardise and review integration-card settings so drift is detected quickly. | ||
| CIS Controls v8 | 5 — Account Management | Integration cards govern access paths that should be owned, reviewed, and removed cleanly. |
| Recommendation — Inventory and retire inactive integrations before they become orphaned access paths. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Cards may display or store credentials and tokens used by the integration. |
| NHI-05 — Overprivileged NHI | The card commonly defines scopes and actions for a non-human integration. | |
| Recommendation — Prevent secrets from appearing in the card UI, logs, or exported configuration. Review granted scopes and remove any permissions the integration does not need. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Integration settings often enable actions that must be restricted to approved operators. |
| Recommendation — Restrict which users can change integration actions and privileged settings. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | Integration cards manage access paths, credentials, and authorisation settings. |
| Recommendation — Apply access-control governance to who can view, edit, or activate each integration. | ||
Practitioner Guidance
Why practitioners should care: Treat each integration card as a governance object, not just a convenience feature. It should have a named owner, a clear purpose, and a bounded permission set that matches the integration’s actual job.
What to watch for: Review cards for long-lived credentials, unclear scope grants, stale endpoints, and integrations that remain enabled after their business use has ended. Those are the conditions that most often turn a routine configuration panel into a security liability.
Practitioner takeaway: If the card controls authentication or authorisation for a connected system, then review, change control, and removal discipline matter as much as the initial setup.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org