Getting Started with CredoID: Quick Setup Guide & Field-Tested Gotchas
CredoID is a software-driven access control platform that works across HID, Mercury, Suprema, ASSA ABLOY, and a dozen other hardware families. This guide won’t repeat the official docs — instead, it walks you through the setup steps that matter most, with the real-world gotchas that catch integrators in the field.
If you follow this guide alongside the documentation, you’ll avoid the issues that typically cost hours of troubleshooting.
Step 1: Meet the Prerequisites
CredoID requires a 64-bit Windows system (7 through Server 2025) or a Linux Docker container, a minimum of 8 GB RAM, and PostgreSQL 16.0+. The installer can bundle PostgreSQL for you.
📚 Full specs: docs.credoid.com → Requirements
Gotcha: No internet required
CredoID does not phone home. Updates are installed manually — there is no OTA mechanism, by design. This makes it suitable for air-gapped and high-security environments, but means you need to plan your update schedule.
Step 2: Open Firewall Ports
A common reason controllers fail to appear in the dashboard is blocked firewall ports. CredoID relies on controllers making inbound TCP connections to the server. If your firewall blocks these, nothing will connect.
💡 Good news: The CredoID installer prompts you to create the required Windows Firewall exceptions automatically during installation. If you accepted that prompt, your firewall is already configured and you can skip to Step 3. The instructions below are for environments where the automatic rules were declined, removed, or where custom firewall software is in use.
Required ports
| Port | Protocol | Used By |
|---|---|---|
| 8090 | TCP | CredoID web client (browser UI) |
| 4070 | TCP | HID VertX controllers |
| 3001 | TCP | Mercury controllers |
| 3002 | TCP | HID Aero controllers |
| 58032 | TCP | CredoID Checkpoint mobile app |
| 20002, 20005 | TCP | ASB Security (MusDo) panels |
| 2001, 2002 | TCP | FATH TANlock3 |
All default ports can be changed in config.additional.json.
📚 Full port list & firewall setup: docs.credoid.com → Firewall
How to verify ports are open
From the controller’s network, use these commands to confirm the CredoID server is reachable on the required ports:
# Windows — test if CredoID is listening on the Mercury port
Test-NetConnection -ComputerName 192.168.1.100 -Port 3001
# Linux / macOS
nc -zv 192.168.1.100 3001Replace 192.168.1.100 with your CredoID server IP and 3001 with the port for your device type.
On the CredoID server itself, confirm the service is actually listening:
# Windows — check all CredoID listening ports
netstat -an | findstr "4070 3001 3002 8090"
# Linux (Docker)
ss -tlnp | grep -E '4070|3001|3002|8090'If a port doesn’t appear in the output, either the CredoID service hasn’t started, or config.additional.json has a non-default port configured.
How to create the Windows firewall rule (manual method)
If you skipped the automatic firewall setup during installation, create the rules manually:
Windows Defender Firewall → Inbound Rules → New Rule → Port → TCP →
Specific ports: 3001, 3002, 4070 → Allow → Apply to all profiles → Name it "CredoID Controllers"📚 Step-by-step with screenshots: docs.credoid.com → Firewall Rule
Step 3: Connect Controllers
CredoID supports an extensive hardware ecosystem — HID (VertX EVO, Aero X1100), Mercury (EP, LP, MP series), Suprema (CoreStation, XPass 2), ASSA ABLOY Aperio, Azure, FATH TANlock, Honeywell, Siram OCR, and ASB MusDo intrusion panels.
Every controller must be configured beforehand to point to the CredoID server. There is no broadcast auto-discovery — controllers make a direct TCP connection to an IP address you specify.
📚 Device-specific guides: docs.credoid.com → Devices
HID VertX
VertX uses a different default network setup than Mercury/Aero. The default IP is 169.254.242.121, and the first login is admin with a blank password.
- Connect via ethernet and open
http://169.254.242.121in a web browser - At “Basic Central Station/Host Communications Setup”, enter either:
- IP Address: the IP where CredoID is running, or
- Host Name: the network name of the CredoID machine
- Click Submit — the controller will connect to CredoID on port 4070 and begin communicating
Make sure there is an incoming connection exception in your firewall settings for port 4070.
Gotcha: VertX web interface requires HTTP, not HTTPS
When accessing the VertX controller’s web interface, your browser may default to https:// and show an ERR_SSL_VERSION_OR_CIPHER_MISMATCH error. The VertX web interface does not support HTTPS — you must manually change the URL to http:// in the address bar. Most modern browsers attempt HTTPS first, so this trips up nearly every first-time setup.
How to verify the connection:
# On the CredoID server, watch for the VertX connection appearing
netstat -an | findstr "4070"
# You should see ESTABLISHED connections from the controller's IP📚 Full VertX guide: docs.credoid.com → VertX EVO
Mercury (EP, LP, MP series)
Mercury controllers connect via the SCP protocol on port 3001. The required Host Comm settings in the controller’s web interface are:
| Setting | Value |
|---|---|
| Connection Type | IP Client |
| Data Security | TLS if Available |
| Host IP | IP address where CredoID is running |
| Connection Mode | Continuous |
| Port Number | 3001 |
After clicking “Accept”, set all DIP switches to OFF and click Apply Settings — the device will reboot to apply the new configuration.
📚 Full Mercury guide: docs.credoid.com → Mercury
Gotcha: Mercury MP OSDP jumper removal
Mercury MP1501 panels ship with OSDP termination jumper J1202 installed. MP1502 panels ship with J1501/J1502 jumpers. If you are using non-OSDP readers (standard Wiegand), you must physically remove these jumpers. Leaving them in causes card data to be read incorrectly — the most common “my reader isn’t working” support call we see.
Similarly, the MR-50-S3B has jumper J602 near the reader port — this must be open for non-OSDP readers.
📚 Jumper reference: docs.credoid.com → Mercury MP series
HID Aero
Aero controllers connect on port 3002 using the same SCP protocol as Mercury, but with a stricter security posture.
Gotcha: Aero requires “TLS Required” — Mercury does not
The CredoID docs specify different Data Security settings for each controller type:
| Controller | Data Security | What it means |
|---|---|---|
| Mercury | TLS if Available | Attempts TLS, falls back to unencrypted if unavailable |
| HID Aero | TLS Required | TLS is mandatory — the connection will not establish without it |
If your Aero panel is configured correctly but won’t come online, verify TLS is working end-to-end. Mercury is more forgiving because it allows fallback.
The required Aero Host Comm settings are:
| Setting | Value |
|---|---|
| Connection Type | IP Client |
| Data Security | TLS Required |
| Host IP | IP address where CredoID is running |
| Connection Mode | Continuous |
| Port Number | 3002 |
📚 Full Aero guide: docs.credoid.com → Aero X1100
Gotcha: Sync = controller reboot (plan your timing)
After making changes in CredoID (doors, modules, schedules), you need to synchronize the configuration to the controller. This causes the controller to reboot:
| Controller | Approximate Reboot Time |
|---|---|
| HID VertX | ~15 seconds |
| HID Aero | Up to 50 seconds |
As the docs note: “That can cause disruptions so plan your changes accordingly.” Schedule sync operations during low-traffic hours in production environments.
Starting with CredoID 4.13.0, Aero and Mercury support live synchronization — most changes upload without requiring a full sync. But deleting doors, inputs, outputs, schedules, changing device module settings, pin code length, and managing access areas still require a manual sync and reboot.
📚 Sync states explained: docs.credoid.com → Synchronize
Step 4: Configure Doors
Once your controllers are online in CredoID, the next step is to create doors. Doors are the logical representation of physical access points — each door ties together a controller module, reader(s), a door contact sensor, and a lock relay.
In CredoID, navigate to Access Points → Doors and click Add. You’ll assign:
- Controller and module — which hardware port controls this door
- Reader(s) — entry reader, and optionally an exit reader
- Door contact — the sensor that detects open/closed state
- Lock relay — the output that controls the electric lock or maglock
- Door mode schedule — when the door is locked, unlocked, or in card-only mode
Without doors configured, readers will appear in the system but won’t grant access — there’s no link between the reader and the lock. This is a required step before testing any card reads or access levels.
Gotcha: Door mode vs. access level
A common misconception: the door mode (locked, unlocked, card only) is a schedule-based behavior that applies to everyone. Access levels determine who can open the door during locked mode. Both must be configured — a door set to “Locked 24/7” with no access levels assigned to any users will deny every card.
📚 Door configuration guide: docs.credoid.com → Doors
Step 5: Configure OSDP Readers
We strongly recommend OSDP over legacy Wiegand for any new installation. CredoID supports toggling Secure Channel encryption on a per-reader basis.
Gotcha: OSDP Auto-Detect has limits
CredoID can auto-detect OSDP readers, but only under these conditions:
- One OSDP reader per port — multi-reader ports require manual address configuration
- HID Aero and Mercury only — VertX does not support auto-detect
- Not supported on downstream modules or older readers like the iCLASS SE R10
If auto-detect doesn’t find your reader, manually set the OSDP address (default: 0) and baud rate (default: 9600) in the Device Modules tab.
Gotcha: Secure Channel only works when the reader has Secure Mode enabled
Enabling Secure Channel in CredoID tells the controller to attempt an encrypted OSDP session — but this only has effect if the reader itself has Secure Mode enabled. If the reader doesn’t have Secure Mode turned on, enabling Secure Channel in CredoID does nothing.
Here’s the actual sequence:
- The reader must have Secure Mode enabled (via HID Reader Manager app or configuration card)
- CredoID’s Secure Channel toggle tells the controller to negotiate an encrypted session with the reader
- Once the secure connection is successfully established, the reader exits Install Mode and will only accept encrypted commands going forward
If you need to reconfigure the reader after it has exited Install Mode, you’ll need the HID Reader Manager mobile app or a configuration card to re-enable Install Mode.
📚 Secure Channel setup: docs.credoid.com → OSDP
Step 6: Set Up Anti-Passback (APB)
CredoID supports Hard and Soft anti-passback modes to prevent credential sharing and tailgating. An optional timeout parameter (in seconds) can be set to automatically reset a user’s APB state after a defined period.
Gotcha: APB is controller-scoped, not global
APB rules are processed on the controller hardware — not in the CredoID server. This means all doors in an APB zone must be wired to the same controller and module chain. You cannot create an APB zone spanning two separate controllers.
- HID Aero: Full APB support with up to 32 X100 door modules per zone
- Mercury: Full APB support
- HID VertX: Partial APB support only
Gotcha: APB requires physical door monitors
Configuring APB in software is not enough. The docs are explicit: “For anti-passback to work, door monitors must be present.” If you don’t have door contact sensors wired, APB will not enforce — regardless of your software configuration.
Gotcha: Changing access levels resets ALL APB states
The docs state explicitly: “Modifying access levels will reset current APB state for all users.” This means any edit to an access level definition wipes the tracked APB position for every user in the system, potentially undermining the anti-tailgating protection until users badge through entry/exit readers to re-establish their positions.
Mitigation: Schedule access level changes during off-hours and notify monitoring staff that APB states have been reset.
📚 Access areas guide: docs.credoid.com → Access Areas
Step 7: Active Directory (LDAP) Sync
CredoID can import users from Active Directory on a scheduled basis using the Synchronize import mode.
Gotcha: Understand “Synchronize” mode and disabled accounts
CredoID’s Synchronize mode does two things — and only two things:
- Imports/updates all users returned by the LDAP query
- Deletes any CredoID user who is no longer present in the LDAP results
The LDAP filter used is (&(objectClass=user)(objectClass=person)) — this returns all user objects including disabled accounts. Disabling an AD account does not remove it from the query results, so the user will not be automatically deleted from CredoID.
However, CredoID does have a bindable Disabled field in the import bindings. If you manually map an AD attribute to this field, CredoID can reflect the disabled status. This binding is not configured by default — you must set it up explicitly in the Bindings dialog.
Our recommendation: Either map the Disabled field in your AD import bindings, or configure your IT offboarding scripts to move departing employees out of the PACS-designated LDAP organizational unit entirely.
📚 Binding configuration: docs.credoid.com → Scheduled Imports → Bindings
Gotcha: Import limits
The AD import has hard limits:
- 8 access levels per user maximum
- 16 locations per user maximum
Enterprise environments with complex role-based access structures will hit these ceilings. If you need more granular assignments, consider the CredoID API or scripting module.
Gotcha: Import Mode is destructive
The Mode setting (Overwrite, Append, or Synchronize) determines what happens to existing data. The docs flag this with an explicit warning: “Mode is a very important setting, proceed with caution.” “Overwrite” will replace existing user data. “Synchronize” will additionally delete users not found in the import source. Start with Append if you’re unsure.
How to test safely:
1. Create a test OU in AD with 2-3 test users
2. Point the LDAP path to that test OU only
3. Run the import manually and check results
4. Only then point it at your production OUIdentification format for AD attributes
If you’re importing credentials via AD attributes, values must follow one of these formats:
{ "CardNumber": "12345", "FacilityCode": "10", "CardFormatBits": 26, "PinCode": "1234" }Or the shorthand Unicode format: 26_10_12345_1234 (bits_facility_card_pin, use 0 for unused PIN).
📚 Full import guide: docs.credoid.com → Scheduled Imports
Step 8: Licensing
After your first successful login, CredoID will present the option to activate a demo license. The demo gives you 30 days, 2 readers, 100 identifications, with all modules enabled — enough to fully evaluate the system before purchasing.
💡 Note: The demo license is not activated automatically. You must explicitly choose to activate it from the licensing prompt after login. This lets you defer activation if you’re setting up the server in advance of your hardware arriving.
Gotcha: License is hardware-ID locked
Production licenses are tied to a hardware ID. If you migrate or change hardware, you’ll need to contact support to get the license re-issued. For redundancy setups, a second 1:1 equivalent license is available at 50% discount.
Gotcha: VMS cameras are entities, not modules
The licensing model separates modules (Scripting, Security, Alerts, Map, Card Designer, AD Import, Triggers) from entities (Readers, Locations, Inputs/Outputs, Cameras, Mobile devices, Elevators). VMS cameras require the presence of a compatible VMS (such as Digifort or Lensec Perspective VMS), licensed separately. Identification count is not limited.
📚 Licensing details: docs.credoid.com → Licensing
Step 9: Firmware Management
CredoID can push firmware updates to HID Aero and Mercury controllers directly from the UI.
Gotcha: Firmware files aren’t bundled since v4.17
You need to download the firmware package separately from download.credoid.com/firmwares.zip and extract it to:
C:\Program Files\Midpoint-Security\CredoID\Service\devices\FirmwaresGotcha: The 1.31.0 bridge — there is no shortcut
Firmware upgrades follow a strict compatibility matrix. The single most important rule:
⚠️ Any controller on firmware 1.27.x through 1.30.9 must upgrade to 1.31.0 first. You cannot skip directly to 1.31.1+ or any 2.x version. Firmware 1.31.0 is a mandatory stepping stone.
Firmware upgrade & downgrade compatibility
| Starting Version | Can Upgrade To | Can Downgrade To |
|---|---|---|
| 1.27.x – 1.30.9 | → 1.31.0 only (mandatory bridge) | → 1.30.4 minimum (PHY caveat — see below) |
| 1.31.0 | → Any 1.31.x or 2.x version | → Cannot downgrade below 1.31.0 |
| 1.31.1 – 1.31.5 | → Any higher 1.31.x or 2.x | → Down to 1.31.1 (not to 1.31.0 or lower) |
| 2.0.0 – 2.0.2 | → Any higher 2.x | → Down to 2.0.0 (not to any 1.x version) |
| 2.1.0+ | → Any higher 2.x | → No downgrade — each 2.x minor is one-way |
Gotcha: Ethernet PHY board revision limits downgrades
Controllers with the newer Ethernet PHY board revision can downgrade to 1.30.4. However, controllers with older boards cannot be downgraded below 1.30.4 at all. There’s no way to determine this from firmware alone — you need to check the board revision physically.
Gotcha: Version 2.x is a one-way road
Once a controller reaches any 2.x firmware, it cannot return to 1.x. Within the 2.x line, each minor version bump (2.1.0 → 2.2.0 → 2.3.0 …) is also one-way — you cannot downgrade between 2.x minor versions. Plan accordingly and test firmware updates on a non-production controller first.
The migration from 1.31.x to 2.x takes approximately 20-50 minutes per controller over LAN. The controller must be on minimum version 1.31.0 before attempting the 2.x migration.
Always synchronize devices after every firmware upgrade.
📚 Firmware guide: docs.credoid.com → Firmware Updates
Bonus: Quick Reference
Default credentials
Admin login after fresh install or password reset: admin / admin. Change this immediately.
Duress PIN
CredoID has a built-in duress feature: in Card & PIN mode, entering your PIN with the last digit incremented by 1 generates a silent duress event while still granting access. PIN 1234 → Duress PIN 1235. If it ends in 9, it wraps to 0.
Reset admin password
# Stop the service first, then run:
cd "C:\Program Files\Midpoint-Security\CredoID\Service"
.\MDP.SID.Launcher.exe /AdminPasswordReset=true
# Resets to admin:admin — restart service afterDocker deployment
docker pull midpointdev/credoidFull Docker guide: hub.docker.com/r/midpointdev/credoid
What’s Next
Once your controllers are online and synchronized, explore:
- Maps — visualize your site
- Rules (Triggers) — automate responses to events
- Scripts — extend CredoID with C# scripts
- OpenAPI — integrate with your enterprise stack
- Mobile Manager — manage access control from your phone
Questions? Contact [email protected] or visit docs.credoid.com.
Technical claims in this post are sourced from docs.credoid.com (v4.23) unless otherwise noted. Controller Host Comm settings, port numbers, and feature specifications are taken directly from the official device setup guides. AD import filter details and identification formats are verified against the CredoID codebase.