SRT Passphrase Rotation for Cloud OBS Ingests and Remote Producers

The direct answer

Rotate an SRT passphrase after temporary device access, a contractor handoff, a copied preset, or any exposure you cannot account for. Do it during a rehearsal window, update both endpoints, prove encrypted connection behavior, and keep a separate fallback ingest ready. Do not change a shared secret live just because it feels safer in the moment.

Haivision's current SRT documentation says encrypted streams require matching settings on source and destination and supports AES-128 or AES-256. The SRT project documentation adds a crucial detail: a passphrase is for encryption, not authentication, and its enforced-encryption setting affects whether peers with mismatched settings are rejected. That distinction matters when a producer says 'we put a password on it' and assumes the route is locked down.

StreamableRun is useful here because the field device contributes to a named ingest while Cloud Hosted OBS keeps public scenes and destinations stable. The producer can put viewers on fallback while the field operator updates an SRT preset, instead of touching platform keys or rebuilding every scene.

Know the difference between routing, access, and encryption

An SRT URL or endpoint tells a device where to connect. A Stream ID can carry an identifier or requested route to the listener. A passphrase enables encryption. They are related operationally, but they solve different problems. Do not paste the same string into every field and call it security.

The SRT access-control guidance says Stream ID is sent by the caller and can be used by a listener to choose whether to accept a connection or select a resource. It also says the application cannot directly inspect the passphrase, and that setting a passphrase lets SRT reject a mismatch. Use a stream ID as a controlled routing label, not as a public note full of names or event details.

Write these facts into the producer packet without writing actual secrets: source device, caller/listener role, host and port owner, stream ID label, encryption requirement, passphrase owner, fallback ingest, and test result. That lets a handoff happen cleanly without a screenshot becoming the secret store.

When rotation is actually needed

Rotate when a temporary encoder was returned, an event laptop was shared, a preset was sent through a chat thread, a venue technician configured a device, a contractor leaves the production, or a device was lost. Rotation is routine cleanup, not an accusation. The important thing is to remove old access before the next show, then prove the new route works.

Do not rotate because a field source merely reconnected. Network recovery and secret rotation are separate decisions. If a phone crosses cells or an encoder restarts, the producer needs the current source to recover quickly. A scheduled rotation should happen after the public stream, at a preflight, or on a dedicated private test.

Keep each contributor on its own credential scope where the workflow supports it. A guest phone should not share the main field encoder's route. A backup source should not silently become the primary because both configurations use a copied old preset. Named, narrow inputs make revocation less dramatic.

• Returned or borrowed hardware.
• Temporary venue or sponsor computer access.
• Preset copied into chat, email, screenshots, or unmanaged notes.
• Crew-role change or contract end.
• Lost device, unknown access, or suspicious source activity.

Rotate downstream to upstream

Plan the change in an order that leaves the public show protected. First create or verify a Cloud OBS fallback scene and backup ingest. Then change the receiver or ingest configuration at the scheduled window. Update one field sender with the new passphrase. Start a private contribution. Confirm connection, audio, video, and correct source identity. Only then remove the old configuration from devices and notes.

If the source and receiver do not agree, expect the route to fail. That is the point of the test, not a reason to disable encryption. Haivision documents matching passphrases on both ends, while the SRT socket-option documentation explains enforced encryption behavior. Treat a clean reject as better evidence than a stream that connects in an unclear state.

A remote producer should not be inventing values. The named credential owner supplies the approved updated preset through an agreed channel. The producer confirms the source is visible in StreamableRun, confirms Cloud OBS is receiving it, and confirms a normal viewer preview before marking the rotation done.

• Prepare fallback and backup before changing the secret.
• Update receiver or named ingest during a private window.
• Update one sender and make a short encrypted test.
• Verify picture, audio, source identity, and published preview.
• Remove old presets and document the date without recording the secret.

Encryption is not the whole access policy

An encrypted contribution is still a production input that needs ownership. Limit who can open StreamableRun control surfaces, who can alter Cloud OBS scenes, and who can change destinations. Do not give a camera operator the same controls as the destination owner merely because they need an SRT preset.

Use sensible access separation: a field operator owns the sending device; an engineering owner manages ingest policy; a producer runs public scenes; the channel owner controls platform accounts. The setup should survive one person losing connectivity without forcing everyone to share the highest-privilege login.

Also protect the operational leftovers. Delete old exported encoder profiles from loaner machines. Remove passwords from task notes. Review saved OBS profiles, screenshots, QR codes, and support tickets. A well-rotated passphrase is less useful if an old complete URL remains in a photo album.

• Separate field contribution from public destination controls.
• Use narrow roles for guest or temporary devices.
• Remove old presets from returned hardware.
• Do not keep secrets in the runbook or post-show report.
• Audit screenshots and shared storage after an event.

The StreamableRun recovery path

Keep the main and backup contributions named separately in StreamableRun. Cloud Hosted OBS should have Main Source, Backup Source, Technical Hold, and BRB or clips scenes. If a planned SRT rotation goes wrong, the producer switches to the safe public scene while the field operator restores the last known-good preset or completes the new pair update off-air.

The platform destinations should remain in the cloud layer. There is no reason to give an SRT field encoder every Twitch, YouTube, Kick, or sponsor RTMP secret. That separation reduces both the scope of a copied preset and the number of things that need to be re-tested after rotation.

After the test, have another operator try the retired configuration only in an approved private environment, if policy permits, to confirm it no longer works. Then record only the outcome: old route retired, new route verified, fallback tested, and next rotation review date.

• Main ingest: updated encrypted SRT source.
• Backup ingest: independent device or conservative route.
• Cloud OBS: public fallback while repair happens.
• Destination layer: unchanged platform outputs managed centrally.
• Handoff: owner, approved channel, test evidence, and cleanup status.

Other resources

These primary sources cover current SRT encryption and access-control behavior. Confirm the exact field names and supported settings in the firmware or app that produces your real stream before changing production credentials.