به منظور جلوگیری از حملات مرد میانی، سیستم اعتبار گواهی سرور مقصد را با بررسی زنجیره گواهی، تاریخ انقضا، وضعیت ابطال (از طریق CRL یا OCSP) و تطابق نام دامنه (Subject Alternative Name) تأیید می‌کند. در صورت عدم تطابق، اتصال قطع شده و رویداد در لاگ ثبت می‌شود. خطای اعتبارسنجی قابل چشم‌پوشی نیست.
به منظور تأمین اصالت سرور، گواهی TLS سرور از یک مرجع گواهی عمومی (CA) معتبر و با اعتبار حداقل یک ساله صادر شده است. اعتبار گواهی به صورت روزانه از طریق پروتکل OCSP (Online Certificate Status Protocol) بررسی می‌شود و در صورت ابطال یا انقضا، اتصالات جدید تا زمان تعویض گواهی مسدود می‌شوند. پینینگ گواهی (Certificate Pinning) برای اپلیکیشن‌های موبایل و کلاینت‌های خاص فعال است.
به منظور امنیت اتصالات خروجی، سیستم در نقش کلاینت (هنگام اتصال به سرویس‌های خارجی) نیز تنها از TLS 1.3 استفاده کرده و از رمزنگاری‌های قوی (AES-256-GCM) پشتیبانی می‌کند. عدم پشتیبانی سرور مقصد از TLS 1.3 منجر به عدم برقراری اتصال می‌شود (بدون فالبک به نسخه‌های ضعیف‌تر). گواهی سرور مقصد قبل از ارسال هرگونه داده بررسی می‌شود.
به منظور احراز هویت کلاینت در ارتباطات حساس، در صورت نیاز (مثلاً در اتصال به API بانکی)، سیستم از گواهی کلاینت با کلید RSA ۳۰۷۲ بیتی و امضای SHA-512 استفاده می‌کند. گواهی کلاینت در یک حافظه امن (Trusted Platform Module) ذخیره شده و هرگز در معرض دسترسی فرآیندهای دیگر قرار نمی‌گیرد.
به منظور جلوگیری از شنود و دستکاری داده‌ها در شبکه، ارتباطات بین کاربر و سیستم (و همچنین بین مؤلفه‌های داخلی) منحصراً از طریق مسیرهای امن (TLS 1.3 با رمزگذاری قوی و احراز هویت دوطرفه) برقرار می‌شود. استفاده از پروتکل‌های ناامن (HTTP، FTP، Telnet) در محیط تولید به طور کامل ممنوع شده و هرگونه تلاش برای برقراری ارتباط ناامن در لایه فایروال مسدود می‌گردد.
به منظور حفاظت از داده‌های احراز هویت در حین انتقال، سیستم تضمین می‌کند که تمام داده‌های احراز هویت، توکن‌های نشست و اطلاعات حساس کاربران تنها از طریق مسیر امن منتقل شوند. کوکی‌های احراز هویت دارای پرچم Secure و HttpOnly هستند و از ارسال آن‌ها از طریق اتصالات غیر TLS جلوگیری می‌شود. همچنین، سیاست HSTS (HTTP Strict Transport Security) با مدت اعتبار حداقل یک سال اعمال شده است.
به منظور تأمین اصالت و یکپارچگی مسیر ارتباطی، سیستم از گواهی‌های دیجیتال صادرشده از مراجع معتبر (CA) و پینینگ گواهی (Certificate Pinning) برای برنامه‌های موبایل استفاده می‌کند. سیستم به صورت دوره‌ای گواهی‌ها را بررسی کرده و در صورت نزدیک شدن به تاریخ انقضا، هشدار صادر می‌کند. هرگونه عدم تطابق گواهی منجر به قطع فوری اتصال می‌شود.
به منظور تأمین امنیت ارتباطات وب، تمامی ارتباطات HTTP به HTTPS هدایت شده و وب‌سرور به گونه‌ای پیکربندی شده است که تنها از TLS 1.3 پشتیبانی می‌کند. نسخه‌های قدیمی (SSLv2، SSLv3، TLS 1.0 و TLS 1.1) به طور کامل غیرفعال شده‌اند. لیست رمزنگاری‌ها (Cipher Suites) شامل TLS_AES_256_GCM_SHA384 و TLS_AES_128_GCM_SHA256 (به ترتیب اولویت) می‌باشد.
به منظور جلوگیری از حملات پروتکل داون‌گرید و تزریق محتوا، هدرهای امنیتی زیر به تمام پاسخ‌های HTTPS اضافه شده‌اند: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload، Content-Security-Policy: default-src 'self' و X-Content-Type-Options: nosniff. این تنظیمات از حملات پروتکل داون‌گرید، تزریق محتوا و تفسیر اشتباه نوع MIME جلوگیری می‌کنند.
به منظور جلوگیری از دستکاری سوابق دسترسی، دسترسی به این سوابق تنها به نقش «بازبین امنیت» محدود شده و این دسترسی نیز از طریق یک پورتال جداگانه و با احراز هویت دو مرحله‌ای انجام می‌پذیرد. سوابق دسترسی به صورت فقط خواندنی (Append-Only) ذخیره شده و هیچ کاربری (حتی مدیر امنیت) نمی‌تواند آن‌ها را حذف یا تغییر دهد. امضای دیجیتال بر روی هر درج جدید، یکپارچگی را تضمین می‌کند.
به منظور محافظت از سوابق دسترسی در برابر دسترسی غیرمجاز یا تخریب، این سوابق به صورت رمزنگاری‌شده در یک حافظه‌گاه خارج از دایرکتوری وب نگهداری می‌شوند. در صورت بروز خطا در ذخیره‌سازی لاگ دسترسی، سیستم بلافاصله به حالت «شکست امن» رفته و از ادامه عملیات حساس جلوگیری می‌کند. همچنین، نسخه پشتیبان از سوابق به صورت روزانه و رمزنگاری‌شده به یک مرکز داده مجزا ارسال می‌شود.
برای جلوگیری از ایجاد نشست‌های جعلی یا دور زدن مراحل احراز هویت، فرآیند برقراری نشست جدید به طی کامل مراحل امنیتی مشروط شده است. این مراحل عبارتند از: ۱) احراز هویت موفق (با روش مجاز)، ۲) تأیید عدم وجود نشست قبلی نامعتبر، ۳) بررسی عدم وجود پرچم‌های مسدودیت (مثل IP تحریم شده)، و ۴) رضایت کاربر به شرایط استفاده (در صورت لزوم). تنها پس از این مراحل، یک شناسه نشست جدید و معتبر صادر می‌شود. هر درخواست نشست که این مراحل را کامل نکرده باشد، با خطای HTTP 403 مواجه می‌شود. این کنترل از ایجاد نشست‌های دغل (Session Spoofing) جلوگیری می‌کند.
برای محافظت از سیستم در برابر دسترسی غیرمجاز در صورت رها شدن ایستگاه کاری توسط کاربر، نشست‌های کاربری پس از ۱۵ دقیقه بی‌فعالیتی (بدون هیچ درخواستی) به طور خودکار از سمت سرور خاتمه می‌یابند. پیش از پایان، یک اخطار در صفحه نمایش داده می‌شود (در دقیقه ۱۴). پس از خاتمه، هرگونه درخواست بعدی کاربر را به صفحه ورود هدایت می‌کند. همچنین، برای محیط‌های پرخطر (مانند ترمینال عمومی)، این زمان به ۵ دقیقه کاهش یافته است. این ویژگی از سوءاستفاده از نشست در دستگاه‌های اشتراکی جلوگیری می‌کند.
به منظور توانمندسازی کاربر در کنترل نشست خود، سیستم به کاربران این امکان را داده است که به صورت صریح و از طریق دکمه «خروج» (Logout) نشست خود را خاتمه دهند. این خاتمه بلافاصله باعث نامعتبر شدن توکن نشست در سمت سرور شده و تمام داده‌های مرتبط با نشست در سمت کلاینت (مانند کوکی‌ها و ذخیره‌سازی محلی) پاک می‌گردد. همچنین، هرگونه درخواست با نشست خاتمه‌یافته با خطای احراز هویت مواجه می‌شود.
به منظور ایجاد زنجیره ممیزی کامل، سیستم به طور خودکار تمام تلاش‌های موفق و ناموفق برای دسترسی به محصول (شامل ورود، خروج، تلاش برای دسترسی به منابع محافظت‌شده و تغییر رمز عبور) را در یک لاگ امنیتی ثبت می‌کند. این سوابق شامل زمان دقیق (با مرجع زمانی NTP)، شناسه کاربر، آی‌پی مبدأ، نوع رویداد و نتیجه آن است. سوابق دسترسی به مدت حداقل یک سال نگهداری می‌شوند.
به منظور اطمینان از اصالت و یکپارچگی به‌روزرسانی‌ها، بسته‌های به‌روزرسانی نرم‌افزار تنها پس از تأیید صحت و یکپارچگی با استفاده از امضای دیجیتال (رمزنگاری نامتقارن) نصب می‌شوند. منبع بروزرسانی (سرور رسمی) با گواهی معتبر احراز هویت شده و فرآیند بروزرسانی در یک محیط ایزوله انجام می‌شود. در صورت شکست در تأیید امضا، به‌روزرسانی متوقف و هشدار صادر می‌گردد.
به منظور حفظ پایداری و قابلیت بازگشت در صورت بروز مشکل، سیستم توانایی بازگشت به نسخه قبلی (Rollback) را دارد. تمام پیکربندی‌های امنیتی و داده‌های کاربری پیش از به‌روزرسانی به صورت خودکار پشتیبان گرفته شده و در صورت نیاز، بازیابی با حفظ یکپارچگی امکان‌پذیر است. لاگ کامل از فرآیند به‌روزرسانی و هرگونه تلاش ناموفق نگهداری می‌شود.
به منظور تضمین در دسترس بودن سرویس‌های امنیتی، سیستم به گونه‌ای طراحی شده است که در صورت از کار افتادن یک مؤلفه (مانند یک نسخه از پایگاه داده یا وب‌سرور)، بدون قطع خدمت به کار خود ادامه دهد. این قابلیت با استفاده از خوشه‌بندی (Clustering)، تعادل بار (Load Balancing) و تکرار داده‌ها (Replication) پیاده‌سازی شده است. سقف تحمل خطا: حداقل تحمل از کار افتادن یک گره در هر سرویس بدون تأثیر بر عملکرد امنیتی.
برای جلوگیری از اشتراک حساب و حملاتی که از چند نشست همزمان سوءاستفاده می‌کنند، سیستم تعداد نشست‌های همزمان هر کاربر را کنترل می‌کند. برای کاربران عادی حداکثر ۲ نشست همزمان (مثلاً روی گوشی و لپ‌تاپ) مجاز است. برای نقش‌های حساس (مدیر) حداکثر ۱ نشست. در صورت تلاش برای ایجاد نشست اضافه، قدیمی‌ترین نشست (بر اساس آخرین فعالیت) به طور خودکار خاتمه می‌یابد (LIFO یا FIFO بسته به سیاست). همچنین، کاربر می‌تواند تمام نشست‌های فعال خود را از طریق صفحه کاربری مشاهده و خاتمه دهد. این کنترل امنیت حساب را به طور قابل ملاحظه‌ای افزایش می‌دهد.
به منظور جلوگیری از نقض امنیتی ناشی از خطای سیستمی، در صورت بروز خطای بحرانی (مانند خرابی مؤلفه رمزنگاری یا پر شدن دیسک لاگ)، سیستم به حالت «شکست امن» (Fail-Safe) وارد می‌شود. در این حالت، تمام عملیات حساس متوقف شده، نشست‌های فعال خاتمه می‌یابند و تنها مدیر امنیت مجاز به انجام عملیات بازیابی است. این ویژگی تضمین می‌کند که هیچ نقض امنیتی ناشی از خطای سیستمی رخ ندهد.