Treat DISA as a privileged inbound-to-outbound bridge
Asterisk defines Direct Inward System Access as a way for a caller outside the PBX to obtain internal dial tone and place a call inside a selected dialplan context. FreePBX exposes a DISA entry as a destination that another call flow can select. That makes the feature a bridge across security and billing boundaries, not a remote extension, VPN or proof of a person's identity.
Asterisk explicitly warns that DISA can compromise PBX security. Start with a written use case, accountable owner, allowed source path, permitted destinations, spending and time limits, monitoring and a removal date. If a more constrained callback, mobile client, VPN or provider feature meets the need, prefer the design with the smaller exposed calling surface.
Map every boundary before enabling the destination
Document the complete path: caller and carrier, inbound number or IVR choice, FreePBX inbound route, DISA destination, authentication prompt, selected dial context, outbound-route match, trunk, provider response, answer and media. Each boundary has a different owner and observable evidence. Reaching a PIN prompt proves neither that the caller is authorized nor that a later outbound route is safe.
Restrict access before the DISA application where dependable controls exist, but do not treat caller ID alone as strong authentication. It can be missing, transformed or spoofed. Keep schedules, allowlists and carrier controls as additional gates, and preserve an administrator recovery path that does not depend on the same call flow.
Use authentication that can be contained and rotated
The current FreePBX release/17.0 source distinguishes configured PINs from a no-password path and can generate an authentication step before dial access. Do not deploy password-free DISA on an externally reachable path. Use long, non-reused numeric values under an organizational credential policy, limit who can view or change them, and assign a rotation and revocation owner.
Do not paste a reusable PIN into a ticket, screenshot, packet capture, CDR export or test note. Multiple shared PINs still provide weak personal attribution unless the surrounding system records a durable non-secret identity. If a PIN may have been exposed, rotate it and verify the old value fails rather than merely deleting the evidence.
Constrain the post-authentication dial context
Asterisk matches the digits entered after authentication in the context supplied to DISA; its documentation recommends a special context with restrictions. FreePBX's current source carries a configured context into a local outbound attempt. The effective context therefore determines what the authenticated caller can reach before outbound-route, trunk and provider policy are considered.
Grant only the destination classes the business case requires. Exclude feature codes, internal applications, premium or international destinations and emergency paths unless their responsible owners explicitly approve and validate them. Treat caller-ID selection as a separate presentation policy, not an entitlement. Record digit and response timeouts as usability and abuse controls, then inspect the generated and loaded dialplan through supported tools after Apply Config; do not edit generated files as the durable repair.
Separate call completion from the option to return to dial tone
FreePBX's current source generates authentication, recording policy, timeout variables and a call through the selected context. It also contains behavior for returning to DISA after some failed or completed attempts. Confirm the installed module's exact hangup and redial behavior before assuming one authenticated session permits only one call.
Define how a busy, rejected, unanswered or completed call must end, which announcement the caller should hear and how long the session may remain usable. Do not infer fraud resistance from a carrier disconnect tone or a single successful test. Preserve Asterisk channel identifiers and provider correlation identifiers so repeated attempts can be distinguished from one bridged call.
Prove valid, invalid, forbidden and unaffected paths
Use bounded authorized tests from an approved source: valid PIN to an allowed non-emergency destination, invalid PIN, old PIN after rotation, forbidden destination, timeout, after-hours path and a normal inbound call that does not select DISA. For an accepted call, record the inbound route, DISA entry, loaded context, digits seen after authentication, outbound route, trunk, remote response and final answer separately.
Review logs and billing records for the expected non-secret correlation without retaining the PIN. Confirm alerts and spending controls activate under their approved test method, then remove captures promptly. Roll back by removing or redirecting the inbound destination and restoring the recorded configuration if any unrelated call flow changes. No PBX, installed module, PIN, route, trunk, provider response or call was inspected or tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- FreePBX DISA release/17.0 source repository ↗
- FreePBX DISA release/17.0 dialplan generation source ↗
- Asterisk DISA application documentation ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.