BigBlueButton security hardening guide

BigBlueButton security hardening starts with a wide media port range

Hardening a self-hosted BigBlueButton server means controlling which TCP and UDP ports are open, protecting the shared secret that authorizes every API call, enforcing TLS, and locking down recordings and the Ubuntu host. This is harder than it looks. The required UDP range is wide, the shared secret is effectively a root credential for the API, Greenlight and LTI integrations add secrets of their own, and recordings hold student data. If you are about to expose a server for classes or meetings, make these decisions before the first user connects.

Start with the network. BigBlueButton needs TCP ports 80 and 443 and UDP ports 16384 to 32768 to be reachable. The TCP ports are familiar to most administrators. The UDP range is the part that surprises teams, because it carries the audio and video media for every session and spans 16,385 ports. Do not open it to any source by default. Write each rule with a stated purpose, record it in your change log, and confirm with the vendor's install documentation which traffic must reach which port. Then test from outside your own network, not only from inside it.

Two prerequisites shape the port and certificate plan. SSL requires a valid hostname, so set and verify DNS before you request certificates and before you open ports to the internet. Docker is also required for sandboxed LibreOffice document conversion, which makes it one more service on the host to include in your exposure review. If you add a TURN server for users behind restrictive firewalls, which the documentation recommends, it changes the port picture, so repeat the port check after that change.

BigBlueButton 4.0 installs on Ubuntu 24.04 64-bit, and direct upgrades from 2.6, 2.7 or 3.0 are not supported, so a clean server installation is recommended. Treat that as a hardening advantage: build the firewall rules, TLS settings and host baseline on a fresh machine rather than carrying over settings from an earlier version. Ask your installer or internal team to document each open port, certificate source, Docker role and host update policy. Those records are the evidence an auditor or internal reviewer will ask for, and they are easier to produce now than after go-live.

Which BigBlueButton parts face the network and need controls

A BigBlueButton server exposes web, media, relay and file surfaces, and each one needs its own control. The cards below list what each part exposes and the control to apply, so you can confirm the open ports, secrets and storage locations in your own environment before go-live.

Web front end on TCP 80 and 443

The web front end serves the browser client and the API over TCP 80 and 443, and it needs a valid hostname for SSL. Only these two ports should be open for web traffic. Confirm that plain HTTP on port 80 is handled in a way that sends users to HTTPS, that the TLS certificate is issued for the exact hostname users type, and that administrative interfaces are not published on the same public address.

Media path on UDP 16384 to 32768

Audio and video travel over UDP 16384 to 32768, and clients must reach this range directly for the media path to work. Open this range only on the BigBlueButton host and keep every other inbound port closed at the firewall. Check the firewall rules after each update, because a rule written for one port range is easy to widen by mistake when media troubleshooting begins.

TURN relay for restrictive networks

The install documentation recommends a TURN server for users behind restrictive firewalls, which relays media when a direct path is blocked. A relay is a second internet-facing service with its own ports and credentials. Confirm which relay ports and address ranges your configuration opens, require authenticated access to the relay, and decide whether it runs on the BigBlueButton host or on a separate machine with its own patching schedule.

Greenlight or LTI integration holding the secret

Greenlight or an LTI connection is the point where users sign in and where the shared secret is configured so the front end can call the BigBlueButton API. Whoever can read that configuration can create and join meetings. Confirm where the secret is stored, who can read the Greenlight or LMS configuration, and whether Greenlight's external authentication is set up for the sign-in method your organization uses.

Shared secret and API checksum algorithm

Every BigBlueButton API call carries a checksum computed from the shared secret. The API documentation describes SHA-256 as the default, SHA-1 for legacy use, and SHA-384 or SHA-512 available since version 2.5. Choose the strongest algorithm that your integrations support, retire SHA-1 wherever the integrations allow it, and never place the secret in a web page, where any visitor could read it.

Docker for LibreOffice conversion sandbox

BigBlueButton needs Docker to run LibreOffice document conversion in a sandbox, so uploaded slides are processed outside the main services. The Docker daemon is a privileged component on the host, and users who can control it can usually gain root access. Confirm that Docker is installed as the documentation requires, keep it patched with the host, and limit which administrative accounts belong to the Docker group.

Which hardening decisions shape the server design

This table compares the server design choices that hardening changes, with the conditions where each option fits and the operational work it adds. Read each decision on its own, then confirm the inventory of clients, networks and integrations in your environment before choosing. The main takeaway is that any option that narrows access or raises checksum strength needs that inventory first.

Decision	Option	When it fits	Operational cost
UDP 16384 to 32768	Open to all sources	Public or mixed audience meetings where users connect from unknown networks	Simplest for users, but the host firewall and call monitoring carry the main control
UDP 16384 to 32768	Restrict to known networks	Campus, VPN or partner networks with a fixed list of client sources	Smaller exposure, but the allow list needs upkeep as users change networks
TURN placement	Same host as BigBlueButton	Small deployments with light relay demand and a single server	One host to patch and monitor, but relay traffic shares CPU and bandwidth with media
TURN placement	Separate host	Users behind restrictive firewalls at higher volume, or relay load that must be isolated	Second host to patch, firewall, certificate and monitor; confirm the required ports
API checksum algorithm	SHA-256 default	New installations and integrations that accept the default	Lowest compatibility risk; confirm every LMS plugin and script uses the same setting
API checksum algorithm	SHA-1 retained for legacy clients	Older integrations that cannot yet send stronger checksums	Keeps old clients working, but a weaker algorithm stays enabled and needs a dated removal plan
API checksum algorithm	SHA-384 or SHA-512 required	Integrations confirmed to support them, which the docs state from version 2.5	Stronger, but each calling application must be tested before enforcement
Greenlight and LTI placement	Split to separate hosts	Separate front-end administration, or heavier user-facing load than the media server	More hosts and certificates, plus a documented process to keep shared secrets in sync
Recording storage	Separate storage	Long retention, access controls or pooled servers that need a shared volume	Access control, encryption and backup scope move to the storage tier; confirm the design

How to harden a BigBlueButton server step by step

This sequence takes a new BigBlueButton 4.0 server on Ubuntu 24.04 from installation to a hardened baseline across network exposure, TLS, TURN, API secrets, sign-in, recordings and host patching. Each step closes with a check you run before moving on, so the finished server can be tested against the same list. Record each result in the handover document.

Start from a clean Ubuntu 24.04 host
Install BigBlueButton 4.0 on a new 64-bit Ubuntu 24.04 server, because the install docs do not support direct upgrades from 2.6, 2.7 or 3.0. Confirm the host meets the documented minimums: 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, 500 GB of disk (50 GB without recording) and 250 Mbit/s symmetrical bandwidth. Choose which front ends to install, such as Greenlight or LTI support, before running the install script. The step is closed when the install completes and the server reports the 4.0.0 release.
Set the hostname and TLS certificate
Assign a fully qualified hostname that resolves publicly, because BigBlueButton needs a valid hostname for SSL. Issue a certificate for that name from a trusted authority and install it so browsers accept the connection without warnings. Confirm the name resolves from outside your network, then run an external TLS test to check the certificate chain, the protocol versions offered and the expiry date before any user joins a room.
Open TCP 80, 443 and the UDP media range
Allow inbound TCP 80 and 443 and UDP 16384 to 32768, and close all other inbound ports at the cloud security group or data center firewall and on the host. Limit SSH to administrator addresses. Confirm from an outside host that ports 80 and 443 answer and that a scan of other common ports shows them closed. Then join a test meeting with audio and video to confirm media flows over the UDP range.
Configure and test TURN from a restricted network
Configure a TURN server for participants behind restrictive firewalls, as the install docs recommend, and set its public address and credentials to match the BigBlueButton configuration. Then test from a network that blocks the UDP media range, so clients must use the relay. Confirm that a participant on that network can hear, speak, see video and share a screen. Do not move on until the restricted-network test passes from at least two client browsers.
Rotate the shared secret and set the checksum algorithm
Generate a new shared secret, store it in the server configuration and your secrets vault, and rotate it on the schedule your security policy sets. Keep SHA-256, the default, and move legacy clients off SHA-1 only after you confirm which LMS and custom integrations still send SHA-1 checksums. Search the rendered HTML and JavaScript of every integration page to confirm the secret is not embedded. Confirm that an API call with an incorrect checksum is refused.
Configure Greenlight or LTI authentication
Enable the sign-in route you chose: Greenlight v3 with external OpenID Connect, configured through environment variables, or LTI launches from the learning management system. Keycloak can bridge SAML, Microsoft or Google sign-in to Greenlight if your identity provider is not OpenID Connect. Confirm that an unauthenticated visitor cannot create or enter rooms through the front end, and that a test account from each route reaches only the rooms it should.
Lock down recording access and Docker sandboxing
Restrict the recordings directory to the service account and confirm that recording links require the correct session or authorization. Verify that Docker is running and that LibreOffice document conversion executes inside a sandboxed container. If you use a shared volume for recordings, review its mount permissions and access list. Confirm by requesting a known recording URL without a session and checking that it is refused, then uploading a test document and confirming it converts.
Apply host patches and confirm the baseline
Apply all pending Ubuntu security updates and the latest BigBlueButton 4.0 maintenance release, restart services and reboot if the kernel changes. Confirm that automatic security updates are enabled and that the update schedule is documented. Record the final BigBlueButton version, open ports, TLS result and secret rotation date in the baseline document. The step closes when the port scan, TLS test and test meeting all pass again after patching.

Shared secret, checksum and recording privacy controls

These controls cover the credentials and transport that let BigBlueButton servers and their integrations trust each other, plus the recordings they produce. The API shared secret, the checksum on each call, the OpenID Connect client secret and the TLS certificate depend on one another, so a weak link in any of them can expose meetings or recordings. Assign an owner to each control during hardening.

Treat the shared secret as a credential

The API shared secret lets any holder create, end and inspect meetings on the server. Generate it during installation, keep it only in the server configuration readable by administrators, and record which teams and integrations hold it. Rotate it after staff changes or any suspected exposure, then update every LMS plugin and Greenlight configuration that uses it. Confirm that backups and configuration repositories do not store it in plain text.

Keep the secret out of web pages

Any value placed in a web page reaches every browser that loads it, through page source, developer tools and cached copies. Calls that need the secret must run in server-side code, such as an LMS plugin or the Greenlight backend, never in client-side JavaScript or an embedded script. Review custom themes, LTI templates and reverse proxy responses for the secret or for full API URLs that contain a checksum.

Checksum on every API call

Every BigBlueButton API call must carry a checksum computed from the call name, the query string and the shared secret. The API documentation sets SHA-256 as the default, keeps SHA-1 for legacy use, and lists SHA-384 and SHA-512 as available since version 2.5. Confirm which algorithm each integration sends, and move legacy integrations to a stronger algorithm where their code allows it. Test a rejected checksum on a staging server before production.

Greenlight OpenID Connect client secrets

Greenlight v3 external authentication through OpenID Connect is configured with environment variables. The client secret belongs in the environment configuration of the Greenlight container or host, not in source code, container images or version-controlled files. Restrict read access to that configuration, confirm that the redirect URI matches the Greenlight hostname exactly, and check that startup logs do not print it. If Keycloak bridges other login methods, apply the same handling to its client secret.

TLS certificates and the valid hostname

BigBlueButton needs a valid hostname for SSL, and the certificate must match that name. Browsers connect to the same hostname for the web interface and the signaling that starts media, so a mismatch often looks like a browser or firewall fault. Confirm the full certificate chain, monitor expiry, and check the DNS record before go-live. If TURN is served over TLS, confirm its certificate and name as well. Test renewal rather than assuming it works.

Recording access, storage and retention

Recordings sit on the server disk under paths that playback components read. Limit filesystem permissions to the service accounts that need them and keep recording directories off world-readable mounts. If Scalelite pools servers with an NFS shared volume, apply the same restrictions to that volume and its export rules. Retention periods and rules for who may view a recording come from your institution's policy and privacy obligations. Your team must set and document them before launch, because the software does not decide them.

What drives hardening effort and cost in a quote

This table lists the factors that change how much hardening work a BigBlueButton deployment needs and how each one affects the quote. Read each row as a question to answer in your written scope, since effort depends on the agreed scope rather than on any fixed figure. Most of the spread between two quotes comes from integrations, network layout and whether the host already meets your baseline.

Driver	How it changes the work	How to keep it down
Number of integrations	Greenlight, LMS (LTI) connections and external identity each add authentication settings, shared secret handling and test cases for every login path.	Limit the first release to the integrations you need, and sequence identity work separately from the hardening baseline.
Number of environments	Test, staging and production each need firewall, TLS, secret and patch configuration, and drift between them has to be verified.	Build one hardened configuration as code and promote it through environments rather than hardening each one by hand.
TURN and recording storage on separate hosts	Each separate host adds its own firewall rules, TLS certificates, access controls and monitoring, and traffic between hosts must be restricted.	Keep TURN on the application server only if sizing allows, or document the inter-host rules once and reuse them.
Firewall zones and networks needing access	Each network that reaches TCP 80 and 443 or the UDP media range 16384 to 32768 needs a documented rule, and each rule needs a test.	Agree the list of source networks before work starts and restrict media ports to the ranges your users actually use.
Compliance evidence requirements	Assessors may ask for configuration baselines, change records, access reviews and log retention, which adds documentation and collection steps.	Ask early which controls your assessor expects, and agree in writing which evidence will be produced and in what format.
State of the existing Ubuntu host	A host that is not a clean Ubuntu 24.04 64-bit installation may need rebuilding, since direct in-place upgrades from earlier BigBlueButton branches are not supported.	Start from a clean installation with the required OS release, and record the current state of any host you plan to reuse.
Ongoing patch and secret rotation support	Patches on the 3.0 and 4.0 branches, host updates and shared secret rotation recur and need a scheduled process and a named owner.	Decide up front who applies updates and rotates secrets, and price the recurring work as a separate retainer item.

How to test that BigBlueButton hardening holds and fails safely

The hardening work is only useful if you can show, from the outside and from inside, that each control still holds after the server is built and after every change to it. Test the perimeter first. From a network outside your environment, scan the public address and confirm that only TCP 80, TCP 443 and the UDP media range (16384 to 32768 in the install documentation) answer. Any other open port, including the database, Redis or administrative ports, is a finding. Run the same scan from more than one vantage point if your organization has them, and confirm the results match the firewall rules you intended to deploy, not just the rules you believe are in place.

Next, test the API and the secret. Send API calls with a missing checksum, an incorrect checksum and a checksum built with an older algorithm, and confirm the server rejects each one with an error rather than processing the request. Then fetch every page the server serves, including the join and landing pages, Greenlight pages if you installed them, and the JavaScript bundles loaded by the browser, and search the responses for the shared secret. The secret must not appear in any of them. Repeat this search after every front-end change, because a customization or a plugin can reintroduce it without anyone noticing.

Test media delivery from a restrictive network. Join a session from a network that blocks direct UDP, such as a guest network or a test segment with UDP egress removed, and confirm that audio and video still flow through the TURN relay. Check the TURN logs to see that the session was relayed, and confirm that TURN credentials are time-limited or otherwise scoped as your configuration specifies. Also test document handling: upload a LibreOffice file, confirm it converts, and check that the conversion ran inside the Docker sandbox. Confirm the exact method for checking the sandbox with your platform team, since it depends on how your host is configured.

Test recording access and failure behavior. Request a recording URL while logged out, with another user's session, and with a guessed identifier, and confirm each request is refused. Then test the failure paths the hardening depends on. Let a TLS certificate renewal fail in a staging environment, and block one of the required ports, then confirm that an alert reaches an on-call person within the window your team has set. A control that breaks silently is a weakness even if the configuration is correct. Ask your security team which tools, scanners and evidence formats they require before you run these tests.

Plan to repeat this whole plan after every platform update, every Ubuntu host patch and every change to the firewall, TURN or certificate configuration. Keep the results, the commands used and the dates in a record that auditors or your own assurance team can review. Ask any partner quoting this work to state in writing which tests are included in the fixed scope, which are optional, and how retests after updates are billed or covered by a retainer.

How single server and scaled deployments change the hardening checks

On a single server, the BigBlueButton media, signaling and web tiers share one trust boundary. Greenlight or LTI integration runs on the same Ubuntu host, so a compromise of the web application or the host reaches the media services and the stored recordings directly. The hardening checks concentrate on one firewall policy, one shared secret and one recording disk.

Firewall: Open TCP 80 and 443 and the UDP range 16384 to 32768 to the internet, since no other host sits in front. Limit SSH and administrative access to named networks.
Secrets: The shared secret used for API checksums sits in the same server configuration that Greenlight or the LTI consumer depends on. Confirm which file holds it, who can read that file, and that the secret never appears in page source.
Checksums: Confirm which checksum algorithm each integration sends. SHA-256 is the default, SHA-1 remains for legacy use, and SHA-384 or SHA-512 are available since version 2.5.
Recordings: Recordings are written to local disk on the same host. Plan the recording disk, set a retention rule, and confirm how deletion and playback access are controlled.
Patching: Host and BigBlueButton updates restart the one service every user depends on, so schedule maintenance windows and test the LMS login path afterward.

Before sign-off, confirm in the install documentation which services bind to which interfaces and where Greenlight or LTI stores its configuration.

Keeping the Ubuntu host and BigBlueButton patched after hardening

Hardening starts to decay the day it is finished. Once the firewall, TLS, shared secret and TURN settings are in place, the Ubuntu host and the BigBlueButton packages still receive fixes, and each fix can change a default you relied on. BigBlueButton 4.0 runs on Ubuntu 24.04 64-bit, and the 3.0 branch continues to receive maintenance releases, such as 3.0.39 published on October 2, 2026. Treat the release page as the source for current patch levels, and confirm with your vendor or partner which branch your servers are on before you schedule any change. Direct upgrades from 2.6, 2.7 or 3.0 to 4.0 are not supported, so moving to 4.0 is a planned migration onto a clean installation, not an in-place update.

Every patch window should end with the same verification checks you used during hardening. Confirm that TCP ports 80 and 443 and the UDP media range still behave as intended, that the checksum algorithm settings are unchanged, that TLS still negotiates correctly, that the TURN server is reachable from a restricted network, and that document conversion still runs in its Docker sandbox. Keep these checks written down as a runbook with expected results, so whoever performs the update can tell a regression from a normal change. Record the outcome of each run alongside the package versions you tested, so you can show later which state was verified and when.

Credentials need their own schedule. Rotate the shared secret used to sign API checksums, and rotate integration credentials such as LMS tool keys, Greenlight OpenID Connect client secrets and any Scalelite or TURN credentials. Plan each rotation as a coordinated change, because the LMS or front end must be updated at the same time as the server. Watch TLS certificate expiry with monitoring that alerts well before the date, and confirm that automated renewal also restarts the services that load the certificate. Ask your partner how alerts reach an on-call person outside business hours, and what they cover if a renewal fails.

Review firewall rules on a fixed schedule and after any change to the network, the LMS or the TURN setup. Keep a current inventory of open ports, public hostnames, integrations and the systems that call the API, because you cannot review what you have not listed. Back up the server configuration, the database used by Greenlight where it applies, and the recording storage, and test a restore at least once. Document every decision and exception, such as a port opened for a specific network, a skipped patch with its compensating control, or an integration kept on an older setting. Those records are what an auditor or a new administrator will ask for first.

What buyers ask before hiring help with BigBlueButton hardening

How much does BigBlueButton security hardening cost?

The price follows from the written scope. DeployOpen does not publish a price list, and the quote depends on what the work covers. The main drivers are the number of servers (one server or a pool that uses Scalelite), whether TURN and recording storage are in scope, how many LMS or Greenlight integrations must be retested, the condition of the existing host, and whether you need evidence packs for an assessor. Ask for a quote that lists each item separately: firewall and port review, TLS, shared secret and checksum settings, TURN, recording access, Ubuntu patching, documentation and handover, and any follow-up testing. Hardening is mostly one-time work. Patching, monitoring and retainers recur, so ask which costs fall into each group.

How long does BigBlueButton hardening take to complete?

The timeline depends on scope and on your starting point. The number of servers, whether the host is a clean installation or an existing system, and how quickly your team approves firewall changes and a maintenance window all affect the schedule. The install documentation says direct upgrades from 2.6, 2.7 or 3.0 to 4.0 are not supported and recommends a clean server, which can add migration work if you are replacing an older host. Testing with live LMS sessions and with users behind restrictive networks also takes time. Ask for the schedule as milestones in the written scope, with your dependencies, such as access approvals and change windows, listed beside each one.

What does our team need to provide during the hardening work?

Plan for access, network owners, LMS administrators and a change window before work starts. You will need administrative access to the host and to the cloud or data center account that runs it. Someone must control DNS for the hostname used for SSL. Network owners must be able to open or review TCP ports 80 and 443 and the UDP range 16384 to 32768. LMS administrators must be available to test embedded sessions in Canvas, Moodle or other platforms you run. A change window is needed for restarts and firewall edits. Name one decision-maker who can accept the risk trade-offs that come up during the work, and confirm each responsibility in the scope document.

Can our internal team harden BigBlueButton without an outside partner?

Yes, a capable team can do the work alone if it has the skills and the time. The work needs Linux administration, firewall and TLS experience, and a test plan for media, TURN and LMS sessions. It touches many layers at once: Ubuntu patching, media port rules, TLS, shared secret handling, checksum algorithms, TURN configuration and recording privacy. Each change can break calls for users, so testing matters as much as configuration. Before you decide, answer three questions internally: who owns the server after handover, who tests LMS integrations after each update, and who collects the evidence an assessor will request. If those owners are not named, a partner's fixed scope can cover the build, documentation and handover.

Does DeployOpen issue audit reports or certifications for BigBlueButton?

No. DeployOpen does not issue audit reports, attestations or certifications. It prepares systems, controls and evidence so that independent auditors or certification bodies can assess them. Hardening work often covers areas that assessors review, such as access control, encryption in transit, logging and patch management, and the documentation can show how each control is implemented. The assessment itself is carried out by an independent party you choose. Before the work starts, ask your assessor which evidence they need, in what format, and for which period, so the work produces what the assessment requires.

Does hardening include the Greenlight or LTI integration?

Confirm this in the written scope before you sign. The BigBlueButton install script can install Greenlight or LTI support on the same server, so the integration sits on the host that the hardening covers. Front-end settings such as TLS, session behavior and room access can be part of the review. LMS connections also depend on the shared secret and checksum settings, so those changes must be tested from the LMS side as well as on the server. If you plan Greenlight v3 with OpenID Connect or Keycloak for sign-in, that is a separate piece of work. Ask whether integration testing with each LMS you use is included and who runs those tests.

What happens after a BigBlueButton server is hardened and handed over?

Ongoing work continues after handover, and it should be agreed in writing. The server still needs Ubuntu host patching, updates on the 3.0 or 4.0 branch as maintenance releases appear, retesting of LMS integrations after each update, call quality monitoring and periodic firewall review. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, so you can choose a retainer or run these tasks with your own staff. Handover should include documentation, a runbook for shared secret rotation and recording access, and a list of who receives alerts. Ask for coverage hours and response expectations in writing, because they are not set by the hardening scope itself.

Is BigBlueButton hardening a fixed-scope engagement?

Most engagements are fixed scope. DeployOpen agrees the scope, deliverables and timelines in writing before work starts. A fixed scope for hardening typically lists the servers involved, the settings to change, the tests to run, the documents to produce and the criteria that show the work is complete. Findings during the work, such as an unsupported host or an unexpected integration, can require a change request, so ask how those are priced and approved before they arise. Also ask the scope to state exclusions clearly, including recording storage design, Scalelite scaling, and single sign-on, if those are not part of the agreed work.

How DeployOpen works on this

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and BigBlueButton security hardening follows the same arc. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts, and ongoing support is available as a retainer.

How we scope

Inventory the server layout, Ubuntu host version, network path and any Greenlight or LMS integration before changing anything.
Confirm which TCP and UDP media ports are open to users, and which firewall rules sit in front of the BigBlueButton host.
Agree in writing which TLS, shared secret, checksum, TURN and recording privacy controls are in scope.

How we build

Apply firewall rules for TCP 80 and 443 and the UDP media range, then test reachability from inside and outside the network.
Configure TLS on a valid hostname, rotate and store the API shared secret outside web pages, and set the checksum algorithm policy.
Review TURN configuration for users behind restrictive firewalls and test recording access controls with a documented test plan.

How we hand over

Deliver a hardening runbook that records each setting, its reason and the command or file where it lives.
Provide a verification checklist the client team can rerun after patches, upgrades or certificate renewals.
Walk through the Ubuntu patching process and the points where an LMS integration must be retested after changes.

How we support

Offer ongoing support and patch review as a retainer, with scope agreed in writing for the BigBlueButton branch in use.
Re-run hardening checks after BigBlueButton maintenance releases and host OS updates, and record the results.
Coordinate with the client's security team for scheduled security testing of the hardened servers when they request it.

BigBlueButton security hardening