Event Credentialing and Accreditation Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does an accreditation build keep expanding beyond the application form?

It starts as a registration form with an approval queue. Then someone points out that individuals do not apply for themselves. A broadcaster submits a crew list, a caterer submits a workforce that changes daily, a sponsor submits guests two days out, and a federation submits a delegation whose roles map to different zones. So bulk submission comes in scope, and with it quotas, coordinators and delegated approval.

Then vetting appears, and vetting is not one check. It is several checks determined by the zone being granted rather than by the job title, each with its own provider, turnaround and definition of a pass. Then the security lead asks what happens at the gate, and the project has crossed from workflow into access control.

The expansion is inherent to the domain. Accreditation is a security control wearing an administrative costume, and every part of it is load bearing. Scope by cycle rather than by feature. Commit that one edition of your event runs end to end for a defined set of registrant categories: organisation submission, category to zone mapping, vetting with one or two providers, approval, photo capture and badge production. Put live entitlement evaluation, offline handheld scanning and multi venue configuration on a written exclusion list for release one. An event date does not move, so the first cycle should be scoped smaller than the ambition and the second edition absorbs the rest.

What goes wrong with registrant, vetting and prior edition data?

Three problems, and one of them is a legal exposure rather than an inconvenience. The first is identity matching. A check run against a name spelled differently from the passport returns a clean result about a different person, and the mismatch is invisible unless the system compares the submitted document against the vetting request. Coordinators uploading spreadsheets will transpose characters, omit middle names and enter dates in their own local format.

The second is expiry. A check completed in March against an event running in July may have lapsed, and for a three week event a check can expire mid tournament. If the record shows a pass with no date attached, nobody notices.

The third is prior edition data, which is simultaneously your biggest cost saving and your largest liability. Last edition's registrants, their organisations and their completed checks make the next edition dramatically cheaper to run. That same data set contains identity documents and vetting outcomes, so retention periods, deletion rules and hosting arrangements are not optional and are not a phase two item.

What works: validate bulk imports at upload and return the errors to the coordinator rather than to your team, model every check with an owner, an expiry and an evidence reference, and write the retention and destruction policy before the first record exists. Carrying prior edition data forward should be an explicit, consented decision per registrant rather than a default of the migration script.

Why do the vetting providers and access control integrations break after launch?

Vetting providers change between editions. That is not a hypothetical, it is the normal pattern, and a build that hard codes one provider's request and response shape will need surgery next cycle. Where the provider is a police or government interface, the pace is set by someone else's approvals and the format is rigid, so integration work that looks small takes months of calendar time.

Access control is the harder one. Writing credential state into a Genetec or equivalent platform in near real time is genuine engineering, not a call to an interface. The states will disagree at some point, because a device was offline, an acknowledgement was lost or an operator changed something locally. Reconciliation between the accreditation system and the gate system is where the difficulty lives, and anyone who quotes it as a simple connection has not done it during a live event.

Three controls hold it together. Abstract the vetting provider behind your own check model so swapping one is configuration rather than rework. Build acknowledgement handling and a reconciliation job that compares what you believe a reader holds against what it actually holds, running continuously rather than nightly. And secure the cooperation of whoever installed and maintains your access hardware early, because their availability, not your developer's, will set the integration date.

What happens when live entitlement evaluation and revocation are not covered?

You get the two failures that end careers. The first is the zone change described above. If the printed badge carries the authority, every change after production is a reprint or a sticker, and inside the final week neither is workable. Separate the badge from the entitlement: the badge carries an identity and a credential number, and the entitlement lives in the system and is evaluated at the gate against the current zone rules, the current day and the current time window. Printed zone icons then become a human readable indicator rather than the authority, which is a deliberate policy decision your security lead must sign off, because some events insist the badge must remain authoritative and the design has to support both.

The second is revocation. Someone is dismissed, a badge is lost, or a person is found in a zone they should not be in and their access is pulled. In a paper driven process, revocation is a radio call that may or may not be heard plus a printed cancellation list supervisors are supposed to check. Everyone working a gate knows that does not work.

Revocation has to be a single action that reaches every reader and handheld within seconds, with an audit record of who revoked it, when and why. Handhelds at soft perimeters must hold local credential state so they keep operating when the network drops, and they must honour revocations issued while they were offline once they reconnect. Day passes and temporary upgrades run on the same mechanism, so a contractor needing field access for two hours on Thursday gets an entitlement that expires by itself instead of a note taped to a badge.

Should you build custom or configure what you already own?

Buy or configure if you accredit a few hundred people who are largely the same from event to event. Your existing access control system plus a controlled approval form is proportionate, and building software here spends security budget on a workflow a shared inbox could run. We would tell you that rather than quote you.

Accredit Solutions is the serious incumbent in this space and is the right answer for a lot of major events. If your process broadly matches how large sporting events already work, and you would rather buy a team that has done it than run a build programme against a fixed date, that is a defensible and often correct decision.

Genetec and its peers are access control platforms and they are excellent at the gate. They are not where an application is written, vetted and argued about for six weeks, so treating an access control system as your accreditation system produces a workflow built out of spreadsheets around it.

Build when the process is genuinely yours: unusual registrant categories, an approval chain across several rights holders and authorities, zone rules that change during the event, or a requirement to sit inside a wider platform you already run for ticketing and workforce. Build too when you run a recurring event and the compounding value of owning the registrant record matters.

How do hidden costs get into the quote?

Four items are missing from most accreditation quotes. The first is the number of vetting providers, and specifically whether any is a government or police interface. Those are slow to arrange and rigid in format, and the elapsed time is not proportional to the engineering.

The second is access control integration, which is dictated by whatever hardware is already installed and by an installer whose cooperation you have to secure. Price it against the actual estate rather than against a generic connector.

The third is photo capture quality. A badge photo that fails at a gate under floodlights is a real operational cost, and the validation rules covering lighting, framing, background and expression are fussier than anyone expects. The fourth is retention and deletion tooling, which is a build item because your data includes identity documents and vetting outcomes.

Ask for all four as named lines. A single number that folds them in will be revised, and the revision arrives in the weeks when you have the least capacity to absorb it.

What separates a build that works from one that fails here?

Four questions, and they are all answerable in a scoping call. Ask how a zone change on the morning of day three reaches a badge printed six weeks earlier. If the answer involves reprinting, they have modelled the badge as the entitlement, and you will be putting stickers on passes in the last week.

Ask what a handheld scanner does at a soft perimeter when the network drops. It must hold local credential state, keep scanning, and converge quickly on reconnection including revocations issued while it was offline. Anything less means the perimeter stops working at the moment it matters.

Ask which access control platforms they have written credential state into, by name, and what they did when the two systems disagreed during a live event. The reconciliation story is the whole signal here, not the initial connection.

Then settle ownership and data handling before kickoff: the repository, the infrastructure accounts, the registrant data and the right to hire another firm, in writing. Accreditation data includes identity documents and vetting outcomes, so hosting has to be under your control and retention has to be your policy rather than a vendor's default. At Digital Heroes the client owns the repository and the data from the first commit, and in this domain that is a governance requirement rather than a commercial preference.