芬蘭電子化政府服務採用行動數位簽章
由芬蘭第二大行動電話網路公司 Elisa 所推出的第一批載有行動簽章 (mobile signature) 所需之安全憑證的行動電話 SIM 卡正式問世，此種 SIM 卡是以國際高科技集團捷德公司 (Giesecke & Devrient, G&D) 的 UniverSIM 產品為基礎所研發，卡片上載有一張類似我國自然人憑證的公民憑證 (citizen certificate) ，具有簽章功能與加密機制。此種技術屬於行動安全建置 (mobile security architecture) －也就是公開金鑰基礎建設 (PKI) －的一部份，能夠確保身分辨識所需具備的安全性與獨特性。
想要利用這項透過行動電話之數位簽章享受政府服務的民眾 可以在當地警察局登記， 預計在 ２００５ 年底前，芬蘭的 OKO 銀行、社會保險機構、稅務機關以及勞工局等都會利用這個新的行動公民憑證 (mobile citizen certificate) 來提供服務，這將會使芬蘭人民擁有一個全國性數位服務的電子身分證。此舉也使得芬蘭在行動通訊與電子化政府領域的領先地位更形穩固。
歐盟執委會於7月13日正式提案，會員國得在各自領土範圍內決定准許、限制或全面禁止基因改造作物的栽種。執委會的提案內容包括對於基因改造作物與非基因改造作物的共存（在同一區域內栽種）管制建議，同時也提出修正條文草案建議供各國於修正各國內有關基因改造作物相關法律的參考。執委會的提案修正了歐盟2001/18/EC指令（Directive 2001/18/EC）使得各會員國可因地制宜考量，自行決定基因改造作物的允許栽種與否。 執委會的提案源自今年三月時對會員國的承諾。歐盟健康與消費政策委員會的主席表示，執委會此提案兌現了當時要在今年夏天結束歐盟各國對基因改造作物的爭議的承諾，此同時他也強調歐盟現行以科學為基礎的授權機制並非完全廢除，全面性的安全評估與監控系統仍繼續運作，這也是歐盟對基因改造作物耕種給予各國彈性措施的同時對安全基本把關的表現。 歐盟原有的規定訂有基因改造作物與非基因改造作物0.9％共存門檻（labellingthreshold，指由受驗作物全部基因中所含改造基因的比例判斷是否為基因改造作物的標準），各會員國必須立法採行有關措施（如作物田的間距）以符合該項要求。 但過去幾年的運作經驗發現，耕作非基因改造作物農民的潛在損失並不限於因為所產作物超過該門檻，某些案例中，基因改造有機物殘存於食品中，反而使得想要將食品以不含基因改造有機物產品販賣者造成損失。執委會新的建議案給予各國調整該共存門檻的權力，同時，各國也可以成立非基因改造專區等。2001/18/EC指令的修正條文（第26b條）將適用於所有的基因改造有機物，各國得自行決定限制或禁止其境內的基因改造作物耕種，無須執委會的授權，但須在境內措施施行一個月內通知歐盟各國及執委會。執委會的提案將在歐洲議會及歐洲理事會通過後正式施行。 對於此一即將於歐盟施行的新基因改造作物耕種規範，生技產業顯然有不同意見，依照生技業者協會EuropaBio的聲明，他們認為新規範充滿對新科學的偏見且阻礙農民的自由選擇權。基於產業的觀點，新的規範架構也有疑慮，例如：0.9％的門檻下放各國自行決定調整，往後將引起權責機關以及農民、買家、以及有關產業製造商之間的爭議；新措施也造成對歐盟內部市場的壁壘—造成歐盟境內國家的或區域的限制林立，而與歐盟的基本原則相悖；最後，對於科學的偏見與歐洲食品安全局（EFSA）的聲譽之影響也是一大隱憂。 歐盟對基因改造作物的立場一直尚未定調，新規範亦僅只是採取「下放」給各國自行決定的作法，惟實際上的運作，綜合當前對基因改造作物之安全性充滿疑慮與爭議的氛圍下，各國未來自行訂定規範將更寬或更嚴，後續發展如何有待密切觀察。
美國猶他州訂定「應用程式商店問責法」保障未成年人用戶之安全網路環境美國猶他州州長於2025年3月26日正式簽署「應用程式商店問責法（App Store Accountability Act）」（下稱本法）並於同年5月7日生效，為全美首部強制應用程式商店實施年齡驗證及家長同意機制的州法，其核心目標為強化對未成年人的網路環境保護。 本法要求應用程式商店供應商（下稱供應商）於用戶創建帳戶時驗證用戶年齡，若確認為未成年人，其帳戶必須與經過驗證的「家長帳戶」相關聯，未成年人下載或購買應用程式前，供應商須自家長處獲得「可驗證的同意」，且為確保該同意基於充分知情，供應商須向家長提出詳細聲明揭露該應用程式之年齡分級、內容描述、個資之收集與共享情況，以及開發者保護用戶資料之措施等內容，且於前述內容發生重大變更時通知家長並重新取得同意。 應用程式開發者（下稱開發者）亦須向供應商提供準確的資訊，並於應用程式發生「重大變更」時及時通知供應商，及透過數據共享機制驗證其猶他州用戶的年齡以及未成年用戶的家長同意狀態。若開發者善意信賴供應商所提供的年齡及同意資訊行事，可豁免承擔違規責任（安全港機制），爰本法主要的問責對象為供應商。 前述核心義務將於2026年5月6日起生效，若供應商或開發者提供不實資訊，將構成欺騙性交易行為而受到追訴；且自2026年12月31日起，若未成年人因供應商或開發者違反本法規定而受到損害，其本人或家長將有權提起民事訴訟請求賠償。
歐盟執委會公布「數位金融包裹」法案為鼓勵金融產業之創新，同時使其遵循應有之責任，並讓歐盟金融消費者與商業機構享有更多之利益，歐盟執委會於2020年10月24日提出數位金融包裹法案（Digital Finance Package），並提出以下2項數位金融立法提案： 一、加密資產立法提案（Proposal for Markets in Crypto-assets） 為促進金融創新並同時保有金融穩定性與保護投資人，歐盟執委會提出加密資產管制框架立法提案，並將加密資產分為已受監管與未受監管兩類，前者將持續依據既有規範進行管理。而針對尚未管制之加密資產，該提案針對加密資產發行人與加密資產服務供應商建立嚴格限制，要求取得核准後始可提供服務。具體而言之，立法提案包含以下項目： （一）針對加密資產、加密資產發行人等金融商品名詞進行定義。並建立加密資產服務供應商與發行人營運上、組織架構與資產發行程序之透明度與揭露制度。 （二）針對向公開市場提供加密資產進行管制，例如，依據提案第4條，供應商應為法人，第5條則要求供應商應製作加密資產白皮書，並將其提供給主管機關後始可於公開市場提供相關服務。 （三）針對代幣資產發行人以及其加密資產之審核程序，依據提案第15條，代幣發行者必須為歐盟境內之法律實體。另外，該法要求加密資產發行人應誠實、公平且專業，並完成加密資產白皮書之出版與制定市場溝通規則。 （四）針對加密資產之收購，該法第4章亦設有相關規範，於第37條及38條規定收購之評估機制。 （五）針對加密資產服務供應商之授權與營運條件，該法第5章規定歐盟證券及市場管理局應建立加密資產服務供應商之登記制度。 （六）針對市場秩序維護之部分，該法於第6章規範相關預防市場濫用之禁止事項與要求，並於第7章賦予歐盟成員國各主管機關相關權力，例如第94條之監督與懲處權限。 二、歐盟數位營運韌性管制框架立法提案（Proposal for Digital Operational Resilience） 數位化總伴隨資安風險，歐盟執委會於包裹法案內亦提出歐盟數位營運韌性管制框架立法提案，以確保相關企業可應對所有與通訊技術有關之干擾與威脅，另外，銀行、證券交易所、票據交換所以及金融科技公司將需遵循嚴格之標準以預防並降低ICT資安事件所產生之衝擊，另外亦將針對金融機構雲端運算服務供應商進行監管。具體規範包含： （一）ICT風險管理要求：該立法提案參照相關國際標準，於第5至第14條制訂相關ICT風險管理要求，惟未要求應遵循具體國際標準。 （二）ICT相關事件報告：該提案於第15至20條規範相關報告義務，將整合歐盟金融機構之ICT相關事件報告與監測程序。 （三）數位運作韌性測試：該提案於第21至第24條要求ICT風險管理框架應定期進行測試，惟具體方法可依據組織之規模、風險側寫與商務模式進行調整。 （四）第三方單位風險：該提案於第25至39條規範組織應對ICT第三方供應商風險進行監測，例如，第25條要求金融機構委外執行業務仍應隨時遵循所有金融服務規範，另外，ICT風險管理框架之內容亦應包含第三方ICT風險之監督策略。
美國國家安全局發布「軟體記憶體安全須知」美國國家安全局（National Security Agency, NSA）於2022年11月10日發布「軟體記憶體安全須知」（“Software Memory Safety” Cybersecurity Information Sheet），說明目前近70%之漏洞係因記憶體安全問題所致，為協助開發者預防記憶體安全問題與提升安全性，NSA提出具體建議如下： 1.使用可保障記憶體安全之程式語言（Memory safe languages）：建議使用C#、Go、Java、Ruby、Rust與Swift等可自動管理記憶體之程式語言，以取代C與C++等無法保障記憶體安全之程式語言。 2.進行安全測試強化應用程式安全：建議使用靜態（Static Application Security Testing, SAST）與動態（Dynamic Application Security Testing, DAST）安全測試等多種工具，增加發現記憶體使用與記憶體流失等問題的機會。 3.強化弱點攻擊防護措施（Anti-exploitation features）：重視編譯（Compilation）與執行（Execution）之環境，以及利用控制流程防護（Control Flow Guard, CFG）、位址空間組態隨機載入（Address space layout randomization, ASLR）與資料執行防護（Data Execution Prevention, DEP）等措施均有助於降低漏洞被利用的機率。 搭配多種積極措施增加安全性：縱使使用可保障記憶體安全之程式語言，亦無法完全避免風險，因此建議再搭配編譯器選項（Compiler option）、工具分析及作業系統配置等措施增加安全性。