How to rotate camera passwords without breaking your VMS

You rotate camera passwords without breaking your VMS by adding the new credential before you remove the old one, so both work during the cutover. Rotation goes wrong when it is treated as a single edit on the camera, because the camera is not the only thing holding that password. The VMS holds it. So does every integration, every technician laptop, and every tool that was pointed at the fleet years ago and forgotten. Change it in one place and the others keep presenting a password that no longer exists.

Why rotation breaks recording, and why you find out late

A VMS stores per-camera credentials and uses them to open and maintain streams. When the password changes on the camera and not in the VMS, one of three things happens.

The obvious case is an immediate authentication failure. The camera rejects the VMS, the VMS marks the device offline, and someone notices within the hour. This is the good outcome.

The second case is a lockout. Cameras that lock an account after repeated failed attempts will do exactly that when a VMS retries a stale password every few seconds. Now the correct password also fails until the lockout clears, and the technician trying to fix the problem concludes the new password is wrong.

The third case is the one that produces audit findings. An established session keeps running on the old credential, so the VMS still shows the camera green. Nothing appears broken. Then the camera reboots for a power event or a firmware update, reconnection fails, and recording stops. The gap is dated to the reboot, not to the rotation, and nobody connects the two for weeks. This is the same class of delayed failure covered in why security cameras go offline across multiple sites: the fleet was already broken, it just had not been asked to prove itself yet.

Step 1: find every consumer of the credential

Before touching anything, list what actually authenticates to your cameras. On a typical fleet that is more than people expect:

• The VMS or recording servers, which is the one everybody remembers
• Analytics or video-processing systems that pull their own streams
• Access control or building systems tied to camera views
• Health and monitoring tooling
• Mobile apps and the browser-saved passwords on technician laptops
• Discovery and commissioning tools left configured from the original install
• Any integrator or vendor with standing remote access

Each of these is a consumer. Rotation is not done when the camera accepts a new password; it is done when every consumer is on the new one and the old one no longer works anywhere.

Step 2: fix the account model before you fix the password

Most rotation pain traces back to one shared administrator account used by every consumer at once. That account cannot be rotated safely, because every rotation is simultaneously a change to the VMS, the analytics platform, three integrations, and the technician who has it saved in a browser.

Separate accounts by function first, on cameras that support named accounts:

• A dedicated account for the VMS or recording tier, used by nothing else
• A separate account per integration
• Named administrator accounts for humans, not one shared login
• Least privilege on each, so a stream consumer is not also an administrator

Once function and account map one to one, rotation becomes a per-consumer operation rather than a fleet-wide breaking change. This is the single highest-value fix in the whole procedure, and it is worth doing even if you never rotate again, because it is also the answer to the access questions in what auditors actually ask about camera systems.

Step 3: add, do not replace

On cameras that support multiple accounts, do not change a password in place. Create the new credential alongside the old one:

1. Add the new account or new credential to the camera, with the same role as the one it replaces.
2. Confirm the camera accepts it before touching anything else.
3. Leave the old credential valid.

You now have an overlap window. Both credentials work, the VMS is still authenticating with the old one, and nothing is broken. Every subsequent step happens inside a state where mistakes are recoverable.

Step 4: cut consumers over in waves

Update the consumers to the new credential, VMS first, one wave of cameras at a time. Never the whole fleet at once.

A sensible first wave is five to ten cameras that are not covering anything critical, at a single site, during business hours when someone can watch. Update the VMS entry for those cameras, verify, and only then expand. If the wave fails, the old credential is still valid on the camera, so rollback is putting the previous password back into the VMS rather than a truck roll to factory-reset devices.

Working through the fleet in waves also surfaces the consumers you forgot in step one, because they start failing while the old credential is still available to unblock them.

Step 5: verify at the VMS, not at the camera

The camera accepting a password proves nothing about recording. Verify at the layer that matters:

• Confirm the VMS shows an active stream and that recording is writing for each rotated camera
• Force a reconnect, by restarting the stream or rebooting the camera on a sample, so you are testing the stored credential rather than a session that was already open
• Check the camera’s own event or access log for the failed attempts that reveal a consumer still using the old password
• Watch for a full recording cycle before declaring the wave done

The forced reconnect is the step people skip, and it is the step that catches the silent failure described above.

Step 6: retire the old credential and record what you did

Once every wave is verified, remove the old account or invalidate the old password, then reconnect once more to prove nothing was quietly depending on it. Store the new credentials in a vault rather than a spreadsheet, and record the date, scope, and result of the rotation. Rotation you cannot evidence has no compliance value, and the record is what turns a stressful afternoon into a repeatable annual control.

Vendor specifics worth knowing

Vendor	What affects rotation
Axis	Named accounts with roles, so additive rotation works cleanly. Factory-defaulted devices on recent AXIS OS releases restrict how you can first connect, which matters when a camera comes back from a reset mid-rotation. See AXIS OS upgrade paths explained.
Hanwha Wisenet	Enforces its own complexity rules, so a password your generator considers strong can still be rejected. Watch for length and character-type minimums, reuse of the user ID inside the password, and repeated or sequential character runs. Test one password against one camera before generating five hundred.
Bosch	Models that use fixed user levels rather than arbitrary named accounts change the shape of the job, because you are rotating a level’s password rather than adding a parallel account. Treat these as the replace-in-place case below.

Verify the current behavior for your exact model and firmware before a fleet-wide run. Camera vendors change credential handling between releases more often than the release notes suggest.

When you cannot add a second credential

Some devices only allow replacing a password in place. There is no overlap window, so buy the safety somewhere else:

• Schedule a maintenance window, and accept a short, known, documented gap rather than a long, unknown one
• Change the camera and the VMS as one operation, in that order, with the VMS update ready to paste before you commit the change on the camera
• Do them in small batches with verification between batches
• Keep the previous password until verification passes, so rollback is possible
• Never do this remotely on a device you cannot physically reach that day

Doing this across 500 cameras

Everything above is sound and completely impractical by hand at fleet scale. A five hundred camera rotation is thousands of individual edits, each one a chance to break a recording stream you will not hear about until the next reboot.

What that costs over a year, and how far the rotation interval slips behind the policy once the work stops fitting the hours available, is worked out in the credential and certificate rotation calculator.

This is a large part of what MentatNOC does. The platform runs credential rotation across the fleet as staged waves, updates the systems that depend on those credentials so the recording tier does not fall out of sync, verifies that each camera came back healthy before the next wave starts, rolls back automatically when a wave fails, and writes the whole run to an auditable trail you can hand to an assessor. Credentials stay in a vault with controlled checkout, not in a spreadsheet. You can see how staged fleet actions work on the platform actions page, or run a rotation yourself in the live platform demo.

Rotating camera passwords is not hard. Rotating them without discovering three weeks later that four cameras stopped recording is the actual job, and the difference between the two is entirely in the sequencing.