Support
Add or Remove an Access Control User, Card or PIN
Credential Management
Summary
Follow the four stages below to diagnose a staff member needs a new card/PIN or a departed user must be revoked without losing evidence, configuration or device ownership.
Applies to
- Managed access-control systems
- Cards, fobs and PIN credentials
Difficulty and time
Difficulty: Moderate
Estimated time: 15 to 35 minutes
What you will need
- The exact model and current firmware or app version
- Administrator access where authorised
- A photo or screenshot of the current status
- One controlled test case and its exact time
What this guide covers
- Preserve and reproduce the fault
- Open the correct diagnostic screen
- Correct the proven cause
- Verify and document the result
Use this page when a staff member needs a new card/PIN or a departed user must be revoked. It includes the menu or screen to look for, the status that matters and a repeatable proof test.
Exact labels can differ between recorder, controller, app and firmware versions. If the named screen is not present, do not guess at destructive options; note the model and current version for support.
Before you start
Protect the current system and record a baseline before changing anything.
- Write down the exact symptom: a new credential is denied, an old credential still works, or person data has not reached the controller.
- Photograph the current status, error text, wiring or timeline as applicable.
- Record the last known working time and anything changed immediately before the fault.
- Export or record the current user/access-level assignment before bulk edits.
Do not delete audit records to remove a user
Disable or revoke access through the supported workflow. Keep legally required transaction records and follow the site privacy/retention policy.
If the required option is missing or the result does not match this guide, stop and identify the exact model before continuing.
What usually causes this
- Credential was not assigned
- Access level excludes the door/time
- Validity expired
- Controller has not synchronised
Step 1: Preserve the current state and reproduce the fault
Begin with a repeatable baseline so you know whether a later change genuinely helped.
- Reproduce the problem once and record: a new credential is denied, an old credential still works, or person data has not reached the controller.
- Note whether every device or user is affected, or only one.
- Compare one working path with the failing path if a comparison exists.
- Export or record the current user/access-level assignment before bulk edits.
Step 2: Open the correct screen and inspect the evidence
The primary diagnostic location is Access-control client > Person/Personnel Management > Add, then Access Control > Access Level/Authorisation > Apply. Do not change anything until the displayed state is recorded.
- Open Access-control client > Person/Personnel Management > Add, then Access Control > Access Level/Authorisation > Apply. Menu wording can vary by model and firmware; use the nearest equivalent label.
- Search for the person and card number first to avoid duplicates.
- Confirm the target doors, schedule, expiry date and credential status.
- Check controller online/synchronisation state before applying changes.
Step 3: Correct only the cause you proved
Use the matching correction below. Make one change, save it, then repeat the same test.
- Create or update the person using a unique ID and verified name.
- Enrol the card/PIN through the supported reader or entry field; never reuse a PIN shared by several staff.
- Assign the correct access level and validity dates, then apply/synchronise to the controller.
- For leavers, disable/revoke the credential and remove it from every relevant access level.
Step 4: Verify, monitor and document the handover
A saved setting is not proof. Test the real outcome locally first, then test any app, cloud or client path separately.
- Present the credential at an authorised door during an authorised time.
- Confirm the transaction log identifies the correct person and grants access.
- Test one non-authorised door or time to prove limits.
- For revoked users, confirm denial and retain the audit record according to policy.
Controlled support test
Situation: The reported symptom was: a new credential is denied, an old credential still works, or person data has not reached the controller.
Solution used: The current state was recorded in Access-control client > Person/Personnel Management > Add, then Access Control > Access Level/Authorisation > Apply, one matching correction was made, and the same test was repeated.
Why this was chosen: This separated the proven cause from unrelated settings.
Installation notes: The final screenshot and test time were saved with the handover record.
Official reference used for this guide
Menu names differ between releases. Confirm model-specific behaviour in Hikvision Person Management documentation before firmware, reset, storage or security-sensitive work.
Common mistakes
- Changing several settings before repeating the original test.
- Using a factory reset, initialise or format option as an early troubleshooting step.
- Treating an app symptom as proof that the local hardware or recording has failed.
- Failing to record the model, version, exact error and test time before escalation.
- Assuming similar-looking models use identical menus or features.
Troubleshooting table
| Symptom | What to check | What to do next |
|---|---|---|
| a new credential is denied, an old credential still works, or person data has not reached the controller | duplicate person/card, no access level, expired validity, controller offline or changes not applied | Open the named diagnostic screen, record the displayed state and use the matching correction above. |
| The named menu is not visible | Different firmware, permissions or model capability | Do not substitute a destructive menu. Capture the model and version and use its official manual. |
| The change saves but the fault remains | The selected cause was not the root cause | Undo the change if appropriate, return to the baseline and compare the failing path with a working one. |
| Local test works but app or client test fails | Account, permission, cloud or remote-network path | Keep the proven local configuration and diagnose the remote path separately. |
| Problem returns later | Intermittent power, cable, storage, network or schedule condition | Record the new failure time and status; correlate it with logs, events and the last known working interval. |
When to contact support
Contact SecurityWholesalers support when the person and access level are correct but controller apply/synchronisation fails or a revoked credential still grants access.
Send the order number if available, exact model, firmware or app version, screenshot of Access-control client > Person/Personnel Management > Add, then Access Control > Access Level/Authorisation > Apply, the failure time, and the result of the local proof test.
Related support guides
- Access Control Support Guides - Browse every guide in this support area.
- All Technical Support Guides - Return to the complete support library.
Related buying guides
- Access Control Buying Guide - Door hardware, credentials and system-planning guide.
Relevant product categories
- Access Control Products - Controllers, readers, locks and credentials.
- Door Strikes - Electric strike hardware.
- Maglocks - Electromagnetic locking hardware.
Still stuck?
Need help choosing or setting up a system? Contact SecurityWholesalers support with your order number, product model and a clear description of the issue.
Frequently asked questions
-
Where should I click first for add access control user card?
Start at Access-control client > Person/Personnel Management > Add, then Access Control > Access Level/Authorisation > Apply. Record the existing state before changing it because labels and available options can vary by model and firmware.
-
What should I look for on that screen?
Look for person status, credential/card number, validity dates, assigned access level, target doors and apply/synchronisation result.
-
What must I avoid changing during the first check?
Disable or revoke access through the supported workflow. Keep legally required transaction records and follow the site privacy/retention policy.
-
How do I prove the correction worked?
Generate one authorised grant and one expected denial, confirm both events name the correct person, then test revocation where required.
-
Why might my menu names look different?
Recorder, controller, camera, app and firmware releases can use different labels. Use the closest equivalent only when its function is clear; otherwise record the model and version for support.
-
Should I factory-reset the device?
Not as an early step. A reset may erase users, network settings, recording configuration, licences or cloud ownership. Back up the configuration and confirm the recovery plan first.
-
What should I send technical support?
Send the exact model and version, screenshot of Access-control client > Person/Personnel Management > Add, then Access Control > Access Level/Authorisation > Apply, exact error text, failure time, what changed before the fault and the result of the controlled local test.
-
Can configuration changes recover data or events that were never recorded?
No. A correction can restore future operation, but it cannot recreate footage, alarm events or access transactions that were never stored.