Logging and Wi-Fi management for factories, warehouses, and construction sites

Why internet on site is the business's responsibility

At a factory, warehouse, or construction site, the internet line serves a far more varied crowd than an administrative office. Shift workers may use the same stations and the same handheld terminals at different hours of the day. Technicians and drivers from contractor firms doing maintenance, installation, or haulage connect with their own phones or company devices. Visitors coming for an audit, a supplier visit, or a delivery want short-term access. Alongside all this, barcode scanners, handheld terminals, industrial printers, and sensors connected to the production line also pass through the same network.

To the outside world, this site has a single identity: the internet line registered in the business's name. When a transaction performed by a staff member on shift or a contractor on site is questioned, the first question goes to the business — because the visible address is the business's. With shift changes, temporary contractor badges, and a large number of shared devices all at once, answering "who was using that device at that moment" without a record is nearly impossible.

An identity-matched access record sorts this crowd out one by one: which user, on which shift, from which MAC-addressed device, with which internal IP, accessed what, can all be seen separately. This lets the business clarify an incident on its own site.

On production sites, this need keeps renewing itself: contractor firms change project by project, seasonal or shift-based staff turn over frequently, and a construction site's crew can change completely after a given phase. When an equipment failure, a security breach, or a supplier dispute is investigated, being able to answer retrospectively "whose device was active on site that day" is less a one-off inquiry than part of the site's everyday management.

Warehouses and construction sites may have multiple entry points, container offices, or a temporary site office instead of a single administrative building; each may have a different access point. Without a centralized logging system, this scattered layout leads to fragmented access information: one access point's log might be kept while another's isn't. izgate removes this fragmentation by monitoring, from a single point, the firewall that all the access points on site are connected to.

Delivery and logistics traffic is also part of this picture: drivers usually enter the site briefly, and may connect to a warehouse management system with their phone or a handheld terminal during loading/unloading. Identity-matching these short-lived connections just like permanent staff's lets a dispute during a delivery (a lost shipment, a damaged-goods report) be linked to which driver was on site at that moment.

Legal framework: the scope of access records

The definition in Law No. 5651 makes no distinction between a production site, a warehouse, or a construction site; any business that provides internet to its staff or visitors falls within scope:

"Toplu kullanım sağlayıcı: Kişilere belli bir yerde ve belli bir süre internet ortamı kullanım olanağı sağlayanı,"

"Public use provider: a person who provides individuals with the means to use the internet at a specific place for a specific period of time,"

Law No. 5651, Article 2/1-i — unofficial translation — mevzuat.gov.tr

The content of the access records that must be kept is also explicitly defined in the Regulation; this definition shows exactly what needs to be recorded in a crowded environment with shared devices:

"Kendi iç ağlarında dağıtılan IP adres bilgilerini, kullanıma başlama ve bitiş zamanını ve bu IP adreslerini kullanan bilgisayarların tekil ağ cihaz numarasını (MAC adresi) gösteren bilgileri, hedef IP adresi, bir veya birden fazla IP adresinin portlar aracılığı ile kullanıcılara paylaştırılması yöntemi ile sunulan internet erişim hizmetinde kullanıcıya tahsis edilen gerçek IP ve port bilgilerini,"

"Information showing the IP address information distributed on their own internal networks, the start and end time of use, and the unique network device number (MAC address) of the computers using these IP addresses, the destination IP address, and, for internet access service provided by sharing one or more IP addresses among users via ports, the actual IP and port information allocated to the user,"

Regulation on Internet Public Use Providers (2017), Article 3/1-e — unofficial translation — mevzuat.gov.tr

The same regulation also requires all public use providers to use a content filtering system (Article 4/1-a); on site, that filtering is applied by your firewall's own web filter, and izgate only collects the blocking and access records that filtering produces and matches them to the device and user. This is not a legal guarantee; the accurate statement is that you can document who performed a transaction on your site and respond fully to a request from the competent authorities. For the detailed framework, see the Regulation on Internet Public Use Providers and the What Are Access Records? guide.

A realistic scenario

The example below shows how an identity-matched record works in practice on a production site.

The same method can be used retrospectively to document which shift an equipment failure started on, which device a security breach originated from, or what resources a contractor firm accessed on site; finding the record requires no extra tool or external request.

What izgate does on this site

izgate separately recognizes shift staff, contractors, visitors, and IoT devices that can't pass through the portal, and identity-matches and signs the access of each. The capabilities below work together from the moment of setup.

• Separate login for shift workers, contractors, and visitorsStaff connect from the corporate network; contractors and visitors connect from the guest network with a visitor code, SMS verification, or administrator approval; access records never mix together.
• Unrecognized DevicesDevices that can't display a login screen — handheld terminals, barcode scanners, or industrial printers — appear in the "Unrecognized Devices" list in the panel; they're registered with a single click, and a portal exemption is defined automatically on the FortiGate.
• Identity-matched access recordsEach line keeps time, internal IP, destination IP/port, NAT IP/port, MAC address, and user together; records can be searched by shift or device.
• RulesThe ability to view FortiGate and MikroTik firewall rules, turn them on/off, and track them with a change history.
• AlertsA device going offline/coming online, an unauthorized device connection, and rule changes are reported instantly.
• Signed archiveWritten to a separate disk at the same time as the live data, protected by a SHA-256 chain and an Ed25519 signature, with a qualified timestamp taken once a day.

How it's set up

Compliance checklist

• Is a separate login method defined for shift staff, contractors, and visitors?
• Are IoT devices that can't pass the portal (handheld terminals, printers, scanners) registered?
• Does every access record keep internal IP, MAC, user, destination, and NAT port together?
• Are multiple sites or construction sites monitored from a single panel?
• Are live and archive records kept on separate disks?
• Do you get an alert when a device goes offline?
• Is a contractor firm's access on site limited in duration and scope?
• Is the integrity of the archive records (hash chain + signature + timestamp) verified regularly?

This list is not a one-time setup check; it is a living checkpoint you should revisit as your site grows or as your contractor/shift structure changes.

Frequently asked questions

This page is for information only; for the current text of the legislation, refer to the official source (mevzuat.gov.tr).