Ports Used by Microsoft Teams
The main ports used by Microsoft Teams are TCP 80 and 443, plus UDP 3478 through 3481. You open these outbound ports on your firewall to let chat, calls, and video run. Most teams start by opening wide network ranges to get meetings working fast. Broad firewall rules and wide admin roles create real risk across your internal apps and databases. How the ports used by Microsoft Teams route traffic The app splits network traffic into two main paths based on the task. Web traffic and text chat us
Microsoft Entra ID (Azure AD) + Privacy by Design: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
The main ports used by Microsoft Teams are TCP 80 and 443, plus UDP 3478 through 3481. You open these outbound ports on your firewall to let chat, calls, and video run. Most teams start by opening wide network ranges to get meetings working fast. Broad firewall rules and wide admin roles create real risk across your internal apps and databases.
How the ports used by Microsoft Teams route traffic
The app splits network traffic into two main paths based on the task. Web traffic and text chat use TCP ports 80 and 443. These ports handle sign-in requests, file sharing, and basic app updates. Every user needs TCP 443 open to log in and read messages.
Live audio, video, and screen sharing rely on UDP ports 3478, 3479, 3480, and 3481. UDP sends media packets fast without waiting to check every single lost packet. If a firewall blocks these four UDP ports, the app falls back to TCP 443. That fallback keeps the call alive, but users will see choppy video and hear lag.
Network admins must also allow traffic to Microsoft cloud IP ranges without inspection traps. Deep packet checks on live media streams add delay and break call quality. Good network rules route UDP media straight to the internet while keeping internal systems locked down.
What firewall port rules solve and what they leave open
Setting up the right outbound ports fixes dropped calls and slow screen shares. It gives your team clear boundaries for office Wi-Fi and VPN split tunnels. When media traffic bypasses the VPN, the VPN server handles less load during all-hands meetings.
Still, network port rules only control where packets can go at the transport layer. They do not govern what admins or bots do inside your backend systems. Many engineering teams connect chat bots and workflow apps to internal databases and cloud servers. A firewall rule checks the port, not the command or query running inside the session.
Microsoft Entra ID (Azure AD) + Privacy by Design: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
When an engineer or bot runs a command from a chat workflow, static keys often power that link. Those keys usually hold broad read and write permissions across production data. Port rules cannot mask sensitive fields like emails, phone numbers, or card numbers in query results. They also cannot require a second human to approve a risky production command before it runs.
How to lock down network and internal app permissions
Start by scoping your outbound firewall rules to the exact UDP and TCP ports needed. Pair those port rules with the official Microsoft destination IP ranges for media and signaling. Turn off TLS decryption on those trusted media paths so calls stay clear.
Next, separate your office collaboration network from your production database and server networks. Chat integrations and ops bots should never hold raw database passwords or standing admin keys. Every request to a database or cloud server should check the user identity and inspect the command in flight.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What happens if UDP ports 3478 to 3481 are blocked?
The app switches live audio and video traffic over to TCP the configured port. Calls will still connect, but users often notice audio delay and frozen video frames.
Does the app need any inbound ports open on our firewall?
No, standard client apps only need outbound connections to the cloud service. Your firewall allows return traffic back through the same active session.
Should live media traffic go through a corporate VPN?
No, routing live voice and video through a VPN adds extra hops and lag. Split-tunneling UDP 3478 through 3481 straight to the internet gives much better call quality.