EAP-TLS কী? সার্টিফিকেট-ভিত্তিক WiFi প্রমাণীকরণ ব্যাখ্যা করা হয়েছে

এই নির্দেশিকাটি EAP-TLS (Extensible Authentication Protocol with Transport Layer Security) সম্পর্কে একটি বিস্তারিত প্রযুক্তিগত রেফারেন্স প্রদান করে, যা এন্টারপ্রাইজ WiFi-এর জন্য উপলব্ধ সবচেয়ে সুরক্ষিত 802.1X প্রমাণীকরণ পদ্ধতি। এটি প্রয়োজনীয় X.509 সার্টিফিকেট অবকাঠামো, পারস্পরিক প্রমাণীকরণ হ্যান্ডশেক এবং আতিথেয়তা, খুচরা, স্বাস্থ্যসেবা এবং সরকারি খাতের পরিবেশের জন্য ব্যবহারিক স্থাপনার ধরণগুলি কভার করে। আইটি ম্যানেজার, নেটওয়ার্ক আর্কিটেক্ট এবং সিটিওরা PKI ডিজাইন, MDM-একীভূত সার্টিফিকেট প্রভিশনিং, RADIUS কনফিগারেশন এবং PCI DSS ও GDPR-এর সাথে সম্মতি সমন্বয়ের বিষয়ে কার্যকরী নির্দেশনা পাবেন।

📖 10 মিনিট পাঠ📝 2,295 শব্দ🔧 2 উদাহরণ❓ 3 প্রশ্ন📚 10 মূল শব্দসমূহ

🎧 এই গাইডটি শুনুন

ট্রান্সক্রিপ্ট দেখুন

INTRO — 0:00 to 1:00

Hello and welcome to this technical briefing from Purple. I'm your host, and today we are unpacking EAP-TLS, or Extensible Authentication Protocol with Transport Layer Security. If you are a network architect, an IT director, or managing infrastructure for large venues like retail chains, hospitals, or stadiums, this briefing is for you. We're cutting through the noise to discuss the most secure 802.1X method available today, exploring why certificate-based authentication is replacing passwords, and how you can practically deploy it in your environment. Let's get straight into it.

TECHNICAL DEEP-DIVE — 1:00 to 6:00

So, what exactly is EAP-TLS? In the world of enterprise WiFi security, it represents the gold standard. Unlike legacy methods such as PEAP or EAP-TTLS which rely on user passwords, EAP-TLS mandates mutual certificate-based authentication. This means the client device must verify the network's identity via a server certificate, and crucially, the network must verify the client's identity via a unique client certificate.

Think about the vulnerability of passwords. They can be shared, phished, or stolen. In a sprawling enterprise environment, a compromised password can grant a bad actor access to your entire internal network. EAP-TLS eliminates this vector entirely. The authentication relies on X.509 certificates issued by a Public Key Infrastructure, or PKI.

Let's walk through the handshake. When a device attempts to connect, the access point acts as the authenticator, forwarding the request to a RADIUS server. The RADIUS server presents its certificate. The client validates this against its trusted root store. If valid, the client then presents its own certificate. The RADIUS server checks this client certificate against the Certificate Authority and verifies it has not been revoked using a Certificate Revocation List or OCSP. Only when both sides are satisfied does the TLS tunnel establish and the EAP-Success message is sent, granting network access.

The cryptographic strength here is formidable. By leveraging TLS 1.2 or 1.3, EAP-TLS ensures perfect forward secrecy and robust encryption. This is why highly regulated sectors — think finance, government, and healthcare — mandate EAP-TLS for compliance frameworks like PCI DSS and HIPAA.

Now, a word on the infrastructure that makes this work: the PKI. Your PKI consists of at minimum a root Certificate Authority and an issuing Certificate Authority. The root CA should be kept completely offline — air-gapped — because its private key is the master trust anchor for your entire certificate hierarchy. The issuing CA handles day-to-day certificate issuance and publishes the Certificate Revocation List. Client certificates are issued to individual devices, not users — this is a device-identity model, not a user-identity model. That distinction matters enormously for IoT devices, shared terminals, and headless systems.

IMPLEMENTATION RECOMMENDATIONS AND PITFALLS — 6:00 to 8:00

Deploying EAP-TLS is highly secure, but it is not without complexity. The primary challenge is lifecycle management of certificates. You cannot manually install certificates on thousands of devices.

For a successful deployment, automation is non-negotiable. You must integrate your PKI with Mobile Device Management, or MDM, or Enterprise Mobility Management platforms. Protocols like SCEP — the Simple Certificate Enrollment Protocol — or EST, Enrollment over Secure Transport, allow for zero-touch provisioning. When a corporate device is powered on, it automatically requests and receives its certificate without user intervention.

A common pitfall is neglecting the revocation process. If a laptop is stolen, you must be able to revoke its certificate immediately. Ensure your RADIUS server is configured to frequently check the CRL or use OCSP for real-time validation. Furthermore, consider the BYOD — Bring Your Own Device — scenario. For unmanaged devices, EAP-TLS can be cumbersome. This is where onboarding portals come in, securely provisioning a temporary certificate to a guest or contractor device.

The other critical pitfall: failing to enforce server certificate validation on client supplicants. This is the most common misconfiguration we see in 802.1X deployments. If your client devices are not configured to validate the RADIUS server's certificate against a specific trusted CA, they will connect to any server presenting any certificate — including a rogue access point. Always specify the trusted CA and the expected server name in your MDM-deployed WiFi profiles.

RAPID-FIRE Q&A — 8:00 to 9:00

Let's tackle a few rapid-fire questions we often hear from CTOs.

Question one: Is EAP-TLS required for WPA3 Enterprise? While WPA3 Enterprise supports other methods, EAP-TLS is strongly recommended and is required if you are implementing the WPA3 Enterprise 192-bit security suite, often called Suite B.

Question two: Can we use public certificates for clients? No. You must use a private internal CA for client certificates. Public CAs are for public-facing web servers. Your internal RADIUS server needs to trust your specific internal Root CA to validate your corporate devices.

Question three: How does this fit with OpenRoaming? OpenRoaming relies on Passpoint and 802.1X. Purple acts as a free identity provider for services like OpenRoaming under the Connect license, facilitating seamless, secure roaming across venues using underlying certificate and identity frameworks.

SUMMARY AND NEXT STEPS — 9:00 to 10:00

To wrap up, EAP-TLS is the definitive choice for securing enterprise wireless networks against credential theft and man-in-the-middle attacks. It shifts the security paradigm from what you know to what you have.

Your next steps? Audit your current 802.1X deployment. If you are still relying on MSCHAPv2 and passwords, it's time to architect a PKI and plan your migration to EAP-TLS. Focus on automating certificate enrollment via your MDM. And critically — check whether your client supplicants are validating the server certificate. That single configuration check could be the most impactful security improvement you make this quarter.

Thank you for listening to this technical briefing from Purple. For more detailed deployment guides and to understand how our analytics and identity platforms can integrate with your secure networks, visit purple dot ai.

মূল বিষয়সমূহ

✓EAP-TLS is the most secure 802.1X authentication method, using mutual X.509 certificate authentication to eliminate credential theft and rogue AP attacks — both the client and the RADIUS server must present valid certificates before network access is granted.
✓A functional PKI is the non-negotiable prerequisite: deploy a two-tier hierarchy (offline root CA + online issuing CA) and configure CRL or OCSP revocation checking on your RADIUS server before deploying EAP-TLS.
✓Certificate lifecycle automation via MDM and SCEP/EST is essential at scale — manual certificate installation does not work beyond a handful of devices, and unmanaged certificate expiry is the most common cause of mass authentication failures.
✓Server certificate validation must be enforced on every client supplicant — leaving it unconfigured or disabled negates EAP-TLS's protection against rogue access point attacks and is the single most impactful misconfiguration to audit.
✓EAP-TLS satisfies PCI DSS 4.0 Requirement 8.6 for multi-factor authentication at the network layer, making it the correct choice for any wireless network in scope for cardholder data processing.
✓For distributed environments (retail chains, hotel groups, conference venues), cloud-hosted RADIUS services and managed PKI providers significantly reduce the operational burden of EAP-TLS deployment without compromising security.
✓Dynamic VLAN assignment via RADIUS certificate attributes enables cryptographically-enforced network segmentation — placing devices on the correct network segment based on certificate properties rather than relying on SSID selection or MAC address filtering.

কার্যনির্বাহী সারসংক্ষেপ

EAP-TLS (Extensible Authentication Protocol – Transport Layer Security) হলো IEEE 802.1X প্রমাণীকরণ পদ্ধতি যা আপনার ওয়্যারলেস প্রমাণীকরণ চেইন থেকে শেয়ার করা শংসাপত্রগুলি সম্পূর্ণরূপে সরিয়ে দেয়। যেখানে PEAP এবং EAP-TTLS একটি এনক্রিপ্ট করা টানেলের মাধ্যমে প্রেরিত ব্যবহারকারীর নাম এবং পাসওয়ার্ডের উপর নির্ভর করে, সেখানে EAP-TLS-এর জন্য ক্লায়েন্ট ডিভাইস এবং RADIUS সার্ভার উভয়কেই একটি বিশ্বস্ত Certificate Authority (CA) দ্বারা জারি করা বৈধ X.509 সার্টিফিকেট উপস্থাপন করতে হয়। এই পারস্পরিক প্রমাণীকরণ মডেলের অর্থ হলো একটি চুরি হওয়া পাসওয়ার্ড অপ্রাসঙ্গিক — একটি বৈধ, বাতিল না হওয়া সার্টিফিকেট ছাড়া, একটি ডিভাইস নেটওয়ার্কে যোগ দিতে পারে না।

হোটেল, খুচরা এস্টেট বা সম্মেলন কেন্দ্র জুড়ে Guest WiFi পরিচালনা করা ভেন্যু অপারেটরদের জন্য এবং কর্মী ও IoT ডিভাইস নেটওয়ার্কের জন্য দায়ী আইটি দলগুলির জন্য, EAP-TLS ওয়্যারলেস প্রমাণীকরণ সুরক্ষার বর্তমান সর্বোচ্চ স্তরকে প্রতিনিধিত্ব করে। এটি PCI DSS 4.0 দ্বারা কার্ডহোল্ডার ডেটা পরিবেশের জন্য বাধ্যতামূলক বা দৃঢ়ভাবে সুপারিশকৃত, HIPAA দ্বারা স্বাস্থ্যসেবা ওয়্যারলেস নেটওয়ার্কের জন্য এবং WPA3 Enterprise 192-bit (Suite B) স্থাপনার জন্য প্রয়োজনীয় পদ্ধতি।

স্থাপনার অতিরিক্ত খরচ বাস্তব — সার্টিফিকেট লাইফসাইকেল ম্যানেজমেন্ট, PKI অবকাঠামো এবং MDM ইন্টিগ্রেশন সহজ নয় — তবে সুরক্ষার ROI যথেষ্ট। এই নির্দেশিকাটি স্থাপত্য, হ্যান্ডশেক, স্থাপনার ধরণ এবং কর্মক্ষম অনুশীলনগুলি নিয়ে আলোচনা করে যা নির্ধারণ করে যে একটি EAP-TLS রোলআউট সফল হবে নাকি থমকে যাবে।

প্রযুক্তিগত গভীর-পর্যালোচনা

EAP-TLS আসলে কী করে

EAP-TLS 802.1X পোর্ট-ভিত্তিক অ্যাক্সেস কন্ট্রোল ফ্রেমওয়ার্কের মধ্যে কাজ করে। প্রতিটি প্রমাণীকরণ বিনিময়ের তিনটি অভিনেতা হলো সাপ্লিক্যান্ট (ক্লায়েন্ট ডিভাইস), অথেন্টিকেটর (ওয়্যারলেস অ্যাক্সেস পয়েন্ট বা পরিচালিত সুইচ), এবং প্রমাণীকরণ সার্ভার (সাধারণত একটি RADIUS সার্ভার যেমন FreeRADIUS, Microsoft NPS, বা Cisco ISE)। অ্যাক্সেস পয়েন্ট নিজে প্রমাণীকরণ সিদ্ধান্ত নেয় না — এটি একটি স্বচ্ছ রিলে হিসাবে কাজ করে, RADIUS প্যাকেটে EAP বার্তাগুলিকে এনক্যাপসুলেট করে এবং প্রমাণীকরণ সার্ভারে ফরোয়ার্ড করে।

RADIUS কীভাবে এই স্থাপত্যকে সমর্থন করে সে সম্পর্কে গভীর বোঝার জন্য, দেখুন RADIUS কী? RADIUS সার্ভারগুলি কীভাবে WiFi নেটওয়ার্কগুলিকে সুরক্ষিত করে ।

EAP-TLS হ্যান্ডশেক নিম্নরূপ সম্পন্ন হয়:

অ্যাক্সেস পয়েন্ট সংযোগকারী ডিভাইসে একটি EAP-Request/Identity পাঠায়।
ডিভাইসটি তার পরিচয় দিয়ে সাড়া দেয় (সাধারণত ব্যবহারকারীর নাম আড়ি পাতা থেকে রক্ষা করার জন্য একটি বেনামী বাইরের পরিচয়)।
RADIUS সার্ভার একটি EAP-TLS/Start বার্তা দিয়ে TLS হ্যান্ডশেক শুরু করে।
ক্লায়েন্ট একটি ClientHello পাঠায়, তার সমর্থিত TLS সাইফার স্যুটগুলি বিজ্ঞাপন করে।
RADIUS সার্ভার ServerHello, তার X.509 সার্ভার সার্টিফিকেট এবং একটি সার্টিফিকেট অনুরোধের সাথে সাড়া দেয়।
ক্লায়েন্ট তার বিশ্বস্ত রুট CA স্টোরের বিরুদ্ধে সার্ভার সার্টিফিকেট যাচাই করে। যদি যাচাইকরণ ব্যর্থ হয়, হ্যান্ডশেকটি বন্ধ হয়ে যায় — যা দুর্বৃত্ত অ্যাক্সেস পয়েন্টগুলির বিরুদ্ধে সুরক্ষা প্রদান করে।
ক্লায়েন্ট তার নিজস্ব X.509 ক্লায়েন্ট সার্টিফিকেট উপস্থাপন করে।
RADIUS সার্ভার ক্লায়েন্ট সার্টিফিকেট যাচাই করে: এটি বিশ্বস্ত রুট CA-তে স্বাক্ষর চেইন পরীক্ষা করে, সার্টিফিকেট মেয়াদোত্তীর্ণ হয়নি তা যাচাই করে এবং সার্টিফিকেট বাতিল হয়নি তা নিশ্চিত করতে Certificate Revocation List (CRL) পরীক্ষা করে বা OCSP রেসপন্ডারকে জিজ্ঞাসা করে।
উভয় পক্ষ TLS মাস্টার সিক্রেট থেকে সেশন কীগুলি বের করে। RADIUS সার্ভার একটি EAP-Success পাঠায় এবং অ্যাক্সেস পয়েন্ট নিয়ন্ত্রিত পোর্টটি খোলে।

ডিভাইসটিকে কোনো নেটওয়ার্ক অ্যাক্সেস দেওয়ার আগেই পুরো বিনিময়টি ঘটে। কোনো সময়েই কোনো পাসওয়ার্ড প্রেরণ করা হয় না। ব্যুৎপন্ন সেশন কীগুলি প্রতি-সেশনে অনন্য, যা ECDHE সাইফার স্যুট ব্যবহার করার সময় perfect forward secrecy প্রদান করে — যার অর্থ একটি সার্টিফিকেট পরে আপস করা হলেও ঐতিহাসিক ট্র্যাফিক ডিক্রিপ্ট করা যাবে না।

X.509 সার্টিফিকেট এবং PKI স্থাপত্য

EAP-TLS-এর নিরাপত্তা সম্পূর্ণরূপে অন্তর্নিহিত PKI-এর অখণ্ডতার উপর নির্ভরশীল। EAP-TLS-এর জন্য একটি সাধারণ এন্টারপ্রাইজ PKI তিনটি স্তরে গঠিত:

স্তর	উপাদান	ভূমিকা
রুট CA	অফলাইন রুট সার্টিফিকেট অথরিটি	ইন্টারমিডিয়েট CA সার্টিফিকেট স্বাক্ষর করে; এয়ার-গ্যাপড রাখা হয়
ইন্টারমিডিয়েট CA	অনলাইন ইস্যুকারী CA	সার্ভার এবং ক্লায়েন্ট সার্টিফিকেট ইস্যু করে; CRL প্রকাশনা পরিচালনা করে
শেষ সত্তা	RADIUS সার্ভার সার্টিফিকেট + ক্লায়েন্ট সার্টিফিকেট	লাইভ প্রমাণীকরণ হ্যান্ডশেকে ব্যবহৃত হয়

রুট CA অফলাইন এবং এয়ার-গ্যাপড রাখা উচিত। এর ব্যক্তিগত কী, যদি আপস করা হয়, তাহলে আপনার পুরো সার্টিফিকেট হায়ারার্কিকে অবৈধ করে দেবে। ইন্টারমিডিয়েট CA দৈনন্দিন ইস্যু করা এবং CRL প্রকাশনা পরিচালনা করে। ক্লায়েন্ট সার্টিফিকেটগুলি পৃথক ডিভাইসগুলিতে (ব্যবহারকারীদের নয়) জারি করা হয়, সাধারণত একটি Subject Alternative Name (SAN) সহ যা ডিভাইসের MAC ঠিকানা বা আপনার MDM থেকে একটি ডিভাইস শনাক্তকারী ধারণ করে।

EAP-TLS বনাম অন্যান্য 802.1X পদ্ধতি

উপরের সারণীটি ব্যাখ্যা করে কেন EAP-TLS নিয়ন্ত্রিত পরিবেশের জন্য প্রস্তাবিত পছন্দ। PEAP-MSCHAPv2, যা এখনও সবচেয়ে ব্যাপকভাবে ব্যবহৃত 802.1X পদ্ধতি, এর পরিচিত দুর্বলতা রয়েছে: সার্ভার সার্টিফিকেট প্রায়শই ক্লায়েন্টদের দ্বারা যাচাই করা হয় না (একটি ভুল কনফিগারেশন যা rogue AP আক্রমণ সক্ষম করে), এবং MSCHAPv2 নিজেই 2012 সাল থেকে ক্রিপ্টোগ্রাফিকভাবে ভেঙে গেছে। EAP-TLS উভয় আক্রমণের পৃষ্ঠকে সরিয়ে দেয়।

WPA2 Enterprise এবং WPA3 Enterprise

EAP-TLS WPA2 Enterprise (IEEE 802.11i) এবং WPA3 Enterprise (IEEE 802.11ax) উভয় ক্ষেত্রেই অভিন্নভাবে কাজ করে। পার্থক্যটি হলো সাইফার স্যুটে যা আলোচনা করা হয় ওয়্যারলেস ডেটা এনক্রিপশন স্তরের জন্য। WPA3 Enterprise Protected Management Frames (PMF) বাধ্যতামূলক করে এবং একটি ঐচ্ছিক 192-বিট নিরাপত্তা মোড (Suite B) অফার করে যার জন্য নির্দিষ্ট ইলিপটিক কার্ভ সাইফার স্যুট (ECDHE + ECDSA অথবা RSA-3072) সহ EAP-TLS প্রয়োজন। বেশিরভাগ এন্টারপ্রাইজ স্থাপনার জন্য, EAP-TLS এবং স্ট্যান্ডার্ড AES-256 সাইফার স্যুট সহ WPA3 Enterprise হল উপযুক্ত লক্ষ্য অবস্থা।

বাস্তবায়ন নির্দেশিকা

পর্যায় 1: PKI ডিজাইন এবং স্থাপন

একটি একক অ্যাক্সেস পয়েন্ট কনফিগার করার আগে, PKI অবশ্যই স্থাপন করা থাকতে হবে। বিদ্যমান অভ্যন্তরীণ CA ছাড়া সংস্থাগুলির জন্য, Windows পরিবেশে Microsoft Active Directory Certificate Services (AD CS) হল সবচেয়ে সাধারণ পছন্দ। ক্রস-প্ল্যাটফর্ম বা ক্লাউড-নেটিভ স্থাপনার জন্য, HashiCorp Vault PKI, EJBCA, অথবা AWS Private CA-এর মতো একটি পরিচালিত PKI পরিষেবা কার্যকর বিকল্প।

এই পর্যায়ে মূল সিদ্ধান্তগুলি:

শংসাপত্রের বৈধতার সময়কাল: 1-2 বছরের ক্লায়েন্ট শংসাপত্রগুলি নিরাপত্তা এবং অপারেশনাল ওভারহেডের মধ্যে ভারসাম্য বজায় রাখে। স্বল্প সময়কাল বাতিলকরণ ইভেন্ট বাড়ায়; দীর্ঘ সময়কাল আপসকৃত শংসাপত্রের জন্য এক্সপোজারের উইন্ডো বাড়ায়।
কী অ্যালগরিদম: RSA-2048 এখনও ব্যাপকভাবে সমর্থিত। ECDSA P-256 ছোট শংসাপত্রের আকার এবং দ্রুত হ্যান্ডশেক সহ সমতুল্য নিরাপত্তা প্রদান করে — নতুন স্থাপনার জন্য প্রস্তাবিত।
CRL বনাম OCSP: CRL বিতরণ বাস্তবায়ন করা সহজ কিন্তু লেটেন্সি এবং ক্যাশিং সমস্যা তৈরি করে। OCSP রিয়েল-টাইম বাতিলকরণ স্থিতি প্রদান করে। উচ্চ-নিরাপত্তা পরিবেশের জন্য, RADIUS সার্ভারে OCSP স্ট্যাপলিং হল পছন্দের পদ্ধতি।

পর্যায় 2: RADIUS সার্ভার কনফিগারেশন

আপনার RADIUS সার্ভারকে অবশ্যই নিম্নলিখিতভাবে কনফিগার করতে হবে:

সংযোগকারী ক্লায়েন্টদের কাছে তার সার্ভার শংসাপত্র (আপনার অভ্যন্তরীণ CA দ্বারা জারি করা) উপস্থাপন করা।
ক্লায়েন্ট শংসাপত্র যাচাইকরণের জন্য শুধুমাত্র আপনার অভ্যন্তরীণ রুট এবং ইন্টারমিডিয়েট CA-গুলিকে বিশ্বাস করা — ক্লায়েন্ট প্রমাণীকরণের জন্য পাবলিক CA-গুলিকে বিশ্বাস করবেন না।
উপস্থাপিত প্রতিটি ক্লায়েন্ট শংসাপত্রের উপর CRL বা OCSP চেক করা।
শংসাপত্রের বৈশিষ্ট্যগুলি (Common Name, SAN, বা OID এক্সটেনশন) নেটওয়ার্ক নীতি নিয়মগুলির সাথে ম্যাপ করা — উদাহরণস্বরূপ, শংসাপত্রের বৈশিষ্ট্যগুলির উপর ভিত্তি করে ডিভাইসগুলিকে নির্দিষ্ট VLAN-এ বরাদ্দ করা।

RADIUS সার্ভার আর্কিটেকচার এবং কনফিগারেশনের বিস্তারিত জানার জন্য, What Is RADIUS? How RADIUS Servers Secure WiFi Networks দেখুন।

পর্যায় 3: MDM/SCEP এর মাধ্যমে শংসাপত্র বিতরণ

ম্যানুয়াল শংসাপত্র ইনস্টলেশন স্কেলযোগ্য নয়। অল্প সংখ্যক ডিভাইসের বাইরে যেকোনো স্থাপনার জন্য, শংসাপত্র সরবরাহ স্বয়ংক্রিয় হতে হবে। স্ট্যান্ডার্ড পদ্ধতি হল:

পরিচালিত কর্পোরেট ডিভাইস: আপনার PKI কে আপনার MDM প্ল্যাটফর্মের (Microsoft Intune, Jamf, VMware Workspace ONE) সাথে একত্রিত করুন। একটি SCEP বা EST প্রোফাইল কনফিগার করুন যা একটি ডিভাইস নথিভুক্ত হলে স্বয়ংক্রিয়ভাবে একটি ক্লায়েন্ট শংসাপত্র অনুরোধ করে এবং ইনস্টল করে। শংসাপত্রটি ডিভাইসের TPM বা Secure Enclave-এর সাথে আবদ্ধ থাকে যেখানে সমর্থিত, যা শংসাপত্র রপ্তানি প্রতিরোধ করে।
BYOD এবং ঠিকাদার ডিভাইস: একটি অনবোর্ডিং পোর্টাল (যেমন Cisco ISE-এর Guest পোর্টাল বা একটি ডেডিকেটেড BYOD সমাধান) স্থাপন করুন যা ব্যবহারকারীকে এককালীন শংসাপত্র ইনস্টলেশন প্রক্রিয়ার মাধ্যমে পরিচালিত করে। স্বল্প বৈধতার সময়কালের সাথে শংসাপত্র জারি করুন এবং VLAN নীতির মাধ্যমে নেটওয়ার্ক অ্যাক্সেস সীমাবদ্ধ করুন।
IoT এবং হেডলেস ডিভাইস: প্রি-শেয়ার্ড চ্যালেঞ্জ পাসওয়ার্ড সহ SCEP বা বুটস্ট্র্যাপ শংসাপত্র সহ EST ব্যবহার করুন। মেয়াদ শেষ হওয়ার আগে একই প্রোটোকলের মাধ্যমে শংসাপত্র নবায়ন স্বয়ংক্রিয় হওয়া উচিত।

পর্যায় 4: অ্যাক্সেস পয়েন্ট এবং SSID কনফিগারেশন

কর্পোরেট SSID নিম্নলিখিতভাবে কনফিগার করুন:

নিরাপত্তা: WPA2 Enterprise অথবা WPA3 Enterprise (802.1X)
EAP প্রকার: EAP-TLS
RADIUS সার্ভার: শেয়ার্ড সিক্রেট সহ আপনার প্রমাণীকরণ সার্ভারের দিকে নির্দেশ করুন
VLAN অ্যাসাইনমেন্ট: RADIUS অ্যাট্রিবিউটের মাধ্যমে ডাইনামিক VLAN অ্যাসাইনমেন্ট সক্ষম করুন (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-ID)
PMF: WPA3 এর জন্য বাধ্যতামূলক; WPA2 এর জন্য দৃঢ়ভাবে প্রস্তাবিত

পর্যায় 5: ক্লায়েন্ট সাপ্লিক্যান্ট কনফিগারেশন

Group Policy বা Intune এর মাধ্যমে পরিচালিত Windows ডিভাইসগুলির জন্য, একটি Wired/Wireless Network Policy স্থাপন করুন যা EAP-TLS, বিশ্বস্ত রুট CA, এবং শংসাপত্র নির্বাচনের মানদণ্ড নির্দিষ্ট করে। macOS এবং iOS-এ, একটি কনফিগারেশন প্রোফাইল স্থাপন করুন। Android-এ, MDM-পরিচালিত WiFi প্রোফাইল ব্যবহার করুন। সমালোচনামূলকভাবে, সার্ভার শংসাপত্র যাচাইকরণ প্রয়োগ করুন — সঠিক CA এবং সার্ভারের নাম নির্দিষ্ট করুন। এটি পরীক্ষা না করা 802.1X স্থাপনার ক্ষেত্রে সবচেয়ে সাধারণ ভুল কনফিগারেশন।

সর্বোত্তম অনুশীলন

সমস্ত সাপ্লিক্যান্টে সার্ভার শংসাপত্র যাচাইকরণ প্রয়োগ করুন। 802.1X স্থাপনার ক্ষেত্রে সবচেয়ে শোষণযোগ্য ভুল কনফিগারেশন হল ক্লায়েন্টরা যে কোনো সার্ভার শংসাপত্র গ্রহণ করে, যা দুর্বৃত্ত অ্যাক্সেস পয়েন্ট আক্রমণ সক্ষম করে। প্রতিটি MDM-স্থাপিত WiFi প্রোফাইলে বিশ্বস্ত CA এবং প্রত্যাশিত সার্ভারের নাম (CN বা SAN) নির্দিষ্ট করা উচিত।

মেয়াদ শেষ হওয়ার আগে শংসাপত্র নবায়ন স্বয়ংক্রিয় করুন। শংসাপত্রগুলি মেয়াদ শেষ হওয়ার 30 দিনের মধ্যে থাকলে সতর্ক করার জন্য মনিটরিং সেট আপ করুন। SCEP বা EST স্বয়ংক্রিয় নবায়ন কনফিগার করুন যাতে ডিভাইসগুলি ব্যবহারকারীর হস্তক্ষেপ ছাড়াই শংসাপত্র নবায়ন করে। একটি ব্যাপক শংসাপত্র মেয়াদ শেষ হওয়ার ঘটনা একটি এন্টারপ্রাইজ নেটওয়ার্ক দল যে সবচেয়ে বিঘ্নিত ঘটনার মুখোমুখি হতে পারে তার মধ্যে অন্যতম।

যেখানে সম্ভব CRL এর পরিবর্তে OCSP প্রয়োগ করুন। CRL ফাইলগুলি বড় হতে পারে এবং ক্লায়েন্টদের দ্বারা ক্যাশ করা হয়, যার অর্থ সম্প্রতি বাতিল করা শংসাপত্র ক্যাশ শেষ না হওয়া পর্যন্ত গৃহীত হতে পারে। OCSP রিয়েল-টাইম স্থিতি প্রদান করে এবং উচ্চ-নিরাপত্তা পরিবেশের জন্য পছন্দের বাতিলকরণ প্রক্রিয়া।

আপনার PKI কে বিভক্ত করুন। বিভিন্ন শংসাপত্র শ্রেণীর জন্য পৃথক ইন্টারমিডিয়েট CA ব্যবহার করুন: একটি RADIUS সার্ভার শংসাপত্রের জন্য, একটি ক্লায়েন্ট ডিভাইস শংসাপত্রের জন্য, একটি ব্যবহারকারী শংসাপত্রের জন্য। এটি একটি CA আপসের বিস্ফোরণ ব্যাসার্ধকে সীমাবদ্ধ করে এবং বাতিলকরণ নীতিকে সরল করে।

প্রমাণীকরণ ইভেন্টগুলি লগ করুন এবং নিরীক্ষণ করুন। আপনার RADIUS সার্ভার প্রতিটি সংযোগ প্রচেষ্টার জন্য একটি প্রমাণীকরণ লগ তৈরি করে। এই লগগুলি আপনার SIEM-এ ফিড করুন। বারবার প্রমাণীকরণ ব্যর্থতা, শংসাপত্র যাচাইকরণ ত্রুটি, বা অপ্রত্যাশিত MAC ঠিকানা থেকে সংযোগের মতো প্যাটার্নগুলি ভুল কনফিগারেশন বা আক্রমণের প্রাথমিক সূচক।

PCI DSS 4.0 এর সাথে সারিবদ্ধ হন। প্রয়োজনীয়তা 8.6 সিস্টেম উপাদানগুলির জন্য শক্তিশালী প্রমাণীকরণ বাধ্যতামূলক করে। PCI DSS এর আওতাধীন ওয়্যারলেস নেটওয়ার্কগুলির জন্য, শংসাপত্র-ভিত্তিক প্রমাণীকরণ সহ EAP-TLSটিকশন নেটওয়ার্ক স্তরে মাল্টি-ফ্যাক্টর প্রমাণীকরণের প্রয়োজনীয়তা পূরণ করে, কারণ সার্টিফিকেট (আপনার কাছে যা আছে) ডিভাইসের TPM-বাউন্ড প্রাইভেট কী (আপনি যা) এর সাথে মিলিত হয়ে দুটি ফ্যাক্টর গঠন করে।

সমস্যা সমাধান ও ঝুঁকি প্রশমন

সাধারণ ব্যর্থতার ধরণ

ব্যর্থতার ধরণ	লক্ষণ	মূল কারণ	সমাধান
সার্টিফিকেট চেইন বৈধকরণ ব্যর্থতা	সার্ভার সার্টিফিকেট বিনিময়ের পর EAP-ব্যর্থতা	ক্লায়েন্ট RADIUS সার্ভারের CA-কে বিশ্বাস করে না	MDM এর মাধ্যমে ডিভাইসের ট্রাস্ট স্টোরে রুট CA সার্টিফিকেট পুশ করুন
ক্লায়েন্ট সার্টিফিকেট উপস্থাপন করা হয়নি	সার্ভার সার্টিফিকেটের পর প্রমাণীকরণ বন্ধ হয়ে যায়	কোন ক্লায়েন্ট সার্টিফিকেট ইনস্টল করা নেই বা ভুল সার্টিফিকেট নির্বাচন করা হয়েছে	SCEP তালিকাভুক্তি সম্পন্ন হয়েছে কিনা যাচাই করুন; MDM প্রোফাইল পরীক্ষা করুন
OCSP/CRL পৌঁছানো যায় না	মাঝে মাঝে প্রমাণীকরণ ব্যর্থতা	RADIUS সার্ভার বাতিলকরণ এন্ডপয়েন্টে পৌঁছাতে পারে না	নিশ্চিত করুন যে OCSP/CRL URL গুলি RADIUS সার্ভার থেকে অ্যাক্সেসযোগ্য; স্থানীয় CRL ক্যাশিং প্রয়োগ করুন
সার্টিফিকেটের মেয়াদ শেষ	সব ডিভাইস একই সাথে প্রমাণীকরণে ব্যর্থ হয়	নবায়ন স্বয়ংক্রিয়করণ কনফিগার করা হয়নি	৩০ দিনের মেয়াদোত্তীর্ণ সতর্কতা প্রয়োগ করুন; SCEP স্বয়ংক্রিয়-নবায়ন কনফিগার করুন
রোগ AP আক্রমণ	ব্যবহারকারীরা দূষিত AP-এর সাথে সংযুক্ত হয়	সাপ্লিক্যান্টে সার্ভার সার্টিফিকেট বৈধকরণ অক্ষম করা হয়েছে	সমস্ত MDM WiFi প্রোফাইলে সার্ভার সার্টিফিকেট বৈধকরণ প্রয়োগ করুন
VLAN অ্যাসাইনমেন্ট ব্যর্থতা	ডিভাইস সংযুক্ত হয় কিন্তু ভুল নেটওয়ার্ক সেগমেন্ট পায়	RADIUS অ্যাট্রিবিউট ভুলভাবে কনফিগার করা হয়েছে	Tunnel-Type (13=VLAN), Tunnel-Medium-Type (6=802), Tunnel-Private-Group-ID (VLAN ID) যাচাই করুন

বৃহৎ আকারের স্থাপনার জন্য ঝুঁকি প্রশমন

একাধিক সম্পত্তি জুড়ে শত শত অ্যাক্সেস পয়েন্ট সহ আতিথেয়তা পরিবেশের জন্য, এবং বিতরণ করা সাইট সহ খুচরা চেইনগুলির জন্য, প্রাথমিক অপারেশনাল ঝুঁকি হল একটি সিঙ্ক্রোনাইজড সার্টিফিকেট মেয়াদোত্তীর্ণের ঘটনা। ডিভাইস গ্রুপ জুড়ে সার্টিফিকেট ইস্যু করার তারিখগুলি পর্যায়ক্রমে সাজান যাতে নবায়নগুলি একই সাথে না হয়ে সময়ের সাথে সাথে বিতরণ করা হয়। আপনার MDM-এ একটি সার্টিফিকেট ইনভেন্টরি বজায় রাখুন এবং ৬০ দিনের মধ্যে মেয়াদোত্তীর্ণ হওয়া সার্টিফিকেটগুলির উপর সাপ্তাহিক প্রতিবেদন চালান।

স্বাস্থ্যসেবা পরিবেশের জন্য, অতিরিক্ত ঝুঁকি হল প্রমাণীকরণ বিলম্ব যা ক্লিনিকাল ওয়ার্কফ্লোকে প্রভাবিত করে। রাউন্ড-ট্রিপ সময় কমাতে আপনার RADIUS সার্ভার স্থাপন অপ্টিমাইজ করুন। প্রমাণীকরণের জন্য WAN নির্ভরতা কমাতে প্রতিটি সাইটে RADIUS প্রক্সি সার্ভার স্থাপনের কথা বিবেচনা করুন।

ROI ও ব্যবসায়িক প্রভাব

নিরাপত্তা বিনিয়োগের পরিমাণ নির্ধারণ

পাসওয়ার্ড-ভিত্তিক 802.1X এর উপর EAP-TLS এর ব্যবসায়িক যুক্তি ডেটা লঙ্ঘনের খরচের বিপরীতে বিবেচনা করলে সহজবোধ্য। ২০২৪ সালে যুক্তরাজ্যে একটি ডেটা লঙ্ঘনের গড় খরচ ছিল £৩.৫৮ মিলিয়ন (IBM Cost of a Data Breach Report)। এন্টারপ্রাইজ লঙ্ঘনের একটি উল্লেখযোগ্য অংশ আপোসকৃত শংসাপত্র থেকে উদ্ভূত হয়। EAP-TLS নেটওয়ার্ক অ্যাক্সেসের জন্য শংসাপত্র চুরির ভেক্টর সম্পূর্ণরূপে দূর করে।

PCI DSS এর অধীন সংস্থাগুলির জন্য, কার্ডহোল্ডার ডেটা প্রকাশের ফলে একটি ওয়্যারলেস নেটওয়ার্ক লঙ্ঘনের জন্য জরিমানা, ফরেনসিক তদন্ত খরচ এবং সম্ভাব্য কার্ড স্কিম জরিমানা হয় যা একটি PKI স্থাপনার খরচকে ম্লান করে দেয়। শুধুমাত্র সম্মতি সারিবদ্ধতা ওয়্যারলেস অবকাঠামোর মাধ্যমে কার্ড পেমেন্ট প্রক্রিয়া করা যেকোনো সংস্থার জন্য বিনিয়োগকে ন্যায্যতা দেয়।

অপারেশনাল দক্ষতার লাভ

বিপরীতভাবে, MDM-একীভূত সার্টিফিকেট প্রভিশনিং সহ একটি সু-বাস্তবায়িত EAP-TLS স্থাপনা পাসওয়ার্ড-ভিত্তিক 802.1X এর তুলনায় হেল্পডেস্কের চাপ কমাতে পারে। পাসওয়ার্ড রিসেট, শেয়ার্ড ক্রেডেনশিয়াল ম্যানেজমেন্ট এবং "আমি WiFi এর সাথে কেন সংযোগ করতে পারছি না" এই ধরনের টিকিটগুলি বাদ দেওয়া হয়। প্রাথমিক স্থাপনার প্রচেষ্টা সামনে-ভারী, তবে স্থিতিশীল-অবস্থার অপারেশনগুলি কম-স্পর্শী।

নিরাপদ স্টাফ নেটওয়ার্কের পাশাপাশি WiFi Analytics স্থাপনকারী ভেন্যু অপারেটরদের জন্য, EAP-TLS এবং ডায়নামিক VLAN অ্যাসাইনমেন্ট দ্বারা সক্ষম বিভাজন মানে একই ফিজিক্যাল অবকাঠামোতে গেস্ট ট্র্যাফিক, স্টাফ ট্র্যাফিক এবং IoT ডিভাইস ট্র্যাফিক পরিষ্কারভাবে আলাদা করা যেতে পারে — হার্ডওয়্যার খরচ কমানোর পাশাপাশি নিরাপত্তা অবস্থান উন্নত করে।

নিরাপদ এন্টারপ্রাইজ WiFi-এ Purple-এর ভূমিকা

Purple-এর প্ল্যাটফর্ম Guest WiFi এবং এন্টারপ্রাইজ নেটওয়ার্ক ইন্টেলিজেন্সের সংযোগস্থলে কাজ করে। কর্মচারী এবং কর্পোরেট ডিভাইস নেটওয়ার্কগুলির জন্য, EAP-TLS প্রমাণীকরণ স্তর সরবরাহ করে। Purple-এর WiFi Analytics প্ল্যাটফর্ম এর উপরে অবস্থিত, যা নেটওয়ার্ক ব্যবহারের ধরণ, ডিভাইসের থাকার সময় এবং ভেন্যুতে পদচারণা সম্পর্কে দৃশ্যমানতা প্রদান করে — এই ডেটা তখনই অর্থপূর্ণ হয় যখন অন্তর্নিহিত নেটওয়ার্ক সঠিকভাবে বিভক্ত এবং প্রমাণীকৃত হয়।

ভেন্যু জুড়ে OpenRoaming এবং Passpoint-ভিত্তিক নির্বিঘ্ন সংযোগ অন্বেষণকারী সংস্থাগুলির জন্য, Purple Connect লাইসেন্সের অধীনে একটি বিনামূল্যে পরিচয় প্রদানকারী হিসাবে কাজ করে, যা EAP-TLS এর ভিত্তি তৈরি করে এমন একই 802.1X এবং সার্টিফিকেট-ভিত্তিক পরিচয় কাঠামো ব্যবহার করে। এটি EAP-TLS কে শুধুমাত্র একটি নিরাপত্তা নিয়ন্ত্রণ হিসাবে নয়, বরং পরিবহন হাব, খুচরা এস্টেট এবং আতিথেয়তা ভেন্যু জুড়ে উন্নত সংযোগ পরিষেবার ভিত্তি হিসাবে স্থাপন করে।

নেটওয়ার্ক আর্কিটেক্টদের জন্য যারা SD-WAN এবং এন্টারপ্রাইজ WiFi নিরাপত্তা কীভাবে ছেদ করে তা মূল্যায়ন করছেন, আধুনিক ব্যবসার জন্য কোর SD-WAN সুবিধা সুরক্ষিত প্রমাণীকরণ কীভাবে আধুনিক WAN আর্কিটেকচারের সাথে একত্রিত হয় সে সম্পর্কে পরিপূরক প্রসঙ্গ সরবরাহ করে।

মূল শব্দ ও সংজ্ঞা

EAP-TLS (Extensible Authentication Protocol – Transport Layer Security)

An 802.1X authentication method defined in RFC 5216 that uses mutual X.509 certificate authentication between the client device and the RADIUS server. Neither side gains network access without presenting a valid, non-revoked certificate signed by a trusted Certificate Authority.

IT teams encounter EAP-TLS when evaluating 802.1X authentication methods for WPA2 Enterprise or WPA3 Enterprise deployments. It is the recommended method for regulated environments (PCI DSS, HIPAA, ISO 27001) and the required method for WPA3 Enterprise 192-bit (Suite B).

X.509 Certificate

A digital certificate standard (defined in ITU-T X.509 and RFC 5280) that binds a public key to an identity (device, server, or user). It contains the subject's identity, the public key, the issuing CA's digital signature, and validity dates. In EAP-TLS, both the RADIUS server and the client device present X.509 certificates during the authentication handshake.

IT teams encounter X.509 certificates when configuring RADIUS servers (server certificate), enrolling devices via MDM (client certificate), and managing PKI infrastructure. Certificate expiry and revocation are the primary operational concerns.

PKI (Public Key Infrastructure)

The combination of hardware, software, policies, and procedures required to create, manage, distribute, store, and revoke digital certificates. In an EAP-TLS deployment, the PKI consists of at minimum a root CA and an issuing CA, plus the CRL/OCSP infrastructure for revocation.

PKI is the foundational dependency for any EAP-TLS deployment. IT teams must design and operate a PKI before EAP-TLS can be deployed. Common PKI platforms include Microsoft AD CS, EJBCA, HashiCorp Vault PKI, and managed services such as AWS Private CA.

RADIUS (Remote Authentication Dial-In User Service)

A networking protocol (RFC 2865) providing centralised authentication, authorisation, and accounting (AAA) for network access. In 802.1X/EAP-TLS deployments, the RADIUS server validates client certificates, enforces network policy, and returns VLAN assignment attributes to the access point.

RADIUS is the authentication server component in every 802.1X deployment. Common implementations include Microsoft NPS, FreeRADIUS, Cisco ISE, and Aruba ClearPass. The RADIUS server must be configured to trust the internal CA and perform certificate revocation checks.

Mutual Authentication

An authentication process in which both communicating parties verify each other's identity before establishing a connection. In EAP-TLS, the client validates the RADIUS server's certificate (protecting against rogue APs) and the RADIUS server validates the client's certificate (protecting against unauthorised device access).

Mutual authentication is the key differentiator of EAP-TLS over PEAP and EAP-TTLS. IT teams should emphasise mutual authentication when justifying EAP-TLS to security auditors and compliance teams, as it directly addresses the rogue AP and credential theft threat vectors.

SCEP (Simple Certificate Enrollment Protocol)

A protocol (originally defined by Cisco, standardised in RFC 8894) that enables automated certificate requests and issuance between a client device and a Certificate Authority. In EAP-TLS deployments, SCEP is used by MDM platforms to automatically provision client certificates to managed devices without user intervention.

SCEP is the standard mechanism for zero-touch certificate provisioning in enterprise MDM environments. IT teams configure SCEP profiles in Intune, Jamf, or Workspace ONE to automate client certificate deployment and renewal.

CRL (Certificate Revocation List)

A periodically published list of certificate serial numbers that have been revoked by the issuing CA before their expiry date. RADIUS servers check the CRL to ensure a client certificate presented during EAP-TLS authentication has not been revoked (e.g., due to device theft or employee departure).

CRL management is a critical operational consideration in EAP-TLS deployments. IT teams must ensure the CRL distribution point is accessible from RADIUS servers, that CRLs are published frequently enough to reflect recent revocations, and that RADIUS servers are configured to reject authentication if the CRL cannot be retrieved.

OCSP (Online Certificate Status Protocol)

A real-time certificate revocation checking protocol (RFC 6960) that allows a RADIUS server to query the CA's OCSP responder for the current status of a specific certificate, rather than downloading and parsing a full CRL. OCSP provides lower latency and more current revocation information than CRL-based checking.

IT teams should prefer OCSP over CRL for high-security environments where real-time revocation is important (e.g., immediately revoking a certificate when a device is reported stolen). OCSP stapling, where the RADIUS server caches and presents the OCSP response, reduces latency and eliminates dependency on the OCSP responder being reachable during every authentication.

802.1X (Port-Based Network Access Control)

An IEEE standard that provides an authentication framework for devices attempting to connect to a LAN or WLAN. It defines three roles: supplicant (the connecting device), authenticator (the access point or switch), and authentication server (RADIUS). EAP-TLS is one of several EAP methods that can be used within the 802.1X framework.

802.1X is the overarching framework within which EAP-TLS operates. IT teams encounter 802.1X when configuring WPA2 Enterprise or WPA3 Enterprise SSIDs, and when configuring wired port authentication on managed switches. Understanding 802.1X is a prerequisite for deploying EAP-TLS.

Perfect Forward Secrecy (PFS)

A cryptographic property of key exchange protocols that ensures session keys cannot be derived from the long-term private key. In EAP-TLS with ECDHE cipher suites, each session generates a unique ephemeral key pair, meaning that compromise of the certificate's private key does not expose historical session traffic.

IT teams should specify ECDHE-based cipher suites when configuring EAP-TLS to ensure PFS. This is particularly important in environments where network traffic is recorded and could be subject to future decryption attempts (a 'harvest now, decrypt later' attack scenario).

কেস স্টাডিজ

A 450-room hotel group with 12 properties needs to migrate its staff WiFi from PEAP-MSCHAPv2 to EAP-TLS. The group runs Windows 10/11 laptops managed via Microsoft Intune, plus approximately 200 Android tablets used by housekeeping staff. The IT team has no existing internal PKI. What is the recommended deployment approach?

Step 1 — PKI Deployment (Weeks 1–3): Deploy Microsoft AD CS with a two-tier hierarchy. Stand up an offline root CA on a dedicated server that will be powered down after initial setup. Deploy an online issuing CA (intermediate CA) on a Windows Server VM. Configure the issuing CA to publish CRLs to an internal web server accessible from all RADIUS servers across the 12 properties. Enable the OCSP responder role on the issuing CA server.

Step 2 — RADIUS Infrastructure (Weeks 2–4): Deploy Microsoft NPS (Network Policy Server) at each property, or centralise with NPS proxy servers at each site pointing to a central NPS cluster. Issue a RADIUS server certificate from the internal CA to each NPS instance. Configure NPS network policy: authentication method = EAP-TLS, trusted root CA = internal root CA, certificate validation = enabled, VLAN assignment via RADIUS attributes.

Step 3 — Intune Certificate Profiles (Weeks 3–5): In Microsoft Intune, create a Trusted Certificate profile to push the root CA certificate to all managed devices. Create a SCEP Certificate profile targeting the issuing CA, with subject name format CN={{DeviceId}}, key usage = Digital Signature, extended key usage = Client Authentication. Create a WiFi profile specifying EAP-TLS, the SCEP certificate profile as the client certificate, and the root CA as the trusted server certificate authority.

Step 4 — Android Tablet Enrolment (Weeks 4–6): Enrol Android tablets into Intune via Android Enterprise (Dedicated Device mode). Deploy equivalent Trusted Certificate, SCEP Certificate, and WiFi configuration profiles. Verify certificate installation on a pilot group of 10 tablets before full rollout.

Step 5 — Pilot and Cutover (Weeks 6–8): Run EAP-TLS in parallel with PEAP on a separate SSID at one pilot property. Validate authentication success rates, VLAN assignment, and certificate renewal behaviour. Roll out property by property. Decommission PEAP SSID after 30-day parallel run at each site.

বাস্তবায়ন সংক্রান্ত নোট: This approach is optimal because it leverages the existing Microsoft ecosystem (Intune + AD CS + NPS) to minimise new tooling. The two-tier PKI with an offline root CA is the industry-standard pattern — the root CA's private key is never exposed to network-connected systems. The parallel SSID approach during cutover is critical for hospitality environments where a failed authentication event during peak occupancy has direct revenue impact. The 30-day parallel run ensures certificate renewal cycles are validated before the legacy SSID is removed. An alternative approach using a managed PKI service (e.g., AWS Private CA) would reduce operational overhead but introduces cloud dependency for a core authentication function — acceptable for cloud-native organisations but a risk consideration for properties with unreliable WAN connectivity.

A national retail chain with 280 stores needs to secure its point-of-sale WiFi network to meet PCI DSS 4.0 requirements. Each store has 8–15 Windows-based POS terminals, a mix of managed and unmanaged devices, and a single IT administrator who manages all stores remotely. The chain currently uses a shared WPA2-PSK password across all stores. What is the migration path to EAP-TLS?

Assessment and Scoping: First, define the PCI DSS cardholder data environment (CDE) scope. POS terminals processing card data are in scope; staff break-room devices are not. Segment the network so that only POS terminals are on the EAP-TLS secured SSID. This limits the certificate deployment scope to a known, managed device population.

Centralised PKI and RADIUS: Deploy a cloud-hosted RADIUS service (e.g., Cisco ISE in the cloud, or JumpCloud RADIUS) to eliminate the need for on-premise RADIUS hardware at each store. This is critical for a distributed retail estate where local server management is not feasible. The cloud RADIUS service connects to the internal PKI via a secure tunnel.

MDM-Driven Certificate Deployment: All POS terminals must be enrolled in an MDM (Microsoft Intune or equivalent). Deploy the root CA trust anchor and SCEP certificate profile via MDM policy. The certificate subject should include the store number and terminal ID (e.g., CN=POS-STORE042-TERM003) to enable granular RADIUS policy and audit logging.

SSID Configuration: Configure a dedicated POS SSID at each store access point with WPA2 Enterprise / EAP-TLS. Use dynamic VLAN assignment to place authenticated POS terminals on the CDE VLAN. Implement a separate guest SSID on a completely isolated VLAN for customer WiFi.

Monitoring and Compliance Evidence: Configure RADIUS authentication logs to be forwarded to a central SIEM. Generate monthly reports showing authentication success rates, certificate validity status, and any revocation events. This log data constitutes audit evidence for PCI DSS Requirement 10 (logging and monitoring) and Requirement 8.6 (authentication management).

বাস্তবায়ন সংক্রান্ত নোট: The key insight here is using a cloud-hosted RADIUS service to avoid the operational burden of managing on-premise authentication infrastructure across 280 stores. For distributed retail, this is almost always the right architectural choice. The scoping decision — limiting EAP-TLS to POS terminals only — is pragmatic and correct from a PCI DSS perspective; applying EAP-TLS to every device in a store before the team has operational experience with the technology increases deployment risk. The certificate naming convention (store number + terminal ID) is a deliberate design choice that makes RADIUS policy management and incident investigation significantly easier. An alternative approach using certificate OID extensions to encode device attributes provides even richer policy control but adds PKI configuration complexity.

দৃশ্যপট বিশ্লেষণ

Q1. Your organisation runs a 600-bed hospital with 1,200 managed Windows laptops and 400 shared Android tablets used by nursing staff. The current WiFi uses PEAP-MSCHAPv2 with Active Directory credentials. A recent penetration test identified that none of the client devices validate the RADIUS server certificate, and the tester successfully performed a rogue AP attack capturing AD credentials. You have been asked to remediate this within 90 days. What is your prioritised remediation plan?

💡 ইঙ্গিত:Consider what can be fixed immediately (configuration change) versus what requires infrastructure work (PKI deployment). Not all remediation steps require EAP-TLS — some can be applied to the existing PEAP deployment while the longer-term migration is planned.

প্রস্তাবিত পদ্ধতি দেখুন

Immediate (Week 1–2): Fix server certificate validation on existing PEAP deployment. Push a GPO/Intune WiFi profile update to all managed Windows devices that specifies the trusted root CA and the RADIUS server's expected CN/SAN. This immediately closes the rogue AP vulnerability without requiring PKI changes. For Android tablets, push an updated MDM WiFi profile. This addresses the critical finding within days.

Short-term (Weeks 2–8): Deploy internal PKI. Stand up a two-tier AD CS PKI (offline root CA + online issuing CA). Issue a new RADIUS server certificate from the internal CA. Update the NPS configuration. Push the new root CA trust anchor to all devices via MDM.

Medium-term (Weeks 6–12): Migrate to EAP-TLS for managed devices. Configure SCEP profiles in Intune for Windows laptops. Deploy client certificate profiles. Create a new EAP-TLS SSID in parallel with the existing PEAP SSID. Pilot with 50 laptops, validate, then roll out in waves. Shared Android tablets are more complex — evaluate whether Android Enterprise Dedicated Device enrolment is feasible, or whether a certificate-based onboarding portal is more appropriate for shared-use devices.

Key consideration: HIPAA requires appropriate safeguards for wireless networks carrying ePHI. The rogue AP vulnerability is a reportable risk. Document the remediation timeline and interim controls for your compliance officer.

Q2. A conference centre is deploying a new WiFi infrastructure to support both a secure staff network (EAP-TLS) and a guest WiFi network. The venue hosts events for up to 5,000 attendees. The IT manager wants to use the same physical access point infrastructure for both networks. How should the network be architected to achieve this, and what are the key configuration decisions?

💡 ইঙ্গিত:Consider SSID segmentation, VLAN design, and the different authentication requirements for staff (certificate-based) versus guests (captive portal or social login). Think about how Purple's guest WiFi platform integrates with this architecture.

প্রস্তাবিত পদ্ধতি দেখুন

SSID and VLAN Design: Deploy two SSIDs on the same physical access point infrastructure. SSID 1 (Staff): WPA3 Enterprise / EAP-TLS, broadcasting on 5GHz and 6GHz bands, mapped to Staff VLAN (e.g., VLAN 10). SSID 2 (Guest): WPA3 Personal or Open with OWE (Opportunistic Wireless Encryption), mapped to Guest VLAN (e.g., VLAN 20). The Guest VLAN should have no access to the Staff VLAN or internal infrastructure — only internet access.

Staff Network: Configure RADIUS server with EAP-TLS policy. Issue client certificates to all staff devices via MDM. Use dynamic VLAN assignment to place authenticated staff devices on VLAN 10. Consider deploying a separate SSID for AV/event management equipment on VLAN 30 with EAP-TLS and a separate certificate policy.

Guest Network: Integrate with Purple's Guest WiFi platform for captive portal authentication, social login, or email capture. The guest network operates entirely independently of the EAP-TLS infrastructure. Purple's WiFi Analytics platform provides dwell time, footfall, and engagement data from the guest network.

Capacity Planning: For 5,000 concurrent guests, ensure the guest VLAN's DHCP scope, internet uplink, and access point density are sized appropriately. EAP-TLS authentication adds negligible overhead per-connection but RADIUS server capacity should be validated for peak event load.

Q3. A retail CTO is evaluating whether to deploy EAP-TLS for 350 stores or to continue with WPA2-PSK with a rotated shared key. The IT team is small (3 people) and has no PKI experience. The CTO's primary concern is PCI DSS compliance for the POS network. What is your recommendation, and how do you frame the business case?

💡 ইঙ্গিত:Consider the PCI DSS requirements, the operational capacity of a small IT team, and whether there are managed service options that reduce the PKI burden. The answer is not necessarily 'deploy full EAP-TLS immediately' — a phased or managed approach may be more appropriate.

প্রস্তাবিত পদ্ধতি দেখুন

Recommendation: EAP-TLS via a managed RADIUS and PKI service, phased over 6 months.

WPA2-PSK is not acceptable for a PCI DSS cardholder data environment. PCI DSS Requirement 8 mandates individual authentication for system components, and a shared PSK does not satisfy this. A breach of the PSK exposes all 350 stores simultaneously. The risk is not theoretical — POS network breaches via compromised WiFi credentials are a documented attack vector in retail.

Managed Service Approach: Rather than building internal PKI expertise, engage a managed RADIUS and PKI provider (e.g., Foxpass, JumpCloud, or SecureW2). These services provide a hosted RADIUS server, a managed CA, and MDM integration out of the box. The IT team configures MDM certificate profiles and access point RADIUS settings — no PKI expertise required. Cost is typically $3–8 per device per month, which is trivial against the cost of a PCI DSS breach.

Business Case: Frame the investment against three cost categories: (1) PCI DSS non-compliance fines and forensic investigation costs following a breach — typically £50k–£500k for a mid-size retailer; (2) card scheme penalties for a cardholder data breach — potentially millions; (3) reputational damage and customer churn. The managed service cost for 350 stores with 15 POS terminals each (5,250 devices) at $5/device/month is approximately $26,250/month — less than the daily cost of a breach investigation.