Performance and scalability define Procivis One’s identity architecture

At a glance

What this is: This is a performance report arguing that Procivis One is designed to scale to millions of users, credentials and transactions without becoming the bottleneck.

Why it matters: It matters because identity teams evaluating issuance, verification and wallet infrastructure need to understand whether scale, latency and reliability are built into the architecture or bolted on later.

By the numbers:

• Procivis One Core consumed just 287 MB of RAM and 0.61 virtual CPU while issuing 20 credentials per second.
• In idle state, Procivis One Core consumes just 19 MB of RAM and 0.029 virtual CPU.
• The next best tested solutions showed response times 10 times slower with the same setup and load.

Context

Digital identity platforms do not fail only at the protocol layer, they also fail when resource usage, latency and concurrency limits turn routine authentication or credential issuance into a bottleneck. In identity infrastructure, performance is a governance issue because slow or unstable systems change how often users and relying parties can actually complete the trust flow.

This article focuses on the operational case for scaling issuance, verification and wallet functions across large populations and constrained environments. Procivis positions Procivis One as a platform that can support national-scale digital identity use cases while keeping response times and system load within usable bounds.

Key questions

Q: What should security teams test before going live with a new identity platform?

A: They should test authentication flows, tenant mapping, MFA enrollment, passwordless behavior, and any step-up controls in staging before production migration. The point is to confirm that users authenticate correctly, access is routed to the right tenant, and security policies behave as expected under real application conditions. Testing early reduces outages and prevents avoidable identity defects.

Q: When does slow identity performance become a governance problem?

A: Slow identity performance becomes a governance problem when delays interfere with timely provisioning, deprovisioning, approvals, or certification. At that point, the issue is no longer just user frustration. The organisation is extending the period in which access changes remain pending, which weakens control execution and increases the chance that business activity outpaces enforcement.

Q: What are the signs that an identity architecture will not scale?

A: Frequent retry loops, rising error rates, uneven response times and heavy resource consumption under moderate load are the clearest warning signs. If those symptoms appear before you reach expected production concurrency, the architecture is already exposing a scale mismatch that will surface as user friction or operational bottlenecks.

Q: Should teams optimise for portability or raw throughput in digital identity?

A: That depends on where the identity service must run. If the programme needs mobile, edge or offline support, portability and low resource use matter as much as raw throughput. If the service is centralised and high-volume, throughput and stability dominate. Most identity programmes need a balance, not a single metric.

Technical breakdown

Why credential issuance throughput becomes an identity control issue

Credential issuance is not just a throughput problem. In digital identity systems, issuance latency affects enrolment completion, user abandonment, retry behaviour and the operational load on downstream verification services. If a platform cannot sustain concurrent issuance without error spikes, the identity programme inherits queuing, manual exception handling and inconsistent user journeys. That becomes especially relevant when the same core must support issuance, storage and verification across multiple deployment modes. Performance engineering therefore sits inside the identity control plane, not beside it. See the Cloud Workload Identity Guide.

Practical implication: Treat issuance latency and concurrency headroom as governance requirements, not engineering nice-to-haves.

How lightweight runtime design changes deployment options

A lightweight runtime matters because digital identity systems are often expected to run in more than one place: servers, mobile wallets and edge-adjacent devices. Lower memory and CPU overhead widen deployment options and reduce the friction of embedding identity functions into constrained environments. Here the architecture question is whether one code base can preserve functional consistency without demanding a heavyweight host. When the same core must operate in a backend issuer and on a user device, resource discipline becomes part of portability and resilience, not merely efficiency.

Practical implication: Validate whether your identity stack can operate within the resource limits of every target runtime before standardising it.

Why offline and low-bandwidth identity flows need separate performance testing

Offline and poor-network scenarios stress identity systems differently from normal online flows. Proximity-based verification, device engagement and limited-bandwidth exchanges introduce delays, retries and protocol timing constraints that do not appear in well-connected lab conditions. A system can look fast in a data centre and still fail the user experience at the edge if it has not been tested under degraded connectivity. The architectural issue is not only whether the protocol works, but whether it remains usable when the network is unreliable or absent. See the Mobile Driving Licence (mDL) Guide.

Practical implication: Test credential issuance and verification under constrained connectivity before relying on the platform for field use.

NHI Mgmt Group analysis

Performance is part of identity governance, not a separate infrastructure concern. When a digital identity platform cannot sustain issuance and verification at scale, the governance problem is no longer abstract policy but practical availability. That shifts identity architecture from an administrative layer to an operational dependency, because users, wallets and relying parties all experience the control as latency, retries or failure. The practitioner conclusion is that performance thresholds belong in identity programme design.

Lightweight execution expands where identity can be governed. A platform that can run on constrained hardware can extend identity functions into mobile and edge environments without redesigning the whole stack. That matters for government, field deployment and embedded use cases where identity must be both portable and consistent. The governance implication is that deployment freedom depends on resource discipline, not on branding or promise. Practitioners should evaluate whether the architecture supports the runtimes they actually need.

Offline identity support changes the reliability baseline. A system that works only when network quality is high is not enough for real-world identity operations. If verification must succeed in poor connectivity or offline contexts, the platform has to preserve protocol integrity while handling degraded transport conditions. That moves the evaluation away from ideal-path demos and toward operational resilience. The practitioner takeaway is that identity assurance and availability have to be measured together, especially for field and mobile use cases.

Scalable identity infrastructure creates an identity blast radius of its own. A platform designed to issue millions of credentials and handle millions of transactions concentrates trust into a smaller number of core services. That concentration is useful for efficiency, but it also means failures propagate faster and affect more users when they occur. The implication is that identity teams need to examine failure domains, not just throughput claims, because scale amplifies both good and bad design choices.

What this signals

Performance engineering is becoming an identity design decision. Teams can no longer treat latency and memory use as back-end concerns while the identity programme focuses only on trust and policy. When issuance and verification sit behind constrained network or device conditions, the platform has to be evaluated as an operational service, not a proof-of-concept.

Resilience at the edge is now part of identity readiness. Mobile and offline use cases force identity architects to think beyond the data centre, because the user experience depends on whether the platform still functions when bandwidth is poor or absent. Cloud workload identity is useful context here, but the larger signal is that deployment context now shapes assurance as much as protocol choice.

Scalability claims should be tested against failure domains, not just peak throughput. A platform that processes large volumes successfully can still create a concentrated trust dependency if too much of the identity flow rests on one core service. Practitioners should watch for the point where performance, reliability and architectural concentration begin to rise and fall together, because that is where governance attention belongs.

For practitioners

• Benchmark identity services under realistic concurrency Measure issuance, verification and storage under the concurrency levels your production environment will actually see, not just single-user tests.
• Test degraded-network user journeys Validate offline, low-bandwidth and intermittent-connectivity flows for the specific mobile and field environments you plan to support.
• Set resource ceilings for every target runtime Define memory and CPU budgets for server, mobile and edge deployments before you standardise the identity architecture.
• Treat performance thresholds as acceptance criteria Require latency, error-rate and throughput targets to be met before identity capabilities are approved for operational use.

Key takeaways

• The article argues that digital identity platforms fail when performance is treated as a feature rather than a design constraint.
• Procivis reports that its core can handle millions of users, credentials and transactions while keeping resource use and error rates low in benchmark tests.
• For practitioners, the decision is whether identity architecture can remain usable under real concurrency, constrained networks and edge deployment conditions.

Related NHI Mgmt Group resources: Cloud Workload Identity Guide · Mobile Driving Licence (mDL) Guide · Security Operations Metrics Guide

Key terms

• Identity Throughput: Identity throughput is the rate at which an organisation can process access-related work without degrading control quality. It is a useful operational measure when staffing is thin, because security failures often begin when the queue grows faster than the team can safely clear it.
• Operational Resilience: Operational resilience is the ability to keep critical services running or recover them quickly after disruption. In identity-led environments, that depends on authentication services, privilege management, and recovery procedures that can be tested under realistic failure conditions.
• Offline Identity: Offline identity is identity established through physical presence, paper documents, or in-person validation rather than a remote digital session. It is useful for higher-assurance checks, but it does not by itself address remote fraud, scale, or the need to verify users continuously across digital channels.
• Control Portability: Control portability is the ability of a governance control to keep working when the application architecture changes. In clean core programmes, portable controls survive release cycles, integrations, and cleanup of custom code, which makes them more reliable than controls that only exist inside legacy extensions.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.