Custom Credential Management Software: Features, Costs, and Best Practices

In 2024, a deepfake attempt hit identity verification systems every five minutes. That is not just a projection. It is a measured reality from the Entrust 2025 Identity Fraud Report. Digital document forgeries jumped 244% year-over-year. Deepfake-enabled fraud losses crossed $200 million in a single quarter.

If you are building a credential management system in 2026, these numbers are your engineering brief. Not a warning or background context. They are the actual specification you are building against.

Most organisations still manage credentials the way they managed them a decade ago. Active Directory groups, a shared spreadsheet, or maybe a basic access card system. That architecture produced 78% of disclosed identity-related breaches in 2025. That architecture is outdated, and it leaves a very visible paper trail of liability.

This guide covers what a custom credential management software actually requires in 2026. Seven core modules, the technology stack behind each one, three cost tiers from a single department to national infrastructure, and the development practices that separate systems that hold up under pressure from ones that look good in a demo.

If you are working with a software development company to build a credential management system in 2026, these numbers are your engineering brief. Not a warning or background context. They are the actual specification you are building against.

The 2026 Threat Environment

Before anything else, understand what your Credential Management System is being built to withstand.

The threat environment has changed in three specific ways that matter at the architecture level. These are not incremental updates to familiar problems. They are structural changes that invalidate assumptions baked into most existing Credential Systems.

Non-human identities now outnumber human ones 10:1 in most large enterprises. API keys, service accounts, certificates, automated pipelines. These are the primary scope of your credentialing design, not a footnote. Most legacy systems were built around the assumption that a credential belongs to a person. That assumption no longer reflects how modern infrastructure actually operates. If your credentialing management solution does not account for machine identities from the ground up, it is already covering less than half the attack surface.

Passkey adoption has crossed a meaningful tipping point.

FIDO Alliance research from 2025 found that 48% of the world's top 100 websites now support passkeys, more than double the 2022 figure. The organisations that treated FIDO2 as a future consideration are now behind the baseline. Any new authentication system built without passkey support is launching into a market that has already moved past it.

Liveness detection has a materially higher bar. 

Pixel-domain liveness detection analyses a single image frame and makes a decision based on texture and colour patterns. It no longer holds up against current deepfake generation quality. A deepfake attempt was recorded every five minutes in 2024 against identity verification systems, according to theEntrust 2025 Identity Fraud Report. The 2026 standard is multi-signal liveness. That means combining passive signals like texture analysis and depth mapping with active challenge-response checks where the user blinks, turns their head, or responds to a real-time prompt. Passive liveness alone is no longer a sufficient control.

Digital document forgery is now an automated problem. 

Document forgeries increased 244% year-over-year between 2023 and 2024. The volume alone makes manual review at enrollment untenable. Automated document verification with AI-assisted fraud detection is the baseline requirement, not a premium feature.

These four changes do not just affect one module in isolation. They ripple through every architectural decision in your system, which is why modernizing legacy access systems from the ground up is the only viable response, from the enrolment engine to the audit log.

Seven Core Modules of a Custom Credential Management Software

A credentialing management solution is not one system. It is seven distinct modules, each with its own data model, API surface, and failure modes. Here is what each one requires.

Identity Proofing and Enrolment Engine

This is where everything begins and where most systems get hurt first. Before any credential is issued, you need to verify that the person requesting it is actually who they claim to be.

At a minimum, this module handles:

• Document verification (passport, driving licence, national ID)
• Biometric capture with liveness detection
• Sanctions and watchlist screening
• Integration with authoritative registers like DBS or professional registries

The data model matters here more than most developers realise. Never store document numbers in plaintext. Hash them. Store biometric templates encrypted with AES-256-GCM, with keys backed by a Hardware Security Module (HSM), not an environment variable.

The architecture recommendation for high-risk deployments is cancelable biometric templates. A standard facial recognition template cannot be changed if it leaks. A cancelable template applies a mathematical transformation. If it is compromised, you change the transformation parameters and effectively re-enroll without recapturing the biometric.

The common mistake: Storing biometric templates encrypted with application-layer keys kept in the same database. An attacker who has the database also has the key. HSM-backed key management is not optional here.

Estimated build time: 20 to 32 days

Credential Issuance and Token Generation

Once identity is verified, this module converts it into an actual credential. That might be a QR code with a signed JWT payload, an NFC smart card, a FIDO2 passkey registration, an X.509 certificate, or a pass pushed to Apple Wallet or Google Wallet.

Different credential types need different issuance workflows. But all of them share one requirement: tamper-evident, auditable issuance with approver authorisation.

The JWT signing decision trips up a lot of teams. HS256 (symmetric HMAC) feels simpler. But at scale, every access control reader that validates credentials becomes a potential source of key leakage. The correct choice is ES256 or RS256, asymmetric signing. The private key stays in the issuance service. Only the public key gets distributed to validation endpoints.

Key integrations for this module:

• Apple PassKit (requires an Apple Developer account and Pass Type ID certificate)
• Google Wallet API (requires OAuth2 service account credentials)
• Internal PKI Certificate Authority
• NFC card management API

The common mistake: Using HS256 because it is simpler to implement. It is simpler until one reader is compromised and the shared secret is exposed across every validation endpoint in your system.

Estimated build time: 18 to 28 days

Access Control Policy Engine

This is the decision engine. Every time a credential attempts to open a door, access a system, or enter a zone, this module decides whether to allow it.

It needs to handle three layers:

• RBAC (Role-based access control) is the base policy layer
• ABAC (Attribute-based access control) for context-sensitive rules
• Time-based rules for valid hours, blackout periods, and temporary access windows

The performance requirement here is strict. The access control decision must be completed in under 50ms at the access point. A turnstile processing 500 people per hour per gate cannot afford synchronous database queries for every access decision. The math does not work.

The solution is an in-memory policy cache, typically Redis, updated asynchronously from the database. For physical access control at high-volume entry points, the engine also needs to function offline. Policies and credential entitlements load onto the reader at startup and refresh on a defined interval.

The common mistake: Building access policy evaluation as direct database queries at the decision point. At 500 gate entries per hour with a 10ms average query time, the gate maxes out at 100 entries per hour before queues form.

Estimated build time: 24 to 36 days

Credential Lifecycle Management

Credentials do not just get issued. They get suspended, updated, and revoked. This module manages the full lifecycle.

The four events it automates:

• Joiner: HR system triggers enrolment when a new employee joins
• Mover: Role change triggers an access review and entitlement update
• Leaver: Departure triggers immediate credential suspension
• Security incident: Breach triggers bulk revocation across all affected credentials

The integration that makes this work is SCIM 2.0, a standard protocol for syncing identity events from HR systems like Workday or SAP directly into the credential management system. Without SCIM integration, revocation depends on the HR team notifying the security team. That handoff has a documented average lag of two or more days. That lag is the window most insider threat incidents exploit.

Revocation propagation SLA:

• Online readers: credential revocation propagated within 30 seconds
• Offline readers: credential appears on the next scheduled sync, maximum 4 hours
• PKI certificates: OCSP responder reflects revocation within the CRL update period

The common mistake: Building revocation as a manual process. Automated SCIM-triggered revocation that fires within seconds of a leaver event is not an enhancement. It is the basic control that the manual process cannot reliably provide.

Estimated build time: 22 to 30 days

Biometric Authentication Module

This module handles biometric verification at access points at runtime, every time someone presents their credential. It is separate from the enrolment module, which captures templates once. This one runs continuously.

It supports two modes:

• 1:1 verification: Compare the submitted biometric against the enrolled template for a known identity
• 1:N identification: Search the submitted biometric against all enrolled templates for a venue or zone

The 2026 engineering requirement for liveness detection combines two signal types. Passive liveness covers texture analysis, depth estimation from 2D images, and reflection patterns. Active liveness adds challenge-response checks: blink, turn your head, raise an eyebrow. Together, they reduce presentation attack success rates below 0.1% against current deepfake methods.

Edge inference is the preferred architecture. Running the biometric matching model directly on the access point device cuts latency below 500ms and removes the dependency on network connectivity. Cloud fallback handles model updates and large-scale 1:N searches.

The common mistake:Using a single biometric vendor SDK without monitoring match accuracy over time. Facial recognition performance degrades as the enrolled population ages and lighting conditions change. At 40,000 enrolled users, a drop from 99.9% to 98% accuracy means 400 false rejections per event.

Estimated build time: 28 to 40 days

Audit, Compliance, and Reporting Engine

Every credential issuance, access decision, lifecycle event, and administrative action needs a tamper-evident record. That is what this module produces.

Regulations that require it include GDPR, HIPAA, FIPS 201, and ISO 27001. The audit log is also the forensic record you consult when something goes wrong. Which means it needs to be protected from the same attacker who might have compromised the system.

An audit log stored in the same database as application data, accessible to the same database users, is not immutable. The standard options are:

• A write-once object store (AWS S3 with Object Lock, Azure Blob with Immutability Policy)
• A separate append-only database with restricted write credentials
• A cryptographic hash chain where each event includes a hash of the previous event

The hash chain approach is particularly practical. Each audit event stores a SHA-256 hash of the previous event. Any modification to a past event breaks the chain and is detectable on the next integrity check.

GDPR note: the right to erasure applies to personal data, not to the audit record of the deletion event itself. That record stays.

The common mistake: Building the audit log as a standard database table with the same write permissions as everything else. An attacker who compromises the system can modify the log to cover their tracks.

Estimated build time: 20 to 28 days

Administrator Portal and Self-Service Interface

Two interfaces live in this module. The admin portal for credential managers handles enrolment approvals, lifecycle management, policy configuration, and emergency response. And the self-service portal for credential holders to view their credentials, report loss or theft, and manage their FIDO2 passkey registrations.

Admin authentication requirements are stricter than end-user authentication. The minimum bar is FIDO2 passkey or hardware token for all admin logins. SMS OTP is explicitly not sufficient. SS7 attacks, SIM swap fraud, and SMS interception are documented attack vectors, and the admin portal of a security credential management system is a high-value target.

Privileged admin actions need a second authoriser. Bulk revocation, policy modification, and emergency lockdown all require a second set of eyes before execution. Any action affecting more than a defined threshold of credentials should never be cleared on a single approval. 

The module also needs break-glass emergency access. Separate emergency credentials that bypass normal controls in a genuine crisis, with every use automatically escalated to security leadership and recorded in the audit log.

The common mistake: Building the admin portal with the same authentication requirements as the end-user portal. The access this portal provides is disproportionately powerful. The authentication protecting it needs to match.

Estimated build time: 18 to 26 days

The Technology Stack

Every layer of the stack in a custom credential management software carries a security implication. Here are the choices that matter and why.

Layer	Technology	Why It Matters
API and core services	Node.js 22+ with NestJS or Python 3.12+ with FastAPI	Type-safe API development with built-in guards. FastAPI is preferred for biometric inference (Python ML ecosystem). Separate services for issuance, access decisions, and biometric matching.
Identity and credential database	PostgreSQL 16+ with pgcrypto, separate read replica for audit queries	Row-Level Security enforces scope isolation at the database layer, not just the application layer. Column-level encryption for PII.
Biometric template storage	Dedicated encrypted store with HSM-backed keys, separate from identity records	Templates in the same table as identity records enable correlation attacks. Separate store, separate key.
Cryptographic key management	AWS CloudHSM or Azure Dedicated HSM; HashiCorp Vault for secrets	FIPS 140-3 Level 3 validation. Private key material never exists outside the hardware boundary.
Revocation propagation	Redis pub/sub for online readers; MQTT for offline readers; CRL for PKI	Online readers receive revocation within 500ms via Redis channel subscription. MQTT handles intermittently connected edge devices.
Admin portal authentication	FIDO2 WebAuthn as primary; YubiKey as alternative; no SMS OTP	WebAuthn credentials are bound to the registered origin. A phishing site cannot capture a usable credential even if the admin visits it.
Infrastructure	AWS ECS Fargate multi-AZ; RDS PostgreSQL Multi-AZ; ElastiCache Redis; AWS WAF	Multi-AZ deployment keeps the system available during single-AZ failures. WAF provides rate limiting and OWASP Top 10 protection before requests reach application services.

One decision worth calling out specifically. Storing cryptographic keys in environment variables or a configuration file is not encryption. It is the illusion of encryption. Anyone with read access to the environment has access to the keys. HSM-backed key management is the standard for any credential system operating at scale.

Cost Breakdown: Three Build Tiers

Custom credential management software does not have a single price point. The build cost depends on the scale of deployment, the credential types required, and the security and compliance standards the system needs to meet.

A common mistake organisations make is scoping a Tier 3 system when they need a Tier 1, or underbuilding a Tier 1 when their actual risk exposure demands a Tier 2. If you want to see how real deployments have navigated this, our enterprise software development case study section offers practical reference points.  Getting the tier right at the start saves significant rework costs later. Here is what each tier includes, what it leaves out, and who it actually fits.

Tier 1: Departmental (£29,000 to £56,000 / 12 to 18 weeks)

This tier is built for a single organisation, one site, or one event type. It covers the fundamentals without the complexity that multi-site or high-security deployments require.

What is included at this tier:

• QR and NFC credential issuance
• Basic role-based access control
• Manual lifecycle management
• A standard audit trail

Biometric authentication is not included at this tier. Identity proofing relies on manual document verification rather than automated AI-assisted checks. Lifecycle management depends on human-initiated actions rather than SCIM-triggered automation.

That is not a shortcoming for the right use case. For a single-site deployment with a manageable credential volume, this tier delivers everything the operation needs without paying for infrastructure it will never use.

Good fit for:

• Sports club season ticket credentials
• Conference venue accreditation
• SME building access control

The organisations that overspend at this tier are usually ones that anticipated growth but never scoped the upgrade path if you expect to scale to multiple sites or add biometrics within 18 months, factor that into the architecture conversation now rather than rebuilding later.

Tier 2: Organisational (£56,000 to £108,000 / 20 to 28 weeks)

This is where the system starts handling complexity at scale. Multi-site or multi-event deployment with automated identity workflows, biometric authentication, and PKI-backed credentials.

What is included at this tier:

• Facial recognition with cloud-based biometric inference
• Automated JML lifecycle management via SCIM 2.0 integration with HR systems
• PKI certificate issuance and management
• Apple Wallet and Google Wallet credential delivery
• GDPR-compliant audit log with right-to-erasure workflow

The SCIM 2.0 HR integration is the capability that justifies much of the step-up in cost from Tier 1. Automated leaver revocation that fires within seconds of an HR system event eliminates the manual notification dependency that produces most revocation lag incidents. For any organisation managing more than a few hundred credentials across multiple sites, that automation is not optional.

Good fit for:

• National governing body accreditation programmes
• Multi-site employers with converged physical and IT access control
• Healthcare trust clinical staff credentials with DBS integration

One thing worth noting at this tier: the biometric authentication runs on cloud inference rather than edge inference. That is sufficient for most deployments, but may introduce latency during peak periods. If sub-500ms biometric match latency is a hard operational requirement, that conversation belongs in Tier 3.

Tier 3: Enterprise or National (£122,000 to £240,000+ / 28 to 40 weeks)

This tier is built for high-security, high-volume deployments where performance SLAs, cryptographic standards, and compliance certification are non-negotiable requirements.

What is included at this tier:

• HSM-backed cryptography with FIPS 140-3 Level 3 validation
• Edge biometric inference for sub-500ms match latency at access points
• Multi-signal liveness detection combining passive and active checks
• 30-second revocation propagation SLA for online readers
• Cancelable biometric template architecture
• Formal penetration testing by CREST or CHECK-certified testers
• Full compliance certification documentation

Olympic-scale or FIFA-scale deployments exceed this tier entirely. Those programmes enter national infrastructure territory, with build costs ranging from £5M to £50M or more, and involve multiple government agencies, international standards bodies, and years of lead time.

Good fit for:

• Government identity infrastructure
• National sporting event accreditation

What the Cost Figures Do Not Include

The build costs above cover development only. There are three additional cost categories to plan for separately.

Annual maintenance runs at 15 to 20% of the build cost. This covers security patching and maintenance, model recalibration for biometric systems, compliance updates, and ongoing penetration testing

Biometric SDK licensing typically runs between £2 and £15 per enrolled user for commercial SDKs. At 10,000 enrolled users, that is a meaningful line item that sits outside the development budget.

HSM infrastructure on AWS CloudHSM runs at approximately $1.50 per hour. For a system running continuously, that adds up to roughly $13,000 per year per HSM cluster before factoring in redundancy requirements.

Plan for all three from the start. The organisations that treat these as surprises in year two are the ones that end up in difficult budget conversations at precisely the moment their system is most operationally critical.

Eight Development Best Practices

Credential systems fail in production, not because developers lacked knowledge of the correct architecture. They fail because development practices acceptable for consumer applications were applied to security infrastructure.

• Threat Model Before Architecture

Use STRIDE methodology to identify every threat against each component before writing a single architecture diagram. The threat model answers one question for each component: what is the highest-privilege action an attacker can take if they compromise this?

If the answer is "issue credentials to any identity," that component needs HSM-backed signing keys and dual-authoriser approval for high-risk issuance.

• Test Every Access Control Boundary Adversarially

Do not just test the allowed case. Test:

• Expired credentials
• Revoked credentials not yet propagated to offline readers
• Credentials for an adjacent zone, but not the target zone
• Recently revoked credentials are still within the propagation window

Each adversarial case needs a failing test before the boundary is considered secure.

• Fail Closed, Not Open

When the system encounters an error, network timeout, database unavailability, or policy evaluation exception, the default must be to deny access. Not grant it. Not "let them through to avoid disrupting the event."

The access point that fails open becomes the entry point for every unauthorized person who times their attempt to coincide with a system slowdown.

• Design Encryption for a Compromised Database

The encryption architecture must assume the database is already in the wrong hands. If database compromise reveals readable credential data because the keys are in environment variables or a secrets table in the same database, the encryption is decorative.

After building the encryption architecture, test it by simulating a full database exfiltration and verifying that no plaintext PII exists in the export.

• Test Revocation At The Speed You Guarantee

If the specification says 30 seconds, the CI/CD pipeline must include a test that measures revocation propagation time under load and fails the build if it exceeds 30 seconds. A revocation SLA that is specified but not tested will drift as system load grows.

• Verify Audit Log Integrity Automatically

The hash chain is not a security control unless it is verified. Run an automated daily integrity check. Set a security team alert on any chain breakage. Include a test that modifies an audit event directly in the database and confirms the integrity check detects it.

• Build Credential Expiry as a First-Class Workflow

Expired credentials that are not renewed cause operational disruption. Proactive notifications at 30 days, 14 days, and 7 days, with self-service renewal, remove the administrative burden. Renewal should not require full identity re-proofing if nothing material has changed since the last verification.

• Document Every Security Decision as an Architecture Decision Record

Security decisions made under deadline pressure are invisible in the code six months later. The developer who sees ES256 rather than RS256 does not know why and may optimise it away in a refactor. Every material security decision needs a documented ADR stored in the repository alongside the code.

Integration Architecture

A credentialing management solution does not operate in isolation. Here are the six integrations that matter most and what to watch for in each.

• HR System (Workday, SAP, BambooHR) SCIM 2.0 webhook push from HR to the credential system. Automates the full JML workflow. Verify HMAC signatures on all SCIM webhook payloads and implement idempotent event processing so duplicate HR events do not create duplicate lifecycle actions.
• Identity Provider (Entra ID, Okta, Ping) SAML 2.0 or OIDC for admin portal authentication, SCIM for user sync. Require the IdP to assert MFA completion before accepting the SAML assertion. Do not allow the authentication assurance level to be downgraded below what the IdP enforces.
• Physical Access Control (Lenel, Gallagher, S2) REST API or vendor SDK for credential provisioning; OSDP for reader communications. PACS door controllers often update their lists on a schedule ranging from 5 minutes to an hour. The Credential Management System must know each reader's maximum propagation latency and alert when revocation confirmations do not arrive within that window.
• Biometric Hardware (Wicket, Idemia, HID) REST API to the biometric service; vendor SDK for template management. When a credential is revoked, template deletion must propagate to all hardware units holding a copy. The audit trail records deletion confirmation from every affected unit.
• Certificate Authority (HID, Entrust, internal CA), CMC or ACME for certificate lifecycle; OCSP for revocation status. For high-volume PKI deployments, implement OCSP stapling. The presenting device caches the OCSP response and staples it to the credential presentation, cutting per-verification round-trip latency.
• Sanctions and Watchlist Screening (Comply Advantage, World-Check) REST API for screening at enrolment; webhook for ongoing monitoring alerts. Enrolment-time screening alone misses credential holders added to watchlists after issuance. Ongoing monitoring is the feature that addresses this gap.

Performance Benchmarks

A security credential management system in production needs to meet seven performance standards. These are not aspirational targets. They are the numbers the system needs to hit before it goes live.

• Access decision latency:

Under 50ms from credential presentation to decision. Test at 500 concurrent gate presentations, 95th percentile under 50ms.

• Biometric match latency:

Under 500ms from capture to match result. Edge inference achieves this consistently; cloud inference may exceed the target during peak periods.

• Revocation propagation:

Under 30 seconds for online readers. Test under load with 1,000 active credentials and 10 concurrent revocation events.

• Credential issuance throughput:

1,000 credentials per hour for pre-event batch issuance. Use SQS or RabbitMQ queues to decouple the issuance service from third-party verification providers.

• Admin portal response time:

Under 2 seconds for all search and report operations at 100,000 credential scale. Requires indexed database fields, pagination, and background pre-computation for slow reports.

• Audit log query performance:

Under 5 seconds for a 90-day audit query for a single identity. Required for GDPR Subject Access Request response. Needs indexed timestamps and monthly partitioning at scale.

• System availability:

99.9% uptime. Multi-AZ deployment with automated failover. Planned maintenance must not overlap with operational event periods.

Secure by Default, Not Secure After the Fact

The most instructive pattern in credential management system failures is not that security was attempted and failed. It is that it was deferred.

"We will add encryption later." "The audit log can come in phase two." "We will sort out revocation when it becomes an issue."

Encryption added to an existing data model costs more and covers less than encryption designed in from the start. An audit log retrofitted to existing code paths has gaps that a purpose-built one does not. Revocation propagation bolted onto an architecture that did not plan for it means restructuring the access decision logic at every single access point.

The seven modules in this guide, the technology stack behind them, the eight development practices, and the integration architecture together describe a custom credential management software that is secure by default.

What does that mean in practice? The deepfake that hits enrolment fails against multi-signal liveness. The attacker who exfiltrates the database finds encrypted columns and separately-stored biometric templates behind HSM-backed keys. The insider whose manager forgets to notify the security team has their credentials revoked within 30 seconds by the automated SCIM workflow. The auditor reviewing a security incident finds a hash-chained immutable log of every action taken in the system.

That is not a compliance checkbox. That is what engineering decisions made correctly, with the threat model as their reference, actually produce.

Build Your Credential Management System with Mobisoft Infotech

Mobisoft Infotech can help you build custom credential management software across all three tiers.

• Tier 1 Departmental: Event accreditation, QR and NFC credentials, RBAC, audit trail.
• Tier 2 Organisational: Biometric authentication, SCIM HR integration, PKI certificates, Apple and Google Wallet, GDPR-compliant audit with right-to-erasure.
• Tier 3 Enterprise or National: HSM cryptography, edge biometric inference, 30-second revocation SLA, formal penetration testing, and compliance certification.

Specialist capabilities include cancelable biometric templates, FIDO2 passkey admin authentication, hash-chain audit log, Redis revocation propagation, and physical access control integration with Lenel, Gallagher, S2, and ASSA ABLOY.

The Bottom Line

Building a credential management system in 2026 is not the same problem it was five years ago. The threat surface is larger, the attack methods are more sophisticated, and the compliance requirements are stricter.

The organisations that get this right do not treat security as a layer they add at the end. They build it into every module, every stack decision, and every development practice from day one. That is what separates a custom software that holds up under adversarial conditions from one that passes a demo and fails in production.

If you are scoping a credentialing management solution and want to get the architecture right before a single line of code is written, Mobisoft Infotech can help.