> For the complete documentation index, see [llms.txt](https://help.security.gallagher.com/knowledge-hub/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.security.gallagher.com/knowledge-hub/products/cc-software/configure/command-centre-cardholders-and-credentials.md).

# Cardholders and credentials

Create and manage cardholders, cards, credentials, and access assignments.

A **cardholder** is the core identity entity in Command Centre. It is any person issued credentials to access a site. A **card** is the physical or mobile credential that grants access at a reader. The bare minimum to provision a working cardholder is **Name + Division + 1 Card + 1 Access Group**, which gives a card read at a reader that grants access.

Cardholder management happens in the Cardholder Viewer (current client) or the Administration Workspace and Command Centre Web (modern). Administrators do this day to day. Installers do it during commissioning to verify the system end to end.

### Provision a cardholder

{% stepper %}
{% step %}
In **Manage > Cardholders**, select **New**.
{% endstep %}

{% step %}
On the **General** tab, enter the name.
{% endstep %}

{% step %}
Set the division (tenancy).
{% endstep %}

{% step %}
Select **Apply**.
{% endstep %}

{% step %}
On the cardholder's **Cards** tab, add a card.
{% endstep %}

{% step %}
Select the **card type**.
{% endstep %}

{% step %}
Enter the **card number**.
{% endstep %}

{% step %}
Set **enabled**.

Multiple cards per cardholder are allowed. This supports replacement cards and different access levels.
{% endstep %}

{% step %}
On the **Access Groups** tab, add at least one [Access Group](/knowledge-hub/products/cc-software/configure/command-centre-access-groups.md).

This defines where and when the cardholder can access. Gallagher guidance recommends a maximum of 10 access groups per cardholder.
{% endstep %}

{% step %}
Select **Apply**.
{% endstep %}

{% step %}
Present the card at a reader.

Access is granted. The audit trail records the read event.
{% endstep %}
{% endstepper %}

That is the minimum. Most real cardholders will also have personal details, access expiries, biometric data, photos, competencies, and notifications configured, but the core flow has four stages.

### Cardholder record contents

The cardholder record is organised into tiles (current client) or sections (web). It is configurable per site, but the standard set is:

| Tile                    | What lives here                                                                   |
| ----------------------- | --------------------------------------------------------------------------------- |
| **Personal Details**    | Name, employee ID, contact, custom fields (per-site configurable)                 |
| **Access Groups**       | Which access groups the cardholder is in, which drives where and when             |
| **Cards / Credentials** | Physical cards, mobile credentials, PINs, biometrics                              |
| **Competencies**        | Qualifications with expiry tracking (for example "first aid valid until 2027-06") |
| **Expiries**            | Cardholder-level expiries (contractor end date, visitor pass)                     |
| **Biometrics**          | Enrolled biometric templates                                                      |
| **Images**              | Photos for ID verification                                                        |
| **Notes**               | Free-text annotations                                                             |
| **Relationships**       | Links to other cardholders (parent/child, vehicle owner, and so on)               |
| **Notifications**       | Notification preferences and rules                                                |
| **History**             | Full audit trail, including activity recorded after deletion                      |

### Card states

| State                 | Meaning                                              |
| --------------------- | ---------------------------------------------------- |
| **Active**            | Card is enabled and working                          |
| **Disabled**          | Disabled by inactivity policy or operator action     |
| **Expired**           | Past expiry date                                     |
| **Not Yet Activated** | Future activation date. Provisioned but not live yet |

Card activity is recorded in the audit trail **even after the cardholder is deleted**, which is important for compliance and forensic investigations.

### Bulk operations

For large estates, individual provisioning does not scale. There are three main bulk paths (see [Command Centre - Bulk Operations](/knowledge-hub/products/cc-software/operate/command-centre-bulk-operations.md) for the full detail):

1. **Bulk Changes feature (Cardholder Viewer).** Select multiple cardholders and apply changes to all. Useful for mass-enabling, mass-expiring, and mass-access-group changes. Filter by access group, division, expiry, or custom field.
2. **CSV-based bulk configuration.** Upload a CSV of cardholders to create or update. Standard during initial site bringup or when migrating from another system.
3. **REST API.** Programmatic provisioning. Common for HR system integration (joiner-mover-leaver flows).

### Constraints

* **Site licence determines maximum cardholders.** A C7000 supports up to 2 million, but the licence may cap lower. Check the licence before promising scale.
* **Recommended maximum 10 access groups per cardholder.** This is soft guidance, not a hard limit, but exceeding it hurts performance and human comprehension.
* **Multiple cards per cardholder is normal.** Replacement cards, contractor cards, a mobile credential alongside a physical card.
* **Personal data fields are configurable per site.** Do not assume "Department" or "Manager" exist on every cardholder. Check the site config.
* **Anti-passback rules track cardholder location through access zones.** A cardholder who badges into a zone cannot badge into the same zone again without first exiting (if anti-passback is enabled). This breaks tailgating.

### Technical reference

Deeper credential content lives in dedicated pages:

* [Credential Information](/knowledge-hub/products/cc-hardware/credentials/credential-information.md). DESFire key hierarchy, SSK versus Default Key, SSK migration modes, rolling keys, UCF, CSN, MIFARE technologies, and legacy credentials.
* [Encoding Solutions](/knowledge-hub/products/cc-hardware/credentials/encoding-solutions.md). Bureau Encoding, Encoder 3, Encoding Kiosk, and encoding troubleshooting.
* [Mobile Connect](/knowledge-hub/products/cc-hardware/credentials/mobile-connect.md). Overview, BLE calibration, custom email, log export, and troubleshooting.

### Related links

* [Command Centre - Access Groups](/knowledge-hub/products/cc-software/configure/command-centre-access-groups.md). What the cardholder is granted: the where and when of access.
* [Command Centre - Bulk Operations](/knowledge-hub/products/cc-software/operate/command-centre-bulk-operations.md). Provisioning at scale.
* [Command Centre - Operator Groups & Privileges](/knowledge-hub/products/cc-software/configure/command-centre-operator-groups-and-privileges.md). The operators who manage cardholders.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://help.security.gallagher.com/knowledge-hub/products/cc-software/configure/command-centre-cardholders-and-credentials.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.