End-to-end encrypted self-hosted video meetings

When end-to-end encrypted self-hosted video meetings are worth the trade-offs

If your board, legal or patient calls carry information that must stay unreadable to the server operator, transport encryption alone is not enough. On Jitsi Meet, end-to-end encryption is available for audio, video and screen sharing in supported clients, but it disables features such as chat and polls, so turning it on is a deliberate trade, not a default you get for free. Per the Jitsi documentation, all Jitsi Meet media is already encrypted on the network with DTLS-SRTP, which protects it between each participant and the videobridge. End-to-end encryption goes further by keeping the keys with the participants, so the bridge relays media it cannot decrypt. Confirm the supported browser and client list against the Jitsi security and privacy page before you write it into a policy.

For this use case, Jitsi Meet is the platform to evaluate, because it is the open-source option that offers end-to-end encryption at all. BigBlueButton is not covered in this section, and its suitability for these calls should be assessed separately. The platform choice matters less than the sensitivity of the meeting itself. A board call on a merger, a privileged legal discussion and a clinical consultation do not all need the same controls, and the design should start from what each meeting type must protect, who joins it, and which features the participants actually need. Ask your legal, clinical and governance owners to classify meeting types first, then decide which ones accept disabled chat, polls and server-side recording.

Once the classification is agreed, plan the controls that surround the encrypted media. Encryption protects content in transit and in the relay, but it does not decide who gets into the room. Expect to combine it with authentication through JWT tokens or another method your identity team already runs, plus lobbies that let a moderator admit each guest, and a separate guest domain for external participants. Be clear with stakeholders that end-to-end encrypted sessions do not remove the need for audit records of who joined, and that any recording must be handled under its own policy. Your implementation partner should show how these settings are applied and tested in your environment before any sensitive meeting goes live.

Which confidentiality and access requirements shape the meeting design

This table maps each confidentiality and access requirement to the build decision it forces and the point where counsel or compliance must confirm the design. Read it as a checklist: the regulatory rows set the evidence you need, and the technical rows show where end-to-end encryption stops and other controls must take over.

Requirement or control	What it means for the build	What to confirm with counsel or compliance
HIPAA 45 CFR 164.312(e)(1), transmission security	Protect ePHI in transit across the network. DTLS-SRTP covers media transport, but chat, polls, file shares and recordings need their own protections.	Whether transport encryption alone satisfies your risk analysis, and which non-media channels carry ePHI.
HIPAA 45 CFR 164.312(b), audit controls	Log room creation, authentication events, moderator actions and recording access. Jitsi end-to-end encryption does not produce these logs on its own.	Which events must be recorded, where logs are retained, and who reviews them.
SEC Rule 17a-4(b)(4), communications retention	If chat, transcripts or recordings are kept as business communications, they need a storage and retention path outside the meeting itself. Plan for at least three years where the rule applies.	Whether meeting content is a business record for your firm, and whether end-to-end encryption blocks the copy you must preserve.
DTLS-SRTP transport encryption	Jitsi encrypts audio and video on the network by default. Media still passes through the videobridge in the standard mode, so the server operator can technically access it.	Whether a bridge-visible media path is acceptable for the meeting category, or whether end-to-end mode is required.
End-to-end encryption scope	Available in Chromium 83+ browsers and the Jitsi Electron client for audio, video and screen sharing. Chat and polls are not covered, and mixed clients may lose the mode.	Whether every participant can use a supported client, and whether a separate, encrypted channel will carry chat and documents.
HTTPS certificate requirement	A proper domain certificate is required for working audio and video. Self-signed certificates cause failures, especially on mobile, so internal PKI must be trusted by every device.	Certificate authority, renewal ownership, and whether guests on unmanaged devices can connect.
JWT-based authentication	Use JWT tokens for moderators and members, with a separate anonymous domain for guests. The older secure domain method is deprecated for new installations.	Who issues tokens, how identity is verified, and how room access is revoked when a board member or clinician leaves.
Lobby and guest access for patients or external counsel	Lobbies hold guests until a moderator admits them. Guests from outside the identity system need a defined admission and recording policy.	Admission procedure, identity checks before entry, and whether guest participation is permitted in privileged sessions.

How Jitsi end-to-end encryption works in practice

Every Jitsi Meet call already encrypts audio and video on the network with DTLS-SRTP, which protects media between each participant and the videobridge. End-to-end encryption (E2EE) is a separate, opt-in layer that adds protection for audio, video and screen sharing so that the videobridge carries media it cannot decrypt. The consequence is operational: when E2EE is on, the encryption keys must reach participants through a path the server does not control, either out of band before the call or through the client's key exchange flow. Decide before you pilot who distributes keys, how they are rotated for each meeting, and what happens when a participant joins late or rejoins after a dropped connection.

E2EE is available in Chromium 83 or newer browsers and in the Jitsi Electron desktop client, and it covers audio, video and screen sharing. It does not cover chat or polls, which means meeting text can still pass through the server in the clear. For board, legal or patient calls, treat chat as a separate data path and either disable it for those meetings or move written discussion to a system with its own controls. Confirm the current browser and client matrix against the Jitsi security and privacy page before you write it into a policy, since support can change between releases.

Verify key handling and participant limits in your own tests rather than relying on a general statement. Run a meeting with the largest group you expect, include a mobile browser, a participant who reconnects mid-call, and a guest who joins through a link, and confirm that every endpoint reports encryption active. Record the results with the Jitsi version you deployed, because E2EE behavior at higher participant counts and on older clients is the detail most likely to differ from the vendor description in your environment.

Which browsers and clients support end-to-end encryption

Jitsi's security documentation states that end-to-end encryption is available in Chromium 83 and later browsers. In this category, the encrypted scope covers audio, video and screen sharing. Chat and polls are not part of the encrypted scope, so a participant who relies on in-meeting chat should treat that text as outside the protection. Transport encryption still applies to every session, since all Jitsi Meet audio and video is encrypted on the network with DTLS-SRTP. The browser version is the control point, so the platform team should confirm the exact version floor and any per-platform caveats in the current Jitsi documentation before setting a standard.

Covered scope: audio, video and screen sharing for participants who join in a supported Chromium-based browser.
Excluded scope: in-meeting chat and polls, which stay outside the end-to-end encrypted path.
Version floor: Chromium 83 or later. Older builds and other engines are not covered by this statement.
Transport layer: DTLS-SRTP still protects media in transit between each participant and the videobridge, whether or not end-to-end encryption is active.
Enrollment: managed browser builds can pin the version so that users cannot fall below the floor.

Confirm the current version floor and any operating system notes against the Jitsi documentation before you publish the standard to users.

Which platforms fit encrypted meetings and why

Encrypted meetings depend on a platform that documents end-to-end encryption and also supports the identity and access controls that sensitive calls require. The cards below cover the primary fit, the feature trade-offs that E2EE introduces, and the checks to run before you commit to any alternative.

Jitsi Meet as the primary fit

Jitsi Meet documents end-to-end encryption for audio, video and screen sharing, and its Apache-2.0 license lets you host it inside your own infrastructure. The current stable tag is stable/jitsi-meet_11248, published September 14, 2026. Confirm that the build you deploy includes the E2EE capability on the browsers and clients your participants actually use before you plan around it.

Authentication options for sensitive rooms

The Jitsi Docker guide lists internal XMPP accounts, JWT tokens, LDAP, Matrix user verification and a hybrid Matrix plus JWT mode, all set through the .env file. For board or legal calls, JWT tokens are the option the Jitsi handbook recommends for new installations, and it pairs them with a separate anonymous domain for guests. Test which combination your identity provider can support before you finalize the design.

Lobby-capable Docker deployment

The official Docker setup runs separate web, prosody, jicofo, jvb, jigasi and jibri containers, and since stable-11146 the containers run rootless with read-only filesystems. Lobbies and moderator controls sit on top of this stack, so confirm in your test environment that the lobby behaves as your meeting policy requires. Plan for the separate jibri container if recording is also in scope, since recording adds its own storage and retention questions.

Chat and polls disabled by E2EE

In Jitsi, end-to-end encryption covers audio, video and screen sharing but not chat or polls. Board packs, legal discussions or patient questions that move through in-meeting chat will fall outside the encrypted channel. Decide early whether those interactions move to a separately governed tool, and document that decision in the meeting policy so participants know where each conversation is protected.

BigBlueButton and other alternatives

This page does not cover BigBlueButton or other open-source meeting options, so do not assume they offer the same encryption model. Their fit depends on needs such as chat, polls, breakout rooms and classroom features, where E2EE may change what is available. Treat any alternative as an open question until its vendor documentation confirms E2EE behavior for each feature you require.

Feature parity checks before selection

Before you select any platform for encrypted calls, ask the vendor or implementation partner to demonstrate E2EE with your browsers, mobile devices and desktop clients. Confirm which features stay available, which are disabled, and how guests join without breaking encryption. Record the answers in your requirements so auditors and board members can see why a given platform was chosen for sensitive meetings.

How to combine token authentication, lobbies and guest access

The Jitsi handbook marks the older secure domain method, where room creation is protected by a username and password, as deprecated for new installations and recommends JWT token authentication instead. Under that model, staff join with a signed token that identifies them and grants moderator rights, while guests use a separate anonymous domain. Keep the two apart in your Docker .env configuration so that an anonymous guest cannot be promoted to moderator by any configuration slip. Confirm in your own build which authentication and anonymous domain settings the release you deploy supports, because the option names and defaults can change between releases.

The Docker guide lists internal XMPP accounts, JWT tokens, LDAP, Matrix user verification and a hybrid Matrix plus JWT mode, all set through the .env file. For board, legal or patient calls, choose one model per meeting class and document it. JWT suits calls where your identity provider or portal issues the token and the room list is controlled by you. LDAP fits organizations that already manage staff in a directory and want group membership to decide access. Matrix verification suits teams that already run Matrix for chat. The hybrid mode adds complexity, so use it only when a real need for both identity sources exists and your tests cover both paths. Record the choice in your access policy so auditors can trace who could enter each class of meeting.

Lobbies and admission are where end-to-end encryption and access control meet in practice. Define one rule for who may admit a participant: for example, only a named moderator in the staff token admits external parties, and no guest can admit another guest. Test that rule with real accounts, a guest device and an unauthenticated browser. Verify lobby behavior yourself, including whether waiting participants can see or hear the room, whether a lobby is enforced when end-to-end encryption is on, how a rejected guest is handled, and how the lobby behaves on the mobile and Electron clients you support. Vendor documentation describes intent, not your deployment, so the test results in your environment are the evidence you keep.

Deployment components for a private encrypted Jitsi service

A private Jitsi deployment is several cooperating services, not one application, and each one affects whether end-to-end encryption works and who can join a call. The cards below cover the core components, the container layout, the certificate and port requirements, and the recording decision that sits outside the encrypted scope.

Web server in front of the app

A web server, either nginx or Apache, serves the Jitsi web application and terminates HTTPS for every participant's browser. It is the only component most users ever reach directly, so it is where your certificate, access logging and hardening settings live. Check that the web server configuration follows the vendor quick start for your distribution and that you own the renewal process for the certificate.

Prosody XMPP signaling server

Prosody is the XMPP server that handles signaling and user accounts for the meeting service. Authentication choices made in the environment file, including internal accounts, JWT tokens or LDAP, are enforced here. Confirm where room and account data is stored and backed up, because it determines what must be restored if the host fails.

Jicofo conference focus

Jicofo is the conference focus component that creates conference rooms, assigns participants to videobridges and manages room state. It is the component to watch when rooms fail to create or when lobby and moderator rules behave unexpectedly. Ask your partner how Jicofo's logs are retained and monitored, since they are the first evidence you will need when a meeting access question comes up.

Jitsi Videobridge media routers

Videobridges carry the audio and video streams between participants, and they are the components that scale out by adding more hosts. Under end-to-end encryption, the bridge forwards media it cannot decrypt, so its capacity planning is separate from the security decision. Confirm the CPU and memory sizing for each bridge with your partner based on expected concurrency, not the defaults alone.

Docker layout and rootless operation

The official Docker setup splits the service into separate web, prosody, jicofo and jvb containers, with jigasi and jibri available as optional additions. Since release stable-11146, the containers run rootless with read-only filesystems, which narrows what a compromised container can change. Confirm the release you deploy includes this behavior and plan how you will pin, test and roll forward image versions.

HTTPS certificate and ports

A certificate issued for your real domain is a hard requirement for working audio and video, and self-signed certificates cause failures, especially on mobile clients. Open 80/TCP and 443/TCP for the web app, and 10000/UDP for media. Port 5349/TCP serves as a TCP fallback and 3478/UDP for STUN is optional, so confirm with your network team whether your firewall and users need them.

Jibri recording sits outside encryption

Jibri adds recording and streaming, but it is a separate decision from end-to-end encryption. A recorder joins the meeting to capture it, so recorded media is not protected by the same end-to-end guarantee and must be governed by its own storage, access and retention rules. Decide whether recording is needed for each meeting type before you deploy it, and document the storage location and deletion process.

How an encrypted meeting service moves from pilot to production

This sequence turns an end-to-end encrypted Jitsi Meet idea into a supported service by classifying meetings first, proving the build in a lab, and only then opening it to a named pilot group and production users. Each phase closes with a written output that the next phase depends on.

Classify meetings and set encryption requirements
Counsel, the board secretary, clinical or practice leads and the CISO agree which meeting types must be end-to-end encrypted, which can use standard transport encryption, and which must never run in a browser. The team records who may join, whether guests are expected, and whether recording is prohibited. The output is a signed meeting classification matrix. Work is done when every meeting type has an encryption level and an owner. Confirm with the business owners that end-to-end encryption does not cover chat or polls, so those features need a separate decision.
Build the lab on a supported host
The platform engineering team installs Jitsi Meet on a host running Debian 12 (Bookworm) or newer, or Ubuntu 24.04 or newer, with OpenJDK 17 as the Java runtime. They open ports 80/TCP, 443/TCP and 10000/UDP, and decide whether 5349/TCP and 3478/UDP are needed for fallback. A proper domain certificate is installed from the start, because the Jitsi handbook states that self-signed certificates cause audio and video problems, especially on mobile. The output is a reachable lab instance with a valid certificate and a documented build record that pins the Jitsi Meet release.
Configure authentication and lobbies
The identity team selects an authentication method. JWT token authentication is the method the Jitsi handbook recommends, and the older username and password secure domain is marked deprecated for new installations. The team configures a separate anonymous domain for guests and enables lobby rooms so that a moderator admits each participant. Options such as LDAP or Matrix user verification are configured in the .env file, and the team confirms which one matches the identity source. The output is a test matrix showing that members authenticate, guests wait in the lobby, and unauthenticated users cannot create rooms.
Standardize clients and test encryption
The team sets a supported client list. End-to-end encryption is available in Chromium 83 or later browsers and the Jitsi Electron client for audio, video and screen sharing, so other browsers are excluded from encrypted meetings unless testing proves otherwise. Testers run the same scripted call on each client, confirm the encryption indicator, check that chat and polls are blocked or handled as a documented exception, and verify device, screen sharing and mobile behavior. The output is a client standard and a signed test report. Confirm current browser behavior in the target versions before publishing the list.
Test security and capture evidence
An independent or internal tester reviews the lab against the agreed classification. The work covers the certificate chain, the exposure of the Prosody, Jicofo and videobridge services, access controls on the admin interfaces, logging of room creation and admission decisions, and whether the deployment meets the audit controls needed for the regulated meeting types. Findings are logged with owners and fixed or accepted in writing. The output is a security test report and an evidence folder mapping each control to a configuration file, a test result and a date. Evidence supports an assessor's review, but DeployOpen does not issue audit reports or certifications.
Run a pilot with a named group
The team opens the service to one named group, such as a board subcommittee or a legal team, for a fixed period agreed in advance. Pilot users follow the client standard, use JWT-backed accounts and join through the lobby. The operations team watches connection quality, failed joins and fallback behavior across networks that users actually use, including remote sites behind restrictive firewalls. Feedback is collected in a log. The output is a pilot report listing incidents, user issues and the go or no-go recommendation. The pilot is complete when the sponsor signs that recommendation.
Cut over to production and hand off the runbook
The team moves the approved configuration to production with a change record, a rollback plan and a tested certificate renewal process. Monitoring, backups of configuration and the upgrade procedure are switched on. The runbook covers onboarding and offboarding of users, how JWT signing keys are rotated, how Jitsi Meet releases are tested before upgrades, and who responds to incidents. The output is a production sign-off, a handoff session with the operations owner and a versioned runbook. Confirm which party will own upgrades and support after handoff, and whether that is in-house, a partner or a retainer.

What auditors and regulators ask for from encrypted meetings

This table maps each evidence area an assessor is likely to request for encrypted meetings to the component that produces it and the record to prepare. Read it as a checklist of what to collect before an assessment, not as a statement that any control is met. DeployOpen prepares evidence and documentation for these areas but does not issue audit reports, attestations or certifications.

Evidence area	What to produce	Component that generates it	Where teams usually fall short
TLS and certificate configuration	Current certificate chain for the meeting domain, protocol and cipher settings, and renewal records	Reverse proxy configuration and certificate store, plus Jitsi web server settings	Self-signed or internal certificates that break audio and video on mobile clients, and no record of renewal dates
Authentication configuration	Documented choice of authentication method, JWT settings, issuer and audience values, and the separate guest domain	Jitsi .env configuration, JWT token issuer, and the identity provider behind it	Use of the deprecated secure domain method, or undocumented changes to the token issuer
JWT issuer controls	Who may issue tokens, signing key ownership, token lifetime, and key rotation history	JWT issuer service and its key management system	Shared signing keys, no rotation record, or tokens that grant moderator rights without review
Access logs for joins and admissions	Timestamped records of who joined each room, who was admitted from the lobby, and which guests were let in	Jitsi Prosody and Jicofo logs, reverse proxy access logs, forwarded to the SIEM	Logs kept only on the container, short retention, or no link between a token identity and a join event
Meeting classification and client standard	Written classification of each meeting type, the clients allowed for it, and which meetings must use end-to-end encryption	Internal policy, meeting classification register, and client approval list	No mapping from sensitive meeting types (board, legal, patient) to an approved client, so E2EE is assumed rather than enforced
E2EE test records by client	Test results showing end-to-end encryption is active for audio, video and screen sharing on each approved browser or client, with the test date and build	Test plan executed against the Jitsi build in use, with screenshots or session evidence	Tests run once at go-live with no retest after upgrades, and no confirmation that chat and polls are excluded from E2EE
Retention for recordings and chat	Retention periods for any recording or chat, deletion procedure, and storage location	Storage system for recordings, Jibri or chat service configuration, and records retention schedule	Recordings written to default locations with no deletion schedule, or chat content that falls outside the retention policy

What do buyers ask before hiring help with encrypted video meetings?

How much more effort do encrypted meetings add compared with standard Jitsi?

Encrypted meetings add design and testing work, not a different server stack. Jitsi's end-to-end encryption covers audio, video and screen sharing in supported clients, but it turns off some features, so the work is mostly deciding which meeting types need it and testing each one against the features people expect. Expect extra effort in three places: confirming which browsers and the Jitsi Electron client your users run, writing rules for when a meeting uses encryption, and checking that chat, polls and any recording or dial-in workflows still behave as the policy assumes. The baseline deployment still needs HTTPS with a proper domain certificate, because the Jitsi handbook says self-signed certificates cause problems for audio and video. Ask any partner to list the features that are disabled in encrypted mode and to show a test plan for each one.

Can our team build encrypted Jitsi meetings without a partner?

Yes, if your team has Linux operations, container experience and someone who can own identity and certificates. The Jitsi quick start targets Debian 12 or newer and Ubuntu 24.04 or newer, requires OpenJDK 17, and needs ports 80/TCP, 443/TCP and 10000/UDP open. The official Docker setup separates web, prosody, jicofo, jvb, jigasi and jibri into containers, so there are more moving parts to patch and monitor. Most internal teams underestimate the parts that are not in the quick start: authentication design (internal accounts, JWT tokens, LDAP or the Matrix options), a separate guest domain, load testing, upgrade routines and documented evidence for auditors. A partner can help with those as a fixed-scope engagement, while your staff keeps day-to-day ownership.

What drives the cost of an encrypted meeting deployment?

Cost depends on scope and the number of people who must be supported, not on the encryption switch itself. The main drivers are identity integration (connecting JWT, LDAP or Matrix-based sign-in to your existing directory), client standardization (how many browser and device combinations you must support), testing (functional, network and load testing across office, remote and guest scenarios), hosting (central server and videobridge capacity, and any TURN capacity for users behind firewalls) and support after go-live. One-time costs cover design, build and testing. Recurring costs cover hosting, certificate renewal, patching, upgrades and support retainers. DeployOpen does not publish prices, so ask for a quote built from a written scope that lists each of these drivers separately.

How long does a pilot take, and what does it need from us?

A pilot length is set in the written scope, after the team confirms the requirements, so ask for the timeline in the proposal rather than a generic figure. Pilots move fastest when you provide named owners for identity, networking and the business process, a set of test users in each role (host, participant, guest), a valid certificate for the meeting domain, and network access for the test servers, including the UDP port used for media. If your network blocks UDP, plan for the TCP fallback on 5349 and confirm how users behind strict firewalls will connect. Ask the partner to list these inputs in the scope so delays are visible early.

Can we keep chat and polls in an end-to-end encrypted meeting?

Not with the supplied Jitsi encryption scope. Jitsi's end-to-end encryption is available for audio, video and screen sharing in Chromium 83 or newer browsers and the Jitsi Electron client, but not for chat or polls. If your policy requires encrypted chat, plan a separate channel for it, such as an encrypted team chat platform, and document that in the meeting procedure. Also confirm how participants on unsupported browsers will join, because they cannot use encryption, and decide whether those meetings are allowed for the sensitive call type at all.

Does a self-hosted encrypted meeting guarantee HIPAA compliance?

No deployment guarantees HIPAA compliance. HIPAA is an obligation on the covered entity or business associate, and the relevant technical requirements include guarding against unauthorized access to ePHI sent over a network (45 CFR 164.312(e)(1)) and audit controls that record and examine activity in systems containing ePHI (164.312(b)). Encryption supports the first requirement, but the rest depends on access control, logging, retention, business associate agreements and policies that are your responsibility. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do. Ask a partner to map each control to the evidence it will produce.

Who is responsible for keeping encrypted meetings working after go-live?

Responsibility is shared, and the split should be written down before go-live. Your team usually owns user accounts, meeting policy and the decision about which meetings must be encrypted. The operator owns patching, certificate renewal, Jitsi upgrades, backups and monitoring of the central server and videobridges. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, which you can scope separately from the build. Ask for a runbook, an escalation path and an upgrade calendar that avoids scheduled sensitive meetings.

What to ask an implementation partner before encrypting sensitive meetings

Start by asking how the partner confirms that end-to-end encryption is actually active for each participant. Jitsi's E2EE covers audio, video and screen sharing in Chromium 83+ browsers and the Jitsi Electron client, and it does not cover chat or polls. Ask for the test method: which browsers and client versions were checked, how the partner verified the encryption indicator on each one, and what happens when a participant joins from an unsupported client. Ask how the partner has tested JWT token rules and lobby behavior, including a token with the wrong room or expired lifetime and a guest joining through the anonymous domain. Ask for written results, not a statement that the controls work.

Ask how they handle certificates and mobile clients. The Jitsi handbook says a proper domain certificate is necessary for working audio and video and warns that self-signed certificates cause problems, especially on mobile. Ask who issues and renews the certificate, whether an internal CA is trusted on managed devices, and how a lapsed certificate would be detected before a board or patient call. Ask how they will document the feature loss for users, including the absence of encrypted chat and polls, and where that notice appears. Ask how the Jitsi version stays current with security updates, who watches the release channel, how patches are tested in a staging environment, and how a patch window is agreed around sensitive meetings.

Finally, ask for the evidence package and the handover model. Request configuration exports, the test records for E2EE, JWT and lobby checks, and change logs, and confirm that DeployOpen prepares evidence for assessments but does not issue audit reports or certifications. Ask who holds the signing keys for JWT tokens, who administers LDAP or internal XMPP accounts after handover, and how access is removed when a board member or clinician leaves. The named owner for key and identity administration should be agreed in the written scope before work starts, not discovered after go-live.

How DeployOpen scopes and supports encrypted Jitsi deployments

DeployOpen plans, implements, hardens, documents and supports self-hosted Jitsi Meet inside your own cloud accounts, data centers or air-gapped networks. For end-to-end encrypted meetings, the work starts with deciding which meeting types truly need the encrypted mode, because that choice changes browser rules, features and authentication design.

How we scope

Engagements are fixed-scope, with the list of meeting types, clients and browsers agreed in writing first.
The written scope names which meetings use end-to-end encryption and which stay on standard transport encryption.
We document the features the encrypted mode disables, such as chat and polls, and how users will handle them.
The scope states the authentication model, lobby rules and guest handling for board, legal or patient calls.
Scope also covers certificate ownership, firewall ports and the hosting location of media servers.

How we build

We deploy the Jitsi Meet components, including the web server, Prosody, Jicofo and Videobridge, in your environment.
Configuration covers JWT token authentication with a separate anonymous domain for guests, where the design calls for it.
We set up HTTPS with a certificate from your trusted authority, since self-signed certificates break mobile audio and video.
We test encrypted sessions across the browsers and clients you approve, and record the results for each one.
Lobby, moderator and room-access settings are tested against the approved access matrix before go-live.

How we hand over

Handover includes configuration records, network diagrams, port inventories and the approved browser support list.
We provide user guidance that explains when encryption is on, and what participants lose in that mode.
Runbooks cover certificate renewal, backups, upgrades and how to add videobridges when meeting load grows.
Compliance teams receive evidence packs that show configuration state and test results for their assessors.
DeployOpen prepares this evidence but does not issue audit reports, attestations or certifications.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover scheduled upgrades timed around board calendars, legal deadlines or clinical hours.
Periodic security testing of the meeting platform, including authentication and access controls, can be added to the retainer.
Support requests are routed through agreed channels, with the response expectations written into the retainer.
Your team should confirm which support tier, hours and escalation paths apply before signing.