Protecting Active Directory (AD) accounts starts with strong password policies, backed by consistent enforcement across the organization. However, make the rules too weak and you increase your attack surface; make them too strict and users will find workarounds, such as writing passwords down, reusing them across systems, or adding a predictable “!” to the end of the last version.

The challenge is enforcing modern, resilient password standards that avoid increasing helpdesk tickets or frustrating the people you’re trying to protect. However, with the right approach, you can strengthen your AD password posture and make life easier for users at the same time.

Adopt passphrases over complex passwords

Traditional password complexity rules are frustrating, and do not provide the protection needed for today’s threat landscape. When people are forced to include symbols, numbers, and mixed cases, they tend to fall back on memorable, but guessable, options like Password!2026.

A better approach is to prioritize length over complexity with passphrases. Longer passwords made up of multiple words are easier to remember and significantly harder to crack. NIST recommends allowing passwords up to 64 characters.

While most users won’t reach that limit, raising the minimum length (for example, to 15 characters or more) strengthens security and reduces the need for awkward, error-prone passwords.

Block weak and compromised passwords

Even with longer passwords, users are still likely to choose weak or common options. Password spraying attacks rely on exploiting that tendency, so it’s crucial that organizations actively block weak password creation. It’s here that solutions like Specops Password Policy help:

• Creating custom banned word lists: Security teams can build tailored dictionaries of blocked terms that reflect their organization’s environment. This helps prevent common weak choices, including passwords based on usernames, display names, repeated characters, incremental changes, or reused elements from existing credentials.
• Breach password protection: By continuously checking passwords against a database of over 5.4 billion known breached credentials, Specops Password Policy helps stop compromised passwords from being used in AD and allows issues to be addressed quickly.

Stopping weak passwords at creation is far more effective than trying to fix the problem after an account has been compromised.

Rethink password expirations

When users are required to reset credentials too often, they tend to make minimal tweaks, changing a few characters or making incremental changes. To avoid this, those setting password policies should move away from mandatory password expiration unless there is evidence of a compromise.

That doesn’t mean expiry should be removed without consideration, particularly where password reuse is a concern. However, there’s a strong case for extending expiry periods when users are creating long, robust passwords and you have controls in place to detect compromised credentials.

Length-based aging reinforces this approach. Tying expiration periods to password length encourages longer, stronger credentials with the reward of extended or even removed expiry, unless a compromise is detected.

Use a password manager

One of the biggest challenges with strong password policies is reuse. Even when employees create a good AD password, they’re likely to repeat it across other systems simply because remembering dozens of credentials isn’t realistic.

An approved password manager, implemented securely, removes that burden. It allows users to generate and, more importantly, store every long, unique password they need for their accounts. For IT teams, enterprise password managers also support better control over shared credentials and privileged accounts. Combined with passphrase-friendly AD policies, they’re a practical way to improve security while reducing friction.

Implement self-service password resets

Password resets are one of the most common causes of helpdesk tickets in AD environments. When policies are strict and employees make mistakes, support queues quickly fill up.

Secure self-service password reset reduces that pressure. By verifying identity through MFA or other authentication methods, staff can reset their own passwords quickly, in many cases eliminating the need to raise a ticket.

Faster recovery reduces downtime, limits risky workarounds, and improves user experience. When people know they won’t be locked out for long, password policies feel far less disruptive.

Customizable notifications

Users shouldn’t be caught off guard by sudden lockouts or last-minute expiry warnings. It’s these annoyances that lead to unnecessary disruption and support calls.

Clear, timely notifications make a difference, highlighting when action is needed and clearly explaining requirements. Good communication won’t replace robust controls, but it helps users stay compliant and reduces the friction that often comes with password enforcement.

Provide dynamic feedback at password creation

Vague “password does not meet requirements” messages are unhelpful. Effectively enforcing AD rules means supplying real-time, specific feedback when creating or changing passwords. Strength meters, banned password checks, and clear prompts make it easy for users to see exactly what the requirements are.

When feedback is immediate and actionable, users are more likely to create stronger credentials. It’s a small usability improvement that delivers a noticeable uplift in password quality.

How Specops can help

Reviewing and updating AD password policies is a balance between security and usability. A good starting point is auditing your AD environment using solutions like Specops Password Auditor. This free tool runs a read-only scan of your AD and highlights any password-related vulnerabilities, presented in an easy-to-understand report.

Specops Password Policy then helps organizations remediate any password-related issues and ensure continued policy enforcement across their environment. This includes practical improvements that strengthen resilience, such as continuously scanning for breached passwords and supporting passphrase implementation.

If you’re rethinking your password strategy, we can help you build an approach that improves protection while maintaining the user experience.

Contact us today or book a demo to see our solutions in action.

Sponsored and written by Specops Software.

Pick up any smart device you own. A doorbell that recognizes faces, a watch that reads your heart rhythm, a thermostat that learns when you leave for work. They feel simple. You tap, they respond.

That simplicity is a lie. A useful one, but a lie.

Behind the clean app and the satisfying click is a stack of engineering decisions that most people never see. And the gap between a device that works for five years and one that dies in eight months almost always traces back to those invisible choices. So let’s look at what actually goes into building the connected gadgets shipping in 2026.

Smart starts with the circuit board, not the cloud

Most coverage of smart devices jumps straight to AI features and voice assistants. But the foundation is physical. A device is a printed circuit board, a microcontroller, a fistful of sensors, a radio, and a battery, all crammed into a shell that has to survive being dropped, sat on, and left in a hot car.

This is where hardware development does its quiet, unglamorous work. Engineers pick a microcontroller based on how much computing the device needs versus how little power it can afford to burn. They route signal traces on the board so a Wi-Fi radio doesn’t drown out a delicate sensor reading. They run the whole thing through thermal testing, drop testing, and certification for FCC and CE marks before it can legally ship.

Get this layer wrong, and no amount of clever software saves you. A poorly designed board produces flaky sensor data. Bad antenna placement means the device drops off your network the moment you walk to the next room. These aren’t software bugs. You can’t patch your way out of a physics problem.

The companies building good hardware treat the proof-of-concept stage as a real checkpoint. They wire up development boards and modular parts to test the core idea cheaply, before committing to a custom design that costs real money to manufacture. It’s the boring discipline that separates products from expensive paperweights.

Firmware is where the device actually thinks

Sitting on top of the hardware is firmware. This is the low-level code that tells the chip what to do, when to wake up, how to read a sensor, and when to phone home. People mix up firmware and software all the time, so here’s the clean split. Software runs on your phone or in the cloud and handles the screens you tap. Firmware lives inside the device and controls the hardware directly.

Firmware is genuinely hard to write well. The constraints are brutal. A typical IoT microcontroller has a tiny amount of memory, often measured in kilobytes, and it might run on a coin cell that needs to last a year. Every line of code competes for space and power.

Then there’s timing. A lot of devices need deterministic, real-time behavior, meaning a sensor reading has to be processed within a fixed window or the whole thing falls apart. A heart monitor that processes a beat “eventually” is useless. The firmware has to guarantee it happens now.

If you want the deep version of how this gets built in practice, Yalantis published a solid breakdown of firmware development for embedded IoT devices that covers architecture, power management, and the over-the-air update workflows that keep a device current after it ships. The OTA piece matters more than it sounds. A device that can’t safely update its own firmware is frozen in time the day it leaves the factory.

Connectivity is a series of trade-offs

Your smart device has to talk to something. Your phone, your router, a cloud server, or all three. Choosing how it talks is one of the most consequential engineering calls in the whole project, and there’s no single right answer.

Bluetooth Low Energy sips power and works great for a wearable talking to your phone, but its range is short and it can’t reach the internet on its own. Wi-Fi reaches everything but drains batteries fast. LoRaWAN travels for miles on almost no power, which is perfect for a soil sensor in a field, but it carries tiny amounts of data slowly. Cellular options like NB-IoT and LTE-M let a device work anywhere there’s a signal, with the catch of ongoing data costs and bigger power draw.

Engineers usually mix these. A fitness band might use BLE to sync with your phone, and your phone carries the data the rest of the way. An industrial sensor in a remote location might use LoRaWAN to a gateway, which then forwards everything over cellular. The “right” combination depends entirely on power budget, data volume, range, and cost, which is exactly why this decision gets made early and gets revisited often.

Sensors and the messy job of trusting them

A smart device is only as good as the data it collects. And raw sensor data is messy.

Take a simple temperature reading. The sensor drifts over time. It gets warmed by the heat of the chip sitting next to it. It returns noisy values that jitter up and down even when nothing changes. Firmware has to calibrate, filter, and sanity-check all of it before the device acts on a single number.

This gets serious fast in regulated fields. A continuous glucose monitor or a medical wearable can’t ship a reading that’s “close enough.” The sensor design, the calibration, and the firmware that validates the data all have to meet standards that consumer gadgets never face. The engineering bar is much higher, and the cost of getting it wrong is measured in patient safety, not customer reviews.

For everyday devices the stakes are lower, but the principle holds. Good devices spend a lot of hidden effort turning unreliable physical signals into numbers you can actually trust.

Where the AI hype meets the silicon

Here’s the part that has changed most recently. A growing share of smart devices now run machine learning models directly on the chip instead of sending everything to the cloud. This is edge computing, and it’s reshaping how devices get built.

The appeal is obvious. Processing data on the device means lower latency, since you’re not waiting on a round trip to a server. It means better privacy, because your data never leaves your hand. And it means the device keeps working when your internet goes down.

The catch is that running a model on a chip with kilobytes of memory is an engineering puzzle. Models have to be shrunk, quantized, and optimized until they fit in the space available without melting the battery. The face-recognition that runs locally on a modern doorbell is a heavily compressed version of what would run on a server. Squeezing it down to fit is real, specialized work, and it’s increasingly where the competitive difference between two similar gadgets actually lives.

Security can’t be the last step

For years, connected devices treated security as an afterthought. Ship the product, patch problems later. That approach has aged badly.

Outdated firmware is now one of the most common ways attackers break into IoT systems. Research from the security firm ONEKEY found that vulnerable firmware accounts for a large majority of successful attacks on connected devices. Once an attacker is inside one poorly secured gadget on your network, they have a foothold to reach everything else.

Building security in from the start means encrypting data both when it’s stored on the device and when it travels to the cloud. It means signing firmware updates so a device only accepts legitimate code, not something an attacker swapped in. And it means designing for recovery, so a compromised device can be safely reset and restored rather than turned into a permanent liability sitting on your shelf.

This is the layer consumers never think about and pay the most for when it’s done badly.

Why the next generation is harder to build

Smart devices are getting more capable, and that capability has a cost that lands squarely on the engineering team. More on-device intelligence. Stricter privacy rules. Longer battery expectations. Tighter security. Regulatory scrutiny that used to apply only to medical gear now creeping toward consumer products too.

None of this shows up in the marketing. The ad shows a person tapping a screen and a light turning on. What it doesn’t show is the year of board revisions, firmware rewrites, connectivity tests, and security audits that made that tap reliable.

So the next time a smart device just works, give a small nod to the invisible stack underneath. The clean experience on the surface is the product of a lot of unglamorous engineering refusing to cut corners. That refusal is the whole difference between a gadget you trust and one you return.

This article is adapted by the author with permission from Tech Policy Press. Read the original article.

South Africa is not just another developing country struggling to govern artificial intelligence (AI); it is the exception with leverage, and the window to act on it is closing. It holds approximately 88% of global platinum-group metal reserves, critical inputs to parts of the semiconductor and data center supply chains that make AI infrastructure possible. It hosts the largest data center market on the continent. Its existing hyperscaler relationships give it procurement leverage that most African states will never have. And a major geopolitical contest over AI infrastructure is being fought on its soil right now, between Chinese and American technology companies competing for control of the systems that will underpin an entire continent’s public sector.

In physics, leverage requires three things: a fulcrum, a lever arm and the ability to apply force. The Bushveld Complex, the world’s largest platinum-group metal deposit, is the fulcrum: a mineral endowment that gives South Africa a position in the semiconductor supply chain that no other African state holds. The since-withdrawn draft policy is the lever arm. The unresolved “OPTION” provisions in the policy are where force would be applied. Without a policy that specifies what South Africa wants in return for market access, the lever arm sits unused, and the weight of two of the world’s largest technology ecosystems settles exactly where those ecosystems want it to settle.

This makes South Africa a global test case. Not because its proposed means of governance is exemplary, but because it is the one developing country with enough structural leverage to negotiate genuinely different terms, and the one that is choosing, through inaction, not to. The recent announcement of a new panel to update the draft policy is an important opportunity. But the deeper failure is not that an AI policy contained bad references. It is that no verification process caught them before the document entered the public domain. That is a systems problem, not merely a political one. It points to a missing layer in how governments are adopting AI.

The contest already underway

Last year, Huawei, pitched an emerging product bundle to tech executives across the continent. Huawei was now bundling access to the DeepSeek’s large language model with its own cloud and storage infrastructure. The price differential was stark: in some cases by more than 90%.

At the same time, Microsoft announced plans to spend ZAR 5.4 billion ($300 million) by the end of 2027 on cloud and AI infrastructure in South Africa, building on a prior ZAR 20.4 billion investment. Google, AWS and Oracle already have cloud regions in the country. According to one analysis, the country’s data center market was valued at $2.16 billion in 2024, the largest in Africa.

These are not commercially neutral investments. Huawei’s infrastructure reach has been explicitly linked to Chinese strategic objectives, including a documented track record of providing governments with surveillance infrastructure through its Safe Cities network. US hyperscaler investment comes with its own dependency structure: closed models, pricing set unilaterally and terms of access that no African government has meaningfully shaped. South Africa is being asked to choose between these dependency models without a policy that specifies what it wants in return.

The leverage it has

There is a particular irony in South Africa’s position. The country whose mines supply platinum-group metals essential to semiconductor manufacturing, and through them to AI compute, has drafted a policy that treats it as a consumer of AI systems rather than a stakeholder in their governance. South Africa digs up the minerals that make AI possible. It has no say over the AI built from them.

The AI triad framework covers algorithms, compute, and data. South Africa has no frontier model development capacity. South Africa holds significant data assets in financial services, healthcare and agriculture, with no clear framework for their sovereign management. South Africa possesses PGM leverage of global significance on the compute axis, currently being transferred without meaningful condition. It also has exceptionally high solar irradiance and significant renewable energy potential. A country that can offer both critical mineral inputs and the energy to power the infrastructure those minerals help build occupies a negotiating position of unusual strength.

The Draft Policy proposes no minimum terms for hyperscaler investment, no data sovereignty requirements, no technology transfer conditions and no compute visibility mechanism. Multiple provisions are explicitly left unresolved, marked “OPTION”, including the most consequential choices about how governance will function. Infrastructure decisions made now determine what is renegotiable later, and the answer is: very little.

Three futures, one default

The three infrastructure futures on offer each create a structurally different form of dependency, and only one creates sovereign capability. The Huawei-hosted DeepSeek integration offers low cost and open-source weights, but with data stored on infrastructure potentially accessible under Chinese legal frameworks, creating surveillance dependency in a pattern already documented across Africa. The second is US closed-model dependency: higher capability, more reliable data protection, but complete API dependency on developers abroad. The third is locally hosted open-weight infrastructure: models governed under South African data sovereignty rules, on infrastructure subject to minimum terms, developed with South African data. As Nathan Lambert at Interconnects has observed, open-weight models are likely the only realistic way to get sovereign AI off the ground as a real effort, enabling local communities and economies to integrate meaningfully with the technology. But this requires procurement conditions, not goodwill.

What binding governance looks like

The GovAI “Governing Through the Cloud” framework identifies four roles compute providers should accept as conditions of operating at scale: securers (protecting model weights and training data), record keepers (maintaining infrastructure usage logs), verifiers (confirming customer compliance with safety standards) and enforcers (restricting access when violations occur). These are operational requirements, not theoretical categories — specific, enforceable, and well within the bargaining power of a market of South Africa’s size and mineral position.

A detailed policy analysis submitted to the Department of Communications and Digital Technologies (DCDT) identifies the specific provisions the final policy must contain: mandatory minimum terms for foreign compute infrastructure investments above ZAR 500 million (~$30 million); a compute reporting threshold; a National AI Safety Institute mandate covering defensive monitoring of AI capability accumulation; and National AI Champion Sector designations to create data assets for domestic model development. Each provision converts a structural advantage into a governance instrument before that advantage is foreclosed by market reality. Just as modern software security increasingly depends on knowing what components are inside a system—model provider, training data, compute environment, evaluation methods, update cadence, human review points, and failure-reporting procedures—public-sector AI governance requires a clear account of the stack before deployment, not after a problem surfaces. A public institution that cannot verify the sources in its own AI policy is unlikely to be ready to verify the AI systems it procures, deploys, or regulates.

Why this is the continental test case

South Africa’s choices will establish a regional precedent for what is commercially negotiable in AI infrastructure. If South Africa negotiates data sovereignty guarantees and technology transfer conditions as requirements for hyperscaler investment, it creates a replicable model. If Microsoft’s $300 million investment and Huawei’s infrastructure expansion proceed on standard commercial terms, as they are currently, it normalizes extractive AI infrastructure across the continent. The lesson is not specific to Africa. Governments everywhere are producing AI strategies while lacking AI assurance infrastructure. South Africa is an early warning, not an isolated case.

The public comment period closed when the policy was withdrawn. But a parallel process remains live: the National Treasury’s Draft General Public Procurement Regulations—the legal instrument that will govern every government AI contract—closes for comment on June 15. Those regulations contain no AI-specific provisions.

South Africa has more AI leverage than any country on the continent. Some argue, with force, that governance requirements risk deterring the infrastructure investment South Africa urgently needs: compute capacity, reliable energy, venture capital, and talent retention. That concern deserves a direct answer. Minimum procurement terms, compute reporting thresholds, and technology transfer conditions are not barriers to investment. They are the conditions under which investment serves the host country rather than extracting from it. Infrastructure built without minimum terms produces dependency. Infrastructure built with them produces leverage. To serve the public interest, its AI policy must use it.

When late last month News24 reported AI-hallucinated references in the draft AI policy, Minister of Communications and Digital Technologies Solly Malatsi withdrew the draft policy. That was a mistake that could cost South Africa and the rest of the continent the initiative on this urgent issue. His more recent constitution of an independent panel is a belated step in the right direction, if it can turn South Africa’s leverage into policy. The panel—chaired by Prof Benjamin Rosman of the Wits Machine Intelligence and Neural Discovery Institute, and including Profs Vukosi Marivate and Alison Gillwald of Research ICT Africa, and Dr Jabu Mtsweni of the CSIR—has the technical and governance credibility to produce a stronger document. What it has not yet produced is a timeline. No revised draft has been scheduled. South Africa remains without a formal AI governance framework in the interim.