🛡️

EPIC Cybersecurity: Who Secures What

Quick Reference QR-AE-017 · Audio Enhancement EPIC · Rev 1.1 · Oct 2026

A one-look summary of how Audio Enhancement secures EPIC, what the district is responsible for, and the first ten things to do.

📄 View or download this guide as a PDF

Click the PDF icon below to open it right here in your browser. In the viewer, use Download (top right) to save a copy, or the printer icon to print it.

🤝

Written by: Brad Roy, VSC Director of Operations · Verified against: AE EPIC Cybersecurity Model Overview DC-41261.0726; Cybersecurity Framework Mapping DC-41262.0726; Public Internet Access DC-41231.1125 · Applies to: EPIC 3.x on-premises systems · aligned to NIST CSF 2.0 and OWASP Top 10:2025

EPIC runs on the district's own network and doesn't need the internet for its core features. That keeps it working during an outage and removes the cloud as an attack path, but it means security is shared: Audio Enhancement secures the application; the district secures the environment around it.

Audio Enhancement secures the application	The district secures the environment
No root or OS access for customers, vendors or users; AE's own access is MFA-protected Unique credentials on every system; no default "backdoor" logins Encryption at rest and in transit (TLS 1.3; 1.2 for compatibility); signed, encrypted updates and backups Hardened OS with unneeded services and ports turned off Rate limiting and account lockout; role-based access; SSO support Secure development, code review and annual third-party penetration testing CVE monitoring, incident response and service bulletins to the maintenance contact	Network segmentation and firewall rules (only the documented ports and hosts) Blocking student and public networks from EPIC Physical security of the server room or closet Credential management: change shipped passwords, no sharing or reuse, remove departed staff Patching the host (for a district VM) and applying EPIC updates when notified Backups to a district-owned share, and testing restores Optional: SSO with the district's identity provider

Audio Enhancement secures the application

The district secures the environment

No root or OS access for customers, vendors or users; AE's own access is MFA-protected
Unique credentials on every system; no default "backdoor" logins
Encryption at rest and in transit (TLS 1.3; 1.2 for compatibility); signed, encrypted updates and backups
Hardened OS with unneeded services and ports turned off
Rate limiting and account lockout; role-based access; SSO support
Secure development, code review and annual third-party penetration testing
CVE monitoring, incident response and service bulletins to the maintenance contact

Network segmentation and firewall rules (only the documented ports and hosts)
Blocking student and public networks from EPIC
Physical security of the server room or closet
Credential management: change shipped passwords, no sharing or reuse, remove departed staff
Patching the host (for a district VM) and applying EPIC updates when notified
Backups to a district-owned share, and testing restores
Optional: SSO with the district's identity provider

1️⃣ At deployment (critical)

#	Action
1	Change every credential that shipped with the system. Don't run production on shipped passwords.
2	Set an accurate maintenance contact in EPIC (Settings › System Settings › School) so security bulletins reach someone.
3	Allow only AE's documented Ports & Services through your firewalls (listed below this table; full checklist in QR-AE-015).
4	Block student and guest networks from reaching EPIC at the network level.
5	Lock the server room or closet.
6	Turn on EPIC's daily or weekly backup to a district-owned, access-controlled share.

Ports & Services (action 3): EPIC › devices TCP 80, 554, 12302, 12303 and UDP 4444, 5004, 5060 · devices › EPIC TCP 2786, 8020, 8081 and UDP 123, 5004, 5060 · staff PCs, kiosks, phones › EPIC TCP 80, 443, 3000, 3355, 3357, 3690, 4000, 4001, 4690, 5004, 8009, 8010, 8015, 8016, 8080, 8089, 8090, 9001, 9003 · audio (RTP) UDP 10000–20000 · optional mDNS for device discovery. Outbound from the EPIC server only (HTTPS 443): licensing.audioenhancement.com; canonical.com, security.ubuntu.com, us.archive.ubuntu.com (TCP 80 and 443) and registry.npmjs.org for upgrades; ntp.ubuntu.com and pool.ntp.org (UDP 123) unless you have internal NTP; ae-support.screenconnect.com and instance-ioy0tx-relay.screenconnect.com for AE remote support.

2️⃣ Ongoing

#	Action	How often
7	Apply AE-recommended updates when a service bulletin arrives. Treat critical bulletins as urgent. Consider turning on automatic OS security patches (Settings › System Settings › Network › Manage Automatic Updates).	As notified
8	Credential hygiene: no sharing, no reuse, periodic rotation. Consider SSO (QR-AE-018).	Ongoing
9	Monitor traffic to and from EPIC against the Ports & Services baseline.	Continuous
10	Test a backup restore.	At least yearly

⚠️

Never expose EPIC to the public internet. It isn't built for internet-facing use, and AE's terms prohibit it. If the district opens it up anyway, the district accepts all the risk. Use a VPN for off-site access, and if a third-party integration needs outside access, open only that port and only to that vendor's known addresses.

🔧

VSC note: For a district security review or procurement questionnaire, ask VSC for AE's detailed Cybersecurity Framework Mapping (NIST CSF 2.0 and OWASP control references and a shared-responsibility matrix). VSC installs and configures EPIC; the district remains responsible for its network and credentials after hand-off.

📚 Sources & credits

Compiled by Brad Roy, VSC Director of Operations
Audio Enhancement: EPIC System Cybersecurity Model Overview DC-41261.0726; EPIC Cybersecurity Framework Mapping and Control Reference DC-41262.0726 (controls, shared responsibility, recommended district actions); EPIC Public Internet Access DC-41231.1125
Menu paths checked on VSC's EPIC 3.2.5 demo server, 10/9/2026. Replaces AE's older Shared Responsibility Security Model DC-40918.01.