Credential and certificate rotation calculator

How the effort is computed

Each stream is costed the same way. One full sweep of the fleet is the per-camera minutes multiplied by the camera count, plus a retry for every camera that fails recoverably, plus the site visits for the ones that do not, plus a fixed block of prep, approvals, and communication per cycle. Multiply that sweep by how many times a year the deadline forces it, and you have the annual hours. Divide by productive hours in an FTE year, and you have the headcount.

Per-camera minutes for credentials are accounts multiplied by minutes per account, plus the relink time. Multiple hard failures at a single site share one visit, because someone driving out for one camera will pick up the others while they are there.

Why the gap opens

The gap is not a discipline problem. It is arithmetic. Both streams draw on the same weekly hours, so the model splits those hours between them in proportion to the work each one demands over a year. That produces a result worth sitting with: when the work exceeds the capacity, every deadline stretches by exactly the same factor, and the share of the fleet sitting past due is set by that one ratio.

At the defaults, 690 hours of demand against 416 hours of capacity is 1.66 times over. The 90-day credential policy becomes a 149-day reality. The 365-day certificate becomes a 554-day reality. About 40 percent of the fleet is past due on any given day, and that number does not change if the team works harder, because the ratio does not change. It changes when the minutes come down or the hours go up.

The practical version of that: the number to argue for is not a rotation project, it is a standing weekly allocation. The second tile is that number.

What the frameworks actually require

There is no single answer, and the disagreement between frameworks is the source of most of the confusion. The short version: modern guidance has stopped asking humans to rotate passwords on a clock, and has not stopped asking that of the machine credentials a camera holds.

Summarized from the published text as of August 2026. This is a working reference, not legal advice, and whether any given camera falls inside a framework's scope is a question for your assessor. Corrections to [email protected].

The mistake worth avoiding

NIST SP 800-63B-4 is widely read as "stop rotating passwords," and for user accounts that reading is correct. It does not reach a camera's admin login. That guidance is scoped to memorized secrets, meaning a password a person keeps in their head and types. A camera admin account is a shared machine credential: it is held by whoever installed the fleet, by the integrator who maintains it, and by the recording system that authenticates with it around the clock. Those are application and system accounts, and PCI DSS handles them in a separate requirement that still expects a periodic change at an interval you set and defend.

The useful consequence is that the interval is usually yours to choose. Choosing a longer one is a legitimate, documentable decision. Choosing 90 days and then missing it by 59 is not, and the second one is what most fleets are actually doing.

The trigger nobody budgets for

The calendar is not the only thing that starts a rotation. CJIS puts it plainly: change the authenticators for a group or role account when membership to that account changes. A camera admin password is a group credential by construction, so every technician who leaves, every subcontractor who finishes a job, and every integrator you stop working with is a rotation trigger on its own. That work is unscheduled, it lands on the same weekly hours as everything else, and this calculator does not model it. Whatever the tool tells you, the real number is higher by however often your roster changes.

Certificates are a deadline, not a policy

A credential that is overdue still works. A certificate that is overdue does not. That asymmetry is why the two streams are modeled separately even though the labor looks alike. An expired server certificate produces trust warnings and breaks integrations that check it. An expired client certificate on a camera that authenticates to the network with 802.1X is worse: the camera fails authentication and leaves the network. Nothing about that is gradual, and a fleet commissioned in one week shares one expiry date, which is how a single afternoon takes out a whole site. That failure mode and the renewal order that avoids it are covered in camera certificates: expiry, 802.1X, and rotation at fleet scale.

The deadline is also moving. CA/Browser Forum ballot SC-081v3 steps the maximum lifetime of a publicly trusted TLS certificate down from 398 days to 200 on 15 March 2026, to 100 on 15 March 2027, and to 47 on 15 March 2029. Certificates issued by an internal private CA are outside that schedule, and most camera certificates are. Two reasons it still matters: internal policy tends to follow public practice within a year or two of it changing, and any camera fronted by a publicly trusted certificate is bound directly. Run the 100-day and 47-day rows in the table above against your own fleet before assuming the private CA makes it someone else's problem.

One more trap specific to cameras. Axis devices have shipped with a self-signed certificate valid until 2038 since AXIS OS 7.20, and from AXIS OS 10.10 that was replaced with a factory-installed IEEE 802.1AR device identity certificate. So a camera can hold a perfectly valid certificate and still fail your policy, because the certificate your policy cares about is the one your CA issued, not the one the factory installed. A fleet with no expiry alerts is not the same as a fleet with current certificates.

Why the minutes per camera are higher than they look

Nobody publishes a per-camera rotation time, so this is field practice rather than vendor data. Three things reliably push the number above the naive estimate:

• The camera is not the only place the credential lives. The recording system authenticates with it, and so does anything else integrated against the camera. Change it in one place and you have created an outage, not a rotation. The work is not finished until someone has confirmed the camera is recording again, and that confirmation is the relink input. The ordering that avoids the recording gap is covered in how to rotate camera passwords without breaking your VMS.
• A lost password is a site visit, not a support ticket. Axis publishes no default password and no recovery path: a device whose password is lost has to be factory defaulted, and on most models that means physically holding the control button on the camera. Hanwha is the same shape, a recessed reset button held while the unit is powered. Cameras are on ceilings, poles, and parking structures. That is the truck-roll input, and it is why the failure rate matters more than its small percentage suggests.
• Cameras hold more than one account. An administrative account and a service account used by the recorder is the common minimum, and fleets that have grown through several integrators carry more. Every one of them is in scope for the same policy, and each is a separate touch.

Firmware campaigns have the same shape and a different bottleneck. If you are planning one, the firmware campaign planner models the waves, soak gates, and maintenance windows that set that calendar.

Assumptions and limits

• Per-camera minutes and the failure rate are planning assumptions. No camera vendor publishes rotation timings, and no vendor or third party publishes rotation failure rates.
• Weekly hours are split between the two streams in proportion to annual demand. A team that protects the certificate deadline first trades one gap for the other rather than removing either.
• The gap figures are steady-state averages. A real fleet has a distribution: some cameras were rotated last week and some have not been touched since commissioning.
• A renewal lead longer than half the certificate lifetime is clamped to half, because past that point renewal is not a lead time, it is a standing job.
• The model prices labor in hours, not currency, and excludes change freezes, the scheduling tail on site visits, and any recording gap during a rotation.
• Only scheduled rotation is priced. Event-driven rotation, when staff leave, when a shared credential is exposed, or when a device comes back from a factory default, is additive and is not modeled here.
• Framework intervals are summaries of published text for orientation. Scope decisions belong to your assessor.
• Nothing is transmitted. The calculation runs in your browser and the share link carries the inputs in the URL.

What this looks like across a real fleet

Every number above assumes somebody knows, for each camera, which accounts it holds, when each was last changed, which certificate it is presenting, and when that certificate expires. On a fleet of any size that inventory is the actual bottleneck, and it goes stale faster than the spreadsheet that holds it. MentatNOC keeps it current on its own: credential and certificate state for every camera, rotation run as an approved and staged action that does not break monitoring, and an expiry that surfaces before it becomes an outage. It never stores or watches your video. The write side is described on the firmware, password, and certificate actions page, the evidence side on compliance and proof, and you can walk a staged action end to end in the live demo.