Engineering overview
Genetec Synergis and ClearID: Managing the Physical Access Lifecycle
Two questions for any access control system.
Who has access to this area today?
The answer takes seconds: run a report, and you have the list.
Why does each of those people still have access?
That is where the answer is usually missing.
Not because no decisions were made. Someone requested the access, someone approved it by email or verbally, and an administrator implemented it. What remains in the system is the outcome—the access right. The justification remains somewhere else: in an email, a request, a spreadsheet, or someone’s memory.
This creates an uncomfortable asymmetry: the security team is accountable for the consequences of access, while the need for that access is determined by others—department heads, area owners, and project managers. The system retains no record of those decisions, so during an audit or investigation, the security team is left defending decisions made by others that it may never have seen.
Three Questions That Become One
Physical access management consists of three distinct tasks.
Who is this person?
The source of truth is the HR system or corporate directory: this is where the person enters the organization, changes roles or departments, and eventually leaves.
Why is this person allowed to enter this particular area?
This is a decision with an owner, a justification, and a defined duration.
What physically enforces that decision?
Controllers, readers, locks, and access rules at the door.
In most organizations, the first and third are automated, while the second still lives in emails and approval threads. That is where risk accumulates—not in doors that fail to operate correctly, but in access rights that were once justified and remain in place after the justification is gone.
A mature architecture does not collapse these layers into one; it connects them properly.
How Does the System Know Who This Person Is?
Manually creating a person in the access control system when they already exist in the HR system means creating a second source of data—one that will fall out of sync with the first as soon as something changes.
The Synergis Card Synchronization plugin imports cardholders, their groups, and access credentials from an external source system into Security Center. Synchronization is one-way: the external system remains the system of record, while Security Center uses the data for physical access control.
But this only addresses the first layer. Synchronization tells the system who the person is. It does not explain why that person should have this particular access.
Every Access Right Needs an Owner, a Justification, and an Expiration Date
The governance problem is not that access rights are assigned incorrectly. It is that the decision behind them does not exist as a managed object: a year later, it cannot be found, reviewed, or challenged.
Genetec ClearID is the layer that operates on top of Synergis and governs access decisions rather than access enforcement. A request records who submitted it, which area it applies to, for what period, and for what reason. The reason is a required field precisely because it will matter during an audit, not when the access is granted. The request is then routed for approval to people who can evaluate the actual need for access, with approvers configured separately for each area.
An approval workflow alone does not solve the problem—any standard corporate ticketing system can route requests for approval. What matters is how directly the decision made at the access governance layer is linked to the system that physically enforces it.
Here, the link is direct. In an access request workflow, the approval does not remain merely a record in a system: the access rule in Security Center is updated, and when the approved period ends, the access rights granted by that rule are removed. There is no person between the decision and its enforcement who can simply forget.
Some access decisions do not need to be made manually at all. Access that a person is entitled to based on their department, role, or employment type can be granted automatically through policy and removed just as automatically when those attributes change. Manual approval is reserved for exceptions—where it actually adds value.
For the security team, this is not a loss of control but a change in role. Instead of making decisions it is not in a position to evaluate on their merits, the security team becomes the owner of the process: who is authorized to approve access, which areas require a second level of approval, and what access durations are permitted. Decision-making is distributed. Control over the process is not.
Access Rights Accumulate Faster Than They Are Reviewed
The clearest example is a contractor. In the traditional model, the instruction is “issue a card for two weeks,” and two weeks later someone has to remember to disable it. The expiration exists in an agreement between people, not as a property of the access right itself. In ClearID, templates can make an end date mandatory and limit the maximum duration according to organizational policy. Requesting indefinite access can therefore become technically impossible.
Where an access right is created manually and has no built-in expiration, the accumulation of excessive access rights is not a failure—it is the natural result of normal operation. Each individual request may appear justified; the problem is what they add up to over three years, as an employee’s actual access gradually stops reflecting their current role.
Granting an access right is not enough. An enterprise model must also be able to demonstrate that the right is still justified.
In ClearID, access reviews are a scheduled process rather than an annual project built around circulating spreadsheets. Reviews can be configured separately for areas, roles, and individuals, and are performed by the people who understand the actual need for access—area owners, role managers, and direct managers. The full history is retained, completed reviews cannot be edited, and an ad hoc review can be initiated after an incident when the organization needs to quickly confirm exactly who had access and on what basis.
The management implication is that physical access maturity becomes measurable. Not simply “security has improved,” but the percentage of active access rights with a recorded justification; the percentage of temporary access rights with an end date; the time between an HR event and the corresponding change in access; and the percentage of access rights confirmed or revoked during the most recent review. The first two metrics can be measured in your own system this week—and they are often the most compelling evidence of where the organization actually stands.
Does This Mean Rebuilding the Physical Layer?
ClearID is not layered on top of just any access control system; it operates on top of Synergis, Security Center’s access control layer. The architecture’s openness exists one layer below: Synergis supports multiple third-party controller, reader, and lock ecosystems. As a result, moving to a governed access model does not necessarily require replacing field hardware at the same time—provided the specific devices and configuration are supported.
This is where precision matters more than promises. A list of supported brands is no longer a sufficient argument—every serious platform has one. The practical question is different: how deeply is the required scenario supported on a specific device model?
A good example is degraded mode, in which an access point continues making access decisions without a connection to the server. This capability is not available across all hardware.
Verification criterion
“The manufacturer is supported” and “this scenario is supported on this specific model” are two different claims—and the second is the one that needs to be verified.
It’s Not the Number of Doors That Scales
In a distributed organization, each site typically has its own access control system and its own history of access decisions: the policy may be formally unified, but the practice varies from site to site.
Scaling an access control system rarely comes down to the number of doors—adding another hundred access points is a well-understood engineering task. The real scaling challenge is the number of access decisions: as the system grows, so do identity profiles, approvals, temporary access rights, exceptions, expiration periods, and access reviews.
Architecturally, this breaks down into three distinct tasks: distributing identity data across Security Center systems, using the platform’s own mechanisms—Global Cardholder Synchronizer and Federation roles; managing the access-granting process itself, which sits one layer above and spans multiple systems; and physical enforcement, which remains local to each site. Treating one of these tasks as a substitute for another leads either to duplicated data or to a policy that exists only on paper.
There is also an organizational condition. A unified policy works only when access decisions are actually made through a single process. If access rights continue to be assigned manually in parallel, the system will show a level of control that does not exist in practice.
How Is Maturity Measured?
The speed at which the system opens a door is the baseline. For enterprise architecture, that is no longer enough as a measure of maturity.
Maturity is defined by whether the organization can explain, a year later, who was granted access, why, by whose decision, for how long—and why that access right still exists. And by whether that explanation is linked to the system that physically enforces the decision.
Decisions disconnected from enforcement produce documentation instead of control.
Enforcement without governed decisions produces order at the doors and chaos in the justification behind them.
Both questions are better asked at the architecture design stage, not three years later—when the system has accumulated access rights whose origins no one remembers anymore.
