Campus One Card and Access Control Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the entitlement model get underestimated so often?

Because the visible artifacts are a card and a door, so the project gets scoped as card issuance plus a connector. The actual system is the decision about what a person may open, and that decision is assembled from four or five sources that each hold part of the answer and none of which is the referee.

This is specific to campus because entitlement changes constantly and for reasons that have nothing to do with the card office. A registrar drops a course and a lab door group should die with it. Housing moves a student between buildings and two sets of rights should swap. Human resources (HR) terminates an affiliate. An academic department grants after hours access to a research space for a semester. Each of those is a different system with a different owner and a different publishing cadence, which is why the honest current answer at most institutions is that access is whatever the most recently pushed file said.

The fix is to make grants derived rather than entered. A grant should be a statement with a source, a reason and an expiry: this person may open this door group because housing assignment 44821 is active through a given date. When the assignment ends, the grant dies on its own because it was never a manual entry. Manual overrides will always exist, so model them explicitly with an owner and a review date rather than pretending they do not. Ask any developer to whiteboard person, credential and grant before you sign, and if they draw a cardholder with a list of door groups, they have described the panel you already own.

What goes wrong when you migrate cardholder groups and manual overrides?

You import a decade of accumulated exceptions and give them a clean interface. Every established access control system carries groups that were added manually for a reason that made sense at the time, by people who have since left, with no expiry and no owner. A straight migration preserves all of them, and because the new system now looks authoritative, nobody questions them again.

The second problem is that historic grants usually cannot be attributed to a source. You can see that a badge is in four groups. You cannot see that two came from housing, one from a departmental request in 2023 and one from a summer camp programme that ended. Without attribution, none of them can expire automatically, which means the new event driven model applies only to grants created after go live while the old ones sit underneath it forever.

Treat migration as an amnesty. Recompute every grant that can be derived from a current system of record and let it flow through the new model. Everything remaining goes into an exceptions list that a named owner reviews with a deadline, and anything unclaimed at the deadline is removed. This is politically uncomfortable and it is the only point at which the cleanup is cheap. Doing it later means asking the same departments the same questions with less momentum behind you.

Why do head end and student system integrations break after launch?

Because most of them are nightly files, and a nightly file fails in a way that looks like nothing happening. A student who drops an afternoon lab still has after hours access to a room with compressed gas cylinders until the next morning's run. A room change made at the housing desk at noon does not reach the doors until the following day, so the student is locked out of the room she moved into and can still open the one she left. Nobody reports the second half of that, because it works in their favour.

Head end integrations break differently. A second door platform is close to a second integration project rather than a configuration change, and institutions that grew by renovation or merger usually have two or three. Each has its own cardholder update semantics, its own tolerance for update volume and its own behaviour when a push partially fails.

Subscribe to change events where the source system supports them, poll tightly where it does not, and recompute grants only for the affected person so volume stays manageable. Target a change visible at an online reader inside a minute, and write every recomputation to an append only log with the triggering event attached, so the answer to why a door opened is a record rather than a theory. Then monitor for silence per source: a registration feed that normally produces hundreds of changes a day and produces none is an incident, not a quiet Tuesday.

What happens when offline locks and stored value reconciliation are not covered?

You get two gaps that both surface at the worst moment. Battery powered wireless locks on residence hall doors commonly hold a cached allow list and only learn about a revocation when a technician walks the building or the lock next reaches a gateway. A deactivation is therefore not complete when the card office presses the button, and most campuses have no view showing which locks have caught up and which have not. During an incident review that absence is the finding.

Stored value fails more quietly and costs more often. Declining balance, dining dollars, print quota, laundry credit and an off campus merchant programme behave like one account to a student and like five ledgers to your accounting office. A disputed charge at a participating restaurant exists in a terminal batch, possibly in the card system, and in a weekly settlement file. Proving what happened takes a person and an afternoon, every time.

For locks, model the estate as assets with a last known sync time, compute a revocation completeness figure per building after every deactivation, trigger push updates through gateways where the hardware supports them, and generate a prioritised technician walk list where it does not. For money, run one account ledger with double entry semantics, every transaction carrying the terminal, the credential used, the device timestamp and your own, plus an idempotency key so a replayed batch cannot double post. Refunds and adjustments are entries, never edits.

Should you build custom or configure Transact or CBORD?

If you are a single campus under roughly 3,000 students, on one access control platform, with dining run in house and no off campus merchant programme, run Transact Campus, CBORD or Atrium as delivered with their standard connector and spend the money on readers instead. A custom layer would be an expensive way to solve a problem you do not have.

Even when you do build, keep those platforms. They are strong where they were designed to be strong: card issuance, dining plan mathematics, declining balance accounts and the merchant estate. Replacing them rarely makes sense. What you build sits above them as the entitlement authority, and they remain the system of record for their own accounts. The mistake institutions make is not choosing the wrong card platform, it is buying a very good component and asking it to be an architecture.

Build when two or more of these hold: you run more than one door platform such as Lenel OnGuard alongside C-CURE 9000 or Genetec Synergis, your entitlements come from three or more systems of record and reconciling them is somebody's job, you have offline locks and cannot state your revocation latency as a number, your stored value programme crosses third party merchants, or you are launching mobile credentials and your identity assurance at provisioning is a portal password.

How do hidden costs get into the quote?

Five places. The number of distinct door platforms, which is the single largest driver and is routinely quoted as though the second were a configuration item. Offline wireless locks and elevator controllers, each with its own update mechanism. Off campus merchant programmes, because settlement with third parties brings financial controls and dispute handling that a campus only programme does not. Payment card scope, if you take top ups in a way that touches your own infrastructure, which you should avoid by using a hosted payment page or tokenising gateway so account numbers never reach your servers. And affiliate populations, since contractors, visiting scholars, camp attendees and alumni gym members each need their own lifecycle, and each is a small policy project with a stakeholder attached.

Count the affiliate populations before you scope. Institutions consistently name three and find nine. Each one needs a rule for how the person is created, what they may access, who approves it and when it ends, and those rules cannot be inferred from the student model.

What separates a campus card build that works from one that fails?

The builds that work make revocation measurable. Not instant, which is a claim no one can make honestly across battery powered residence hall hardware, but measurable: a completeness figure per building after each deactivation, expressed in plain language for the card office and campus safety. If a developer tells you revocation is instant, they have not worked with this hardware and you will discover it during an incident review rather than a demo.

They also settle data protection early rather than as a late requirement. Door history is sensitive information about students and staff, and it forms part of an education record subject to FERPA in the relevant contexts. Decide who may query it, whether campus safety needs a documented reason, and how long you retain it, because the default in most access platforms is to keep everything forever. Build the retention policy and the approval workflow into the system rather than leaving it as an operational habit.

Finally, ask what the developer has integrated by name. Lenel OnGuard and C-CURE 9000 are different problems. Banner and Workday Student are different problems. A vending supplier's batch file is a different problem from a print management interface. Then get ownership in writing before kickoff: the repository, the cloud accounts and the right to hire anyone else. At Digital Heroes the code is yours from the first commit, and middleware sitting on the critical path for life safety and money is not something to rent.