Author: Osiris

  • Fire Alarm Secondary Power: Battery Sizing, Load Testing and Transfer Verification

    Fire Alarm Secondary Power: Battery Sizing, Load Testing and Transfer Verification

    Fire alarm secondary power is a designed operating system, not simply a pair of batteries in a cabinet. Capacity calculations, charger performance, connected loads, battery condition and automatic transfer all contribute to whether the system can continue operating when primary power is lost.

    This guide complements the practical material in Articles & Analysis and the Fire Safety archive.

    Establish the documented load

    Start with the approved equipment list and identify standby and alarm current for the control unit, annunciators, communication equipment, modules, detectors, notification power supplies and other loads served by the same batteries. Field additions can invalidate an older calculation even when the panel shows no trouble.

    Required standby and alarm periods, design margins and derating factors depend on the adopted code edition, system type, project documents, listed equipment and authority having jurisdiction. One duration or percentage should not be treated as universal.

    Inspect installation and condition

    Record battery manufacturer, model, rated capacity, installation date and terminal arrangement. Look for swelling, leakage, corrosion, loose connections, damaged insulation, excessive heat and cabinet contamination. Confirm polarity and secure mounting. Open-circuit voltage alone does not demonstrate usable capacity under load.

    Verify charger and supervision

    Measure charger and battery conditions using the listed equipment procedure and approved test method. Confirm that battery disconnection produces the intended supervised trouble and that restoring the circuit clears correctly. Investigate a charger that masks a weak battery during normal mains operation.

    Test transfer from primary power

    Use the authorized procedure to remove primary power and observe automatic transfer. The panel, communication path and required connected functions should remain stable while the correct trouble signal appears locally and remotely. Restore primary power and verify recharge indication and normal status. Coordinate the test to prevent an unintended dispatch.

    Apply an appropriate load test

    Testing may use the system load, a listed battery tester or another approved method. Record initial conditions, applied load, duration, measured values and recovery. A result outside the manufacturer’s limits or project criteria requires evaluation and corrective action. Replacing batteries without investigating excessive load or charger faults may only postpone another failure.

    Keep calculations aligned with the field

    • Update current totals after adding devices, modules or communicators.
    • Include auxiliary power supplies and their own batteries in the inventory.
    • Link battery records to the exact panel and cabinet.
    • Document replacement, disposal and post-work retesting.

    Acceptance should combine calculation review, physical inspection, supervision, transfer behavior and load evidence. The final report should cite the applicable requirements and preserve enough detail for the next technician to repeat the method.

    Sources

  • Fire Door and Access Control Interface Testing: Fail-Safe Release Without Security Gaps

    Fire Door and Access Control Interface Testing: Fail-Safe Release Without Security Gaps

    Fire alarm and access control systems often share control of doors, but they serve different objectives. Emergency operation must support safe egress and required fire or smoke separation while normal operation protects controlled areas. A correct interface test proves the approved sequence instead of assuming that every lock should simply release.

    Related commissioning guidance appears in Articles & Analysis and the Fire Safety archive.

    Start with the approved door schedule

    For each opening, identify the door and frame rating, locking hardware, closer, hold-open device, request-to-exit equipment, emergency release, power source and control modules. Record which alarm zone or building condition should affect it. Required behavior depends on the door function, adopted codes, listed hardware, approved design and authority having jurisdiction; not every controlled door universally fails open.

    Trace the interface path

    Determine whether the fire alarm provides a dry contact, supervised module or networked command, and which access-control component removes or changes power. Verify fault supervision where required. Labeling should allow a technician to connect the fire panel point to the exact door and access output without relying on institutional memory.

    Test normal emergency operation

    Initiate the approved fire-alarm condition and observe the complete sequence. Confirm that affected locks, holders and operators reach their specified state; that occupants can egress as designed; and that fire or smoke doors close and latch where required. Test local manual-release devices independently. A successful access-control software command does not prove the hardwired emergency path.

    Test loss of power and communication

    Simulate the power-loss conditions included in the design, including local access supply, fire-alarm interface supply and network communication where applicable. Observe whether backup power changes the sequence. Verify trouble indications and confirm that a single fault does not silently leave a door in an unsafe or permanently unsecured condition.

    Verify reset and relocking

    After the initiating condition clears, reset systems in the documented order. Confirm that doors do not relock while an emergency release remains active, and that authorized relocking restores security without preventing required egress. Check door alignment, latch engagement and position monitoring; an electrical reset cannot compensate for damaged hardware.

    Use a door-by-door record

    • Opening identifier and physical location
    • Normal, alarm, power-loss and manual-release states
    • Panel, access controller and monitoring messages
    • Release, closure, latching and reset observations
    • Defect owner, corrective action and retest result

    Coordinate testing with fire-safety, security and facilities teams. Acceptance criteria and periodic intervals should be taken from the adopted requirements and project documentation rather than generalized across every occupancy.

    Sources

  • Sprinkler Supervisory Monitoring: Valves, Waterflow and Fire Pump Signals

    Sprinkler Supervisory Monitoring: Valves, Waterflow and Fire Pump Signals

    A sprinkler system is not fully supervised merely because a fire alarm panel displays a normal condition. Valves, waterflow devices, pressure switches, pumps, power supplies and communication paths must report the right condition with a label that operators can act on.

    Commissioning should trace each field input through the panel, remote monitoring and restoration process. Related technical material is available in Articles & Analysis and the Fire Safety archive.

    Keep signal classes distinct

    An alarm signal indicates a condition associated with fire response, such as sustained waterflow. A supervisory signal indicates an off-normal condition in a fire-protection system, such as a control valve moving from its intended position. Trouble identifies a fault affecting monitoring or operation. The precise classification and timing must follow adopted requirements, approved design documents, listed devices and the authority having jurisdiction.

    Verify valve supervision

    Identify every supervised valve and confirm its normal position. Operate the valve slowly and verify that the correct point appears locally and at the monitoring destination. The displayed label should identify the actual system and location, not a generic input number. Restore the valve fully and confirm that the supervisory condition clears without leaving the system impaired.

    Test waterflow as an end-to-end event

    Use the approved test connection or procedure and record the sequence from water movement to panel indication, notification and remote receipt. Mechanical retard features and programmed delays should be evaluated against the approved design. Reset the system, check for leakage and verify that the alarm does not remain latched unnoticed.

    Include pressure and fire-pump information

    Where monitored, test pressure-related inputs, pump running, controller trouble, power conditions and other specified states. Do not infer pump performance from a status contact; hydraulic and controller tests are separate activities. Confirm that operators understand which signal requires emergency response and which requires maintenance investigation.

    Coordinate testing safely

    • Notify the monitoring center and affected occupants before testing.
    • Use impairment procedures when valves or pumps are taken out of normal service.
    • Protect against unintended water discharge and equipment damage.
    • Restore every bypass, valve and notification function after the test.

    Build a defensible record

    Document device type, address, physical location, normal state, activation method, panel text, remote text, timestamps and restoration. Testing intervals and acceptance details vary by jurisdiction and system type, so the record should cite the applicable procedure rather than asserting one universal schedule. Unresolved mismatches should remain visible until corrected and retested.

    Sources

  • Fire Detection in High-Ceiling Spaces: Smoke Stratification, Beam Detection and Aspirating Sampling

    Fire Detection in High-Ceiling Spaces: Smoke Stratification, Beam Detection and Aspirating Sampling

    High-ceiling spaces challenge the assumption that smoke will quickly reach a detector mounted at the highest point. Warehouses, atria, aircraft hangars and production buildings can delay or redirect smoke through temperature gradients, ventilation and large internal volumes.

    The design question is therefore not simply which detector has the longest range. Engineers must identify the fire signatures, airflow and response objective, then select and validate a detection method. More guidance is available in Articles & Analysis and the Fire Safety archive.

    Understand smoke movement first

    Buoyant smoke can cool as it rises and may stabilize below the roof, a condition commonly described as stratification. Heating, roof temperature, air handling, racking and stored goods can change the plume. A design based only on clear ceiling height may miss these interactions.

    Compare available detection approaches

    Point smoke detectors are familiar and provide individual device locations, but response can be delayed when smoke takes time to reach the ceiling. Optical beam detectors monitor obscuration across a long path and can cover broad open areas, although alignment, structural movement and obstructions require attention. Aspirating smoke detection draws air through a pipe network to a central detector and can sample at selected heights, but pipe transport time, airflow balance, contamination and maintenance access must be engineered.

    Account for the operating environment

    • Map normal and emergency ventilation modes.
    • Review roof geometry, cranes, banners, racks and future storage changes.
    • Consider dust, condensation, sunlight and temperature variation.
    • Provide access for alignment, sampling-hole inspection and detector service.

    Use performance-based evidence where needed

    NFPA research on high-ceiling detector spacing shows why ceiling height deserves specific evaluation. Computational analysis, smoke tests or other approved engineering methods may be needed for unusual spaces. Spacing and acceptance criteria depend on the adopted codes, project documents, listed device instructions and the authority having jurisdiction; a single universal distance is not appropriate.

    Commission the complete signal path

    Testing should demonstrate that the selected fire signature reaches the sensing path and produces the intended alarm at the correct panel location. For beam systems, verify alignment, obscuration response and trouble conditions. For aspirating systems, check airflow supervision, pipe integrity, transport behavior and each sample point. Confirm interfaces to notification, smoke control and monitoring without assuming that one detector test proves every sequence.

    Preserve a repeatable baseline

    Document detector locations, beam paths, pipe calculations, airflow measurements, alarm thresholds, test material, environmental conditions and response times. Reassess the design when occupancy, racking, ventilation or ceiling obstructions change. A repeatable baseline makes later maintenance more useful than a simple pass label.

    Sources

  • Voice Evacuation Intelligibility Testing: From Audibility to STI

    Voice Evacuation Intelligibility Testing: From Audibility to STI

    A voice evacuation system can be loud enough to hear and still fail to deliver an understandable instruction. Audibility confirms that a signal rises above the environment; intelligibility asks whether listeners can correctly understand the words. Commissioning must address both outcomes.

    This distinction is especially important in transport halls, factories, atria, tunnels and other spaces with reverberation or changing background noise. Related fire-safety guides are available in Articles & Analysis and the Fire Safety archive.

    Begin with the design objective

    Identify the occupied zones, expected ambient conditions, message languages and emergency actions. Review speaker layout, amplifier loading, zoning, survivability and message priority. Acceptance criteria must come from the adopted codes, approved design documents, listed equipment and the authority having jurisdiction; one score should not be presented as universal.

    Separate level from clarity

    Measure the emergency message against representative background noise, but do not stop after confirming sound pressure. Excessive level can worsen reflections or distortion. Inspect speaker aiming and spacing, competing announcements, reverberant finishes and obstructions. A quiet test after hours may not represent an occupied building.

    Use STI or STIPA carefully

    Speech Transmission Index methods, including STIPA, estimate how the transmission path preserves modulations important to speech. The test signal, meter settings, measurement positions and background-noise conditions must follow the selected method and project procedure. Record the measured value with its location and operating condition rather than reporting an unexplained site average.

    Plan representative measurement points

    • Include zone boundaries, corners, areas below balconies and locations between speakers.
    • Test near machinery, ventilation outlets and other recurring noise sources.
    • Verify each message path, emergency microphone and automatic message sequence.
    • Check fault monitoring and backup-power operation separately from acoustic performance.

    Diagnose a failed area systematically

    A poor result may come from reverberation, low signal-to-noise ratio, overlapping speaker arrivals, distortion, incorrect equalization or an unsuitable speaker pattern. Corrective action might involve changing aiming, spacing, level balance, delay, acoustic treatment or the message itself. Short, direct wording often performs better than a complex sentence, but message changes require approval.

    Document and retest

    Record the instrument, calibration, test signal, floor plan position, ambient condition, system mode, measured level and intelligibility result. Link every defect to corrective work and repeat the same measurement after changes. Periodic tests should use a controlled baseline so that a genuine deterioration is distinguishable from a different test setup.

    Sources

  • Google Rolls Out Gemini 4 Argon to Trusted Cyber Defenders

    Google Rolls Out Gemini 4 Argon to Trusted Cyber Defenders

    Google has announced Gemini 4 Argon, a model it is initially making available to selected cyber defenders through the company’s Fairwind Program. Google says the system is intended to help find, validate and patch software vulnerabilities.

    Access begins with a restricted defender program

    The company is not presenting the initial rollout as unrestricted public availability. Google says trusted participants may receive access tailored to defensive research, and that selected defenders could work with a version without the cyber guardrails applied in broader settings. Those statements describe Google’s access model and claimed capabilities; they are not independent proof of performance in every environment.

    Human validation remains necessary

    Security teams evaluating an AI-assisted research system should define test scope, protect sensitive code and credentials, and require reproducible evidence before accepting a reported vulnerability or patch. Suggested fixes still need code review, regression testing and deployment controls. Organizations should also document who can use less-restricted capabilities and how resulting artifacts are retained. Unsupported benchmark comparisons should not substitute for testing against an organization’s own applications and threat model. More AI-security developments are available in the SectechMedia Technology News archive.

    Sources

  • Sucuri Finds Self-Rebuilding WordPress Backdoor Across Files, Database and Memory

    Sucuri Finds Self-Rebuilding WordPress Backdoor Across Files, Database and Memory

    Sucuri researchers have documented a WordPress backdoor designed to rebuild itself when defenders remove only part of the infection. The company calls the malware SC and describes a mesh of cooperating components distributed across the site’s files, database and operating environment.

    Persistence extends beyond a single malicious file

    Sucuri said copies or recovery logic can reside in WordPress files, database options, archives, scheduled tasks and System V shared memory. A surviving component can restore removed pieces during a later request. The command mechanism also uses blockchain infrastructure, reducing its dependence on a conventional command domain that defenders could block or seize.

    Cleanup requires a full-system investigation

    Deleting one suspicious loader is unlikely to be sufficient. Responders should preserve evidence, enumerate web files and database options, inspect scheduled jobs and drop-ins, review memory-related artifacts where the platform permits it, and compare the installation with a trusted baseline. Credentials for WordPress, hosting, databases and deployment systems may also require rotation. Sites should be rebuilt from known-good components when integrity cannot be established. Further application-security reporting is available in the SectechMedia Technology News archive.

    Sources

  • Europol Seizes KillSec Ransomware Infrastructure in Operation KillSwitch

    Europol Seizes KillSec Ransomware Infrastructure in Operation KillSwitch

    Law-enforcement agencies have taken control of servers and a leak site associated with the KillSec ransomware operation in an action Europol called Operation KillSwitch. Europol said three suspects were arrested and that a 16-year-old was suspected of leading the group.

    Servers and leak infrastructure were seized

    The takedown occurred on September 30. Authorities said they secured at least 110 terabytes of data against further unauthorized publication. Taking control of leak infrastructure can interrupt extortion activity and preserve evidence, but it does not by itself prove that every affiliate, credential or victim-facing access path has been removed.

    Claims remain subject to judicial process

    The people identified in the investigation are suspects, not convicted offenders. Organizations previously affected by KillSec should preserve evidence, coordinate with the appropriate authorities and continue rotating credentials or rebuilding systems where incident-response findings require it. A public takedown should not be treated as a substitute for checking persistence, exposed data and third-party access. Security teams can follow additional law-enforcement and ransomware developments in the SectechMedia Technology News archive.

    Sources

  • Kiteworks Patches Maximum-Severity Email Protection Gateway Flaw

    Kiteworks Patches Maximum-Severity Email Protection Gateway Flaw

    Kiteworks has released security updates addressing 126 vulnerabilities, including a maximum-severity flaw in its Email Protection Gateway. The most serious issue, tracked as CVE-2026-54154, can enable remote code execution without authentication when several weaknesses are chained together.

    The attack path crosses multiple weaknesses

    According to the public reporting and CVE record, the chain combines path traversal, code injection and missing authentication. An attacker able to reach a vulnerable gateway could potentially execute code remotely. The risk is significant because email-security gateways commonly sit near an organization’s external boundary and may process untrusted content.

    Use the vendor’s release guidance

    Administrators should identify every deployed Email Protection Gateway, consult Kiteworks guidance for the applicable supported release and apply the prescribed fixes. The public sources reviewed for this report do not justify inventing affected or fixed version numbers. Teams should also restrict management exposure, review gateway logs for unexpected activity and verify that credentials or trust relationships available to the appliance cannot be used for lateral movement. Patch validation should include service health and security logging, not only a successful installation message. Additional vulnerability updates are tracked in the SectechMedia Technology News archive.

    Sources

  • MetaMask Exits Affected Ethereum Validators After Infrastructure Incident

    MetaMask Exits Affected Ethereum Validators After Infrastructure Incident

    MetaMask has begun precautionary exits for Ethereum validators affected by an incident involving part of its staking infrastructure. The company said the event did not create an immediate threat to MetaMask wallets, separating the validator response from the security of users’ wallet accounts.

    Validator exits are a containment measure

    Reporting from BleepingComputer and CoinDesk said MetaMask was working with staking provider Lido while the affected validators moved through Ethereum’s exit process. Lido said the relevant validators were expected to complete the exit stage by October 7, although full withdrawal and any subsequent restaking could take longer. Public estimates about the number of validators involved have not been confirmed by MetaMask and should not be treated as an official incident total.

    Operators should distinguish wallet risk from staking operations

    The incident illustrates why security communications should identify the affected service boundary. A problem in validator infrastructure can interrupt rewards or change staking operations without automatically exposing wallet credentials. Staking operators should preserve logs, review administrative access, verify validator withdrawal settings and monitor official updates before taking further action. Users should rely on MetaMask’s published channels rather than unsolicited recovery messages, which can appear after widely reported incidents. More verified incident coverage is available in the SectechMedia Technology News archive.

    Sources