ASD ISM 0558 Restrict IP phone network access in public areas
What it says
IP phones used in public areas do not have the ability to access data networks, voicemail and directory services.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishPublic area IP phones cannot connect to data networks or access voicemail and directories.
IP phones in public areas, like conference rooms or lobbies, should not be able to connect to your main data network or access services like voicemail and company directories. This is important because if someone misuses these phones, they could potentially listen to messages meant for others or access sensitive company information.
Free. Save your status, tasks and notes.
Why it matters
If public-area IP phones can access data networks, voicemail or directories, attackers could pivot into internal systems or harvest sensitive information.
How to implement
IT team should physically segment network: The team should ensure that IP phones in public areas are connected to a separate network from the main data network.
This can often be done by setting up a separate VLAN (Virtual Local Area Network) to isolate these devices.
System administrators should disable unnecessary services: Administrators need to disable services like voicemail and directory access on IP phones used publicly.
This can be achieved through the phone's configuration settings or management software.
Procurement should verify equipment features: When buying new IP phones, procurement should confirm that the phones can support network segregation and do not have easy access to data networks by default.
Facility managers should monitor placement of phones: Facility managers need to ensure that IP phones are placed strategically in public areas to discourage tampering, while still being easy to use by staff and visitors.
IT team should conduct regular security checks: They should routinely test public area IP phones to ensure they can't unexpectedly connect to data networks or access restricted services.
This includes regularly checking phone firmware and configuration settings.
Keep it running
Audit public-area IP phones to confirm they cannot reach data networks, voicemail or directories; enforce VLAN/ACL restrictions and disable unused ports/features.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Network configuration documentation: Request details of network settings that show how public area IP phones are segregated from the main data network.
Look at
The VLAN configuration or similar setup.
Good evidence
Is clear documentation showing these phones are on a separate network segment.
- Check 2 of 5What an auditor asks for
Ask for
Phone configuration records: Obtain records that show service restrictions, like disabled voicemail and directory access on public IP phones.
Look at
Any administrative settings or profiles applied to these phones.
Good evidence
Includes specific settings showing restricted services.
- Check 3 of 5What an auditor asks for
Ask for
To see logs of security checks: Request logs or reports from routine security checks on public area IP phones.
Look at
Dates, findings, and actions taken.
Good evidence
Is a regularly updated log showing checks were performed and any issues were addressed.
- Check 4 of 5What an auditor asks for
Ask for
Vendor specifications: Request the product specifications that were reviewed before purchasing IP phones for public areas.
Look at
Details for network segmentation features.
Good evidence
Is confirmation from specifications that phones can be appropriately isolated.
- Check 5 of 5What an auditor asks for
Ask for
Incident response records: Request to see any incident reports involving public area IP phones.
Look at
Incidents of misuse or unexpected access.
Good evidence
Is a record showing few or no incidents due to proper controls being in place.
Mappings
Closest match in ISO/IEC 27001: A.8.3, Restrict access to information and assets, which this control partially meets.
ISO/IEC 27001: 4 mappings
This control partially meets A.8.3.
ISM-0558 requires that public area IP phones are restricted from accessing organisational data networks and telephony services such as voicemail and directories. Annex A 8.3 requires access to information and associated assets to be restricted according to the organisation's access control policy, which can be implemented via network access controls and service authorisation rules for IP phones. ISM-0558 is a specific, technology/location-focused application of access restriction, while Annex A 8.3 is a broad access control requirement across many asset types and access paths.
This control partially meets A.8.20.
ISM-0558 requires public area IP phones to be configured so they cannot reach internal data networks or associated services like voicemail and directories. Annex A 8.20 requires networks and network devices to be secured, managed, and controlled, which typically includes hardening switch ports, applying ACLs, and controlling routing between voice and data networks. ISM-0558 is a specific restriction for a particular device/location scenario, while Annex A 8.20 is a broader requirement covering overall network/device security management.
This control partially meets A.8.21.
ISM-0558 mandates that IP phones in public areas are prevented from accessing data networks and sensitive telephony services such as voicemail and directories. Annex A 8.21 focuses on defining, implementing, and monitoring security mechanisms and requirements for network services, which can include ensuring voice services are delivered without exposing broader internal services to public-area endpoints. ISM-0558 is an explicit access restriction for a specific endpoint class, whereas Annex A 8.21 is broader and service-governance oriented.
This control partially meets A.8.22.
ISM-0558 requires that IP phones located in public areas are technically restricted so they cannot access data networks, voicemail, or directory services. Annex A 8.22 requires network segregation between groups of services/users/systems, which is a common method to place public-area IP phones on a constrained voice-only segment or VLAN. ISM-0558 is a specific use case and outcome, whereas Annex A 8.22 is a broader network design control that applies across the organisation.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.